One document matched: draft-ford-shared-addressing-issues-01.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 I-D.nishitani-cgn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nishitani-cgn.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">
<!ENTITY I-D.shirasaki-nat444 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shirasaki-nat444">
<!ENTITY I-D.boucadair-port-range SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boucadair-port-range">
<!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-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-ford-shared-addressing-issues-01"
	ipr="trust200902">

	<front>

		<title abbrev="Issues with IP Address Sharing">Issues with IP Address Sharing</title>

		<author fullname="Mat Ford" initials="M" surname="Ford" role="editor">
			<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>
				<email>mohamed.boucadair@orange-ftgroup.com</email>
			</address>
		</author>

		<author fullname="Alain Durand" initials="A" surname="Durand">
			<organization>Comcast</organization>
			<address>
				<email>Alain_Durand@cable.comcast.com</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 year="2009" />

		<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 attempts to
				identify 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"/>. 
            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 attempts to identify those common to all such address sharing approaches. 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 these issues.</t>
            
            <t>In the presence of continued network growth, and in the absence of very widespread dual-stack deployment, increased IP address sharing is inevitable. A restricted 
            type of IPv4 connectivity service is going to operate in parallel with the existing IPv4 Internet of today. This restricted Internet service isn't going to be the 
            same as existing services - some applications aren't going to work and third-parties will also be impacted.</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 small set of users,
				and a single subscriber account with 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. These proposals
				include Carrier Grade 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" />
				, IVI
				<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" />
				.
			</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. All these proposals extend the address space by
				adding
				port information, they differ in the way they manage the port
				value.
			</t>

			<t>
				IP address sharing solutions fall into two classes. Either a
				centralised, 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>

			<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. All the
				proposals listed above
				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
				(e.g. A+P).
			</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 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.</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" />
				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. In any case, limiting
				the number of ports available
				will
				limit the compression ratio.
			</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.</t>

			</section>

			<section anchor="Incoming Ports" 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 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 of
						incoming
						ports by their subscribers.
						This may be either via a UPnP or NAT-PMP
						relay over a tunnelled
						direct connection between CPE and CGN or a web interface to configure the incoming port on the CGN. Note, 
                        that such an interface effectively makes public what was previously a private service interface and this may raise security concerns.</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 always 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 the 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 (e.g. a web server accessible on a port other than
						port 80).
					</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="Incoming Ports"/> 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"/> 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"/> for more discusion 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>
				</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
						<xref target="RFC3947" />
						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: ICE, STUN, TURN, etc.</t>
				</list>
			</t>
		</section>

<section title="ICMP" anchor="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. 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. Responses to outgoing ICMP should make use of the ICMP identifier value to route the response appropriately. 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 discrete private IP addresses for each CPE device. For port-range solutions, ICMP will  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. Alternatively another protocol could be used for diagnostic purposes, e.g UDP ping.</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 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>
            <t>[Placeholder for more details of impact of address-sharing on multicast deployments.]</t>
		</section>

		<section title="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>
                <t>[Placeholder for more details of impact of address-sharing on mobility deployments.]</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.</t>

		</section>

		<section anchor="Security" title="Security">
			<section 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" />
					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="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 application servers on the network today log IPv4
					addresses in connection
					attempts to protect themselves from certain
					attacks. For example, if a
					server sees too
					many login attempts from
					the same IPv4 address, it may decide to put
					that address in a
					penalty box for a certain time. 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.</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 title="IPsec">
				<t>
					Even if IPSec is not deployed for mass market (e.g. residential),
					impacts of solutions based on shared IP addresses should be
					evaluated
					and assessed.
					<xref target="RFC3947" />
					proposes a solution to
					solve issues documented in
					<xref target="RFC3715" />
					. The
					applicability of
					<xref target="RFC3947" />
					in the context of
					shared IP address solutions should be evaluated.
				</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="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
				geolocation services can provide. 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 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>
		</section>

		<section anchor="Traceability" title="Traceability">
			<t>Legal obligations require a service provider to provide the
				identity of a
				subscriber upon request to the authorities. Where one
				public IPv4
				address is shared between several subscribers, the
				knowledge of the
				IP address alone is not enough to identify the
				appropriate
				subscriber. The legal request should include the
				information: [IP
				address - Port - Protocol- Begin_Timestamp -
				End_Timestamp].</t>

			<t>Address sharing solutions must record and store all mappings
				(typically during 6 months
				to one year, depending on the
				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 groups, the ratio of public addresses to
				subscribers, whether or not these groups timeout, the impact on
				logging requirements and port randomisation security.</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>

		</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 raises no security
				issues.
				<xref target="Security" />
				discusses some of the security and identity-related implications
				of
				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. The authors are
				also
				grateful to Christian Jacquenet, Iain Calder, Joel Halpern, Brian
				Carpenter, Gregory
				Lebovitz, Bob Briscoe and Marcelo Bagnulo for
				their helpful comments and
				suggestions for
				improving this document.
			</t>

			<t>This memo was created using the xml2rfc tool.</t>
		</section>
	</middle>

	<back>

		<references title="Informative References"> &RFC2663; &RFC2993; &RFC2782; &RFC5135; &RFC2827; &RFC3947; &RFC1918;
     &RFC3715; &RFC4787; &I-D.nishitani-cgn; &I-D.ietf-softwire-dual-stack-lite; &I-D.ymbk-aplusp;
      &I-D.ietf-behave-v6v4-xlate-stateful; &I-D.despres-sam; &I-D.ietf-behave-v6v4-xlate;
       &I-D.ietf-tsvwg-port-randomization; &I-D.shirasaki-nat444; &I-D.boucadair-port-range; &I-D.haddad-mext-nat64-mobility-harmful;

			<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>

		</references>
	</back>
</rfc>