One document matched: draft-weil-shared-transition-space-request-01.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-04.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.fuller-240space SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-fuller-240space-02.xml">
<!ENTITY I-D.wilson-class-e SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wilson-class-e-02.xml">
]>
<rfc category="info" docName="draft-weil-shared-transition-space-request-01"
     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>Cox Communications</organization>

      <address>
        <postal>
          <street>1400 Lake Hearn Drive</street>

          <city>Atlanta</city>

          <region>GA</region>

          <code>30319</code>

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

        <email>jason.weil@cox.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="11" month="November" year="2010" />

    <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 implimenting 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 NAT444 <xref target="I-D.shirasaki-nat444"></xref> (see
      <xref target="I-D.donley-nat444-impacts"></xref>), it is the transition
      mechnism that has the least customer impact for many carriers.</t>

      <t>To deal with some of the NAT444 limitations, it becomes necessary for
      a provider to utilize address space in the NAT444 infrastructure that
      will not conflict with it's customer space.</t>

      <t>This document requests that IANA reserve a portion of the remaining
      unallocated space as Shared Transition Space for the enablement of a
      clean transition strategy in provider networks.</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 . 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, the preferred method for addressing the
      problems presented in both documents is to direct IANA to reserve
      address space from its unassigned IPv4 address pool for Shared
      Transition Space.</t>
    </section>

    <section title="Shared Transition Space">
      <t>This document proposes the assignment of the equivalent of a /10 as
      Shared Transition Space. This block could be composed of one contiguous
      assignment, or several discontiguous assignments. 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 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="Problems using Future Use Space">
      <t><xref target="I-D.fuller-240space"></xref> and <xref
      target="I-D.wilson-class-e"></xref> suggest that 240.0.0.0/4 space could
      be used as Shared Transition Space. However, as discussed in <xref
      target="I-D.azinger-additional-private-ipv4-space-issues"></xref>, some
      existing network equipment does not support addresses in the 240.0.0.0/4
      range. In particular, <xref target="CISCO"></xref> states that "no
      addresses are allowed with the highest-order bits set to 1111". It is
      likely that many home routers will not support this range, either. In
      order to use this range, equipment vendors would need to update software
      code for existing routers and end users would need to upgrade their home
      devices. As many older home routers do not support automatic updates, it
      is unlikely that enough end users would upgrade to make the 240.0.0.0/4
      range viable for Shared Transition Space use.</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 from its remaining pool of
      unallocated IPv4 addresses for use as Shared Transition Space.</t>
    </section>
  </middle>

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

      &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.fuller-240space;

      &I-D.wilson-class-e;

      <reference anchor="RFC2119">
        <front>
          <title></title>

          <author>
            <organization></organization>
          </author>

          <date />
        </front>
      </reference>

      <reference anchor="CISCO"
                 target="http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cwhubs/starvwug/83428.htm#xtocid74886">
        <front>
          <title>TCP/IP Overview</title>

          <author fullname="Cisco">
            <organization>Cisco Systems</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>