One document matched: draft-ietf-intarea-shared-addressing-issues-02.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 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.ietf-tsvwg-port-randomization SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-port-randomization.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-02"
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></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></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></street>
<city>Reston, VA</city>
<country>USA</country>
</postal>
<email>roberts@isoc.org</email>
</address>
</author>
<date month="October" year="2010" />
<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. Solution-specific discussions are out
of scope.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Allocations of IPv4 addresses from the Internet Assigned Numbers
Authority (IANA) are currently forecast to be complete during 2011 <xref
target="IPv4_Report"></xref>. Allocations from some 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 and thereby mitigate 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"></xref> 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"></xref>,
Dual-Stack-Lite <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref>, NAT64 <xref
target="I-D.ietf-behave-v6v4-xlate-stateful"></xref> <xref
target="I-D.ietf-behave-v6v4-xlate"></xref> , Address+Port (A+P)
proposals <xref target="I-D.ymbk-aplusp"></xref>, <xref
target="I-D.boucadair-port-range"></xref> and SAM <xref
target="I-D.despres-sam"></xref>. <xref target="Annex"></xref> 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"></xref>.</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"></xref> and <xref target="RFC2993"></xref> ).
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"></xref> 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 |
+------------------------------------------------+--------+---------+
| Overly restrictive allocations of outgoing | x | |
| ports will impact performance for end users | | |
| | | |
| Incoming port negotiation mechanisms may fail | xx | |
| | | |
| Incoming connections to Well-Known Ports will | x | |
| not work | | |
| | | |
| Some applications will fail to operate | x | x |
| | | |
| TCP control block sharing will be affected | x | x |
| | | |
+------------------------------------------------+--------+---------+
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| 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"></xref>, 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"></xref>).</t>
<t>Additional latency due to indirect routing and degraded
geoproximity (see <xref target="Geoloc"></xref>).</t>
<t>Exposure to new amplification attacks (see <xref
target="Security"></xref>).</t>
<t>Service usage monitoring is made more complicated (see <xref
target="Usage"></xref>).</t>
<t>Incoming port negotiation mechanisms may fail (see <xref
target="PortNegotiation"></xref>).</t>
<t>IP blocking for abuse/spam will cause collateral damage (see
<xref target="Security"></xref>).</t>
<t>Load balancing algorithms may be impacted (see <xref
target="LoadBalancing"></xref>).</t>
<t>Traceability of network usage and abuse will be impacted (see
<xref target="Traceability"></xref>).</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"></xref>. 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>IANA has classified the whole port space into three categories (as
defined in http://www.iana.org/assignments/port-numbers): <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"></xref> 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"></xref> 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"></xref>. 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"></xref>). 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="I-D.ietf-tsvwg-port-randomization"></xref> 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"></xref> 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 UPnP IGD. If
a CGN is present, the port must also be open in the CGN. The
situation may be alleviated somewhat if the CGN architecture is
composed of only one NAT level (no NAT in the CPE) as for DS-Lite,
although a service provider operating this solution 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 has, currently, no way to
redirect the application to use another port number. UPnP IGD 2.0,
currently being defined, should improve this and allow for
allocation of any available port.</t>
</section>
<section title="NAT Port Mapping Protocol (NAT-PMP)">
<t>NAT-PMP already has a better semantic here, enabling the NAT to
redirect the application to an available port number.</t>
</section>
</section>
<section anchor="WKP" title="Connection to a Well-Known Port Number">
<t>Once an IPv4 address sharing mechanism is in place, 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"></xref> 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>
</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"></xref> 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;</t>
<t>Applications that use fixed ports (e.g., well-known ports) - see
<xref target="WKP"></xref> for more discussion of this;</t>
<t>Applications that do not use any port (e.g., ICMP) - where
address sharing solutions map subscribers to (private) IP addresses
on a one-to-one basis this will not be an issue, otherwise such
applications will require special handling - see <xref
target="ICMP"></xref> 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. A service
provider-based NAT may, or may not, support NAT-traversal for IKE
<xref target="RFC3947"></xref> for example. For port-range
solutions, ALGs will require modification to deal with the
port-range restriction, but will otherwise have the same
capabilities as today.</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>, <xref
target="I-D.cheshire-nat-pmp"></xref>, 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"></xref>
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. 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, and sometimes in a different country, 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 carry any port information and is consequently
problematic for address sharing mechanisms. Sourcing ICMP from hosts
behind an address sharing solution does not pose problems, although
responses to outgoing ICMP 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. Several applications make use of this (e.g., P2P applications)
and measurements derived by such applications in the presence of an
address sharing solution will be erroneous. The second case is that of
ICMP sourced from within the network of the address sharing solution
provider (e.g., for network management 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 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 messages handling in NAT-based
environments are specified in <xref target="RFC5508"></xref>.</t>
</section>
<section title="MTU">
<t>In applications where the end hosts are attempting to use path MTU
Discovery <xref target="RFC1191"></xref> 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"></xref>, 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.</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 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="I-D.ietf-tsvwg-port-randomization"></xref>.</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="ICMP"></xref> 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"></xref>
.</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="I-D.ietf-tsvwg-port-randomization"></xref> 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. The exact TCP
Sequence Number (SN) should also be known. 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.</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"></xref>
proposes a solution to solve issues documented in <xref
target="RFC3715"></xref> . The applicability of <xref
target="RFC3947"></xref> in the context of shared IP address solutions
should be evaluated. In particular, 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"></xref> for more
information).</t>
</section>
<section title="Policing Forwarding Behaviour">
<t><xref target="RFC2827"></xref> 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="TCP Control Block Sharing">
<t><xref target="RFC2140"></xref> 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 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, sudden 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"></xref>. 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"></xref>. 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"></xref>.</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"></xref>.</t>
</section>
<section title="Support of Multicast">
<t><xref target="RFC5135"></xref> 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"></xref></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"></xref> 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="Acknowledgements" title="Acknowledgements">
<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"></xref> 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"></xref> , 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"></xref> (two layers of NAT) and
<xref target="I-D.ietf-softwire-dual-stack-lite"></xref> (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"></xref> , or Port Range <xref
target="I-D.boucadair-port-range"></xref> , or SAM (Stateless
Address Mapping) <xref target="I-D.despres-sam"></xref> .</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"></xref> , 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">
<?rfc include='reference.RFC.1337'?>
<?rfc include='reference.RFC.2140'?>
<?rfc include='reference.RFC.2663'?>
<?rfc include='reference.RFC.2993'?>
<?rfc include='reference.RFC.2782'?>
<?rfc include='reference.RFC.5135'?>
<?rfc include='reference.RFC.2827'?>
<?rfc include='reference.RFC.3947'?>
<?rfc include='reference.RFC.1918'?>
<?rfc include='reference.RFC.3715'?>
<?rfc include='reference.RFC.4787'?>
<?rfc include='reference.RFC.3056'?>
<?rfc include='reference.RFC.1191'?>
<?rfc include='reference.I-D.gont-behave-nat-security'?>
<?rfc include='reference.I-D.nishitani-cgn'?>
<?rfc include='reference.I-D.ietf-softwire-dual-stack-lite'?>
<?rfc include='reference.I-D.ymbk-aplusp'?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate-stateful'?>
<?rfc include='reference.I-D.despres-sam'?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate'?>
<?rfc include='reference.I-D.ietf-tsvwg-port-randomization'?>
<?rfc include='reference.I-D.shirasaki-nat444'?>
<?rfc include='reference.I-D.boucadair-port-range'?>
<?rfc include='reference.I-D.haddad-mext-nat64-mobility-harmful'?>
<?rfc include='reference.I-D.cheshire-nat-pmp'?>
<?rfc include='reference.I-D.thaler-port-restricted-ip-issues'?>
<reference anchor="IPv4_Report"
target="http://www.potaroo.net/tools/ipv4/index.html">
<front>
<title>IPv4 Address Report</title>
<author initials="G" surname="Huston">
<organization>Geoff Huston</organization>
</author>
<date year="2009" />
</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>
<author initials="J" surname="Siren"></author>
<author initials="P" surname="Eronen"></author>
<date year="2007" />
</front>
</reference>
<reference anchor="UPnP-IGD"
target="http://www.upnp.org/standardizeddcps/igd.asp">
<front>
<title>Universal Plug and Play (UPnP) Internet Gateway Device
(IGD)</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date month="November" year="2001" />
</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></organization>
</author>
<date year="2006" />
</front>
</reference>
<?rfc include='reference.RFC.5508'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:19:36 |