One document matched: draft-ietf-intarea-shared-addressing-issues-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2663 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2663.xml">
<!ENTITY RFC2993 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2993.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC3947 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3947.xml">
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC3715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3715.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5135 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5135.xml">
<!ENTITY RFC1337 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1337.xml">
<!ENTITY RFC2140 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2140.xml">
<!ENTITY RFC3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY RFC5508 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5508.xml">
<!ENTITY RFC1191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC6056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6056.xml">
<!ENTITY RFC5996 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY RFC1340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1340.xml">
<!ENTITY RFC5961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5961.xml">
<!ENTITY I-D.nishitani-cgn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nishitani-cgn.xml">
<!ENTITY I-D.gont-behave-nat-security SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.gont-behave-nat-security.xml">
<!ENTITY I-D.ietf-softwire-dual-stack-lite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-dual-stack-lite.xml">
<!ENTITY I-D.ymbk-aplusp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ymbk-aplusp.xml">
<!ENTITY I-D.ietf-behave-v6v4-xlate-stateful SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-v6v4-xlate-stateful.xml">
<!ENTITY I-D.ietf-behave-v6v4-xlate SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-v6v4-xlate.xml">
<!ENTITY I-D.despres-sam SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.despres-sam.xml">
<!ENTITY I-D.shirasaki-nat444 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shirasaki-nat444.xml">
<!ENTITY I-D.boucadair-port-range SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boucadair-port-range.xml">
<!ENTITY I-D.haddad-mext-nat64-mobility-harmful SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.haddad-mext-nat64-mobility-harmful.xml">
<!ENTITY I-D.cheshire-nat-pmp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-nat-pmp.xml">
<!ENTITY I-D.thaler-port-restricted-ip-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thaler-port-restricted-ip-issues.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-intarea-shared-addressing-issues-03" ipr="trust200902">
<front>
<title abbrev="Issues with IP Address Sharing">Issues with IP Address Sharing</title>
<author fullname="Mat Ford" initials="M." role="editor" surname="Ford">
<organization>Internet Society</organization>
<address>
<postal>
<street/>
<city>Geneva</city>
<country>Switzerland</country>
</postal>
<email>ford@isoc.org</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street/>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Alain Durand" initials="A" surname="Durand">
<organization>Juniper Networks</organization>
<address>
<email>adurand@juniper.net</email>
</address>
</author>
<author fullname="Pierre Levis" initials="P." surname="Levis">
<organization>France Telecom</organization>
<address>
<postal>
<street>42 rue des Coutures</street>
<street>BP 6243</street>
<city>Caen Cedex 4</city>
<code>14066</code>
<country>France</country>
</postal>
<email>pierre.levis@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Phil Roberts" initials="P" surname="Roberts">
<organization>Internet Society</organization>
<address>
<postal>
<street/>
<city>Reston, VA</city>
<country>USA</country>
</postal>
<email>roberts@isoc.org</email>
</address>
</author>
<date month="February" year="2011"/>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>IPv4 address exhaustion completion shared sharing issues</keyword>
<abstract>
<t>The completion of IPv4 address allocations from IANA and the RIRs is causing service
providers around the world to question how they will continue providing IPv4 connectivity
service to their subscribers when there are no longer sufficient IPv4 addresses to allocate
them one per subscriber. Several possible solutions to this problem are now emerging based
around the idea of shared IPv4 addressing. These solutions give rise to a number of issues
and this memo identifies those common to all such address sharing approaches. Such issues
include application failures, additional service monitoring complexity, new security
vulnerabilities and so on. Solution-specific discussions are out of scope.</t>
<t>Over the long term, deploying IPv6 is the only way to ease pressure on the public IPv4
address pool without the need for address sharing mechanisms that give rise to the issues
identified herein.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Allocations of IPv4 addresses from the Internet Assigned Numbers Authority (IANA) were
completed on Feburary 3, 2011 <xref target="IPv4_Pool"/>. Allocations from Regional Internet
Registries (RIRs) are anticipated to be complete around a year later, although the exact
date will vary from registry to registry. This is causing service providers around the world
to start to question how they will continue providing IPv4 connectivity service to their
subscribers when there are no longer sufficient IPv4 addresses to allocate them one per
subscriber. Several possible solutions to this problem are now emerging based around the
idea of shared IPv4 addressing. These solutions give rise to a number of issues and this
memo identifies those common to all such address sharing approaches and collects them in a
single document.</t>
<t>Over the long term, deploying IPv6 is the only way to ease pressure on the public IPv4
address pool without the need for address sharing mechanisms that give rise to the issues
identified herein. In the short term, maintaining growth of IPv4 services in the presence of
IPv4 address depletion will require address sharing. Address sharing will cause issues for
end-users, service providers and third parties such as law enforcement agencies and content
providers. This memo is intended to highlight and briefly discuss these issues.</t>
<t>Increased IPv6 deployment should reduce the burden being placed on an address sharing
solution, and should reduce the costs of operating that solution. Increasing IPv6 deployment
should cause a reduction in the number of concurrent IPv4 sessions per subscriber. If the
percentage of end-to-end IPv6 traffic significantly increases, so that the volume of IPv4
traffic begins decreasing, then the number of IPv4 sessions will decrease. The smaller the
number of concurrent IPv4 sessions per subscriber, the higher the number of subscribers able
to share the same IPv4 public address, and consequently, the lower the number of IPv4 public
addresses required. However, this effect will only occur for subscribers who have both an
IPv6 access and a shared IPv4 access. This motivates a strategy to systematically bind a
shared IPv4 access to an IPv6 access. It is difficult to foresee to what extent growing IPv6
traffic will reduce the number of concurrent IPv4 sessions, but in any event, IPv6
deployment and use should reduce the pressure on the available public IPv4 address pool.</t>
</section>
<section title="Shared Addressing Solutions">
<t>In many networks today a subscriber is provided with a single public IPv4 address at their
home or small business. For instance, in fixed broadband access, an IPv4 public address is
assigned to each CPE (Customer Premises Equipment). CPEs embed a NAT function which is
responsible for translating private IPv4 addresses (<xref target="RFC1918"/> addresses)
assigned to hosts within the local network, to the public IPv4 address assigned by the
service provider (and vice versa). Therefore, devices located with the LAN share the single
public IPv4 address and they are all associated with a single subscriber account and a
single network operator.</t>
<t>A number of proposals currently under consideration in the IETF rely upon the mechanism of
multiplexing multiple subscribers' connections over a smaller number of shared IPv4
addresses. This is a significant change. These proposals include Carrier Grade NAT (CGN.
a.k.a., LSN for Large Scale NAT) <xref target="I-D.nishitani-cgn"/>, Dual-Stack-Lite <xref
target="I-D.ietf-softwire-dual-stack-lite"/>, NAT64 <xref
target="I-D.ietf-behave-v6v4-xlate-stateful"/>
<xref target="I-D.ietf-behave-v6v4-xlate"/> , Address+Port (A+P) proposals <xref
target="I-D.ymbk-aplusp"/>, <xref target="I-D.boucadair-port-range"/> and SAM <xref
target="I-D.despres-sam"/>. <xref target="Annex"/> provides a classification of these
different types of solutions and discusses some of the design considerations to be borne in
mind when deploying large-scale address sharing. Whether we're talking about
Dual-Stack-Lite, A+P, NAT64 or CGN isn't especially important - it's the view from the
outside that matters, and given that, most of the issues identified below apply regardless
of the specific address sharing scenario in question. Issues specific to A+P proposals are
addressed in <xref target="I-D.thaler-port-restricted-ip-issues"/>.</t>
<t>In these new proposals, a single public IPv4 address would be shared by multiple homes or
small businesses (i.e., multiple subscribers) so the operational paradigm described above
would no longer apply. In this document we refer to this new paradigm as large-scale address
sharing. All these proposals extend the address space by adding port information, they
differ in the way they manage the port value.</t>
<t>Security issues associated with NAT have long been documented (see <xref target="RFC2663"/>
and <xref target="RFC2993"/> ). However, sharing IPv4 addresses across multiple subscribers
by any means, either moving the NAT functionality from the home gateway to the core of the
service provider network, or restricting the port choice in the subscriber's NAT, creates
additional issues for subscribers, content providers and network operators. Many of these
issues are created today by public Wi-Fi hotspot deployments. As such large-scale address
sharing solutions become more widespread in the face of IPv4 address depletion, these issues
will become both more severe and more commonly felt. NAT issues in the past typically only
applied to a single legal entity; as large-scale address sharing becomes more prevalent
these issues will increasingly span across multiple legal entities simultaneously.</t>
<t>All large-scale address sharing proposals share technical and operational issues and these
are addressed in the sections that follow. These issues are common to any service-provider
NAT, enterprise NAT, and also non-NAT solutions that share individual IPv4 addresses across
multiple subscribers. This document is intended to bring all of these issues together in one
place.</t>
</section>
<section title="Analysis of Issues as they Relate to First and Third Parties">
<t>In this section we present an analysis of whether the issues identified in the remainder of
this document are applicable to the organisation deploying the shared addressing mechanism
(and by extension their subscribers) and/or whether these issues impact third parties (e.g.,
content providers, law enforcement agencies, etc.). In this analysis, issues that affect
end-users are deemed to affect 1st parties, as end-users can be expected to complain to
their service provider when problems arise. Where issues can expect to be foreseen and
addressed by the party deploying the shared addressing solution, they are not
attributed.</t>
<t>In <xref target="Figure1"/> we have also tried to indicate (with 'xx') where issues are
newly created in addition to what could be expected from the introduction of a traditional
NAT device. Issues marked with a single 'x' are already present today in the case of typical
CPE NAT, however they can be expected to be more severe and widespread in the case of
large-scale address sharing.</t>
<figure anchor="Figure1" title="Shared addressing issues for first and third parties">
<artwork><![CDATA[
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| Restricted allocations of outgoing | x | |
| ports will impact performance for end users | | |
| | | |
| Incoming port negotiation mechanisms may fail | xx | |
| | | |
| Incoming connections to Assigned Ports will | x | |
| not work | | |
| | | |
| Port discovery mechanisms will not work | x | |
| | | |
| Some applications will fail to operate | x | x |
| | | |
| Assumptions about parallel/serial connections | x | x |
| may fail | | |
| | | |
+------------------------------------------------+--------+---------+
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| TCP control block sharing will be affected | x | x |
| | | |
| Reverse DNS will be affected | x | x |
| | | |
| Inbound ICMP will fail in many cases | x | x |
| | | |
| Amplification of security issues | xx | xx |
| | | |
| Fragmentation will require special handling | x | |
| | | |
| Single points of failure and increased | x | |
| network instability | | |
| | | |
| Port randomisation will be affected | x | |
| | | |
| Service usage monitoring and abuse logging | xx | xx |
| will be impacted for all elements in the chain | | |
| between service provider and content provider | | |
| | | |
| Penalty boxes will no longer work | xx | xx |
| | | |
| Spam blacklisting will be affected | xx | xx |
| | | |
| Geo-location services will be impacted | xx | xx |
| | | |
| Geo-proximity mechanisms will be impacted | xx | xx |
| | | |
| Load balancing algorithms may be impacted | | xx |
| | | |
| Authentication mechanisms may be impacted | | x |
| | | |
| Traceability of network usage and abusage will | | xx |
| be affected | | |
| | | |
| IPv6 transition mechanisms will be affected | xx | |
| | | |
| Frequent keep-alives reduce battery life | x | |
| | | |
+------------------------------------------------+--------+---------+ ]]></artwork>
</figure>
<t>As can be seen from <xref target="Figure1"/>, deployment of large-scale address sharing
will create almost as many problems for third parties as it does for the service provider
deploying the address sharing mechanism. Several of these issues are specific to the
introduction of large-scale address sharing as well. All of these issues are discussed in
further detail below.</t>
</section>
<section title="Content Provider Example">
<t>Taking a content provider as an example of a third-party, and focusing on the issues that
are created specifically by the presence of large-scale address sharing, we identify the
following issues as being of particular concern:<list style="symbols">
<t>Degraded geolocation for targeted advertising and licensed content restrictions (see
<xref target="Geoloc"/>).</t>
<t>Additional latency due to indirect routing and degraded geoproximity (see <xref
target="Geoloc"/>).</t>
<t>Exposure to new amplification attacks (see <xref target="Security"/>).</t>
<t>Service usage monitoring is made more complicated (see <xref target="Usage"/>).</t>
<t>Incoming port negotiation mechanisms may fail (see <xref target="PortNegotiation"
/>).</t>
<t>IP blocking for abuse/spam will cause collateral damage (see <xref target="Security"
/>).</t>
<t>Load balancing algorithms may be impacted (see <xref target="LoadBalancing"/>).</t>
<t>Traceability of network usage and abuse will be impacted (see <xref
target="Traceability"/>).</t>
</list></t>
</section>
<section title="Port Allocation">
<t>When we talk about port numbers we need to make a distinction between outgoing connections
and incoming connections. For outgoing connections, the actual source port number used is
usually irrelevant. (While this is true today, in a port-range solution it is necessary for
the source port to be within the allocated range). But for incoming connections, the
specific port numbers allocated to subscribers matter because they are part of external
referrals (used by third parties to contact services run by the subscribers).</t>
<t>The total number of subscribers able to share a single IPv4 address will depend upon
assumptions about the average number of ports required per active subscriber, and the
average number of simultaneously active subscribers. It is important to realise that the TCP
design makes it undesirable for clients to re-use ports while they remain in the TIME-WAIT
state (typically 4 minutes after the connection has concluded). TIME-WAIT state removes the
hazard of old duplicates for "fast" or "long" connections, in which clock-driven Initial
Sequence Number selection is unable to prevent overlap of the old and new sequence spaces.
The TIME-WAIT delay allows all old duplicate segments time enough to die in the Internet
before the connection is reopened <xref target="RFC1337"/>. Therefore ports in this state
must be included in calculations concerning port usage per subscriber.</t>
<t>Most of the time the source port selected by a client application will be translated
(unless there is direct knowledge of a port-range restriction in the client's stack), either
by a NAT in the subscriber's device, or by a CPE NAT, or by a CPE NAT and a CGN.</t>
<t><xref target="RFC1340"/> defines the Assigned Ports (both System and User). IANA has
further classified the whole port space into three categories, as defined in <xref
target="IANA_Ports"/>
<list style="symbols">
<t>The Well-Known Ports are those from 0 through 1023.</t>
<t>The Registered Ports are those from 1024 through 49151.</t>
<t>The Dynamic and/or Private Ports are those from 49152 through 65535.</t>
</list></t>
<t><xref target="RFC4787"/> notes that current NATs have different policies with regard to
this classification; some NATs restrict their translations to the use of dynamic ports, some
also include registered ports, some preserve the port if it is in the well-known range.
<xref target="RFC4787"/> makes it clear that the use of port space (1024-65535) is safe:
"mapping a source port to a source port that is already registered is unlikely to have any
bad effects". Therefore, for all address sharing solutions, there is no reason to only
consider a subset of the port space (1024-65535) for outgoing source ports.</t>
<section anchor="OutgoingPorts" title="Outgoing Ports">
<t>According to measurements the average number of outgoing ports consumed per active
subscriber is much, much smaller than the maximum number of ports a subscriber can use at
any given time. However, the distribution is heavy-tailed, so there are typically a small
number of subscribers who use a very high number of ports <xref target="CGN_Viability"/>.
This means that an algorithm that dynamically allocates outgoing port numbers from a
central pool will typically allow more subscribers to share a single IPv4 address than
algorithms that statically divide the resource by pre-allocating a fixed number of ports
to each subscriber. Similarly, such an algorithm should be more able to accommodate
subscribers wishing to use a relatively high number of ports.</t>
<t>It is important to note here that the desire to dynamically allocate outgoing port
numbers will make a service provider's job of maintaining records of subscriber port
number allocations considerably more onerous (see <xref target="Traceability"/>). The
number of records per subscriber will increase from 1 in a scheme where ports are
statically allocated, to a much larger number equivalent to the total number of outgoing
ports consumed by that subscriber during the time period for which detailed logs must be
kept.</t>
<t>A potential problem with dynamic allocation occurs when one of the subscriber devices
behind such a port-shared IPv4 address becomes infected with a worm, which then quickly
sets about opening many outbound connections in order to propagate itself. Such an
infection could rapidly exhaust the shared resource of the single IPv4 address for all
connected subscribers. It is therefore necessary to impose limits on the total number of
ports available to an individual subscriber to ensure that the shared resource (the IPv4
address) remains available in some capacity to all the subscribers using it. However,
static schemes for ports assignment may introduce security issues <xref target="RFC6056"/>
when small contiguous port ranges are statically assigned to subscribers.</t>
<t>Session failure due to NAT state overflow or timeout (when the NAT discards session state
because it's run out of resource) can be experienced when the configured quota per user is
reached or if the NAT is out of recourses.</t>
</section>
<section anchor="IncomingPorts" title="Incoming Ports">
<t>It is desirable to ensure that incoming ports remain stable over time. This is
challenging as the network doesn't know anything in particular about the applications that
it is supporting and therefore has no real notion of how long an application/service
session is still ongoing and therefore requiring port stability.</t>
<t>Early measurements <xref target="CGN_Viability"/> also seem to indicate that, on average,
only very few ports are used by subscribers for incoming connections. However, a majority
of subscribers accept at least one inbound connection.</t>
<t>This means that it is not necessary to pre-allocate a large number of incoming ports to
each subscriber. It is possible to either pre-allocate a small number of ports for
incoming connections or do port allocation on demand when the application wishing to
receive a connection is initiated. The bulk of incoming ports can be reserved as a
centralized resource shared by all subscribers using a given public IPv4 address.</t>
<section anchor="PortNegotiation" title="Port Negotiation">
<t>In current deployments, one important and widely used feature of many CPE devices is
the ability to open incoming ports (port forwarding) either manually, or with a protocol
such as Universal Plug and Play Internet Gateway Device (UPnP IGD) <xref
target="UPnP-IGD"/>. If a CGN is present, the port must also be opened in the CGN. CGN
makes subscribers dependent on their service provider for this functionality.</t>
<t>If the CPE and the CGN are required to co-operate in order for port forwarding
functionality to work, protocol development will be required to provide an automated
solution. If the CGN architecture is composed of only one NAT level (no NAT in the CPE)
as for DS-Lite, the service provider will still be required to offer some means for
configuring incoming ports by their subscribers. This may be either via a UPnP or
NAT-PMP relay over a tunnelled direct connection between the CPE and CGN, or a web
interface to configure the incoming port mapping on the CGN. Note, that such an
interface effectively makes public what was previously a private management interface
and this raises security concerns that must be addressed.</t>
<t>For port-range solutions, port forwarding capabilities may still be present at the CPE,
with the limitation that the open incoming port must be within the allocated port-range
(for instance it is not possible to open port 5002 for incoming connections if port 5002
is not within the allocated port-range).</t>
<section title="Universal Plug and Play (UPnP)">
<t>Using the UPnP semantic, an application asks "I want to use port number X, is that
ok?" and the answer is yes or no. If the answer is no, the application will typically
try the next port in sequence, until it either finds one that works or gives up after
a limited number of attempts. UPnP IGD 1.0 has no way to redirect the application to
use another port number. UPnP IGD 2.0 improves this situation and allows for
allocation of any available port.</t>
</section>
<section title="NAT Port Mapping Protocol (NAT-PMP)">
<t>NAT-PMP enables the NAT to redirect the requesting application to a port deemed to be
available for use by the NAT state mapping table.</t>
</section>
</section>
<section anchor="WKP" title="Connection to a Well-Known Port Number">
<t>Once an IPv4 address sharing mechanism is in place, inbound connections to well-known
port numbers will not work in the general case. Any application that is not port-agile
cannot be expected to work. Some workaround (e.g., redirects to a port-specific URI)
could be deployed given sufficient incentives. There exist several proposals for
'application service location' protocols which would provide a means of addressing this
problem, but historically these proposals have not gained much deployment traction.</t>
<t>For example, the use of DNS SRV records <xref target="RFC2782"/> provides a potential
solution for subscribers wishing to host services in the presence of a shared-addressing
scheme. SRV records make it possible to specify a port value related to a service,
thereby making services accessible on ports other than the Well-Known ports. It is worth
noting that this mechanism is not applicable to HTTP.</t>
</section>
<section title="Port Discovery Mechanisms">
<t>Port discovery using a UDP port to discover a service available on a corresponding TCP
port, either through broadcast, multicast or unicast, is a commonly deployed mechanism.
Unsolicited inbound UDP will be dropped by address sharing mechanisms as they have no
live mapping to enable them to forward the packet to the appropriate host. Address
sharing thereby breaks this service discovery technique.</t>
</section>
</section>
</section>
<section title="Impact on Applications">
<t>Address sharing solutions will have an impact on the following types of applications: <list
style="symbols">
<t>Applications that establish inbound communications - these applications will have to
ensure that ports selected for inbound communications are either within the allocated
range (for port-range solutions) or are forwarded appropriately by the CGN (for
CGN-based solutions). See <xref target="IncomingPorts"/> for more discussion of
this;</t>
<t>Applications that carry address and/or port information in their payload - where
translation of port and/or address information is performed at the IP and transport
layers by the address sharing solution, an ALG will also be required to ensure
application layer data is appropriately modified. Note that ALGs are required in some
cases, and in many other cases end-to-end protocol mechanisms have developed to work
around a lack of ALGs in address translators, to the point of it being preferable to
avoid any support in the NAT;</t>
<t>Applications that use fixed ports - see <xref target="WKP"/> for more discussion of
this;</t>
<t>Applications that do not use any port (e.g., ICMP) - will require special handling -
see <xref target="ICMP"/> for more discussion of this;</t>
<t>Applications that assume the uniqueness of source addresses (e.g., IP address as
identifier) - such applications will fail to operate correctly in the presence of
multiple, discrete, simultaneous connections from the same source IP address;</t>
<t>Applications that explicitly prohibit concurrent connections from the same address -
such applications will fail when multiple subscribers sharing an IP address attempt to
use them simultaneously.</t>
<t>Applications that do not use TCP or UDP for transport - All IP address sharing
mechanisms proposed to date are limited to TCP, UDP, and ICMP, thereby preventing end
users from fully utilizing the Internet (e.g., SCTP, DCCP, RSVP, protocol 41
(IPv6-over-IPv4), protocol 50 (IPsec ESP)).</t>
</list></t>
<t>Applications already frequently implement mechanisms in order to circumvent the presence of
NATs (typically CPE NATs): <list style="symbols">
<t>Application Layer Gateways (ALGs): Many CPE devices today embed ALGs that allow
applications to behave correctly despite the presence of NAT on the CPE. When the NAT
belongs to the subscriber, the subscriber has flexibility to tailor the device to his or
her needs. For CGNs, subscribers will be dependent on the set of ALGs that their service
provider makes available. For port-range solutions, ALGs will require modification to
deal with the port-range restriction, but will otherwise have the same capabilities as
today. Note that ALGs are required in some cases, and in many other cases end-to-end
protocol mechanisms have developed to work around lack of ALGs, to the point of it being
preferable to avoid any support in the NAT.</t>
<t>NAT Traversal Techniques: There are several commonly-deployed mechanisms that support
operating servers behind a NAT by forwarding specific TCP or UDP ports to specific
internal hosts (<xref target="UPnP-IGD"/>, <xref target="I-D.cheshire-nat-pmp"/>, and
manual configuration). All of these mechanisms assume the NAT's WAN address is a
publicly-routable IP address, and fail to work normally when that assumption is wrong.
There have been attempts to avoid that problem by automatically disabling the NAT
function and bridging traffic instead upon assignment of a private IP address to the WAN
interface (as is required for <xref target="Windows-Logo"/> certification). Bridging
(rather than NATting) has other side effects (DHCP requests are served by an upstream
DHCP server which can increase complexity of in-home networking).</t>
</list></t>
</section>
<section anchor="Geoloc" title="Geo-location and Geo-proximity">
<t>IP addresses are frequently used to indicate, with some level of granularity and some level
of confidence, where a host is physically located. Using IP addresses in this fashion is a
heuristic at best, and is already challenged today by other deployed capabilities, e.g.
tunnels. Geo-location services are used by content providers to allow them to conform with
regional content licensing restrictions, to target advertising at specific geographic areas,
or to provide customised content. Geo-location services are also necessary for emergency
services provision. In some deployment contexts (e.g., centralised CGN), shared addressing
will reduce the level of confidence and level of location granularity that IP-based
geo-location services can provide. Viewed from the content provider, a subscriber behind a
CGN geolocates to wherever the prefix of the CGN appears to be; very often that will be in a
different city than the subscriber. Other forms of geo-location will still work as
usual.</t>
<t>A slightly different use of an IP address is to calculate the proximity of a connecting
host to a particular service delivery point. This use of IP address information impacts the
efficient delivery of content to an end-user. If a CGN is introduced in communications and
it is far from an end-user connected to it, application performance may be degraded insofar
as IP-based geo-proximity is a factor.</t>
</section>
<section anchor="Usage" title="Tracking Service Usage">
<t>As large-scale address sharing becomes more commonplace, monitoring the number of unique
users of a service will become more complex than simply counting the number of connections
from unique IP addresses. While this is a somewhat inexact methodology today due to the
widespread use of CPE NAT, it will become a much less useful approach in the presence of
widespread large-scale address sharing solutions. In general, all elements that monitor
usage or abusage in the chain between a service provider that has deployed address sharing
and a content provider will need to be upgraded to take account of the port value in
addition to IP addresses.</t>
</section>
<section anchor="ICMP" title="ICMP">
<t>ICMP does not include a port field and is consequently problematic for address sharing
mechanisms. Some ICMP message types include a fragment of the datagram that triggered the
signal to be sent, which is assumed to include port numbers. For some ICMP message types,
the Identifier field has to be used as a demuxing token. Sourcing ICMP echo messages from
hosts behind an address sharing solution does not pose problems, although responses to
outgoing ICMP echo messages will require special handling, such as making use of the ICMP
identifier value to route the response appropriately.</t>
<t>For inbound ICMP there are two cases. The first case is that of ICMP sourced from outside
the network of the address sharing solution provider. Where ICMP messages include a fragment
of an outgoing packet including port numbers it may be possible to forward the packet
appropriately. In addition to these network signalling messages, several applications (e.g.,
P2P applications) make use of ICMP echo messages which include no hints that could be used
to route the packet correctly. Measurements derived by such applications in the presence of
an address sharing solution will be erroneous or fail altogether. The second case is that of
ICMP sourced from within the network of the address sharing solution provider (e.g., for
network management, signalling and diagnostic purposes). In this case ICMP can be routed
normally for CGN-based solutions owing to the presence of locally unique private IP
addresses for each CPE device. For port-range solutions, ICMP echo messages will not be
routable without special handling, e.g., placing a port number in the ICMP identifier field,
and having port-range routers make routing decisions based upon that field.</t>
<t>Considerations related to ICMP message handling in NAT-based environments are specified in
<xref target="RFC5508"/>.</t>
</section>
<section anchor="MTU" title="MTU">
<t>In applications where the end hosts are attempting to use path MTU Discovery <xref
target="RFC1191"/> to optimize transmitted packet size with underlying network MTU, shared
addressing has a number of items which must be considered. As covered in <xref target="ICMP"
/>, ICMP "Packet Too Big" messages must be properly translated through the address sharing
solution in both directions. However, even when this is done correctly, MTU can be a
concern. Many end hosts cache PMTUd information for a certain period of time. If the MTU
behind the address sharing solution is inconsistent, the public end host may have the
incorrect MTU value cached. This may cause it to send packets that are too large, causing
them to be dropped if the DF (Don't Fragment) bit is set, or causing them to be fragmented
by the network, increasing load and overhead. Because the host eventually will reduce MTU to
the lowest common value for all hosts behind a given public address, it may also send
packets that are below optimal size for the specific connection, increasing overhead and
reducing throughput.</t>
<t>This issue also generates a potential attack vector, that a malevolent user could send an
ICMP "Packet Too Big" (Type 3, Code 4) message indicating a Next-Hop MTU of anything down to
68 octets. This value will be cached by the off-net server for all subscribers sharing the
address of the malevolent user. This could lead to a DoS against both the remote server and
the large-scale NAT device itself (as they will both have to handle many more packets per
second).</t>
</section>
<section title="Fragmentation">
<t>When a packet is fragmented, transport-layer port information (either UDP or TCP) is only
present in the first fragment. Subsequent fragments will not carry the port information and
so will require special handling. In addition, the IP Identifier may no longer be unique as
required by the receiver to aid in assembling the fragments of a datagram.</t>
</section>
<section anchor="Traceability" title="Traceability">
<t>In many jurisdictions, service providers are legally obliged to provide the identity of a
subscriber upon request to the appropriate authorities. Such legal requests have
traditionally included the source IPv4 address and date (and usually the time), which is
sufficient information when subscribers are assigned IPv4 addresses for a long duration.</t>
<t>However, where one public IPv4 address is shared between several subscribers, the IPv4
address no longer uniquely identifies a subscriber. There are two solutions to this problem:
<list style="symbols">
<t>The first solution is for servers to additionally log the source port of incoming
connections and for the legal request to include the source port. The legal request
should include the information: [Source IP address, Source Port, Timestamp] (and
possibly other information). Accurate time-keeping (e.g., use of NTP or SNTP) is vital
because port assignments are dynamic. A densely populated CGN could mean even very small
amounts of clock skew between a third party's server and the CGN operator will result in
ambiguity about which customer was using a specific port at a given time.</t>
<t>The second solution considers it is unrealistic to expect all servers to log the source
port number of incoming connections. To deal with this, service providers using IPv4
address sharing may need to log IP destination addresses.</t>
</list></t>
<t>Destination logging is imperfect if multiple subscribers are accessing the same (popular)
server at nearly the same time, it can be impossible to disambiguate which subscriber
accessed the server, especially with protocols that involve several connections (e.g.,
HTTP). Thus, logging the destination address on the NAT is inferior to logging the source
port at the server.</t>
<t>If neither solution is used (that is, the server is not logging source port numbers and the
NAT is not logging destination IP addresses), the service provider cannot trace the
offending activity to a specific subscriber. In this circumstance, the service provider
would need to disclose the identity of all subscribers who had active sessions on the NAT
during the time period in question. This may be a large number of subscribers.</t>
<t>Address sharing solutions must record and store all mappings (typically during 6-12 months,
depending on the local jurisdiction) that they create. If we consider one mapping per
session, a service provider should record and retain traces of all sessions created by all
subscribers during one year (if the legal storage duration is one year). This may be
challenging due to the volume of data requiring storage, the volume of data to repeatedly
transfer to the storage location, and the volume of data to search in response to a
query.</t>
<t>Address sharing solutions may mitigate these issues to some extent by pre-allocating groups
of ports. Then only the allocation of the group needs to be recorded, and not the creation
of every session binding within that group. There are trade-offs to be made between the
sizes of these port groups, the ratio of public addresses to subscribers, whether or not
these groups timeout, the impact on logging requirements and port randomisation security
<xref target="RFC6056"/>.</t>
</section>
<section anchor="Security" title="Security">
<t>Before noting some specific security-related issues caused by large-scale address sharing,
it is perhaps worth noting that, in general, address sharing creates a vector for attack
amplification in numerous ways. See <xref target="MTU"/> for one example.</t>
<section title="Abuse Logging and Penalty Boxes">
<t>When an abuse is reported today, it is usually done in the form: IPv4 address X has done
something bad at time T0. This is not enough information to uniquely identify the
subscriber responsible for the abuse when that IPv4 address is shared by more than one
subscriber. Law enforcement authorities may be particularly impacted because of this. This
particular issue can be fixed by logging port numbers, although this will increase logging
data storage requirements.</t>
<t>A number of services on the network today log the IPv4 source addresses used in
connection attempts to protect themselves from certain attacks. For example, if a server
sees too many requests from the same IPv4 address in a short period of time, it may decide
to put that address in a penalty box for a certain time during which requests are denied,
or it may require completion of a CAPTCHA for future requests. If an IPv4 address is
shared by multiple subscribers, this would have unintended consequences in a couple of
ways. First it may become the natural behavior to see many login attempts from the same
address because it is now shared across a potentially large number of subscribers. Second
and more likely is that one user who fails a number of login attempts may block out other
users who have not made any previous attempts but who will now fail on their first
attempt. In the presence of widespread large-scale address sharing, penalty box solutions
to service abuse simply will not work.</t>
</section>
<section title="Authentication">
<t>Simple address-based identification mechanisms that are used to populate access control
lists will fail when an IP address is no longer sufficient to identify a particular
subscriber. Including port numbers in access control list definitions may be possible at
the cost of extra complexity, and may also require the service provider to make static
port assignments, which conflicts with the requirement for dynamic assignments discussed
in <xref target="OutgoingPorts"/>.</t>
<t>Address or DNS-name based signatures (e.g. some X.509 signatures) may also be affected by
address sharing as the address itself is now a shared token, and the name to address mapping may
not be current.</t>
</section>
<section title="Spam">
<t>Another case of identifying abusers has to do with spam blacklisting. When a spammer is
behind a CGN or using a port-shared address, blacklisting of their IP address will result
in all other subscribers sharing that address having their ability to source SMTP packets
restricted to some extent.</t>
</section>
<section anchor="random" title="Port Randomisation">
<t>A blind attack that can be performed against TCP relies on the attacker's ability to
guess the 5-tuple (Protocol, Source Address, Destination Address, Source Port, Destination
Port) that identifies the transport protocol instance to be attacked. <xref
target="RFC6056"/> describes a number of methods for the random selection of the source
port number, such that the ability of an attacker to correctly guess the 5-tuple is
reduced. With shared IPv4 addresses, the port selection space is reduced. Preserving port
randomisation is important and may be more or less difficult depending on the address
sharing solution and the size of the port space that is being manipulated. Allocation of
non-contiguous port ranges could help to mitigate this issue.</t>
<t>It should be noted that guessing the port information may not be sufficient to carry out
a successful blind attack. An in-window TCP Sequence Number (SN) should also be known or
guessed. A TCP segment is processed only if all previous segments have been received,
except for some Reset segment implementations which immediately process the Reset as long
as it is within the Window. If SN is randomly chosen it will be difficult to guess it (SN
is 32 bits long); port randomisation is one protection among others against blind attacks.
There is more detailed discussion of improving TCP's robustness to Blind In-Window Attacks
in <xref target="RFC5961"/>.</t>
</section>
<section title="IPsec">
<t>The impact of large-scale IP address sharing for IPsec operation should be evaluated and
assessed. <xref target="RFC3947"/> proposes a solution to solve issues documented in <xref
target="RFC3715"/> . <xref target="RFC5996"/> specifies Internet Key Exchange Protocol
Version 2 which includes NAT traversal mechanisms that are now widely used to enable IPsec
to work in the presence of NATs in many cases. Nevertheless, service providers may wish to
ensure that CGN deployments do not inadvertently block NAT traversal for security
protocols such as IKE (refer to <xref target="I-D.gont-behave-nat-security"/> for more
information).</t>
</section>
<section title="Policing Forwarding Behaviour">
<t><xref target="RFC2827"/> motivates and discusses a simple, effective, and straightforward
method for using ingress traffic filtering to prohibit Denial-of-Service (DoS) attacks
which use forged IP addresses. Following this recommendation, service providers operating
shared-addressing mechanisms should ensure that source addresses, or source ports in the
case of port-range schemes, are set correctly in outgoing packets from their subscribers
or they should drop the packets.</t>
<t>If some form of IPv6 ingress filtering is deployed in the broadband network and DS-Lite
service is restricted to those subscribers, then tunnels terminating at the CGN and coming
from registered subscriber IPv6 addresses cannot be spoofed. Thus a simple access control
list on the tunnel transport source address is all that is required to accept traffic on
the southbound interface of a CGN.</t>
</section>
</section>
<section title="Transport Issues">
<section title="Parallel connections">
<t>Systems that assume that multiple simultaneous connections to a single IP address implies
connectivity to a single host - such systems may experience unexpected results.</t>
</section>
<section title="Serial connections">
<t>Systems that assume that returning to a given IP address means returning to the same
physical host, as with stateful transactions. This may also affect cookie-based
systems.</t>
</section>
<section title="TCP Control Block Sharing">
<t><xref target="RFC2140"/> defines a performance optimisation for TCP based on sharing
state between TCP control blocks that pertain to connections to the same host, as opposed
to maintaining state for each discrete connection. This optimisation assumes that an
address says something about the properties of the path between two hosts, which is
clearly not the case if the address in question is shared by multiple hosts at different
physical network locations. While CPE NAT today causes problems for sharing TCP control
block state across multiple connections to a given IP address, large-scale address sharing
will make these issues more severe and more widespread.</t>
</section>
</section>
<section title="Reverse DNS">
<t>Many service providers populate forward and reverse DNS zones for the public IPv4 addresses
that they allocate to their subscribers. In the case where public addresses are shared
across multiple subscribers, such strings are, by definition, no longer sufficient to
identify an individual subscriber without additional information.</t>
</section>
<section anchor="LoadBalancing" title="Load Balancing">
<t>Algorithms used to balance traffic load for popular destinations may be affected by the
introduction of address sharing. Where balancing is achieved by deterministically routing
traffic from specific source IP addresses to specific servers, imbalances in load may be
experienced as address sharing is enabled for some of those source IP addresses. This will
require re-evaluation of the algorithms used in the load-balancing design. In general, as
the scale of address sharing grows, load-balancing designs will need to be re-evaluated and
any assumptions about average load per source IP address revisited.</t>
</section>
<section title="IPv6 Transition Issues">
<t>IPv4 address sharing solutions may interfere with existing IPv4 to IPv6 transition
mechanisms, which were not designed with IPv4 shortage considerations in mind. With
port-range solutions for instance, incoming 6to4 packets should be able to find their way
from a 6to4 relay to the appropriate 6to4 CPE router, despite the lack of direct port range
information (UDP/TCP initial source port did not pass through the CPE port range translation
process). One solution would be for a 6to4 IPv6 address to embed not only an IPv4 address
but also a port range value.</t>
<t>Subscribers allocated with private addresses will not be able to utilise 6to4 to access
IPv6, but may be able to utilise Teredo.</t>
<t>Shared addresses should be drawn from space designated as such <xref target="RFC1918"/>.
Otherwise their use will break the widely implemented assumption that public IPv4 addresses
are globally unique addresses and hence break many protocols and applications, e.g., 6to4
<xref target="RFC3056"/>. Some routers enable 6to4 on their WAN link. 6to4 requires a
publicly-routable IPv4 address. Enabling 6to4 when the apparently public IPv4 WAN address is
in fact behind a NAT creates a disconnected IPv6 island. Issues created by sharing public
address space across multiple hosts are specifically addressed in <xref
target="I-D.thaler-port-restricted-ip-issues"/>.</t>
</section>
<section title="Introduction of Single Points of Failure">
<t>In common with all deployments of new network functionality, the introduction of new nodes
or functions to handle the multiplexing of multiple subscribers across shared IPv4 addresses
could create single points of failure in the network. Any IP address sharing solution should
consider the opportunity to add redundancy features in order to alleviate the impact on the
robustness of the offered IP connectivity service. The ability of the solution to allow hot
swapping from one machine to another should be considered. This is especially important
where the address sharing solution in question requires the creation of per-flow state in
the network.</t>
</section>
<section title="State Maintenance Reduces Battery Life">
<t>In order for hosts to maintain network state in the presence of NAT, keep-alive messages
have to be sent at frequent intervals. For battery-powered devices, sending these keep-alive
messages can result in significantly reduced battery performance than would otherwise be the
case <xref target="Mobile_Energy_Consumption"/>.</t>
</section>
<section title="Support of Multicast">
<t><xref target="RFC5135"/> specifies requirements for a NAT that supports Any Source IP
Multicast or Source-Specific IP Multicast. Port-range routers that form part of port-range
solutions will need to support similar requirements if multicast support is required.</t>
</section>
<section title="Support of Mobile-IP">
<t>IP address sharing within the context of Mobile-IP deployments (in the home network and/or
in the visited network), will require Home Agents and/or Foreign Agents to be updated so as
to take into account the relevant port information. There may also be issues raised when an
additional layer of encapsulation is required thereby causing, or increasing the need for,
fragmentation and reassembly.</t>
<t>Issues for Mobile-IP in the presence of NAT are discussed in <xref
target="I-D.haddad-mext-nat64-mobility-harmful"/></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section title="Security Considerations">
<t>This memo does not define any protocol and therefore creates no new security issues. <xref
target="Security"/> discusses some of the security and identity-related implications of IP
address sharing.</t>
</section>
<section title="Contributors">
<t>This document is based on sources co-authored by J.L. Grimault and A. Villefranque of
France Telecom.</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>This memo was partly inspired by conversations that took place as part of Internet Society
(ISOC) hosted roundtable events for operators and content providers deploying IPv6.
Participants in those discussions included John Brzozowski, Leslie Daigle, Tom Klieber, Yiu
Lee, Kurtis Lindqvist, Wes George, Lorenzo Colliti, Erik Kline, Igor Gashinsky, Jason
Fesler, Rick Reed, Adam Bechtel, Larry Campbell, Tom Coffeen, David Temkin, Pete Gelbman,
Mark Winter, Will Charnock, Martin Levy, Greg Wood and Christian Jacquenet.</t>
<t>The authors are also grateful to Christian Jacquenet, Iain Calder, Joel Halpern, Brian
Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo Bagnulo, Dan Wing and Wes George for their
helpful comments and suggestions for improving the document.</t>
<t>This memo was created using the xml2rfc tool.</t>
</section>
<section anchor="Annex" title="Annex">
<section title="Classes of Address Sharing Solution">
<t>IP address sharing solutions fall into two classes. Either a service-provider operated
NAT function is introduced and subscribers are allocated addresses from <xref
target="RFC1918"/> space, or public IPv4 addresses are shared across multiple
subscribers by restricting the range of ports available to each subscriber. These classes
of solution are described in a bit more detail below. <list style="symbols">
<t>CGN-based solutions: These solutions propose the introduction of a NAPT function in
the service provider's network, denoted also as Carrier Grade NAT (CGN), or Large
Scale NAT (LSN) <xref target="I-D.nishitani-cgn"/> , or Provider NAT. The CGN is
responsible for translating private addresses to publicly routable addresses. Private
addresses are assigned to subscribers, a pool of public addresses is assigned to the
CGN, and the number of public addresses is smaller than the number of subscribers. A
public IPv4 address in the CGN pool is shared by several subscribers at the same time.
Solutions making use of a service provider-based NAT include <xref
target="I-D.shirasaki-nat444"/> (two layers of NAT) and <xref
target="I-D.ietf-softwire-dual-stack-lite"/> (a single layer of NAT).</t>
<t>Port-range solutions: These solutions avoid the presence of a CGN function. A single
public IPv4 address is assigned to several subscribers at the same time. A restricted
port range is also assigned to each subscriber so that two subscribers with the same
IPv4 address have two different port ranges that do not overlap. These solutions are
called A+P (Address+Port) <xref target="I-D.ymbk-aplusp"/> , or Port Range <xref
target="I-D.boucadair-port-range"/> , or SAM (Stateless Address Mapping) <xref
target="I-D.despres-sam"/> .</t>
</list></t>
</section>
<section anchor="asmf" title="Address Space Multiplicative Factor">
<t>The purpose of sharing public IPv4 addresses is to increase the addressing space. A key
parameter is the factor by which service providers want or need to multiply their IPv4
public address space; and the consequence is the number of subscribers sharing the same
public IPv4 address. We refer to this parameter as the address space multiplicative
factor, the inverse is called the compression ratio.</t>
<t>The multiplicative factor can only be applied to the subset of subscribers that are
eligible for a shared address. The reasons a subscriber cannot have a shared address can
be: <list style="symbols">
<t>It would not be compatible with the service they are currently subscribed to (for
example: business subscriber).</t>
<t>Subscriber CPE is not compatible with the address sharing solution selected by the
service provider (for example it does not handle port restriction for port-range
solutions or it does not allow IPv4 in IPv6 encapsulation for the DS-Lite solution),
and its replacement is not easy.</t>
</list></t>
<t>Different service providers may have very different needs. A long-lived service provider,
whose number of subscribers is rather stable, may have an existing address pool that will
only need a small extension to cope with the next few years, assuming that this address
pool can be re-purposed for an address sharing solution (small multiplicative factor, less
than 10). A new entrant or a new line of business will need a much bigger multiplicative
factor (e.g., 1000). A mobile operator may see its addressing needs grow dramatically as
the IP-enabled mobile handset market grows.</t>
<t>When the multiplicative factor is large, the average number of ports per subscriber is
small. Given the large measured disparity between average and peak port consumption <xref
target="CGN_Viability"/> , this will create service problems in the event that ports are
allocated statically. In this case, it is essential for port allocation to map to need as
closely as possible, and to avoid allocating ports for longer than necessary. Therefore,
the larger the multiplicative factor, the more dynamic the port assignment has to be.</t>
</section>
</section>
</middle>
<back>
<references title="Informative References"> &RFC1337; &RFC2140; &RFC2663; &RFC2993; &RFC2782;
&RFC5135; &RFC5508; &RFC1191; &RFC2827; &RFC3947; &RFC1918; &RFC3715; &RFC4787; &RFC3056;
&RFC5961; &RFC1340; &RFC5996; &RFC6056; &I-D.gont-behave-nat-security; &I-D.nishitani-cgn;
&I-D.ietf-softwire-dual-stack-lite; &I-D.ietf-behave-v6v4-xlate-stateful; &I-D.ymbk-aplusp;
&I-D.despres-sam; &I-D.ietf-behave-v6v4-xlate; &I-D.shirasaki-nat444;
&I-D.boucadair-port-range; &I-D.haddad-mext-nat64-mobility-harmful; &I-D.cheshire-nat-pmp;
&I-D.thaler-port-restricted-ip-issues; <reference anchor="IPv4_Pool"
target="http://icann.org/en/news/releases/release-03feb11-en.pdf">
<front>
<title>Available Pool of Unallocated IPv4 Internet Addresses Now Completely
Emptied</title>
<author initials="ICANN" surname="ICANN">
<organization>ICANN</organization>
</author>
<date year="2011"/>
</front>
</reference>
<reference anchor="CGN_Viability"
target="http://www.wand.net.nz/~salcock/someisp/flow_counting/result_page.html">
<front>
<title>Research into the Viability of Service-Provider NAT</title>
<author initials="S" surname="Alcock">
<organization>WAND Network Research Group</organization>
</author>
<date year="2008"/>
</front>
</reference>
<reference anchor="Mobile_Energy_Consumption" target="http://research.nokia.com/node/5597">
<front>
<title>Energy Consumption of Always-On Applications in WCDMA Networks</title>
<author initials="H" surname="Haverinen"/>
<author initials="J" surname="Siren"/>
<author initials="P" surname="Eronen"/>
<date year="2007"/>
</front>
</reference>
<reference anchor="UPnP-IGD" target="http://upnp.org/specs/gw/igd2/">
<front>
<title>Universal Plug and Play (UPnP) Internet Gateway Device (IGD) V 2.0</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization/>
</author>
<date month="December" year="2010"/>
</front>
</reference>
<reference anchor="IANA_Ports" target="http://www.iana.org/assignments/port-numbers">
<front>
<title>IANA Port Number Assignments</title>
<author/>
<date month="February" year="2011"/>
</front>
</reference>
<reference anchor="Windows-Logo"
target="http://www.microsoft.com/whdc/winlogo/hwrequirements/default.mspx">
<front>
<title>Windows Logo Program Device Requirements</title>
<author fullname="Microsoft" surname="Microsoft">
<organization/>
</author>
<date year="2006"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:34:56 |