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 <[email protected]> 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 <[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 | | * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
