Draft Policy ARIN-2010-12: IPv6 Subsequent Allocation [Archived]
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.
Status: NRPM Section6.5.2.1
Tracking Information
Discussion Tracking
Mailing List:
Formal introduction on PPML on 20 July 2010
Origin - Policy Proposal 118
Draft Policy - 20 July 2010 (with staff assessment)
Last call - 13-27 October 2010
AC recommended adoption - 18 November 2010
Adopted and implmented - 12 January 2011
ARIN Public Policy Meeting:
ARIN Advisory Council:
AC Shepherds:
Marla Azinger and
Heather Schiller
- 15 July 2010
- 19 Aug 2010
- 16 Sep 2010
- 8 Oct 2010
- 27 Oct 2010
- 18 Nov 2010
- 16 Dec 2010
ARIN Board of Trustees:
Revisions:
Implementation:
Draft Policy ARIN-2010-12
IPv6 Subsequent Allocation
Version/Date: 18 November 2010
Policy statement:
Modify 6.5.2.1 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 transitional allocations will be reviewed every 3 years and reclaimed if they are no longer in use for transitional purposes. All such allocations for transitional technology will be made from a block designated for this purpose.
Rationale:
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
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.