Re: [sig-policy] New version of prop-111 Request-based expansion of IPv6
I would like to see a proposal that looked to discuss and possibly
extend the list of justifications available for members when
requesting prefixes (such as Traffic Engineering).
I encourage the proposer of prop-111 to look at authoring such a
proposal for discussion by the community.
Regards
Dean Pemberton
Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
dean at internetnz dot net dot nz
To promote the Internet's benefits and uses, and protect its potential.
On Fri, Feb 14, 2014 at 12:29 PM, Andy Linton <asjl at lpnz dot org> 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
> fujisaki at syce dot net
>
>
> 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
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>