Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default
Hi Mike,
Thank you for your comments, and I'm so sorry for replying so late.
| > The proposal "prop-111-v001: Request-based expansion of IPv6 default
| > allocation size" has been sent to the Policy SIG for review. It will be
| > presented at the Policy SIG at APNIC 37 in Petaling Jaya, Malaysia, on
| > Thursday, 27 February 2014.
|
| This policy reminds me of prop-090/098 and prop-099, all of which were previously abandoned.
The main difference between previous proposal and prop-111 will be to
utilize address space that already reserved and potentially unused.
| > - For traffic control purpose, some LIRs announce address blocks
| > longer than /32 (e.g. /35). However, some ISPs set filters to block
| > address size longer than /32. If LIRs have multiple /32, they can
| > announce these blocks and its reachability will be better than
| > longer prefix.
|
| Has there been research to support the view that prefixes longer than /32 are widely filtered? It would appear that there are a significant number of /48s announced today - http://bgp.potaroo.net/v6/as2.0/index.html. A handful of networks filtering ge /33 does not meaningfully limit the use of more specific announcements as a TE tool.
This is not real example, but there are some filtering practices
to filter longer prefix than /32.
> Packet Filter and Route Filter Recommendation for IPv6 at xSP routers
> https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendations.html
> [4] IPv6 BGP filter recommendations
> http://www.space.net/~gert/RIPE/ipv6-filters.html
I'm not sure how many LIRs using such kind of practice, and I do not
say it is good or not, but I've heard some sites (including my
organization) had applied this kind of filter in the past.
| > 2. Objective of policy change
| > -----------------------------
| >
| > This proposal modifies the eligibility for an organization to receive
| > an initial IPv6 allocation up to a /29 by request basis.
|
| The problem statement says that the minimum allocation should be increased to a /29. Are you proposing that the minimum size is increased, or that a /29 can be obtained with no further justification compared to a /32?
My intention is not to change minimum allocation size (it is still /32
in my proposal) but to allow LIRs to get a block (from /32 to /29)
if they meet the criteria for /32.
| > 5. Explain the advantages of the proposal
| > -----------------------------------------
| >
| > - It will be possible for LIRs to control traffic easier.
|
| I think I need to see some evidence that ge /33 is filtered on a large scale before I can support this policy on this basis.
In addition to above filtering practice, I'll check some looking
glasses to find real examples.
| > - It is possible to use current reserved blocks efficiently.
|
| It seems that the intention of the policy is that the remainder of the initial /29 reservations is “used at all”, rather than any specific “efficiency” gain is obtained. If a member has a /32 allocation out of a /29 reservation, but has no need for address space beyond a /32, how is it more efficient to automatically allocate this space?
As you pointed out, the word 'efficiently' was not proper here. I removed
that word in the revised text.
Yours Sincerely,
--
Tomohiro Fujisaki
past: Mike Jager <mike at mikej dot net dot nz>
Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size
Date: Sat, 1 Feb 2014 00:26:50 +1300
| On 26/01/2014, at 14:22, Andy Linton <asjl at lpnz dot org> wrote:
|
| > The proposal "prop-111-v001: Request-based expansion of IPv6 default
| > allocation size" has been sent to the Policy SIG for review. It will be
| > presented at the Policy SIG at APNIC 37 in Petaling Jaya, Malaysia, on
| > Thursday, 27 February 2014.
|
| This policy reminds me of prop-090/098 and prop-099, all of which were previously abandoned.
|
| > - For traffic control purpose, some LIRs announce address blocks
| > longer than /32 (e.g. /35). However, some ISPs set filters to block
| > address size longer than /32. If LIRs have multiple /32, they can
| > announce these blocks and its reachability will be better than
| > longer prefix.
|
| Has there been research to support the view that prefixes longer than /32 are widely filtered? It would appear that there are a significant number of /48s announced today - http://bgp.potaroo.net/v6/as2.0/index.html. A handful of networks filtering ge /33 does not meaningfully limit the use of more specific announcements as a TE tool.
|
| > - If an LIR needs address blocks larger than /32, LIRs may tend to
| > announce as a single prefix if a /29 is allocated initially at
| > once. i.e., total number of announced prefixes in case 1 may be
| > smaller than in case 2.
| >
| > case 1:
| > The LIR obtains /29 at the beginning of IPv6 network construction.
| >
| > case 2:
| > The LIR obtains /32, and /31, /30 additionally with the subsequent
| > allocation mechanism.
|
| It would be disappointing if networks that received a subsequent allocation contiguous with their existing allocation(s) announced this as a a separate prefix rather than aggregating it.
|
| In the days of v4, APNIC would reserve the address space next to an allocation for a member to receive within a certain time period if justified. I would expect that whatever behaviour members displayed in aggregation/non-aggregation of these v4 prefixes would be repeated when receiving contiguous v6 allocations. Perhaps the v4 behaviour could be investigated to determine the likelihood of aggregation of multiple v6 allocations.
|
| > 2. Objective of policy change
| > -----------------------------
| >
| > This proposal modifies the eligibility for an organization to receive
| > an initial IPv6 allocation up to a /29 by request basis.
|
| The problem statement says that the minimum allocation should be increased to a /29. Are you proposing that the minimum size is increased, or that a /29 can be obtained with no further justification compared to a /32?
|
| > 5. Explain the advantages of the proposal
| > -----------------------------------------
| >
| > - It will be possible for LIRs to control traffic easier.
|
| I think I need to see some evidence that ge /33 is filtered on a large scale before I can support this policy on this basis.
|
| > - It is possible to use current reserved blocks efficiently.
|
| It seems that the intention of the policy is that the remainder of the initial /29 reservations is “used at all”, rather than any specific “efficiency” gain is obtained. If a member has a /32 allocation out of a /29 reservation, but has no need for address space beyond a /32, how is it more efficient to automatically allocate this space?
|
| If this is to proceed, I agree with Owen that /28 makes more sense than /29. However, I’m not sure that this needs to happen at all.
|
| There still seems to be a belief that it is “hard” to receive an allocation larger than a /32, and that this places limitations on members’ addressing plans, particularly when performing sparse allocation within a member’s network. This is absolutely not the case. I have personally justified a /28 using a method very similar to Owen’s preferred addressing plan. It was far from difficult.
|
| Perhaps what is needed is not a policy change, but some education around the fact that a /32 is the *minimum* allocation (much like a /22 was the *minimum* IPv4 allocation), and that with some reasonable justification, a larger allocation is definitely obtainable.
|
| -Mike
| * sig-policy: APNIC SIG on resource management policy *
| _______________________________________________
| sig-policy mailing list
| sig-policy at lists dot apnic dot net
| http://mailman.apnic.net/mailman/listinfo/sig-policy
|
|