<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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" color="#000000"><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><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><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><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. Even a provider which doesn't see this, I am pretty sure that their customers will see it</div><div>in short order.</div><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><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><div><br></div><div>Owen</div><div><br></div></body></html>