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-2026 | 2026-04-24 11:13:10 |