Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AFRINIC-rpd] Fwd: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size

Ernest ernest at afrinic.net
Wed Jan 29 07:53:28 UTC 2014


FYI,

A new policy proposal in the Asia Pacific region suggests a minimum
IPv6 allocation of up to a /29 (based on the fact that currently, an
allocated /32 is picked out of a reserved /29).

As this is the same IPv6 reservation practice at AFRINIC, you may
find this proposal interesting. (The proposal text follows below).

Regards,
Ernest.

> ----------------------------------------------------------------------
> prop-111-v001: Request-based expansion of IPv6 default allocation size
> ----------------------------------------------------------------------
> 
> Author:       Tomohiro Fujisaki
>               fujisaki at syce.net
> 
> 
> 1. Problem statement
> --------------------
> 
>    Currently, IPv6 minimum allocation size to LIRs is defined as /32 in
>    the "IPv6 address allocation and assignment policy", while APNIC
>    currently reserves up to /29 for each /32 allocation. It's better to
>    expand this minimum allocation size up to /29 since:
> 
>    - 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.
> 
>    - 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.
> 
>    - Before sparse allocation mechanism implemented in late 2008, /29
>      was reserved for all /32 holders by sequence allocation mechanism
>      in the early years. It is possible to use these reserved
>      blocks efficiently with this modification.
> 
> 
> 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.
> 
> 
> 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 will be possible for LIRs to control traffic easier.
>    - It is possible to use current reserved blocks efficiently.
> 
> 
> 6. Explain the disadvantages of the proposal
> --------------------------------------------
> 
>    Some people may argue this will lead to inefficient utilization of
>    IPv6 space. However, the space up to /29 is reserved by APNIC
>    secretariat for each /32 allocation.
> 
> 
> 7. Impact on resource holders
> -----------------------------
>    NIRs must implement this policy if it is implemented by APNIC.




More information about the RPD mailing list