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

Fri Oct 15 16:31:46 EDT 2010

On Oct 15, 2010, at 1:08 PM, Mark Townsley wrote:

> 
> ARIN and all,
> 
> This has been an enlightening exchange over the past week or so. I
> appreciate all time and attention devoted to this topic, as well as the
> lively exchanges by all. For my part, I am now off to enjoy a final
> weekend at home before traveling four out of the next five weeks.
> 
> For the record, my position on the last call below is:
> 
> 1. I am very pleased to see a policy for subsequent allocation, and that
> ARIN recognizes the need for 6rd at this stage of deployment and has
> acted accordingly. I admit that there are no ideal alternatives, all are
> tradeoffs at one level or another.
> 
> 2. One the following two revisions
> 
> "- Requests for transition space will not be exempt from returns."
> "- Allocations will be from a designated block."
> 
> I do not support use of a segregated space for all 6rd allocations, nor
> the idea that return of that space could happen in bulk while
> individual allocations were still in use by some ISPs. However, I would
> support individual review and return of space when individual ISPs are
> finished with it. I admit to not fully understanding what the return
> process might be though, which could be clouding my judgment. Perhaps a
> future date, 7-10 years has been suggested here by some, before any such
> return could be considered would be useful for other folks like me to
> have less concern.
> 
I am not in favor of establishing any definite end date at this time.
The policy provides for 3-year reviews of utilization, but, does not
provide for reclamation as part of that review unless there is a lack
of utilization.

I think this is reasonable.

> 3. On the following revision:
> 
> "- /24 was added as the maximum prefix size."
> 
> /24 for 6rd seems generous, /28 would probably suffice, particularly if
> it would come with less "strings attached" in terms of possibility of
> return before the ISP is ready for the space to be returned.
> 
I would not favor reducing what you call "strings attached" even if we
reduced the size to /32. The /24 allows for /56 assignments through
6rd to end sites. /28 would only facilitate /60s which I think will set
a bad precedent for home network size.

While I realize that Free is using /60s, that doesn't mean i have to think
it is in any way desirable that they do so.

> 4. Above all, I do not want to see any delay in implementation of a
> policy that allows for SPs to get a subsequent allocation of at least
> /28 for 6rd deployment in the ARIN region.
> 
I think that /24 and /28 would be approvable on the same time table.
I haven't heard anyone speaking in opposition to this policy in last
call.

Frankly, I think that the concerns you have expressed are mostly
not actually present in the policy as written.  I would be surprised
if any meaningful effort was made to deprecate these addresses
before there were viable native solutions available for all technologies
and the vast majority of providers had made the switch to native.

While I think it is important to preserve the ability to make a
communal decision to deprecate these addresses, I am not at
all in favor of deprecating them rapidly or prematurely.

Owen

> Best Regards,
> 
> - Mark
> 
> 
> 
> 
> On 10/13/10 8:10 PM, 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.