Hi policy sig members,
I submitted revised version of:
“prop-111: Request-based expansion of IPv6 default allocation size"
At the last policy sig discussion, I got concern about address allocation
without any constraint, and some criteria should be added to expand the
block size.
In this revised proposal, I added the requirement to demonstrate need
for both initial and subsequent allocations to reflect such opinions.
For initial allocation:
> The organizations
> can receive up to /29 by providing utilization information of the whole
> address space.
For subsequent allocation:
> 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.
I would appreciate your opinion of my proposal.
Yours Sincerely,
--
Tomohiro Fujisaki
From: Masato Yamanishi <[email protected]>
Subject: [sig-policy] New version of prop-111: Request-based expansion of IPv6
default allocation size
Date: Thu, 31 Jul 2014 11:42:21 -0700
| 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-guidelin
| es/ipv6-guidelines
|
| [3] Packet Filter and Route Filter Recommendation for IPv6 at xSP routers
| https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendat
| ions.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
