One document matched: draft-weil-shared-transition-space-request-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5569 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5569.xml">
<!ENTITY I-D.azinger-additional-private-ipv4-space-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-azinger-additional-private-ipv4-space-issues-05.xml">
<!ENTITY I-D.intarea-shared-addressing-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-intarea-shared-addressing-issues-02.xml">
<!ENTITY I-D.shirasaki-nat444-isp-shared-addr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shirasaki-nat444-isp-shared-addr-04.xml">
<!ENTITY I-D.shirasaki-nat444 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shirasaki-nat444-02.xml">
<!ENTITY I-D.donley-nat444-impacts SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-donley-nat444-impacts-01.xml">
<!ENTITY I-D.bdgks-arin-shared-transition-space SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bdgks-arin-shared-transition-space-00.xml">
]>
<rfc category="info" docName="draft-weil-shared-transition-space-request-02"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Shared Transition Space Request">IANA Reserved IPv4 Prefix
    for Shared Transition Space</title>

    <author fullname="Jason Weil" initials="J.W." surname="Weil">
      <organization>Time Warner Cable</organization>

      <address>
        <postal>
          <street>13820 Sunrise Valley Drive</street>

          <city>Herndon</city>

          <region>VA</region>

          <code>20171</code>

          <country>USA</country>
        </postal>

        <email>jason.weil@twcable.com</email>
      </address>
    </author>

    <author fullname="Victor Kuarsingh" initials="V.K." surname="Kuarsingh">
      <organization>Rogers Communications</organization>

      <address>
        <postal>
          <street>8200 Dixie Road</street>

          <city>Brampton</city>

          <region>ON</region>

          <code>L6T 0C1</code>

          <country>Canada</country>
        </postal>

        <email>victor.kuarsingh@rci.rogers.com</email>
      </address>
    </author>

    <author fullname="Chris Donley" initials="C.D." surname="Donley">
      <organization>CableLabs</organization>

      <address>
        <postal>
          <street>858 Coal Creek Circle</street>

          <city>Louisville</city>

          <region>CO</region>

          <code>80027</code>

          <country>USA</country>
        </postal>

        <email>c.donley@cablelabs.com</email>
      </address>
    </author>

    <author fullname="Christopher Liljenstolpe" initials="C.D.L"
            surname="LILJENSTOLPE">
      <organization>Telstra Corp</organization>

      <address>
        <postal>
          <street>7/242 Exhibition Street</street>

          <city>Melbourne</city>

          <region>VIC</region>

          <code>316</code>

          <country>AU</country>
        </postal>

        <phone>+61 3 8647 6389</phone>

        <facsimile></facsimile>

        <email>cdl@asgaard.org</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Marla Azinger" initials="M.A." surname="Azinger">
      <organization>Frontier Communications</organization>

      <address>
        <postal>
          <street></street>

          <city>Vancouver</city>

          <region>WA</region>

          <code></code>

          <country>US</country>
        </postal>

        <phone>+1.360.513.2293</phone>

        <facsimile></facsimile>

        <email>marla.azinger@frontiercorp.com</email>

        <uri></uri>
      </address>
    </author>

    <date day="8" month="July" year="2011" />

    <workgroup>Operations and Management Area Working Group</workgroup>

    <abstract>
      <t>This document requests a reserved IANA IPv4 address allocation as
      Shared Transition Space to support the deployment of IPv4 address
      sharing technologies post IPv4 exhaustion.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Many operators are currently implementing their IPv6 transition
      plans. During the transition, continued support for heritage IPv4 only
      devices will be required. While most operators are well aware of the
      limitations of Carrier Grade NAT, particularly NAT444 <xref
      target="I-D.shirasaki-nat444"> </xref> (see <xref
      target="I-D.donley-nat444-impacts"></xref>), it is the transition
      mechanism that has the least customer impact for many carriers.</t>

      <t>To deploy Carrier Grade NAT, it becomes necessary for a provider to
      create an inside address pool that will not conflict with its customer
      address space. This document requests that IANA reserve a /10 of IPv4
      addresses to use as Shared Transition Space. As IANA has exhausted its
      pool of addresses, one or more RIR(s) or legacy address holder(s) will
      need to supply IANA with such addresses (e.g. per <xref
      target="ARIN">ARIN Draft Policy 2011-5</xref>).</t>
    </section>

    <section title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </section>

    <section title="Motivation">
      <t>The Internet community is rapidly consuming the remaining supply of
      unallocated IPv4 addresses. During the transition period to IPv6, it is
      imperative that Service Providers maintain IPv4 service for devices and
      networks that are currently incapable of upgrading to IPv6.</t>

      <t>In order to provide IPv4 service to customers and/or devices once the
      IPv4 address space is exhausted, Service Providers must multiplex
      several subscribers behind a single IPv4 address using one of several
      techniques including NAT444 or Carrier Grade NAT. Providers need
      sufficient non-<xref target="RFC1918"></xref> address space to deploy
      such technologies and avoid overlap with customer use of private address
      space.</t>

      <t>Many CPE router devices used to provide residential or small-medium
      business services have been optimized for IPv4 operation, and typically
      require replacement in order to fully support the transition to IPv6
      (either natively or via one of many transition technologies). In
      addition, various consumer devices including IP-enabled televisions,
      gaming consoles, medical and family monitoring devices, etc. are
      IPv4-only, and cannot be upgraded. While these will eventually be
      replaced with dual-stack or IPv6 capable devices, this transition will
      take many years. As these are typically consumer-owned devices, service
      providers do not have control over the speed of their replacement cycle.
      However, consumers have an expectation that they will continue to
      receive IPv4 service, and that such devices will continue to have IPv4
      Internet connectivity after the IPv4 pool is exhausted, even if the
      customer contracts for new service with a new provider.</t>

      <t>Until such customers replace their Home Gateways and all IPv4-only
      CPE devices with IPv6-capable devices, Service Providers will be
      required to continue to offer IPv4 services through the use of an IPv4
      address sharing technology such as NAT444 <xref
      target="I-D.shirasaki-nat444"></xref>. The challenges associated with
      these deployments are identified in <xref
      target="I-D.shirasaki-nat444-isp-shared-addr"></xref>, <xref
      target="I-D.donley-nat444-impacts"></xref>, and <xref
      target="I-D.ietf-intarea-shared-addressing-issues"></xref>.</t>

      <t>Addressing solutions for dealing with the depletion of the IPv4
      public address space and the lack of available private addresses within
      large providers are presented in <xref
      target="I-D.azinger-additional-private-ipv4-space-issues"></xref> as
      well as <xref target="I-D.shirasaki-nat444-isp-shared-addr"></xref>. For
      infrastructure providers whose customers are already using <xref
      target="RFC1918"></xref> space, as described in <xref
      target="I-D.bdgks-arin-shared-transition-space"></xref> and <xref
      target="ARIN"></xref>, the preferred method for addressing the problems
      presented in both documents is to direct IANA to reserve address space
      for Shared Transition Space.</t>
    </section>

    <section title="Shared Transition Space">
      <t>This document proposes the assignment of a /10 as Shared Transition
      Space. Shared Transition Space is IPv4 address space reserved for
      Infrastructure provider use with the purpose of facilitating IPv6
      transition and IPv4 coexistence deployment. The requested block SHOULD
      NOT be utilized for any purpose other than as "inside" addresses in a
      carrier NAT environment (e.g. between the CGN and customer CPE devices)
      or for other IPv4 to IPv6 transition infrastructure. Network equipment
      manufacturers MUST NOT use the assigned block in default or example
      device configurations.</t>

      <t>Because Shared Transition addresses have no meaning outside of the
      Infrastructure Provider, routing information about shared transition
      space networks MUST NOT be propagated on interdomain links, and packets
      with shared transition source or destination addresses SHOULD NOT be
      forwarded across such links. Internet service providers SHOULD filter
      out routing information about shared transition space networks on
      ingress links.</t>
    </section>

    <section title="Security Considerations">
      <t>This memo does not define any protocol, and raises no security
      issues. Any addresses allocated as Shared Transition Space would not be
      routable on the Internet.</t>
    </section>

    <section title="IANA Considerations">
      <t>IANA is asked to reserve an IPv4 /10 for use as Shared Transition
      Space. This prefix is intended to be non-routable. As IANA has exhausted
      its pool of IPv4 address space, it may be necessary for one or more RIRs
      and/or legacy address holders to provide such addresses for IANA
      reservation (e.g. per <xref target="ARIN"> ARIN Draft Policy
      2011-5</xref>).</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      &RFC1918;

      &RFC2119;

      &I-D.azinger-additional-private-ipv4-space-issues;

      &I-D.intarea-shared-addressing-issues;

      &I-D.donley-nat444-impacts;

      &I-D.shirasaki-nat444-isp-shared-addr;

      &I-D.shirasaki-nat444;

      &I-D.bdgks-arin-shared-transition-space;

      <reference anchor="ARIN"
                 target="https://www.arin.net/policy/proposals/2011_5.html">
        <front>
          <title>Shared Transition Space for IPv4 Address Extension</title>

          <author fullname="ARIN">
            <organization>American Registry for Internet
            Numbers</organization>
          </author>
        </front>
      </reference>
    </references>

    <section title="Acknowledgements">
      <t>Thanks to the following people (in alphabetical order) for their
      guidance and feedback: <list style="hanging">
          <t>John Brzozowski</t>

          <t>Isaiah Connell</t>

          <t>Greg Davies</t>

          <t>Kirk Erichsen</t>

          <t>Wes George</t>

          <t>Tony Hain</t>

          <t>Philip Matthews</t>

          <t>John Pomeroy</t>

          <t>Barbara Stark</t>

          <t>Jean-Francois Tremblay</t>

          <t>Leo Vegoda</t>

          <t>Steven Wright</t>

          <t>Ikuhei Yamagata</t>
        </list></t>
    </section>
  </back>
</rfc>