One document matched: draft-weil-shared-transition-space-request-10.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-10"
ipr="trust200902" updates="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="30" month="November" year="2011" />
<abstract>
<t>This document requests the allocation of an IPv4 /10 address block to
be used as Shared Carrier Grade Network Address Translation (CGN) Space.
Service Providers will use Shared CGN Space to number the interfaces
that connect CGN devices to Customer Premise Equipment (CPE). As this
document proposes the allocation of an additional special-use IPv4
address block, it updates RFC 5735.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IPv4 address space is nearly exhausted. However, ISPs must continue
to support IPv4 growth until IPv6 is fully deployed. To that end, many
ISPs will deploy Carrier Grade NAT (CGN) such as that described in <xref
target="RFC6264"></xref>. In order to effectively deploy CGN, ISPs
require a new IPv4 /10 address block. This address block will be called
the Shared CGN Space and will be used to number the interfaces that
connect CGN devices to CPE.</t>
<t>Shared CGN Space is distinct from <xref target="RFC1918"></xref>
address space. Like <xref target="RFC1918"></xref> space, Shared CGN
Space must be unique to the network but need not be globally unique.
Unlike <xref target="RFC1918"></xref> address space, Shared CGN Space is
not available for any purpose other than numbering the interfaces that
connect a CGN to CPE.</t>
<t>This document requests the allocation of an IPv4 /10 address block to
be used as Shared Carrier Grade Network (CGN) Space. In conversations
with many ISPs, a /10 is the smallest block that will allow them to
deploy CGNs on a regional basis without requiring nested CGNs. For
Instance, as described in <xref
target="I-D.shirasaki-isp-shared-addr"></xref>, a /10 is sufficient to
service Points of Presence in the Tokyo area.</t>
<t>As this document proposes the allocation of an additional special-use
IPv4 address block, it updates <xref target="RFC5735"></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="Alternatives to Shared CGN Space">
<t>The interfaces that connect CGN devices to CPE might conceivably be
numbered from any of the following address spaces: <list style="symbols">
<t>legitimately assigned globally unique address space</t>
<t>usurped globally unique address space (i.e., squat space)</t>
<t><xref target="RFC1918"></xref> space</t>
<t>Shared CGN Space</t>
</list></t>
<t>A Service Provider can number the interfaces in question from
legitimately assigned globally unique address space. While this solution
poses the fewest problems, it is impractical because globally unique
IPv4 address space is in short supply. While the Regional Internet
Registries (RIR) have enough address space to allocate a single /10 to
be shared by all Service Providers, they do not have enough address
space to make a unique assignment to each Service Provider.</t>
<t>Service Providers MUST NOT number the interfaces in question from
usurped globally unique address space (i.e., squat space). If a Service
Provider leaks advertisements for squat space into the global Internet,
the legitimate owners of that address space may be adversely impacted,
as would those wishing to communicate with them. Even if the Service
Provider did not leak advertisements for squat space, the Service
Provider and its subscribers might lose connectivity to the legitimate
owner of that address space.</t>
<t>A Service Provider can number the interfaces in question from <xref
target="RFC1918"></xref> space if either of the following conditions are
true: <list style="symbols">
<t>The Service Provider knows that the CPE/NAT works correctly when
the same <xref target="RFC1918"></xref> address block is used both
on its inside and outside interfaces.</t>
<t>The Service Provider knows that the <xref
target="RFC1918"></xref> address block that it uses to number
interfaces between the CGN and CPE is not used on the subscriber
side of the CPE.</t>
</list>Unless at least one of the conditions above is true, the
Service Provider cannot safely use <xref target="RFC1918"></xref>
address space and must resort to Shared CGN Space. This is typically the
case in an unmanaged service, where subscribers provide their own CPE
and number their own internal network.</t>
</section>
<section title="Use of Shared CGN Space">
<t>Shared CGN Space is IPv4 address space reserved for Service Provider
use with the purpose of facilitating CGN deployment. Specifically:<list
style="symbols">
<t>Shared CGN Space MUST NOT be utilized for any purpose other than
as "inside" addresses in a CGN environment (e.g., between the CGN
and CPE).</t>
<t>Network equipment manufacturers MUST NOT use Shared CGN Space in
default or example device configurations.</t>
<t>Shared CGN Space MUST NOT be used on the customer premise side of
a subscriber NAT device.</t>
</list></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 across Service Provider boundaries. Service
Providers MUST filter incoming advertisements regarding Shared CGN
Space. One exception to the above proscription against exchanging routes
for Shared CGN Space is in the case of a defined business relationship
between two Service Providers (e.g., for hosted CGN service).</t>
<t>Packets with Shared CGN Space source or destination addresses MUST
NOT be forwarded across Service Provider boundaries. Service Providers
MUST filter such packets on ingress links. As above, one exception to
the above proscriptions is in the case of business relationships such as
hosted CGN service.</t>
<t>When running a single DNS infrastructure, Service Providers MUST NOT
include Shared CGN Space in zone files. When running a split DNS
infrastructure, Service Providers MUST NOT include Shared CGN Space in
external-facing zone files.</t>
<t>Reverse DNS queries for Shared CGN Space addresses MUST NOT be
forwarded to the global DNS infrastructure. DNS Providers SHOULD filter
requests for Shared CGN Space reverse DNS queries on recursive
nameservers. 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>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>
<section title="Risk">
<t></t>
<section title="Analysis">
<t>Some existing applications discover the outside address of their
local CPE, determine whether the address is reserved for special-use,
and behave differently based on that determination. If a new IPv4
address block is reserved for special-use and that block is used to
number CPE outside interfaces, some of the above-mentioned
applications may fail.</t>
<t>For example, assume that an application requires its peer (or some
other device) to initiate an incoming connection directly with its CPE
outside address. That application discovers the outside address of its
CPE and determines whether that address is reserved for special-use.
If the address is reserved for special-use, the application rightly
concludes the that address is not reachable from the global Internet
and behaves in one manner. If the address is not reserved for
special-use, the application assumes that the address is reachable
from the global Internet and behaves in another manner.</t>
<t>While the assumption that a non-special-use address is reachable
from the global Internet is generally safe, it is not always true
(e.g., when the CPE outside interface is numbered from globally unique
address space but that address is not advertised to the global
Internet as when it is behind a CGN). Such an assumption could cause
certain applications to behave incorrectly in those cases.</t>
</section>
<section title="Empirical Data">
<t>As described in <xref target="RFC6269"></xref> and <xref
target="I-D.donley-nat444-impacts"></xref>, CGNs offer a reasonable
quality of experience for many basic services including web, email,
and Instant Messaging. This is true regardless of whether the address
range between the CGN and CPE is globally unique, Shared CGN Space, or
<xref target="RFC1918"></xref> space. However, CGNs do adversely
impact some advanced services, in particular:<list style="numbers">
<t>Console gaming – some games fail when two subscribers
using the same outside public IPv4 address try to connect to each
other.</t>
<t>Video streaming – performance is impacted when using one
of several popular video streaming technologies to deliver
multiple video streams to users behind particular CPE routers.</t>
<t>Peer-to-peer – some peer-to-peer applications cannot seed
content due to the inability to open incoming ports through the
CGN. Likewise, some SIP client implementations cannot receive
incoming calls unless they first initiate outgoing traffic or open
an incoming port through the CGN using <xref
target="I-D.ietf-pcp-base"></xref> or similar mechanism.</t>
<t>Geo-location - geo-location systems identify the location of
the CGN server, not the end host.</t>
<t>Simultaneous logins - some websites (particularly banking and
social networking websites) restrict the number of simultaneous
logins per outside public IPv4 address.</t>
<t>6to4 - 6to4 requires globally reachable addresses, and will not
work in networks that employ addresses with limited topological
span such as those employing CGNs.</t>
</list></t>
<t>Based on testing documented in <xref
target="I-D.donley-nat444-impacts"></xref>, the CGN impacts on 1-5 are
comparable regardless of whether globally unique, Shared CGN Space, or
<xref target="RFC1918"></xref> addresses are used. There is, however,
a difference between the three alternatives in the treatment of
6to4.</t>
<t>As described in <xref target="RFC6343"></xref>, CPE routers do not
attempt to initialize 6to4 tunnels when they are configured with <xref
target="RFC1918"></xref> or <xref target="RFC5735"></xref> WAN
addresses. When configured with globally unique or Shared CGN Space
addresses, such devices may attempt to initiate 6to4, which would
fail. Service Providers can mitigate this issue using 6to4-PMT <xref
target="I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel"></xref> or
blocking the route to 192.88.99.1 and generating an IPv4 'destination
unreachable' message <xref target="RFC6343"></xref>. When the address
range is well-defined, as with Shared CGN Space, CPE 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 <xref target="RFC1918"></xref> space. When the CGN-CPE
address range is not well-defined, as in the case of globally unique
space, it will be more difficult for CPE router vendors to mitigate
against this issue.</t>
<t>Thus, when comparing the use of <xref target="RFC1918"></xref> and
Shared CGN Space, Shared CGN Space poses an additional impact on 6to4
connectivity, which can be mitigated by Service Provider or CPE router
vendor action. On the other hand, the use of <xref
target="RFC1918"></xref> address space poses more of a challenge
vis-a-vis Shared CGN Space when the subscriber and Service Provider
use overlapping <xref target="RFC1918"></xref> space, which will be
outside the Service Provider's control in the case of unmanaged
service. Service Providers have indicated that it is more challenging
to mitigate the possibility of overlapping <xref
target="RFC1918"></xref> address space on both sides of the CPE router
than it is to mitigate the 6to4 impacts of Shared CGN Space.</t>
</section>
</section>
<section title="Security Considerations">
<t>Similar to other <xref target="RFC5735"></xref> special use IPv4
addresses, Shared CGN Space does not directly raise security issues.
However, the Internet does not inherently protect against abuse of these
addresses. Attacks have been mounted that depend on the unexpected use
of similar special-use addresses. 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 and should consider including Shared CGN Space in Ingress
Filter lists <xref target="RFC3704"></xref> unless their Internet
service incorporates a CGN.</t>
<t>To mitigate against potential misuse of Shared CGN Space, except
where required for hosted CGN service or similar business relationship,
<list style="symbols">
<t>Routing information about Shared CGN Space networks MUST NOT be
propagated across Service Provider boundaries. Service Providers
MUST filter incoming advertisements regarding Shared CGN Space.</t>
<t>Packets with Shared CGN Space source or destination addresses
MUST NOT be forwarded across Service Provider boundaries. Service
Providers MUST filter such packets on ingress links.</t>
<t>Service Providers MUST NOT include Shared CGN Space in
external-facing DNS zone files.</t>
<t>Reverse DNS queries for Shared CGN Space addresses MUST NOT be
forwarded to the global DNS infrastructure.</t>
<t>DNS Providers SHOULD filter requests for Shared CGN Space reverse
DNS queries on recursive nameservers.</t>
</list></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"?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.draft-shirasaki-isp-shared-addr-06'?>
<?rfc include="reference.I-D.draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-03"?>
<?rfc include='reference.RFC.6343'?>
<?rfc include='reference.RFC.3704'?>
<?rfc include="reference.RFC.6304"?>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.I-D.draft-donley-nat444-impacts-03'?>
<?rfc include='reference.RFC.6264'?>
<?rfc include='reference.I-D.draft-ietf-pcp-base-13'?>
</references>
<section title="Acknowledgments">
<t>Thanks to the following people (in alphabetical order) for their
guidance and feedback: <list style="hanging">
<t>Stan Barber</t>
<t>John Brzozowski</t>
<t>Isaiah Connell</t>
<t>Greg Davies</t>
<t>Owen DeLong</t>
<t>Kirk Erichsen</t>
<t>Wes George</t>
<t>Chris Grundemann</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 |