Hi policy-sig ML colleagues, I've modified section 4 '4. Proposed policy solution' in prop-111-v003. The purpose of this modification is only to adjust proposed policy text to current policy text. There are no changes in the context of the proposal.
Yours Sincerely, -- Tomohiro Fujisaki From: Masato Yamanishi <[email protected]> Subject: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size Date: Wed, 17 Sep 2014 10:26:18 +1000 | Dear SIG members | | A new version of the proposal “prop-111: Request-based expansion of IPv6 | default allocation size has been sent to the Policy SIG for review. | | There are changes to section 4. Proposed policy solution only. | | Information about earlier versions is available from: | | http://www.apnic.net/policy/proposals/prop-111 | | You are encouraged to express your views on the proposal: | | - Do you support or oppose the proposal? | - Is there anything in the proposal that is not clear? | - What change could be made to this proposal to make it more effective? | | Please find the text of the proposal below. | | Kind Regards, | | Andy and Masato | | | | ---------------------------------------------------------------------- | prop-111-v004 Request-based expansion of IPv6 default allocation size | ---------------------------------------------------------------------- | | Author: Tomohiro Fujisaki | [email protected] | | | 1. Problem statement | -------------------- | | IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 | address allocation and assignment policy"[1]. It's better to | expand this minimum allocation size up to /29 (/32 - /29) since: | | - Before sparse allocation mechanism implemented in late 2006, /29 | was reserved for all /32 allocations by sequential allocation | method made from those old /23 blocks. These reserved blocks | might be kept unused in the future. | | - Sparse allocation mechanism was implemented in late 2006 with a | /12 allocation from the IANA. Under the sparse allocation | mechanism, there is no reservation size defined, and the space | between allocations continues to change, depending on the | remaining free pool available in APNIC. | | However, the "APNIC guidelines for IPv6 allocation and | assignment requests"[2] stated: | | "In accordance with APNIC's "IPv6 address allocation and | assignment policy", where possible, subsequent delegations to the | same resource holder are made from an adjacent address block by | growing the delegation into the free space remaining, unless | disaggregated ranges are requested for multiple discrete | networks." | | So, it is expected that allocation up to /29 is guaranteed for | consistency with allocations above. Based on the current | situation, contiguous allocation of /29 can still be accommodated | even under the sparse allocation mechanism (Current /32 | allocations from the /12 block can grow up to /24 at this stage). | | - After amended HD Ratio (0.94) and base calculation size (/56) was | introduced (prop-031 and prop-033), to obtain address blocks larger | than /32 and to request additional address blocks became harder | especially for small and middle size ISPs. | | - For traffic control purpose, some LIRs announce address blocks | longer than /32 (e.g. /35). However, some ISPs may set filters to | block address size longer than /32 since some filtering | guidelines recommend to filter longer prefix than /32([3][4]). If | LIRs have multiple /32, they can announce these blocks and its | reachability will be better than longer prefix. | | - 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. | | 2. Objective of policy change | ----------------------------- | | This proposal modifies the eligibility for an organization to | receive or extend an IPv6 address space up to a /29 (/32 -/29) by | explaining how the extended space up to /29 will be used. | | | 3. Situation in other regions | ----------------------------- | | RIPE-NCC: | The policy "Extension of IPv6 /32 to /29 on a per-allocation vs | per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get | up to /29 by default. | | | 4. Proposed policy solution | ---------------------------- | | - Change the text to "5.2.2 Minimum initial allocation size" of | current policy document as below: | | Organizations that meet the initial allocation criteria are | eligible to receive an initial allocation of /32. The organizations | can receive up to /29 by providing utilization information of the whole | address space. | | - Change /32 to /29 in "5.2.3 Larger initial allocations” | | Initial allocations larger than /29 may be justified if: | | - Add following text as 5.3.4 | | 5.3.4 Extend existing allocations to /29 | LIRs that hold one or more IPv6 allocations are able to request | extension of each of these allocations up to a /29 without meeting | the utilization rate for subsequent allocation by providing their network | plan to show how the whole address space will be used. | | | 5. Explain the advantages of the proposal | ----------------------------------------- | | - It is possible to utilize address blocks which is potentially | unused into the future. | | - Organizations can design their IPv6 networks more flexibly. | | - It will be possible for LIRs to control traffic easier. | | | 6. Explain the disadvantages of the proposal | -------------------------------------------- | | Some people may argue this will lead to inefficient utilization of | IPv6 space since LIRs can obtain huge address size unnecessarily. | However, this will not happen because larger address size needs | higher cost to maintain that address block. | | | 7. Impact on resource holders | ----------------------------- | | NIRs must implement this policy if it is implemented by APNIC. | | | 8. References (if required) | --------------------------- | | [1] IPv6 address allocation and assignment policy | http://www.apnic.net/policy/ipv6-address-policy | | [2] APNIC guidelines for IPv6 allocation and assignment requests | https://www.apnic.net/publications/media-library/documents/resource-guidelines/ipv6-guidelines | | [3] 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 * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
