[arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation - Last Call (text revised)

Christopher Morrow christopher.morrow at gmail.com
Thu Oct 14 00:01:06 EDT 2010


On Wed, Oct 13, 2010 at 5:54 PM, Owen DeLong <owen at delong.com> wrote:
> To clarify, the /24 maximum and the designated block apply ONLY
> to subsequent allocations for transitional purposes. Subsequent allocations
> for native IPv6 deployment are not restricted or encumbered in any way
> other than the standards set forth in existing policy.

That was the intent Dan and I had at the table in the meeting, and at
the AC meeting afterwards.

-chris
(adding agreement only)
> On Oct 13, 2010, at 11:10 AM, ARIN wrote:
>
>> The ARIN Advisory Council (AC) met on 8 October 2010 and decided to
>> send the following draft policy to last call:
>>
>>   Draft Policy 2010-12: IPv6 Subsequent Allocation
>>
>> The AC made the following revisions to the text:
>>  - /24 was added as the maximum prefix size.
>>  - Allocations will be from a designated block.
>>  - Requests for transition space will not be exempt from returns.
>>
>> Feedback is encouraged during the last call period. All comments should
>> be provided to the Public Policy Mailing List. Last call for 2010-12
>> will expire on 27 October 2010. After last call the AC will conduct
>> their last call review.
>>
>> The draft policy text is below and available at:
>> https://www.arin.net/policy/proposals/
>>
>> The ARIN Policy Development Process is available at:
>> https://www.arin.net/policy/pdp.html
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Draft Policy 2010-12
>> IPv6 Subsequent Allocation
>>
>> Version/Date: 13 October 2010
>>
>> Policy statement:
>>
>> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
>>
>> Subsequent allocations will also be considered for deployments 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 with a /24 being the maximum allowed
>> for a transition technology. Justification for these allocations will be
>> reviewed every 3 years and reclaimed if it is not in use. All such
>> allocations for transitional technology will be made from a block
>> designated for this purpose.
>>
>> 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
>>
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



More information about the ARIN-PPML mailing list