On 26/01/2014, at 14:22, Andy Linton asjl@lpnz.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.
- 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?
- 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