Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default
> 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.