[arin-ppml] Opposed to 2010-9 and 2010-12

[Owen DeLong]

> 
> Classifying 6rd as a means to an end for native IPv6 is an architectural statement, though one that is at least consistent with the 6rd RFC. Limiting the space which 6rd can run, however, presupposes how the transition from 6rd to native is to be done.
> 
> From RFC 5969:
> 
>    The SP can choose to provision a separate IPv6 address block for
>    native service, or reuse the 6rd prefix block itself.  
> 
> An ARIN policy that requires moving to a different block is, by the letter, an IETF standards-track RFC violation. 
> 
However, this is not the first time the IETF has made the mistake of stepping over the line from Architectureal
design to address policy. ARIN sets address policy for the ARIN service region, the IETF does not.

Another example of ARIN policy correcting this error on the part of IETF would be 2005-1, prior to which
there was no facility for Provider Independent End User assignments in ANY region. Today there is
policy to support those assignments in all 5 regions.

> I'm calling this out only to underscore that there are serious operational considerations with respect to allowing native and 6rd to coexist within the same prefix while moving to native. Considerations that could actually discourage movement to native by ISPs. We want it to be as easy as possible for ISPs to move to native IPv6 from 6rd. This is why this sentence exists in the RFC.
> 
Yes... Those operational considerations are hazardous to address policy and would prevent any ability to
ensure the eventual deprecation of this "transitional" technology at the expense of vast amounts of address
space which would have been distributed in an excessively (even by IPv6 standards) wasteful manner.

I'm all for 6rd as a temporary fix, but, as a permanent institution, it is pretty awful. Even if we ignore the
issue of deprecation and assume that providers would switch to native without additional motivation,
allowing them to have their native and 6rd deployments to co-exist in the same space would result
in sparse allocation of their native blocks across the oversized prefix granted for 6rd which would
prevent future reclamation of that oversized prefix.

By requiring the native deployments to go in a separate prefix which is more appropriately sized for
the ISPs native deployment, we ensure the ability to eventually reclaim and re-use these oversized
blocks for other purposes.

> Putting 6rd into a segregated block, in particular with the threat of that block expiring, only adds to deployment hurdles. Today, it would be one more thing that the poor person at the ISP that actually wants to see IPv6 deployed before the CGNs take over has to convince his or her management is not a future risk factor. Tomorrow, it could be one more hurdle for the ISP to renumber their IPv6 customer when moving to native. 
> 
There is no threat of that block expiring. The intent is to allow for a mechanism by which to signal the following:

1.	Native deployments should go in a separate appropriately sized block.
2.	6rd is temporary and transitional in nature. It is not to be considered permanent.
	Temporary in this case may well span a decade, but, there should eventually be an end date.
3.	The sooner you migrate your customers from 6rd to native, the better. There is value in pressuring
	your vendors to make this possible.

The CGN FUD really is overplayed here. Even with this limitation, CGN remains far less attractive to
any provider. Even a provider which doesn't see this, I am pretty sure that their customers will see it
in short order.

> I'm all for facilitation. Let's focus on that rather than assuming we know how the operator is going to migrate from 6rd to native and encoding that in the ARIN policy.
> 
The point of this aspect of the policy is not that we are assuming the operator will migrate. We are
requiring that they eventually do. Allowing them to hang on to these oversized 6rd blocks beyond
the point where a switch to native is practicable is not good stewardship of the address space.

If you can get 6rd to fit in  single /16, then, perhaps we could consider allowing it to be permanent.

However, if ~3,000 ARIN members deploy 6rd /24s, then, you're talking about the vast majority
of an entire /12 just in the ARIN region. Since most of them could deploy native and give their
customers much larger (256x) assignments and fit within 1/16th of the proposed address space
for 6rd, (IOW, a 4096x gain in addressing efficiency), I believe that the ARIN community has
a valid interest in ensuring that this is a temporary use of address resources.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/70d0b8f1/attachment.htm>