One document matched: draft-weil-shared-transition-space-request-05.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 RFC6269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml">
<!ENTITY RFC6319 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6319.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-01.xml">
]>
<rfc category="info" docName="draft-weil-shared-transition-space-request-05"
     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@gmail.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>Australia</country>
        </postal>

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

        <email>cdl@asgaard.org</email>
      </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>

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

        <phone>+1.360.513.2293</phone>

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

    <date day="20" month="September" year="2011" />

    <abstract>
      <t>This document requests that an IPv4 /10 be reserved as Shared
      Transition Space solely to facilitate deployment of IPv6 transition/IPv4
      coexistence technologies after 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 legacy IPv4-only
      devices will be required. Also, some IPv6 transition technologies
      require the use of IPv4 address space. In order to facilitate the
      deployment of transition technologies and to support such legacy
      IPv4-only devices and services, Service Providers require IPv4 address
      space that is separate from the range of IPv4 addresses used by
      subscribers. This address space need not be unique to each provider, but
      should be outside of <xref target="RFC1918"></xref> space. This document
      requests that an IPv4 /10 be reserved as Shared Transition Space solely
      to facilitate deployment of IPv6 transition/IPv4 coexistence
      technologies.</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. 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, often
      using a Carrier Grade NAT (CGN) <xref target="RFC6264"></xref>. For
      several IPv4 extension/IPv6 transition technologies including NAT444
      <xref target="I-D.shirasaki-nat444"></xref>, 6RD<xref
      target="RFC5969"></xref>, and 6to4-PMT<xref
      target="I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel"></xref>,
      addresses between the CGN and subscriber home routers need not be
      globally unique, only unique inside the CGN. Thus, 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. 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>.</t>

      <t>Additional use cases for Shared Transition Space are described in
      <xref target="I-D.bdgks-arin-shared-transition-space"></xref>.</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, except where required based on business
      relationships such as hosted CGN service. Internet service providers
      SHOULD filter out routing information about shared transition space
      networks on ingress links. Reverse DNS queries for Shared Transition
      Space addresses MUST NOT be forwarded to the global DNS
      infrastructure.</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 record the allocation of an IPv4 /10 for use as
      Shared Transition Space.</t>
    </section>
  </middle>

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

      &RFC2119;

      <?rfc include="reference.RFC.6264"?>
    </references>

    <references title="Informative References">
      &I-D.bdgks-arin-shared-transition-space;

      <?rfc include="reference.I-D.draft-shirasaki-nat444-04"?>

      <?rfc include="reference.I-D.draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-03"?>

      <?rfc include="reference.RFC.5969"?>
    </references>

    <section title="Acknowledgments">
      <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>

PAFTECH AB 2003-20262026-04-24 11:13:10