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

[Owen DeLong]

On Oct 14, 2010, at 9:56 AM, Mark Townsley wrote:

> On 10/14/10 5:02 PM, Owen DeLong wrote:
>> 
>>> 
>>> 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.
> 6rd is just getting deployed now, so precisely how to transition it to native is still speculative. But, I know that technically it is quite possible (with equipment that will be available in 2011, if not today) to allow 6rd and native exist alongside one another in a very transparent manner to the end-user. Native can be brought up (or back down if there is a problem) one CPE, one head-end or one DSLAM at a time in whatever order the network operations folks want without having to alert the customer-care folks that have to deal with IPv6 being renumbered within the house, nor dealing with the well-known issues of multihoming towards two disparate address blocks. Once, say, a region of the network has transitioned appropriately (something that may only happen after the last end-user goes out and buys the right CPE, or the operator deploys enough native gear), a move to a more aggregated space and disabling of 6rd within the region can be scheduled appropriately. Policy should not disallow nor even discourage such an approach.
> 

Nothing in what I have proposed prevents that. The operator can use the 6rd space to do the transition
and then renumber after the transition is done if they want. The key is not to believe that the 6rd
space is in any way permanent.

The policy sent to last call by the AC merely requires that the 6rd allocations be done from a specific
prefix for that purpose and conveys that the 6rd allocations are transitional and temporary in nature.
It doesn't do anything to interfere with the approach you describe, so long as the provider does
eventually get to that renumber point.

> Again, I'm trying to make it *easier* for the operator to move to native. I want the operator to have tools available to make that as easy as possible, with the fewest moving parts. The incentive to have native v6 customers within an aggregated space will still be there, even if native and 6rd interfaces are allowed to exist at the same time, but that move can be staged and scheduled with appropriate advance notice and care independent of getting the user on native as soon as physically possible.
> 
We're in agreement there to a certain extent. However, it has to be done with responsible address management in mind as well. Making the 6rd prefixes permanent would be irresponsible.

> We agree that 6rd should be temporary. I think we even agree that it might take 10 years to move completely from 6rd to native. I'm even be OK with asking the provider to give back the block when they are done with it if we are demonstrably on track towards some new global IPv6 address exhaustion problem. We aren't far away from one another here.

Agreed.

>> 
>>> 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.
> I think #2 and #3 are reasonable, and you don't need #1 to make that clear. 

No, but, you do need #1 to make it possible to enforce #2 and #3 later.

>> 
>> The CGN FUD really is overplayed here. Even with this limitation, CGN remains far less attractive to
>> any provider.
> Then why are so many looking to buy them? Why the policy proposals for a shared-SP space? 

There are no policy proposals for shared-SP space. There is an IETF draft. The IETF draft in
question is generally opposed in the address policy community, to the best of my knowledge.
Most of the discussions I've been involved in where it was a subject were about the number
of different ways in which said draft was a bad idea.

Frankly, I'm betting that the providers that buy CGNs will be very dissatisfied with them in
relatively short order. I also think that they will be encouraging their customers to switch
to other providers.

>> Even a provider which doesn't see this, I am pretty sure that their customers will see it
>> in short order.
> I heard the same argument 10 years ago about the NAT the customers now claim they NEED. Perhaps your view is tainted by being so close to the IPv6-enabled world. From my vantage, we are still very much in a battle.

I tend to doubt it. NAT was pretty bad, but, CGN/LSN/whatever you want to call it is far
less attractive from the SP and the customer perspective than NAT was. It's all the problems
of NAT amplified many many times over with some additional new unique problems.

I think that the odds of CGN/LSN making it to wide-scale deployment are near zero.
Notice that nobody has even tested CGN/LSN on real end users yet.

>> 
>>> 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
> "most of them could deploy native"?? Wishing this to be true will not make it happen. The problem is that they evaluated deploying native and realized the could not and only then did we come along with 6rd and turn things around. That's where we are, like it or not. But I think you agree with this as your report on which technologies work and which do not on this thread was quite accurate. 
> 
You misunderstand me... I wasn't saying they can deploy native now. I was saying that once
native is a possibility, the required address size for native is several orders of magnitude
smaller while providing a couple of orders of magnitude more address space to their
customers.

Please take this paragraph only in the context of measuring the relative address consumption/
unit of customer space and not as a statement of current abilities.

Owen

> - Mark
>> 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/51ed61c8/attachment.htm>