Draft Policy 2010-9: IPv6 for 6rd

[Member Services]

Draft Policy 2010-9
IPv6 for 6rd

On 15 July 2010 the ARIN Advisory Council (AC) selected "IPv6 for 6rd"
as a  draft policy for adoption discussion on the PPML and at the Public
Policy Meeting in Atlanta in October.

The draft was developed by the AC from policy proposal "113. IPv6 for
6rd". Per the Policy Development Process the AC submitted text to ARIN
for a staff and legal assessment prior to its selection as a draft
policy. Below the draft policy is the ARIN staff and legal assessment,
followed by the text that was submitted by the AC.

Draft Policy 2010-9 is below and can be found at:
https://www.arin.net/policy/proposals/2010_9.html

You are encouraged to discuss Draft Policy 2010-9 on the PPML prior to
the October Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-9
IPv6 for 6rd

Version/Date: 20 July 2010

Policy statement:

If you have non contiguous IPv4 addresses then you automatically qualify
for IPv6 space for 6rd. Upon receipt of a 6rd request, the minimum
subnet required for the functionality of 6rd will be automaticlly
granted and larger blocks will be granted based on justification. If
IPv6 addresses are already allocated to the requestor then an effort
will be made to give them an IPv6 allocation that is preferably
contiguous to the prior existing one. The use of this address space will
be used for 6rd and returned to ARIN when 6rd is no longer used on the
network. Justification for use of IPv6 for 6rd will be reviewed every 3
years and reclaimed if it is not in use. Requestor 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.

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

Rationale:

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.

Timetable for implementation: Immediate



#####


STAFF ASSESSMENT

Proposal: (113) IPv6 for 6rd
Proposal Version (Date): 29 June 2010
Date of Assessment:  13 July 2010

1. Proposal Summary (Staff Understanding)

This policy allows registrants with at least two blocks of on-contiguous
IPv4 address blocks to request a /32 or larger of IPv6 addresses to be
used for a 6rd deployment. The registration would be good for 3 years,
after which time it would be reviewed and reclaimed if not in use for
either the original 6rd deployment or some other v6 network technology.

2. Comments

A. ARIN Staff Comments

•  Neither the proposal, nor the rationale, provides any understanding
of why the first qualification criterion is "non contiguous IPv4
addresses". Why does the proposal exclude organizations with a single,
aggregated prefix registered to them?
•  The proposal sets a default allocation size of /32, but provides no
concrete criteria for ARIN staff to use when reviewing a request for a
larger initial size of addresses for 6rd deployment. For example, if an
organization says they need 32 bits for encapsulating the IPv4 address,
and wants to give a /48 to each customer, they would need a /16 of IPv6
address space. Current IPv6 policy provides guidance for determining the
initial allocation size using the organization’s existing network
infrastructure and customer base.   This policy would have staff
determining initial allocation requests larger than a /32 based on how
their end user customers are using multiple subnets. Should staff be
approving any request for initial IPv6 allocations for 6rd larger than a
/32 whenever the justification is “end users with multiple subnets?
•  The last sentence of the proposal ("Justification for a subnet of a
/28 ...") seems to be out of place.  It might fit better as the third
sentence following and larger blocks will be granted based on
justification.  Additionally, it would be clearer if the text were
changed slightly to read “for a subnet of /28 and larger ”?

B. ARIN General Counsel
No comments at this time.  It is unlikely to pose any legal concerns.

3. Resource Impact

This policy would have minimal resource impact.  It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:
•  Updated guidelines
•  Staff training

4. Proposal Text

Policy statement:
If you have non-contiguous IPv4 addresses then you automatically qualify
for IPv6 space for 6rd.  Upon receipt of a 6rd request, A minimum of a
/32 will be automatically granted and larger blocks will be granted
based on justification.  An effort will be made to provide any
additional IPv6 allocations contiguous to any prior existing ones.  The
use of this address space will be used for 6rd and returned to ARIN when
6rd is no longer used on the network. Justification for use of IPv6 for
6rd will be reviewed every 3 years and reclaimed if it is not in use.
Requestor 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 V6 or some other V6 network technology.

Rationale:

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

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