[arin-ppml] Policy Proposal 118: IPv6 Subsequent Allocation

Member Services info at arin.net
Mon Jun 21 08:39:43 EDT 2010


ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step to make sure
that they understand the proposal and believe the community will as
well. Staff will report their results to the ARIN Advisory Council (AC)
within 10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

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

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

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 118: IPv6 Subsequent Allocation

Proposal Originator: Marla Azinger, Alain Durand, Mark Townsley

Proposal Version:1

Date: 21 June 2010

Proposal type:NEW

Policy term:permanent

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









More information about the ARIN-PPML mailing list