One document matched: draft-weil-shared-transition-space-request-06.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="bcp" docName="draft-weil-shared-transition-space-request-06"
ipr="trust200902" updates="1918, 5735">
<?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 CGN Space Request">IANA Reserved IPv4 Prefix for
Shared CGN 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="26" month="September" year="2011" />
<abstract>
<t>This document requests that an IPv4 /10 be reserved as Shared CGN
Space solely to facilitate deployment of IPv4 Carrier Grade NAT (CGN)
technologies after IPv4 exhaustion. This document updates RFC 1918 and
RFC 5735 to reserve an additional special-use address range for use
between a CGN and home router.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IPv4 address space is nearly exhausted. Until the Internet fully
transitions to IPv6, Service Providers will be required to offer
continued support for legacy IPv4-only devices. In order to facilitate
the deployment of Carrier Grade NAT (CGN) technologies <xref
target="RFC6264"></xref> 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 needs to be outside of <xref
target="RFC1918"></xref> space. This document requests that an IPv4 /10
be reserved as Shared CGN Space solely to facilitate deployment of CGN
technologies in Service Provider networks. As Shared CGN Space is a new
special-use address range between a CGN and home router, this document
updates <xref target="RFC1918"></xref> and <xref
target="RFC5735"></xref> to reflect its use.</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, many Service Providers will need to multiplex
several subscribers behind a single IPv4 address using a Carrier Grade
NAT (CGN) <xref target="RFC6264"></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>Additional applicability and analysis of Shared CGN Space is
described in <xref
target="I-D.bdgks-arin-shared-transition-space"></xref>.</t>
</section>
<section title="Shared CGN Space">
<t>This document proposes the assignment of a /10 as Shared CGN Space.
Shared CGN Space is IPv4 address space reserved for Service Provider use
with the purpose of facilitating CGN deployment. The requested block
MUST NOT be utilized for any purpose other than as "inside" addresses in
a CGN environment (e.g., between the CGN and customer premises equipment
(CPE)). Network equipment manufacturers MUST NOT use the assigned block
in default or example device configurations.</t>
<t>Because Shared CGN Space addresses have no meaning outside of the
Service Provider, routing information about Shared CGN Space networks
MUST NOT be propagated on interdomain links, and packets with Shared CGN
Space source or destination addresses MUST NOT be forwarded across such
links, except where required based on business relationships such as
hosted CGN service. Service Providers SHOULD filter out routing
information about Shared CGN Space networks on ingress links. DNS
queries for Shared CGN Space addresses MUST NOT be forwarded to the
global DNS infrastructure. This is done to avoid having to set up
something similar to AS112.net for RFC 1918 private address space that a
host has incorrectly sent for a DNS reverse-mapping queries on the
public Internet <xref target="RFC6304"></xref>.</t>
<t>Shared CGN Space is expected to be used in a Service Provider
Environment. Shared CGN Space MUST NOT be used in network environments
described in <xref target="RFC1918"></xref> as designed for private
addresses - namely, for hosts that do not require access to hosts in
other enterprises or the Internet at large, or hosts that need access to
a limited set of outside services (e.g., E-mail, FTP, netnews, remote
login) that can be handled by mediating gateways (e.g., application
layer gateways). Shared CGN Space MUST NOT be used inside a home router
NAT. With the exception of subscribers using bridged Internet access
(i.e., without a home router between the subscriber and Service Provider
networks), subscriber hosts SHOULD NOT use Shared CGN Space addresses.
Because CGN service requires non-overlapping address space on each side
of the home NAT and CGN, entities misusing Shared CGN Space for purposes
other than for CGN service, as described in this document, are likely to
experience problems implementing or connecting to CGN service at such
time as they exhaust their supply of public IPv4 addresses.</t>
<section anchor="absd" title="Address-Based Scope Detection">
<t>Some CPE router devices make assumptions about their connectivity
scope based on their WAN-side IPv4 address. This is particularly
evident in their handling of 6to4 <xref target="RFC3056"></xref>,
<xref target="RFC3068"></xref>. As described in <xref
target="RFC6343"></xref>, CPE routers do not attempt to initialize
6to4 tunnels when they are configured with a <xref
target="RFC1918"></xref> or <xref target="RFC5735"></xref> WAN
address. When configured with a Shared CGN Space address (or other
address range not described in <xref target="RFC5735"></xref>), such
devices may attempt to initiate 6to4. Since 6to4 includes the WAN IPv4
address embedded in its IPv6 address, should 6to4 traffic traverse a
CGN, return traffic could be misdirected and not reach the originating
router. Service Providers can mitigate this issue using a technology
such as 6to4-PMT <xref
target="I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel"></xref>.
When the address range is well-defined, as with Shared CGN Space, home
router vendors can include Shared CGN Space in their list of
special-use addresses (e.g., <xref target="RFC5735"></xref>) and treat
Shared CGN Space similarly to private <xref target="RFC1918"></xref>
space. When the WAN address is not well-defined, as in the case of
Globally Unique space, it will be more difficult for home router
vendors to mitigate against this issue. </t>
<t>CGN technologies impose additional impacts on applications (see
<xref target="RFC6269"></xref> and <xref
target="I-D.donley-nat444-impacts"></xref>) that are not dependent on
the address space between the CGN and home router.</t>
</section>
</section>
<section title="Alternatives">
<t>As described in <xref target="RFC6319"></xref>, there are two
alternatives to Shared CGN Space, considered below:</t>
<t><list style="numbers">
<t>Use private <xref target="RFC1918"></xref> address space.</t>
<t>Use Globally-Unique address space.</t>
</list></t>
<section title="RFC1918 Space">
<t>In some cases, it may be possible to instead use private <xref
target="RFC1918"></xref> address space between the CGN and CPE
devices. In situations where all endpoints in the network are managed
by the service provider (including customer LAN addressing), this may
be a viable option. However, when customers administer their own LANs
or use default addresses assigned to CPE devices, the possibility of
address conflict becomes a significant risk to operations. Private
<xref target="RFC1918"></xref> address space is not generally intended
to be used for purposes which cross administrative domains. Further,
CGN service requires address space in one administrative domain that
extends to leaf networks that are generally single-homed to the
serving administrative domain. This usage is outside of Category 1 and
Category 2, defined in <xref target="RFC1918"></xref> for use of
private address space.</t>
<t>A study of DNS traffic <xref target="v6ops-msg06187"></xref> has
shown that effectively all of the existing private <xref
target="RFC1918"></xref> address space is currently being used by
end-sites attached to the Internet. While individual network
environments may vary in this regard, most Service Providers face the
risk that their use of private address space will conflict with their
customer end-sites.</t>
<t>In the event of conflict, it is possible that the end-site CPE
routers will fail and/or not function correctly. While some CPE
implementations will support overlapping addresses on the "inside" and
"outside" interfaces, others are known to fail under such
circumstances. Also, the use of private <xref target="RFC1918"></xref>
address space on interfaces and hosts often causes default behaviors
on such hosts which may not be desirable when the endpoint is actually
connected to the Internet. For instance, one common home router warns
customers against enabling NAT when it detects private <xref
target="RFC1918"></xref> addresses on its WAN interface, and instead
encourages bridge mode. If NAT mode is enabled, the router turns the
status light amber, indicating an error.</t>
</section>
<section title="Globally Unique Space">
<t>If Shared CGN Space is not available, the total aggregate demand
for Globally-Unique space behind a CGN will be significantly higher
than the /10 requested as Shared CGN Space. In addition to use of
significant IPv4 addresses that could otherwise be offered to
subscribers, as described in <xref
target="I-D.bdgks-arin-shared-transition-space"></xref>, if various
organizations use public address space to number CGN zones, it will be
difficult for other networks/hosts to deterministically know if the
endpoints are using Internet reachable addresses, or if they are
leaking from behind a CGN, as described above (<xref
target="absd"></xref>). This situation would likely lead to additional
technical issues during various leakage conditions, make it difficult
to identify filter rule issues, and pose challenges for Content
Distribution Networks (CDNs) or other third party providers.</t>
</section>
</section>
<section title="Security Considerations">
<t>Similar to other <xref target="RFC5735"></xref> special use IPv4
addresses, Shared CGN Space as described in this document does not
directly raise security issues. However, the Internet does not
inherently protect against abuse of these addresses. Unless required for
legitimate business needs between directly-connected Service Providers,
Service Providers SHOULD filter incoming router advertisements for
Shared CGN Space. Attacks have been mounted that depend on the
unexpected use of similar special-use addresses. However, it should also
be noted that this address spaces may be used legitimately outside a
single administrative domain. Thus, network operators are encouraged to
review this document and determine what security policies should be
associated with this address block within their specific operating
environments. In many cases, Shared CGN Space will be appropriate to
include in Ingress Filter lists <xref target="RFC3704"></xref>.</t>
</section>
<section title="IANA Considerations">
<t>IANA is asked to record the allocation of an IPv4 /10 for use as
Shared CGN Space.</t>
<t>The Shared CGN Space address range is: x.x.0.0/10. [Note to RFC
Editor: this address range to be added before publication]</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC1918;
&RFC2119;
<?rfc include="reference.RFC.5735"?>
<?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.3056"?>
<?rfc include='reference.RFC.3068'?>
<?rfc include='reference.RFC.6343'?>
<?rfc include='reference.RFC.3704'?>
<?rfc include="reference.RFC.5969"?>
<?rfc include="reference.RFC.6319"?>
<?rfc include="reference.RFC.6304"?>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.I-D.draft-donley-nat444-impacts-01'?>
<reference anchor="v6ops-msg06187"
target="http://www.ietf.org/mail-archive/web/v6ops/current/msg06187.html">
<front>
<title>Re: [v6ops] IETF 79 Meeting minutes - Draft</title>
<author fullname="Akira Kato">
<organization>WIDE</organization>
</author>
<date day="16" month="Nov" year="2010" />
</front>
</reference>
</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:09 |