Draft Policy 2010-9: IPv6 for 6rd [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: Abandoned

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 20 July 2010

Origin - Policy Proposal 113

Draft Policy - 20 July 2010 (with staff assessment)

Revised - 24 September 2010

Abandoned by the AC - 13 October 2010

Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN XXVI

ARIN Advisory Council:

AC Shepherds:
Marla Azinger and Heather Schiller

ARIN Board of Trustees:

Revisions:

Previous version(s)

Implementation:

Draft Policy 2010-9
IPv6 for 6rd

Version/Date: 24 September 2010

Policy statement:

6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969. If you have IPv4 addresses then you automatically qualify for IPv6 space for 6rd. Upon receipt of a 6rd request, an appropriate additional IPv6 allocation will be made that supports 6rd to be counted as a separate & parallel deployment to IPv4 and native IPv6. There is no requirement to segregate address space requested under this policy from regular IPv6 Allocation Supernets. From a management perspective this address space is to be treated as regular IPv6 address space.

While it is possible for an operator to transition to native IPv6 within the same address space used by 6rd, some operators may wish to keep native IPv6 users separate from 6rd users to permit optimization of aggregation. If an operator chooses to renumber users to an address space outside the 6rd aggregate when transitioning them to native IPv6, the 6rd allocation may be returned to ARIN when it is no longer in use.
It is suggested that contiguous allocations be made to any prior existing ones in the event justification for more IPv6 address space exists when the organization transitions 6rd out of their network.

Justification for use of IPv6 for 6rd will be reviewed after the first 3 years and reclaimed if it is not in use. After the first 3 years, any additional reviews will follow regular IPv6 policy. Requester will be exempt from returning all or a portion of the address space when 6rd is no longer used if they can show justification for need of the 6rd address space for other existing IPv6 addressing requirements be it native IPv6 or some other IPv6 network technology.

Rationale:

6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969. 6rd has been used successfully by a number of service providers to deploy IPv6 based on automatic IPv6 prefix delegation and tunneling over existing IPv4 infrastructure. The chief advantage of this approach is that it deploys the service quickly while enabling the network administration to manage its deployment outlays, and ensures the correspondence between IPv4 and IPv6 routing. 6rd is distinct from other transition technologies such as 6to4 and Teredo in that it operates within the confines of a service provider network, allowing it to be managed by the service provider. 6rd is designed to be transparent to both the user and the rest of the Internet at large.

To allow automatic prefix delegation to sites and stateless tunneling, 6rd utilizes a mapping scheme between an operator’s IPv6 allocation and IPv4 address space. With a /32 allocation and non-contiguous IPv4 addressing plan, IPv6 deployment with 6rd is possible, but generally results in no more than a /64 to a subscriber site. A /28 allows the operator to delegate prefixes shorter than /64, allowing multiple /64 subnets within the home. When IPv4 addresses are known to be contiguous for the lifetime of the 6rd deployment, mechanisms exist for a more efficient mapping. This is most likely if the operator has deployed IPv4 NAPT technology within their network, and are addressing homes within a contiguous block of RFC 1918 space (e.g., 10/8).

This example shows how the 6rd prefix is created based on a /28 IPv6 prefix using one of several non-contiguous global address ranges. This is a more realistic scenario of service providers in North America deploying IPv6 with 6rd today:

    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

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. This example assumes the operator is facing IPv4 scarcity to the point it has deployed or is planning to deploy a layer of NAPT (“Carrier Grade NAT”) within the service provider network and addressed its subscribers with private addresses accordingly:

    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

Justifications: Examples of how to display home networks using multiple subnets is accomplished by providing a network plan that involves the use of routing opposed to bridging. Such plans may involve the reduction of NAT, next-gen services, media types, separate L2 domains and more. The plan must simply show how the end user environment is not a single LAN subscriber.

Supporting Research: 6rd is responsible for the largest production Ipv6 deployment today, supporting 4.5 million subscribers in France within a /26 that was granted by RIPE. This ISP previously had a /32, and went back and to RIPE for an additional /26. At least one other provider has deployed 6rd within a /27 that was granted recently for 6rd. A /24 was recently granted as well, likely for 6rd deployment. There are multiple providers in North America and around the world that have committed to delivering residential broadband service with 6rd, or are doing so today.

The following RIPE report shows the affect 6rd has had in France, which accounts for the largest deployment in all of Europe or North America.

http://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-2-country-level-and-other-statistics

“In Figure 2 (Western Europe), we see a native IPv6 client capability in France of over 4%. This is mainly caused by free.fr that accounts for 70% of the native IPv6 clients measured. Note that technically free.fr uses 6rd-tunneling, but externally that looks, feels and smells like native IPv6”

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.