Draft Policy 2010-9: IPv6 for 6rd - revised

[ARIN]

Draft Policy 2010-9
IPv6 for 6rd

2010-9 has been revised.

This draft policy is open for discussion on this mailing list and will
be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.

2010-9 is below and available at:
https://www.arin.net/policy/proposals/2010_9.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


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