Even the new version is still a relatively bad idea, IMHO. While I support allowing anyone who has a /29 reservation from the /23(s) allocated to the LIRs in the early days being able to simply ask for and receive that, I would much rather see the /12 space handed out in nibble aligned chunks to the extent practicable.
The claim of routing filters is not reflective of reality on the open internet where /48s are widely accepted and /35s are rarely (if ever) filtered. Owen On Jul 31, 2014, at 11:42 AM, Masato Yamanishi <[email protected]> wrote: > 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. > > 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 changes 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-v003 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. > > - Add following text in the policy document: > > for Existing IPv6 address space holders > > 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 explaining > 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
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
