<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 14, 2010, at 9:56 AM, Mark Townsley wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
On 10/14/10 5:02 PM, Owen DeLong wrote:
<blockquote cite="mid:D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com" type="cite">
<div>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"><br>
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.<br>
<br>
From RFC 5969:<br>
<br>
The SP can choose to provision a separate IPv6 address
block for<br>
native service, or reuse the 6rd prefix block itself. <br>
<font class="Apple-style-span"><font class="Apple-style-span" color="#144fae"><br>
</font></font></div>
</blockquote>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> An ARIN policy that
requires moving to a different block is, by the letter, an
IETF standards-track RFC violation. <br>
<br>
</div>
</blockquote>
However, this is not the first time the IETF has made the
mistake of stepping over the line from Architectureal</div>
<div>design to address policy. ARIN sets address policy for the
ARIN service region, the IETF does not.</div>
<div><br>
</div>
<div>Another example of ARIN policy correcting this error on the
part of IETF would be 2005-1, prior to which</div>
<div>there was no facility for Provider Independent End User
assignments in ANY region. Today there is</div>
<div>policy to support those assignments in all 5 regions.</div>
<div><br>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> 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.<br>
<br>
</div>
</blockquote>
Yes... Those operational considerations are hazardous to address
policy and would prevent any ability to</div>
<div>ensure the eventual deprecation of this "transitional"
technology at the expense of vast amounts of address</div>
<div>space which would have been distributed in an excessively
(even by IPv6 standards) wasteful manner.</div>
<div><br>
</div>
<div>I'm all for 6rd as a temporary fix, but, as a permanent
institution, it is pretty awful. Even if we ignore the</div>
<div>issue of deprecation and assume that providers would switch
to native without additional motivation,</div>
<div>allowing them to have their native and 6rd deployments to
co-exist in the same space would result</div>
<div>in sparse allocation of their native blocks across the
oversized prefix granted for 6rd which would</div>
<div>prevent future reclamation of that oversized prefix.</div>
</blockquote>
<blockquote cite="mid:D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com" type="cite">
<div><br>
</div>
<div>By requiring the native deployments to go in a separate
prefix which is more appropriately sized for</div>
<div>the ISPs native deployment, we ensure the ability to
eventually reclaim and re-use these oversized</div>
<div>blocks for other purposes.</div>
</blockquote>
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.<br>
<br></div></blockquote></div><div>Nothing in what I have proposed prevents that. The operator can use the 6rd space to do the transition</div><div>and then renumber after the transition is done if they want. The key is not to believe that the 6rd</div><div>space is in any way permanent.</div><div><br></div><div>The policy sent to last call by the AC merely requires that the 6rd allocations be done from a specific</div><div>prefix for that purpose and conveys that the 6rd allocations are transitional and temporary in nature.</div><div>It doesn't do anything to interfere with the approach you describe, so long as the provider does</div><div>eventually get to that renumber point.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
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.<br>
<br></div></blockquote>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.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
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.<br></div></blockquote><div><br></div>Agreed.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com" type="cite">
<div><br>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> 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. <br>
<br>
</div>
</blockquote>
There is no threat of that block expiring. The intent is to
allow for a mechanism by which to signal the following:</div>
<div><br>
</div>
<div>1.<span class="Apple-tab-span" style="white-space: pre;"> </span>Native
deployments should go in a separate appropriately sized block.</div>
<div>2.<span class="Apple-tab-span" style="white-space: pre;"> </span>6rd
is temporary and transitional in nature. It is not to be
considered permanent.</div>
<div><span class="Apple-tab-span" style="white-space: pre;"> </span>Temporary
in this case may well span a decade, but, there should
eventually be an end date.</div>
<div>3.<span class="Apple-tab-span" style="white-space: pre;"> </span>The
sooner you migrate your customers from 6rd to native, the
better. There is value in pressuring</div>
<div><span class="Apple-tab-span" style="white-space: pre;"> </span>your
vendors to make this possible.</div>
</blockquote>
I think #2 and #3 are reasonable, and you don't need #1 to make that
clear. <br></div></blockquote><div><br></div>No, but, you do need #1 to make it possible to enforce #2 and #3 later.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com" type="cite">
<div><br>
</div>
<div>The CGN FUD really is overplayed here. Even with this
limitation, CGN remains far less attractive to</div>
<div>any provider. </div>
</blockquote>
Then why are so many looking to buy them? Why the policy proposals
for a shared-SP space? <br></div></blockquote><div><br></div>There are no policy proposals for shared-SP space. There is an IETF draft. The IETF draft in</div><div>question is generally opposed in the address policy community, to the best of my knowledge.</div><div>Most of the discussions I've been involved in where it was a subject were about the number</div><div>of different ways in which said draft was a bad idea.</div><div><br></div><div>Frankly, I'm betting that the providers that buy CGNs will be very dissatisfied with them in</div><div>relatively short order. I also think that they will be encouraging their customers to switch</div><div>to other providers.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com" type="cite">
<div>Even a provider which doesn't see this, I am pretty sure that
their customers will see it</div>
<div>in short order.<br>
</div>
</blockquote>
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.<br></div></blockquote><div><br></div>I tend to doubt it. NAT was pretty bad, but, CGN/LSN/whatever you want to call it is far</div><div>less attractive from the SP and the customer perspective than NAT was. It's all the problems</div><div>of NAT amplified many many times over with some additional new unique problems.</div><div><br></div><div>I think that the odds of CGN/LSN making it to wide-scale deployment are near zero.</div><div>Notice that nobody has even tested CGN/LSN on real end users yet.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com" type="cite">
<div><br>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> 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.<br>
<br>
</div>
</blockquote>
The point of this aspect of the policy is not that we are
assuming the operator will migrate. We are</div>
<div>requiring that they eventually do. Allowing them to hang on
to these oversized 6rd blocks beyond</div>
<div>the point where a switch to native is practicable is not good
stewardship of the address space.</div>
<div><br>
</div>
<div>If you can get 6rd to fit in single /16, then, perhaps we
could consider allowing it to be permanent.</div>
<div><br>
</div>
<div>However, if ~3,000 ARIN members deploy 6rd /24s, then, you're
talking about the vast majority</div>
<div>of an entire /12 just in the ARIN region. Since most of them
could deploy native and give their</div>
</blockquote>
"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. <br>
<br></div></blockquote>You misunderstand me... I wasn't saying they can deploy native now. I was saying that once</div><div>native is a possibility, the required address size for native is several orders of magnitude</div><div>smaller while providing a couple of orders of magnitude more address space to their</div><div>customers.</div><div><br></div><div>Please take this paragraph only in the context of measuring the relative address consumption/</div><div>unit of customer space and not as a statement of current abilities.</div><div><br></div><div>Owen</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
- Mark<br>
<blockquote cite="mid:D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com" type="cite">
<div>customers much larger (256x) assignments and fit within
1/16th of the proposed address space</div>
<div>for 6rd, (IOW, a 4096x gain in addressing efficiency), I
believe that the ARIN community has</div>
<div>a valid interest in ensuring that this is a temporary use of
address resources.</div>
</blockquote>
<br>
<br>
<br>
<br>
<blockquote cite="mid:D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com" type="cite">
<div><br>
</div>
<div>Owen</div>
<div><br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></body></html>