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

[Mark Townsley]

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.

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.

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.

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.