[arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation

Tue Jul 20 14:12:21 EDT 2010

Draft Policy 2010-12
IPv6 Subsequent Allocation

On 15 July 2010 the ARIN Advisory Council (AC) selected "IPv6 Subsequent
Allocation" 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 "118. IPv6
Subsequent Allocation". 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-12 is below and can be found at:
https://www.arin.net/policy/proposals/2010_12.html

You are encouraged to discuss Draft Policy 2010-12 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-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

#####

STAFF ASSESSMENT

Proposal:  (118) IPv6 Subsequent Allocation
Proposal Version (Date): 21 June 2010
Date of Assessment:  14 July 2010

1. Proposal Summary (Staff Understanding)

This policy opens the IPv6 ISP additional allocation policy to allow for
subsequent allocations to be considered when a new technology is being
implemented which requires a separate block from existing IPv6
allocations. Subsequent allocations issued under this new language must
be reviewed with the registrant every 3 years by ARIN staff.

2. Comments

A. ARIN Staff Comments

•  The policy text provides no concrete criteria for ARIN staff to
determine when an organization does, or does not, qualify for a
subsequent IPv6 allocation.
•  Additionally, there are no criteria to be used to determine the size
of the allocation an organization qualifies for. 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
space.    Current IPv6 policy provides clear criteria for judging the
subsequent allocation size by applying an hd ratio of .94, a criterion
which can be applied consistently across the board.  This policy would
have staff determining subsequent allocation based on “some technical
documentation” without any real guidelines.  Should staff be approving
any request for subsequent IPv6 allocations of any size whenever the
justification is “we’re using it for a transitional technology”?

B. ARIN General Counsel

No comments at this time.  It is unlikely to raise legal issues.

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:

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