<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body 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" 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>
    </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>
    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>
    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>
    <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>
    <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>
    <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>
    <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>
    - 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>
  </body>
</html>