2010-12 Previous Version [Archived]

View the current policy proposal text.

The following version was archived on 18 November 2010.

Draft Policy 2010-12
IPv6 Subsequent Allocation

Version/Date: 13 October 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 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.

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

The following version was archived on 13 October 2010.

Draft Policy 2010-12
IPv6 Subsequent Allocation

Version/Date: 20 July 2010

Policy statement:

Modify 6.5.2.1 Subsequent allocation criteria. ADD the following sentence: Subsequent allocations will also be considered for transitional technologies 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. Justification for these allocations will be reviewed every 3 years and reclaimed if it is not in use. Requester will be exempt from returning all or a portion of the address space if they can show justification for need of this allocation for other existing IPv6 addressing requirements be it Native V6 or some other V6 network technology.

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