I'm Policy WG Chair of JP Open Policy Forum, Toshio Tachibana. We had an opinion collection meeting with our community in Japan, and would like to share our input.
--------------------------------------------------------------------------- [prop-111] Request-based expansion of IPv6 default allocation size Support: - It is good to be able to receive allocation at once instead of making multiple applications which may be cumbersome --------------------------------------------------------------------------- Best regards, Toshio Tachibana On Fri, Feb 14, 2014 at 8:29 AM, Andy Linton <[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 this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Regards, > > Andy and Masato > > > ---------------------------------------------------------------------- > prop-111-v002 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). > > - 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 an initial IPv6 allocation up to a /29 (/32 - /29) by > request basis. > > > 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. For allocations > up to /29 no additional documentation is necessary. > > - 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 and providing > further documentation. > > > > 5. Explain the advantages of the proposal > ----------------------------------------- > - It is possible to utilize address blocks which is potentially > unused into the future. > - It will be possible for LIRs to control traffic easier. > - Organizations can design their IPv6 networks more flexibly. > > > 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 > ------------- > [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
