On 26/01/2014, at 14:22, Andy Linton <[email protected]> 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 [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
