[arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation - Last Call (text revised)
The ARIN Advisory Council (AC) met on 8 October 2010 and decided to
send the following draft policy to last call:
Draft Policy 2010-12: IPv6 Subsequent Allocation
The AC made the following revisions to the text:
- /24 was added as the maximum prefix size.
- Allocations will be from a designated block.
- Requests for transition space will not be exempt from returns.
Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2010-12
will expire on 27 October 2010. After last call the AC will conduct
their last call review.
The draft policy text is below and available at:
The ARIN Policy Development Process is available at:
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Draft Policy 2010-12
IPv6 Subsequent Allocation
Version/Date: 13 October 2010
Modify 18.104.22.168 Subsequent allocation criteria. Add the following:
Subsequent allocations will also be considered for deployments that
cannot be accommodated by, nor were accounted for, under the initial
allocation. Justification for the subsequent subnet size will be based
on the plan and technology provided with a /24 being the maximum allowed
for a transition technology. Justification for these allocations will be
reviewed every 3 years and reclaimed if it is not in use. All such
allocations for transitional technology will be made from a block
designated for this purpose.
Current organizations cannot get an allocation for a IPv6 transitional
technology if they have already received their initial allocation of
IPv6. The reason they cannot get an additional IPV6 allocation is
because they don't meet the HD ratio for a subsequent allocation and
they don't want to use their initial assignment because it is
insufficient, mapped out for other long term plans, or already has
portions in use.
An alternative proposal to permit more allocations was submitted that
supported 6rd but since then community members have come forward with
concern that this should support not just one particular technology but
any that enable v6 deployment.
Justification Example: Below is an example of how the details for a
technology and its subnet requirements could be provided as
justification. This example is based of 6rd.
6rd is intended to be an incremental method for deploying IPv6 and
bridge the gap for End Users to the IPv6 Internet. The method provides a
native dual-stack service to a subscriber site by leveraging existing
infrastructure. If an entity already has a /32 of IPv6 they can not use
the same /32 for native IPv6 as they do for the 6rd routing and a
separate minimum size of a /32 is required while a larger subnet like a
/28 may be needed based on a non-contiguous IPv4 addressing plan.
The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
IPv4 address and must be short enough so that a /56 or /60 can be given
to subscribers. This example shows how the 6rd prefix is created based
on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first
octet (10) is excluded from the encoding) 6rd CE router IPv4 address:
10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
This example shows how the 6rd prefix is created based on a /28 IPv6
prefix using one of several non-contiguous global address ranges:
SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude
common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4
address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
Timetable for implementation: Immediate