draft-ietf-intarea-shared-addressing-issues-00.txt   draft-ietf-intarea-shared-addressing-issues-01.txt 
Internet Engineering Task Force M. Ford, Ed. Internet Engineering Task Force M. Ford, Ed.
Internet-Draft Internet Society Internet-Draft Internet Society
Intended status: Informational M. Boucadair Intended status: Informational M. Boucadair
Expires: December 6, 2010 France Telecom Expires: January 1, 2011 France Telecom
A. Durand A. Durand
Comcast Juniper Networks
P. Levis P. Levis
France Telecom France Telecom
P. Roberts P. Roberts
Internet Society Internet Society
June 4, 2010 June 30, 2010
Issues with IP Address Sharing Issues with IP Address Sharing
draft-ietf-intarea-shared-addressing-issues-00 draft-ietf-intarea-shared-addressing-issues-01
Abstract Abstract
The completion of IPv4 address allocations from IANA and the RIRs is The completion of IPv4 address allocations from IANA and the RIRs is
causing service providers around the world to question how they will causing service providers around the world to question how they will
continue providing IPv4 connectivity service to their subscribers continue providing IPv4 connectivity service to their subscribers
when there are no longer sufficient IPv4 addresses to allocate them when there are no longer sufficient IPv4 addresses to allocate them
one per subscriber. Several possible solutions to this problem are one per subscriber. Several possible solutions to this problem are
now emerging based around the idea of shared IPv4 addressing. These now emerging based around the idea of shared IPv4 addressing. These
solutions give rise to a number of issues and this memo identifies solutions give rise to a number of issues and this memo identifies
those common to all such address sharing approaches. Solution- those common to all such address sharing approaches. Solution-
specific discussions are out of scope. specific discussions are out of scope.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 1, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Shared Addressing Solutions . . . . . . . . . . . . . . . . . 4 2. Shared Addressing Solutions . . . . . . . . . . . . . . . . . 4
3. Analysis of Issues as they Relate to First and Third 3. Analysis of Issues as they Relate to First and Third
Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 7 4. Content Provider Example . . . . . . . . . . . . . . . . . . . 8
4.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 8 5. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 10 5.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Connection to a Well-Known Port Number . . . . . . . . 10 5.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 10
5. Impact on Applications . . . . . . . . . . . . . . . . . . . . 11 5.2.2. Connection to a Well-Known Port Number . . . . . . . . 11
6. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 12 6. Impact on Applications . . . . . . . . . . . . . . . . . . . . 12
7. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 12 7. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 13
8. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 14
9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 13 9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 14 12. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 16
11.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 17
11.4. Port Randomisation . . . . . . . . . . . . . . . . . . . . 15 12.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.4. Port Randomisation . . . . . . . . . . . . . . . . . . . . 17
11.6. Policing Forwarding Behaviour . . . . . . . . . . . . . . 16 12.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. TCP Control Block Sharing . . . . . . . . . . . . . . . . . . 16 12.6. Policing Forwarding Behaviour . . . . . . . . . . . . . . 18
13. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. TCP Control Block Sharing . . . . . . . . . . . . . . . . . . 18
14. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 17 14. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 18
15. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 17 15. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 19
16. Introduction of Single Points of Failure . . . . . . . . . . . 18 16. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 19
17. State Maintenance Reduces Battery Life . . . . . . . . . . . . 18 17. Introduction of Single Points of Failure . . . . . . . . . . . 19
18. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 18 18. State Maintenance Reduces Battery Life . . . . . . . . . . . . 20
19. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 18 19. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 20
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 20. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 20
21. Security Considerations . . . . . . . . . . . . . . . . . . . 19 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
22. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 22. Security Considerations . . . . . . . . . . . . . . . . . . . 20
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 23. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
24. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 24. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
24.1. Classes of Address Sharing Solution . . . . . . . . . . . 19 25. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
24.2. Address Space Multiplicative Factor . . . . . . . . . . . 20 25.1. Classes of Address Sharing Solution . . . . . . . . . . . 21
25. Informative References . . . . . . . . . . . . . . . . . . . . 21 25.2. Address Space Multiplicative Factor . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 26. Informative References . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Allocations of IPv4 addresses from the Internet Assigned Numbers Allocations of IPv4 addresses from the Internet Assigned Numbers
Authority (IANA) are currently forecast to be complete during 2011 Authority (IANA) are currently forecast to be complete during 2011
[IPv4_Report]. Allocations from some Regional Internet Registries [IPv4_Report]. Allocations from some Regional Internet Registries
(RIRs) are anticipated to be complete around a year later, although (RIRs) are anticipated to be complete around a year later, although
the exact date will vary from registry to registry. This is causing the exact date will vary from registry to registry. This is causing
service providers around the world to start to question how they will service providers around the world to start to question how they will
continue providing IPv4 connectivity service to their subscribers continue providing IPv4 connectivity service to their subscribers
skipping to change at page 5, line 23 skipping to change at page 5, line 23
A number of proposals currently under consideration in the IETF rely A number of proposals currently under consideration in the IETF rely
upon the mechanism of multiplexing multiple subscribers' connections upon the mechanism of multiplexing multiple subscribers' connections
over a smaller number of shared IPv4 addresses. This is a over a smaller number of shared IPv4 addresses. This is a
significant change. These proposals include Carrier Grade NAT (CGN) significant change. These proposals include Carrier Grade NAT (CGN)
[I-D.nishitani-cgn] , Dual-Stack-Lite [I-D.nishitani-cgn] , Dual-Stack-Lite
[I-D.ietf-softwire-dual-stack-lite] , NAT64 [I-D.ietf-softwire-dual-stack-lite] , NAT64
[I-D.ietf-behave-v6v4-xlate-stateful] , IVI [I-D.ietf-behave-v6v4-xlate-stateful] , IVI
[I-D.ietf-behave-v6v4-xlate] , Address+Port (A+P) proposals [I-D.ietf-behave-v6v4-xlate] , Address+Port (A+P) proposals
[I-D.ymbk-aplusp] , [I-D.boucadair-port-range] and SAM [I-D.ymbk-aplusp] , [I-D.boucadair-port-range] and SAM
[I-D.despres-sam]. Section 24 provides a classification of these [I-D.despres-sam]. Section 25 provides a classification of these
different types of solution and discusses some of the design different types of solution and discusses some of the design
considerations to be borne in mind when deploying large-scale address considerations to be borne in mind when deploying large-scale address
sharing. 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
[I-D.thaler-port-restricted-ip-issues].
In these new proposals, a single public IPv4 address would be shared In these new proposals, a single public IPv4 address would be shared
by multiple homes or small businesses (i.e. multiple subscribers) so by multiple homes or small businesses (i.e. multiple subscribers) so
the operational paradigm described above would no longer apply. In the operational paradigm described above would no longer apply. In
this document we refer to this new paradigm as large-scale address this document we refer to this new paradigm as large-scale address
sharing. All these proposals extend the address space by adding port sharing. All these proposals extend the address space by adding port
information, they differ in the way they manage the port value. information, they differ in the way they manage the port value.
Security issues associated with NAT have long been documented (see Security issues associated with NAT have long been documented (see
[RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across [RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across
skipping to change at page 6, line 22 skipping to change at page 6, line 27
identified in the remainder of this document are applicable to the identified in the remainder of this document are applicable to the
organisation deploying the shared addressing mechanism (and by organisation deploying the shared addressing mechanism (and by
extension their subscribers) and/or whether these issues impact third extension their subscribers) and/or whether these issues impact third
parties (e.g. content providers, law enforcement agencies, etc.). In parties (e.g. content providers, law enforcement agencies, etc.). In
this analysis, issues that affect end-users are deemed to affect 1st this analysis, issues that affect end-users are deemed to affect 1st
parties, as end-users can be expected to complain to their service parties, as end-users can be expected to complain to their service
provider when problems arise. Where issues can expect to be foreseen provider when problems arise. Where issues can expect to be foreseen
and addressed by the party deploying the shared addressing solution, and addressed by the party deploying the shared addressing solution,
they are not attributed. they are not attributed.
In Figure 1 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.
+------------------------------------------------+--------+---------+ +------------------------------------------------+--------+---------+
| Issue | 1st | 3rd | | Issue | 1st | 3rd |
| | party | parties | | | party | parties |
+------------------------------------------------+--------+---------+ +------------------------------------------------+--------+---------+
| Overly restrictive allocations of outgoing | x | | | Overly restrictive allocations of outgoing | x | |
| ports will impact performance for end users | | | | ports will impact performance for end users | | |
| | | | | | | |
| Incoming port negotiation mechanisms may fail | x | | | Incoming port negotiation mechanisms may fail | xx | |
| | | | | | | |
| Incoming connections to Well-Known Ports will | x | | | Incoming connections to Well-Known Ports will | x | |
| not work | | | | not work | | |
| | | | | | | |
| Some applications will fail to operate | x | x | | Some applications will fail to operate | x | x |
| | | | | | | |
| TCP control block sharing will be affected | x | x | | TCP control block sharing will be affected | x | x |
| | | | | | | |
+------------------------------------------------+--------+---------+
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| Reverse DNS will be affected | x | x | | Reverse DNS will be affected | x | x |
| | | | | | | |
| Inbound ICMP will fail in many cases | x | x | | Inbound ICMP will fail in many cases | x | x |
| | | | | | | |
| Amplification of security issues | x | x | | Amplification of security issues | xx | xx |
| | | | | | | |
| Fragmentation will require special handling | x | | | Fragmentation will require special handling | x | |
| | | | | | | |
| Single points of failure and increased | x | | | Single points of failure and increased | x | |
| network instability | | | | network instability | | |
| | | | | | | |
| Port randomisation will be affected | x | | | Port randomisation will be affected | x | |
| | | | | | | |
+------------------------------------------------+--------+---------+ | Service usage monitoring and abuse logging | xx | xx |
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| Service usage monitoring and abuse logging | x | x |
| will be impacted for all elements in the chain | | | | will be impacted for all elements in the chain | | |
| between service provider and content provider | | | | between service provider and content provider | | |
| | | | | | | |
| Penalty boxes will no longer work | x | x | | Penalty boxes will no longer work | xx | xx |
| | | | | | | |
| Spam blacklisting will be affected | x | x | | Spam blacklisting will be affected | xx | xx |
| | | | | | | |
| Geo-location services will be impacted | x | x | | Geo-location services will be impacted | xx | xx |
| | | | | | | |
| Geo-proximity mechanisms will be impacted | x | x | | Geo-proximity mechanisms will be impacted | xx | xx |
| | | | | | | |
| Load balancing algorithms may be impacted | | x | | Load balancing algorithms may be impacted | | xx |
| | | | | | | |
| Authentication mechanisms may be impacted | | x | | Authentication mechanisms may be impacted | | x |
| | | | | | | |
| Traceability of network usage and abusage will | | x | | Traceability of network usage and abusage will | | xx |
| be affected | | | | be affected | | |
| | | | | | | |
| IPv6 transition mechanisms will be affected | x | | | IPv6 transition mechanisms will be affected | xx | |
| | | | | | | |
| Frequent keep-alives reduce battery life | x | | | Frequent keep-alives reduce battery life | x | |
| | | | | | | |
+------------------------------------------------+--------+---------+ +------------------------------------------------+--------+---------+
Figure 1: Shared addressing issues for first and third parties Figure 1: Shared addressing issues for first and third parties
As can be seen from Figure 1, deployment of large-scale address As can be seen from Figure 1, deployment of large-scale address
sharing will create almost as many problems for third parties as it sharing will create almost as many problems for third parties as it
does for the service provider deploying the address sharing does for the service provider deploying the address sharing
mechanism. All of these issues are discussed in further detail mechanism. Several of these issues are specific to the introduction
below. of large-scale address sharing as well. All of these issues are
discussed in further detail below.
4. Port Allocation 4. Content Provider Example
Taking a content provider as an example of a third-party, and
focussing 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:
o Degraded geolocation for targeted advertising and licensed content
restrictions (see Section 7).
o Additional latency due to indirect routing and degraded
geoproximity (see Section 7).
o Exposure to new amplification attacks (see Section 12).
o Service usage monitoring is made more complicated (see Section 8).
o Incoming port negotiation mechanisms may fail (see Section 5.2.1).
o IP blocking for abuse/spam will cause collateral damage (see
Section 12).
o Load balancing algorithms may be impacted (see Section 15).
o Traceability of network usage and abuse will be impacted (see
Section 11).
5. Port Allocation
When we talk about port numbers we need to make a distinction between When we talk about port numbers we need to make a distinction between
outgoing connections and incoming connections. For outgoing outgoing connections and incoming connections. For outgoing
connections, the actual source port number used is usually connections, the actual source port number used is usually
irrelevant. (While this is true today, in a port-range solution it irrelevant. (While this is true today, in a port-range solution it
is necessary for the source port to be within the allocated range). is necessary for the source port to be within the allocated range).
But for incoming connections, the specific port numbers allocated to But for incoming connections, the specific port numbers allocated to
subscribers matter because they are part of external referrals (used subscribers matter because they are part of external referrals (used
by third parties to contact services run by the subscribers). by third parties to contact services run by the subscribers).
skipping to change at page 8, line 44 skipping to change at page 9, line 38
[RFC4787] notes that current NATs have different policies with regard [RFC4787] notes that current NATs have different policies with regard
to this classification; some NATs restrict their translations to the to this classification; some NATs restrict their translations to the
use of dynamic ports, some also include registered ports, some use of dynamic ports, some also include registered ports, some
preserve the port if it is in the well-known range. [RFC4787] makes preserve the port if it is in the well-known range. [RFC4787] makes
it clear that the use of port space (1024-65535) is safe: "mapping a 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 source port to a source port that is already registered is unlikely
to have any bad effects". Therefore, for all address sharing to have any bad effects". Therefore, for all address sharing
solutions, there is no reason to only consider a subset of the port solutions, there is no reason to only consider a subset of the port
space (1024-65535) for outgoing source ports. space (1024-65535) for outgoing source ports.
4.1. Outgoing Ports 5.1. Outgoing Ports
According to measurements the average number of outgoing ports According to measurements the average number of outgoing ports
consumed per active subscriber is much, much smaller than the maximum consumed per active subscriber is much, much smaller than the maximum
number of ports a subscriber can use at any given time. However, the number of ports a subscriber can use at any given time. However, the
distribution is heavy-tailed, so there are typically a small number distribution is heavy-tailed, so there are typically a small number
of subscribers who use a very high number of ports [CGN_Viability]. of subscribers who use a very high number of ports [CGN_Viability].
This means that an algorithm that dynamically allocates outgoing port This means that an algorithm that dynamically allocates outgoing port
numbers from a central pool will typically allow more subscribers to numbers from a central pool will typically allow more subscribers to
share a single IPv4 address than algorithms that statically divide share a single IPv4 address than algorithms that statically divide
the resource by pre-allocating a fixed number of ports to each the resource by pre-allocating a fixed number of ports to each
subscriber. Similarly, such an algorithm should be more able to subscriber. Similarly, such an algorithm should be more able to
accommodate subscribers wishing to use a relatively high number of accommodate subscribers wishing to use a relatively high number of
ports. ports.
It is important to note here that the desire to dynamically allocate It is important to note here that the desire to dynamically allocate
outgoing port numbers will make a service provider's job of outgoing port numbers will make a service provider's job of
maintaining records of subscriber port number allocations maintaining records of subscriber port number allocations
considerably more onerous (see Section 10). The number of records considerably more onerous (see Section 11). The number of records
per subscriber will increase from 1 in a scheme where ports are per subscriber will increase from 1 in a scheme where ports are
statically allocated, to a much larger number equivalent to the total statically allocated, to a much larger number equivalent to the total
number of outgoing ports consumed by that subscriber during the time number of outgoing ports consumed by that subscriber during the time
period for which detailed logs must be kept. period for which detailed logs must be kept.
A potential problem with dynamic allocation occurs when one of the A potential problem with dynamic allocation occurs when one of the
subscriber devices behind such a port-shared IPv4 address becomes subscriber devices behind such a port-shared IPv4 address becomes
infected with a worm, which then quickly sets about opening many infected with a worm, which then quickly sets about opening many
outbound connections in order to propagate itself. Such an infection outbound connections in order to propagate itself. Such an infection
could rapidly exhaust the shared resource of the single IPv4 address could rapidly exhaust the shared resource of the single IPv4 address
for all connected subscribers. It is therefore necessary to impose for all connected subscribers. It is therefore necessary to impose
limits on the total number of ports available to an individual limits on the total number of ports available to an individual
subscriber to ensure that the shared resource (the IPv4 address) subscriber to ensure that the shared resource (the IPv4 address)
remains available in some capacity to all the subscribers using it. remains available in some capacity to all the subscribers using it.
4.2. Incoming Ports 5.2. Incoming Ports
It is desirable to ensure that incoming ports remain stable over It is desirable to ensure that incoming ports remain stable over
time. This is challenging as the network doesn't know anything in time. This is challenging as the network doesn't know anything in
particular about the applications that it is supporting and therefore particular about the applications that it is supporting and therefore
has no real notion of how long an application/service session is has no real notion of how long an application/service session is
still ongoing and therefore requiring port stability. still ongoing and therefore requiring port stability.
Early measurements [CGN_Viability] also seem to indicate that, on Early measurements [CGN_Viability] also seem to indicate that, on
average, only very few ports are used by subscribers for incoming average, only very few ports are used by subscribers for incoming
connections. However, a majority of subscribers accept at least one connections. However, a majority of subscribers accept at least one
inbound connection. inbound connection.
This means that it is not necessary to pre-allocate a large number of 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- incoming ports to each subscriber. It is possible to either pre-
allocate a small number of ports for incoming connections or do port allocate a small number of ports for incoming connections or do port
allocation on demand when the application wishing to receive a allocation on demand when the application wishing to receive a
connection is initiated. The bulk of incoming ports can be reserved connection is initiated. The bulk of incoming ports can be reserved
as a centralized resource shared by all subscribers using a given as a centralized resource shared by all subscribers using a given
public IPv4 address. public IPv4 address.
4.2.1. Port Negotiation 5.2.1. Port Negotiation
In current deployments, one important and widely used feature of many In current deployments, one important and widely used feature of many
CPE devices is the ability to open incoming ports (port forwarding) 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 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 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 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 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 provider operating this solution will still be required to offer some
means for configuring incoming ports by their subscribers. This may means for configuring incoming ports by their subscribers. This may
be either via a UPnP or NAT-PMP relay over a tunnelled direct be either via a UPnP or NAT-PMP relay over a tunnelled direct
skipping to change at page 10, line 27 skipping to change at page 11, line 18
the incoming port mapping on the CGN. Note, that such an interface the incoming port mapping on the CGN. Note, that such an interface
effectively makes public what was previously a private management effectively makes public what was previously a private management
interface and this raises security concerns that must be addressed. interface and this raises security concerns that must be addressed.
For port-range solutions, port forwarding capabilities may still be For port-range solutions, port forwarding capabilities may still be
present at the CPE, with the limitation that the open incoming port present at the CPE, with the limitation that the open incoming port
must be within the allocated port-range (for instance it is not must be within the allocated port-range (for instance it is not
possible to open port 5002 for incoming connections if port 5002 is possible to open port 5002 for incoming connections if port 5002 is
not within the allocated port-range). not within the allocated port-range).
4.2.1.1. Universal Plug and Play (UPnP) 5.2.1.1. Universal Plug and Play (UPnP)
Using the UPnP semantic, an application asks "I want to use port 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 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, no, the application will typically try the next port in sequence,
until it either finds one that works or gives up after a limited until it either finds one that works or gives up after a limited
number of attempts. UPnP has, currently, no way to redirect the number of attempts. UPnP has, currently, no way to redirect the
application to use another port number. UPnP IGD 2.0, currently application to use another port number. UPnP IGD 2.0, currently
being defined, should improve this and allow for allocation of any being defined, should improve this and allow for allocation of any
available port. available port.
4.2.1.2. NAT Port Mapping Protocol (NAT-PMP) 5.2.1.2. NAT Port Mapping Protocol (NAT-PMP)
NAT-PMP already has a better semantic here, enabling the NAT to NAT-PMP already has a better semantic here, enabling the NAT to
redirect the application to an available port number. redirect the application to an available port number.
4.2.2. Connection to a Well-Known Port Number 5.2.2. Connection to a Well-Known Port Number
Once an IPv4 address sharing mechanism is in place, connections to Once an IPv4 address sharing mechanism is in place, connections to
well-known port numbers will not work in the general case. Any well-known port numbers will not work in the general case. Any
application that is not port-agile cannot be expected to work. Some application that is not port-agile cannot be expected to work. Some
workaround (e.g. redirects to a port-specific URI) could be deployed workaround (e.g. redirects to a port-specific URI) could be deployed
given sufficient incentives. There exist several proposals for given sufficient incentives. There exist several proposals for
'application service location' protocols which would provide a means 'application service location' protocols which would provide a means
of addressing this problem, but historically these proposals have not of addressing this problem, but historically these proposals have not
gained much deployment traction. gained much deployment traction.
For example, the use of DNS SRV records [RFC2782] provides a For example, the use of DNS SRV records [RFC2782] provides a
potential solution for subscribers wishing to host services in the potential solution for subscribers wishing to host services in the
presence of a shared-addressing scheme. SRV records make it possible presence of a shared-addressing scheme. SRV records make it possible
to specify a port value related to a service, thereby making services to specify a port value related to a service, thereby making services
accessible on ports other than the Well-Known ports. It is worth accessible on ports other than the Well-Known ports. It is worth
noting that this mechanism is not applicable to HTTP. noting that this mechanism is not applicable to HTTP.
5. Impact on Applications 6. Impact on Applications
Address sharing solutions will have an impact on the following types Address sharing solutions will have an impact on the following types
of applications: of applications:
o Applications that establish inbound communications - these o Applications that establish inbound communications - these
applications will have to ensure that ports selected for inbound applications will have to ensure that ports selected for inbound
communications are either within the allocated range (for port- communications are either within the allocated range (for port-
range solutions) or are forwarded appropriately by the CGN (for range solutions) or are forwarded appropriately by the CGN (for
CGN-based solutions). See Section 4.2 for more discussion of CGN-based solutions). See Section 5.2 for more discussion of
this; this;
o Applications that carry address and/or port information in their o Applications that carry address and/or port information in their
payload - where translation of port and/or address information is payload - where translation of port and/or address information is
performed at the IP and transport layers by the address sharing performed at the IP and transport layers by the address sharing
solution, an ALG will also be required to ensure application layer solution, an ALG will also be required to ensure application layer
data is appropriately modified; data is appropriately modified;
o Applications that use fixed ports (e.g. well-known ports) - see o Applications that use fixed ports (e.g. well-known ports) - see
Section 4.2.2 for more discussion of this; Section 5.2.2 for more discussion of this;
o Applications that do not use any port (e.g. ICMP) - where address o Applications that do not use any port (e.g. ICMP) - where address
sharing solutions map subscribers to (private) IP addresses on a sharing solutions map subscribers to (private) IP addresses on a
one-to-one basis this will not be an issue, otherwise such one-to-one basis this will not be an issue, otherwise such
applications will require special handling - see Section 8 for applications will require special handling - see Section 9 for
more discussion of this; more discussion of this;
o Applications that assume the uniqueness of source addresses (e.g. o Applications that assume the uniqueness of source addresses (e.g.
IP address as identifier) - such applications will fail to operate IP address as identifier) - such applications will fail to operate
correctly in the presence of multiple, discrete, simultaneous correctly in the presence of multiple, discrete, simultaneous
connections from the same source IP address; connections from the same source IP address;
o Applications that explicitly prohibit concurrent connections from o Applications that explicitly prohibit concurrent connections from
the same address - such applications will fail when multiple the same address - such applications will fail when multiple
subscribers sharing an IP address attempt to use them subscribers sharing an IP address attempt to use them
simultaneously. simultaneously.
o 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)).
Applications already frequently implement mechanisms in order to Applications already frequently implement mechanisms in order to
circumvent the presence of NATs (typically CPE NATs): circumvent the presence of NATs (typically CPE NATs):
o Application Layer Gateways (ALGs): Many CPE devices today embed o Application Layer Gateways (ALGs): Many CPE devices today embed
ALGs that allow applications to behave correctly despite the ALGs that allow applications to behave correctly despite the
presence of NAT on the CPE. When the NAT belongs to the presence of NAT on the CPE. When the NAT belongs to the
subscriber, the subscriber has flexibility to tailor the device to subscriber, the subscriber has flexibility to tailor the device to
his or her needs. For CGNs, subscribers will be dependent on the his or her needs. For CGNs, subscribers will be dependent on the
set of ALGs that their service provider makes available. A set of ALGs that their service provider makes available. A
service provider-based NAT may, or may not, support NAT-traversal service provider-based NAT may, or may not, support NAT-traversal
for IKE [RFC3947] for example. For port-range solutions, ALGs for IKE [RFC3947] for example. For port-range solutions, ALGs
will require modification to deal with the port-range restriction, will require modification to deal with the port-range restriction,
but will otherwise have the same capabilities as today. but will otherwise have the same capabilities as today.
o NAT Traversal Techniques: ICE, STUN, TURN, etc. See o NAT Traversal Techniques: There are several commonly-deployed
Section 4.2.1. mechanisms that support operating servers behind a NAT by
forwarding specific TCP or UDP ports to specific internal hosts
([UPnP-IGD], [I-D.cheshire-nat-pmp], and manual configuration).
All of these mechanisms assume the NAT's WAN address is a
publicly-routable IP address, and fail to work normally when that
assumption is wrong. There have been attempts to avoid that
problem by automatically disabling the NAT function and bridging
traffic instead upon assignment of a private IP address to the WAN
interface (as is required for [Windows-Logo] certification).
Bridging (rather than NATting) has other side effects (DHCP
requests are served by an upstream DHCP server which can increase
complexity of in-home networking).
6. Geo-location and Geo-proximity 7. Geo-location and Geo-proximity
IP addresses are frequently used to indicate, with some level of IP addresses are frequently used to indicate, with some level of
granularity and some level of confidence, where a host is physically granularity and some level of confidence, where a host is physically
located. Geo-location services are used by content providers to located. Geo-location services are used by content providers to
allow them to conform with regional content licensing restrictions, allow them to conform with regional content licensing restrictions,
to target advertising at specific geographic areas, or to provide to target advertising at specific geographic areas, or to provide
customised content. Geo-location services are also necessary for customised content. Geo-location services are also necessary for
emergency services provision. In some deployment contexts (e.g. emergency services provision. In some deployment contexts (e.g.
centralised CGN), shared addressing will reduce the level of centralised CGN), shared addressing will reduce the level of
confidence and level of location granularity that IP-based geo- confidence and level of location granularity that IP-based geo-
location services can provide. Other forms of geo-location will location services can provide. Viewed from the content provider, a
still work as usual. 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.
A slightly different use of an IP address is to calculate the A slightly different use of an IP address is to calculate the
proximity of a connecting host to a particular service delivery proximity of a connecting host to a particular service delivery
point. This use of IP address information impacts the efficient point. This use of IP address information impacts the efficient
delivery of content to an end-user. If a CGN is introduced in 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, communications and it is far from an end-user connected to it,
application performance may be degraded insofar as IP-based geo- application performance may be degraded insofar as IP-based geo-
proximity is a factor. proximity is a factor.
7. Tracking Service Usage 8. Tracking Service Usage
As large-scale address sharing becomes more commonplace, monitoring As large-scale address sharing becomes more commonplace, monitoring
the number of unique users of a service will become more complex than the number of unique users of a service will become more complex than
simply counting the number of connections from unique IP addresses. simply counting the number of connections from unique IP addresses.
While this is a somewhat inexact methodology today due to the While this is a somewhat inexact methodology today due to the
widespread use of CPE NAT, it will become a much less useful approach widespread use of CPE NAT, it will become a much less useful approach
in the presence of widespread large-scale address sharing solutions. in the presence of widespread large-scale address sharing solutions.
In general, all elements that monitor usage or abusage in the chain In general, all elements that monitor usage or abusage in the chain
between a service provider that has deployed address sharing and a between a service provider that has deployed address sharing and a
content provider will need to be upgraded to take account of the port content provider will need to be upgraded to take account of the port
value in addition to IP addresses. value in addition to IP addresses.
8. ICMP 9. ICMP
ICMP does not carry any port information and is consequently ICMP does not carry any port information and is consequently
problematic for address sharing mechanisms. Sourcing ICMP from hosts problematic for address sharing mechanisms. Sourcing ICMP from hosts
behind an address sharing solution does not pose problems, although behind an address sharing solution does not pose problems, although
responses to outgoing ICMP will require special handling, such as responses to outgoing ICMP will require special handling, such as
making use of the ICMP identifier value to route the response making use of the ICMP identifier value to route the response
appropriately. appropriately.
For inbound ICMP there are two cases. The first case is that of ICMP For inbound ICMP there are two cases. The first case is that of ICMP
sourced from outside the network of the address sharing solution sourced from outside the network of the address sharing solution
skipping to change at page 13, line 39 skipping to change at page 15, line 5
Another concern relating to ICMP in the presence of large-scale Another concern relating to ICMP in the presence of large-scale
address sharing is that a malevolent user could send an ICMP "Packet address sharing is that a malevolent user could send an ICMP "Packet
Too Big" (Type 3, Code 4) message indicating a Next-Hop MTU of 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 anything down to 68 octets. This value will be cached by the off-net
server for all subscribers sharing the address of the malevolent server for all subscribers sharing the address of the malevolent
user. This could lead to a DoS against both the remote server and 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 the large-scale NAT device itself (as they will both have to handle
many more packets per second). many more packets per second).
9. Fragmentation 10. Fragmentation
When a packet is fragmented, transport-layer port information (either When a packet is fragmented, transport-layer port information (either
UDP or TCP) is only present in the first fragment. Subsequent UDP or TCP) is only present in the first fragment. Subsequent
fragments will not carry the port information and so will require fragments will not carry the port information and so will require
special handling. special handling.
10. Traceability 11. Traceability
Legal obligations require a service provider to provide the identity In many jurisdictions, service providers are legally obliged to
of a subscriber upon request to the authorities. Where one public provide the identity of a subscriber upon request to the appropriate
IPv4 address is shared between several subscribers, the knowledge of authorities. Where one public IPv4 address is shared between several
the IP address alone is not enough to identify the appropriate subscribers, the knowledge of the IP address alone is not enough to
subscriber. The legal request should include the information: [IP identify the appropriate subscriber. The legal request should
address - Port - Protocol- Begin_Timestamp - End_Timestamp]. include the information: [IP address - Port - Protocol- Timestamp]
Accurate time-keeping is clearly important. A densely populated CGN (this does not preclude the possibility that a real legal request may
could mean even very small amounts of clock skew between a content include additional information). Accurate time-keeping (e.g. use of
provider and the CGN operator will result in ambiguity about which NTP or SNTP) is vital because port assignments are dynamic. A
customer was using a specific port at a given time. densely populated CGN could mean even very small amounts of clock
skew between a content provider and the CGN operator will result in
ambiguity about which customer was using a specific port at a given
time.
Considering that it is unrealistic to expect all servers to start Considering that it is unrealistic to expect all servers to start
logging port information of connection attempts, address sharing logging port information of connection attempts, address sharing
service providers may need to start logging destinations as well, service providers may need to start logging IP destination addresses
giving rise to privacy concerns. as well, giving rise to privacy concerns.
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.
If 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.
Address sharing solutions must record and store all mappings Address sharing solutions must record and store all mappings
(typically during 6 months to one year, depending on the (typically during 6 months to one year, depending on the
jurisdiction) that they create. If we consider one mapping per jurisdiction) that they create. If we consider one mapping per
session, a service provider should record and retain traces of all session, a service provider should record and retain traces of all
sessions created by all subscribers during one year (if the legal sessions created by all subscribers during one year (if the legal
storage duration is one year). This may be challenging due to the storage duration is one year). This may be challenging due to the
volume of data requiring storage, the volume of data to repeatedly volume of data requiring storage, the volume of data to repeatedly
transfer to the storage location, and the volume of data to search in transfer to the storage location, and the volume of data to search in
response to a query. response to a query.
Address sharing solutions may mitigate these issues to some extent by Address sharing solutions may mitigate these issues to some extent by
pre-allocating groups of ports. Then only the allocation of the pre-allocating groups of ports. Then only the allocation of the
group needs to be recorded, and not the creation of every session group needs to be recorded, and not the creation of every session
binding within that group. There are trade-offs to be made between binding within that group. There are trade-offs to be made between
the sizes of these groups, the ratio of public addresses to the sizes of these groups, the ratio of public addresses to
subscribers, whether or not these groups timeout, the impact on subscribers, whether or not these groups timeout, the impact on
logging requirements and port randomisation security. logging requirements and port randomisation security.
11. Security 12. Security
Before noting some specific security-related issues caused by large- Before noting some specific security-related issues caused by large-
scale address sharing, it is perhaps worth noting that, in general, scale address sharing, it is perhaps worth noting that, in general,
address sharing creates a vector for attack amplification in numerous address sharing creates a vector for attack amplification in numerous
ways. See Section 8 for one example. ways. See Section 9 for one example.
11.1. Abuse Logging and Penalty Boxes 12.1. Abuse Logging and Penalty Boxes
When an abuse is reported today, it is usually done in the form: IPv4 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 address X has done something bad at time T0. This is not enough
information to uniquely identify the subscriber responsible for the information to uniquely identify the subscriber responsible for the
abuse when that IPv4 address is shared by more than one subscriber. abuse when that IPv4 address is shared by more than one subscriber.
Law enforcement authorities may be particularly impacted because of Law enforcement authorities may be particularly impacted because of
this. This particular issue can be fixed by logging port numbers, this. This particular issue can be fixed by logging port numbers,
although this will increase logging data storage requirements. although this will increase logging data storage requirements.
A number of application servers on the network today log IPv4 A number of services on the network today log the IPv4 source
addresses in connection attempts to protect themselves from certain addresses used in connection attempts to protect themselves from
attacks. For example, if a server sees too many login attempts from certain attacks. For example, if a server sees too many requests
the same IPv4 address, it may decide to put that address in a penalty from the same IPv4 address in a short period of time, it may decide
box for a certain time. If an IPv4 address is shared by multiple 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 subscribers, this would have unintended consequences in a couple of
ways. First it may become the natural behavior to see many login ways. First it may become the natural behavior to see many login
attempts from the same address because it is now shared across a attempts from the same address because it is now shared across a
potentially large number of subscribers. Second and more likely is potentially large number of subscribers. Second and more likely is
that one user who fails a number of login attempts may block out 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 other users who have not made any previous attempts but who will now
fail on their first attempt. In the presence of widespread large- fail on their first attempt. In the presence of widespread large-
scale address sharing, penalty box solutions to service abuse simply scale address sharing, penalty box solutions to service abuse simply
will not work. will not work.
11.2. Authentication 12.2. Authentication
Simple address-based identification mechanisms that are used to Simple address-based identification mechanisms that are used to
populate access control lists will fail when an IP address is no populate access control lists will fail when an IP address is no
longer sufficient to identify a particular subscriber. Including longer sufficient to identify a particular subscriber. Including
port numbers in access control list definitions may be possible at port numbers in access control list definitions may be possible at
the cost of extra complexity, and may also require the service the cost of extra complexity, and may also require the service
provider to make static port assignments, which conflicts with the provider to make static port assignments, which conflicts with the
requirement for dynamic assignments discussed in Section 4.1 . requirement for dynamic assignments discussed in Section 5.1 .
11.3. Spam 12.3. Spam
Another case of identifying abusers has to do with spam blacklisting. Another case of identifying abusers has to do with spam blacklisting.
When a spammer is behind a CGN or using a port-shared address, When a spammer is behind a CGN or using a port-shared address,
blacklisting of their IP address will result in all other subscribers blacklisting of their IP address will result in all other subscribers
sharing that address having their ability to source SMTP packets sharing that address having their ability to source SMTP packets
restricted to some extent. restricted to some extent.
11.4. Port Randomisation 12.4. Port Randomisation
A blind attack that can be performed against TCP relies on the A blind attack that can be performed against TCP relies on the
attacker's ability to guess the 5-tuple (Protocol, Source Address, attacker's ability to guess the 5-tuple (Protocol, Source Address,
Destination Address, Source Port, Destination Port) that identifies Destination Address, Source Port, Destination Port) that identifies
the transport protocol instance to be attacked. the transport protocol instance to be attacked.
[I-D.ietf-tsvwg-port-randomization] describes a number of methods for [I-D.ietf-tsvwg-port-randomization] describes a number of methods for
the random selection of the source port number, such that the ability the random selection of the source port number, such that the ability
of an attacker to correctly guess the 5-tuple is reduced. With of an attacker to correctly guess the 5-tuple is reduced. With
shared IPv4 addresses, the port selection space is reduced. shared IPv4 addresses, the port selection space is reduced.
Preserving port randomisation is important and may be more or less Preserving port randomisation is important and may be more or less
skipping to change at page 16, line 16 skipping to change at page 17, line 47
It should be noted that guessing the port information may not be It should be noted that guessing the port information may not be
sufficient to carry out a successful blind attack. The exact TCP sufficient to carry out a successful blind attack. The exact TCP
Sequence Number (SN) should also be known. A TCP segment is Sequence Number (SN) should also be known. A TCP segment is
processed only if all previous segments have been received, except processed only if all previous segments have been received, except
for some Reset Segment implementations which immediately process the for some Reset Segment implementations which immediately process the
Reset as long as it is within the Window. If SN is randomly chosen 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 it will be difficult to guess it (SN is 32 bits long); port
randomisation is one protection among others against blind attacks. randomisation is one protection among others against blind attacks.
11.5. IPsec 12.5. IPsec
The impact of large-scale IP address sharing for IPsec operation The impact of large-scale IP address sharing for IPsec operation
should be evaluated and assessed. [RFC3947] proposes a solution to should be evaluated and assessed. [RFC3947] proposes a solution to
solve issues documented in [RFC3715] . The applicability of solve issues documented in [RFC3715] . The applicability of
[RFC3947] in the context of shared IP address solutions should be [RFC3947] in the context of shared IP address solutions should be
evaluated. In particular, service providers may wish to ensure that evaluated. In particular, service providers may wish to ensure that
CGN deployments do not inadvertently block NAT traversal for security CGN deployments do not inadvertently block NAT traversal for security
protocols such as IKE (refer to [I-D.gont-behave-nat-security] for protocols such as IKE (refer to [I-D.gont-behave-nat-security] for
more information). more information).
11.6. Policing Forwarding Behaviour 12.6. Policing Forwarding Behaviour
[RFC2827] motivates and discusses a simple, effective, and [RFC2827] motivates and discusses a simple, effective, and
straightforward method for using ingress traffic filtering to straightforward method for using ingress traffic filtering to
prohibit Denial-of-Service (DoS) attacks which use forged IP prohibit Denial-of-Service (DoS) attacks which use forged IP
addresses. Following this recommendation, service providers addresses. Following this recommendation, service providers
operating shared-addressing mechanisms should ensure that source operating shared-addressing mechanisms should ensure that source
addresses, or source ports in the case of port-range schemes, are set addresses, or source ports in the case of port-range schemes, are set
correctly in outgoing packets from their subscribers or they should correctly in outgoing packets from their subscribers or they should
drop the packets. drop the packets.
If some form of IPv6 ingress filtering is deployed in the broadband If some form of IPv6 ingress filtering is deployed in the broadband
network and DS-Lite service is restricted to those subscribers, then network and DS-Lite service is restricted to those subscribers, then
tunnels terminating at the CGN and coming from registered subscriber tunnels terminating at the CGN and coming from registered subscriber
IPv6 addresses cannot be spoofed. Thus a simple access control list IPv6 addresses cannot be spoofed. Thus a simple access control list
on the tunnel transport source address is all that is required to on the tunnel transport source address is all that is required to
accept traffic on the southbound interface of a CGN. accept traffic on the southbound interface of a CGN.
12. TCP Control Block Sharing 13. TCP Control Block Sharing
[RFC2140] defines a performance optimisation for TCP based on sharing [RFC2140] defines a performance optimisation for TCP based on sharing
state between TCP control blocks that pertain to connections to the state between TCP control blocks that pertain to connections to the
same host, as opposed to maintaining state for each discrete same host, as opposed to maintaining state for each discrete
connection. This optimisation assumes that an address says something connection. This optimisation assumes that an address says something
about the properties of the path between two hosts, which is clearly 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 not the case if the address in question is shared by multiple hosts
at different physical network locations. While CPE NAT today causes at different physical network locations. While CPE NAT today causes
problems for sharing TCP control block state across multiple problems for sharing TCP control block state across multiple
connections to a given IP address, large-scale address sharing will connections to a given IP address, large-scale address sharing will
make these issues more severe and more widespread. make these issues more severe and more widespread.
13. Reverse DNS 14. Reverse DNS
Many service providers populate forward and reverse DNS zones for the Many service providers populate forward and reverse DNS zones for the
public IPv4 addresses that they allocate to their subscribers. In public IPv4 addresses that they allocate to their subscribers. In
the case where public addresses are shared across multiple the case where public addresses are shared across multiple
subscribers, such strings are, by definition, no longer sufficient to subscribers, such strings are, by definition, no longer sufficient to
identify an individual subscriber without additional information. identify an individual subscriber without additional information.
14. Load Balancing 15. Load Balancing
Algorithms used to balance traffic load for popular destinations may Algorithms used to balance traffic load for popular destinations may
be affected by the introduction of address sharing. Where balancing be affected by the introduction of address sharing. Where balancing
is achieved by deterministically routing traffic from specific source is achieved by deterministically routing traffic from specific source
IP addresses to specific servers, sudden imbalances in load may be IP addresses to specific servers, sudden imbalances in load may be
experienced as address sharing is enabled for some of those source IP experienced as address sharing is enabled for some of those source IP
addresses. This will require re-evaluation of the algorithms used in addresses. This will require re-evaluation of the algorithms used in
the load-balancing design. In general, as the scale of address the load-balancing design. In general, as the scale of address
sharing grows, load-balancing designs will need to be re-evaluated sharing grows, load-balancing designs will need to be re-evaluated
and any assumptions about average load per source IP address and any assumptions about average load per source IP address
revisited. revisited.
15. IPv6 Transition Issues 16. IPv6 Transition Issues
IPv4 address sharing solutions may interfere with existing IPv4 to IPv4 address sharing solutions may interfere with existing IPv4 to
IPv6 transition mechanisms, which were not designed with IPv4 IPv6 transition mechanisms, which were not designed with IPv4
shortage considerations in mind. With port-range solutions for shortage considerations in mind. With port-range solutions for
instance, incoming 6to4 packets should be able to find their way from 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 a 6to4 relay to the appropriate 6to4 CPE router, despite the lack of
direct port range information (UDP/TCP initial source port did not direct port range information (UDP/TCP initial source port did not
pass through the CPE port range translation process). One solution pass through the CPE port range translation process). One solution
would be for a 6to4 IPv6 address to embed not only an IPv4 address would be for a 6to4 IPv6 address to embed not only an IPv4 address
but also a port range value. but also a port range value.
Subscribers allocated with private addresses will not be able to Subscribers allocated with private addresses will not be able to
utilise 6to4 to access IPv6, but may be able to utilise Teredo. utilise 6to4 to access IPv6, but may be able to utilise Teredo.
16. Introduction of Single Points of Failure Shared addresses should be drawn from space designated as such
[RFC1918]. Otherwise their use will break the widely implemented
assumption that public IPv4 addresses are globally unique addresses
and hence break many protocols and applications, e.g. 6to4 [RFC3056].
Some routers enable 6to4 on their WAN link. 6to4 requires a publicly-
routable IPv4 address. Enabling 6to4 when the apparently public IPv4
WAN address is in fact behind a NAT creates a disconnected IPv6
island. Issues created by sharing public address space across
multiple hosts are specifically addressed in
[I-D.thaler-port-restricted-ip-issues].
17. Introduction of Single Points of Failure
In common with all deployments of new network functionality, the In common with all deployments of new network functionality, the
introduction of new nodes or functions to handle the multiplexing of introduction of new nodes or functions to handle the multiplexing of
multiple subscribers across shared IPv4 addresses could create single multiple subscribers across shared IPv4 addresses could create single
points of failure in the network. Any IP address sharing solution points of failure in the network. Any IP address sharing solution
should consider the opportunity to add redundancy features in order should consider the opportunity to add redundancy features in order
to alleviate the impact on the robustness of the offered IP to alleviate the impact on the robustness of the offered IP
connectivity service. The ability of the solution to allow hot connectivity service. The ability of the solution to allow hot
swapping from one machine to another should be considered. This is swapping from one machine to another should be considered. This is
especially important where the address sharing solution in question especially important where the address sharing solution in question
requires the creation of per-flow state in the network. requires the creation of per-flow state in the network.
17. State Maintenance Reduces Battery Life 18. State Maintenance Reduces Battery Life
In order for hosts to maintain network state in the presence of NAT, In order for hosts to maintain network state in the presence of NAT,
keep-alive messages have to be sent at frequent intervals. For keep-alive messages have to be sent at frequent intervals. For
battery-powered devices, sending these keep-alive messages can result battery-powered devices, sending these keep-alive messages can result
in significantly reduced battery performance than would otherwise be in significantly reduced battery performance than would otherwise be
the case [Mobile_Energy_Consumption]. the case [Mobile_Energy_Consumption].
18. Support of Multicast 19. Support of Multicast
[RFC5135] specifies requirements for a NAT that supports Any Source [RFC5135] specifies requirements for a NAT that supports Any Source
IP Multicast or Source-Specific IP Multicast. Port-range routers IP Multicast or Source-Specific IP Multicast. Port-range routers
that form part of port-range solutions will need to support similar that form part of port-range solutions will need to support similar
requirements if multicast support is required. requirements if multicast support is required.
[Placeholder for more details of impact of address sharing on [Placeholder for more details of impact of address sharing on
multicast deployments.] multicast deployments.]
19. Support of Mobile-IP 20. Support of Mobile-IP
IP address sharing within the context of Mobile-IP deployments (in IP address sharing within the context of Mobile-IP deployments (in
the home network and/or in the visited network), will require Home 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 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 the relevant port information. There may also be issues raised when
an additional layer of encapsulation is required thereby causing, or an additional layer of encapsulation is required thereby causing, or
increasing the need for, fragmentation and reassembly. increasing the need for, fragmentation and reassembly.
Issues for Mobile-IP in the presence of NAT are discussed in Issues for Mobile-IP in the presence of NAT are discussed in
[I-D.haddad-mext-nat64-mobility-harmful] [I-D.haddad-mext-nat64-mobility-harmful]
20. IANA Considerations 21. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
21. Security Considerations 22. Security Considerations
This memo does not define any protocol and raises no security issues. This memo does not define any protocol and raises no security issues.
Section 11 discusses some of the security and identity-related
Section 12 discusses some of the security and identity-related
implications of address sharing. implications of address sharing.
22. Contributors 23. Contributors
This document is based on sources co-authored by J.L. Grimault and A. This document is based on sources co-authored by J.L. Grimault and A.
Villefranque of France Telecom. Villefranque of France Telecom.
23. Acknowledgements 24. Acknowledgements
This memo was partly inspired by conversations that took place as This memo was partly inspired by conversations that took place as
part of Internet Society (ISOC) hosted roundtable events for part of Internet Society (ISOC) hosted roundtable events for
operators and content providers deploying IPv6. Participants in operators and content providers deploying IPv6. Participants in
those discussions included John Brzozowski, Leslie Daigle, Tom those discussions included John Brzozowski, Leslie Daigle, Tom
Klieber, Yiu Lee, Kurtis Lindqvist, Wes George, Lorenzo Colliti, Erik Klieber, Yiu Lee, Kurtis Lindqvist, Wes George, Lorenzo Colliti, Erik
Kline, Igor Gashinsky, Jason Fesler, Rick Reed, Adam Bechtel, Larry Kline, Igor Gashinsky, Jason Fesler, Rick Reed, Adam Bechtel, Larry
Campbell, Tom Coffeen, David Temkin, Pete Gelbman, Mark Winter, Will Campbell, Tom Coffeen, David Temkin, Pete Gelbman, Mark Winter, Will
Charnock, Martin Levy, Greg Wood and Christian Jacquenet. The Charnock, Martin Levy, Greg Wood and Christian Jacquenet. The
authors are also grateful to Christian Jacquenet, Iain Calder, Joel authors are also grateful to Christian Jacquenet, Iain Calder, Joel
Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo
Bagnulo and Dan Wing for their helpful comments and suggestions for Bagnulo and Dan Wing for their helpful comments and suggestions for
improving this document. improving this document.
This memo was created using the xml2rfc tool. This memo was created using the xml2rfc tool.
24. Annex 25. Annex
24.1. Classes of Address Sharing Solution 25.1. Classes of Address Sharing Solution
IP address sharing solutions fall into two classes. Either a IP address sharing solutions fall into two classes. Either a
service-provider operated NAT function is introduced and subscribers service-provider operated NAT function is introduced and subscribers
are allocated addresses from [RFC1918] space, or public IPv4 are allocated addresses from [RFC1918] space, or public IPv4
addresses are shared across multiple subscribers by restricting the addresses are shared across multiple subscribers by restricting the
range of ports available to each subscriber. These classes of range of ports available to each subscriber. These classes of
solution are described in a bit more detail below. solution are described in a bit more detail below.
o CGN-based solutions: These solutions propose the introduction of a o CGN-based solutions: These solutions propose the introduction of a
NAPT function in the service provider's network, denoted also as NAPT function in the service provider's network, denoted also as
skipping to change at page 20, line 27 skipping to change at page 22, line 17
o Port-range solutions: These solutions avoid the presence of a CGN o Port-range solutions: These solutions avoid the presence of a CGN
function. A single public IPv4 address is assigned to several function. A single public IPv4 address is assigned to several
subscribers at the same time. A restricted port range is also subscribers at the same time. A restricted port range is also
assigned to each subscriber so that two subscribers with the same assigned to each subscriber so that two subscribers with the same
IPv4 address have two different port ranges that do not overlap. IPv4 address have two different port ranges that do not overlap.
These solutions are called A+P (Address+Port) [I-D.ymbk-aplusp] , These solutions are called A+P (Address+Port) [I-D.ymbk-aplusp] ,
or Port Range [I-D.boucadair-port-range] , or SAM (Stateless or Port Range [I-D.boucadair-port-range] , or SAM (Stateless
Address Mapping) [I-D.despres-sam] . Address Mapping) [I-D.despres-sam] .
24.2. Address Space Multiplicative Factor 25.2. Address Space Multiplicative Factor
The purpose of sharing public IPv4 addresses is to increase the The purpose of sharing public IPv4 addresses is to increase the
addressing space. A key parameter is the factor by which service addressing space. A key parameter is the factor by which service
providers want or need to multiply their IPv4 public address space; providers want or need to multiply their IPv4 public address space;
and the consequence is the number of subscribers sharing the same and the consequence is the number of subscribers sharing the same
public IPv4 address. We refer to this parameter as the address space public IPv4 address. We refer to this parameter as the address space
multiplicative factor, the inverse is called the compression ratio. multiplicative factor, the inverse is called the compression ratio.
The multiplicative factor can only be applied to the subset of The multiplicative factor can only be applied to the subset of
subscribers that are eligible for a shared address. The reasons a subscribers that are eligible for a shared address. The reasons a
skipping to change at page 21, line 19 skipping to change at page 23, line 10
When the multiplicative factor is large, the average number of ports When the multiplicative factor is large, the average number of ports
per subscriber is small. Given the large measured disparity between per subscriber is small. Given the large measured disparity between
average and peak port consumption [CGN_Viability] , this will create average and peak port consumption [CGN_Viability] , this will create
service problems in the event that ports are allocated statically. service problems in the event that ports are allocated statically.
In this case, it is essential for port allocation to map to need as 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 closely as possible, and to avoid allocating ports for longer than
necessary. Therefore, the larger the multiplicative factor, the more necessary. Therefore, the larger the multiplicative factor, the more
dynamic the port assignment has to be. dynamic the port assignment has to be.
25. Informative References 26. Informative References
[CGN_Viability] [CGN_Viability]
Alcock, S., "Research into the Viability of Service- Alcock, S., "Research into the Viability of Service-
Provider NAT", 2008, <http://www.wand.net.nz/~salcock/ Provider NAT", 2008, <http://www.wand.net.nz/~salcock/
someisp/flow_counting/result_page.html>. someisp/flow_counting/result_page.html>.
[I-D.boucadair-port-range] [I-D.boucadair-port-range]
Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
"IPv4 Connectivity Access in the Context of IPv4 Address "IPv4 Connectivity Access in the Context of IPv4 Address
Exhaustion: Port Range based IP Architecture", Exhaustion: Port Range based IP Architecture",
draft-boucadair-port-range-02 (work in progress), draft-boucadair-port-range-02 (work in progress),
July 2009. July 2009.
[I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.despres-sam] [I-D.despres-sam]
Despres, R., "Scalable Multihoming across IPv6 Local- Despres, R., "Scalable Multihoming across IPv6 Local-
Address Routing Zones Global-Prefix/Local-Address Address Routing Zones Global-Prefix/Local-Address
Stateless Address Mapping (SAM)", draft-despres-sam-03 Stateless Address Mapping (SAM)", draft-despres-sam-03
(work in progress), July 2009. (work in progress), July 2009.
[I-D.gont-behave-nat-security] [I-D.gont-behave-nat-security]
Gont, F. and P. Srisuresh, "Security implications of Gont, F. and P. Srisuresh, "Security implications of
Network Address Translators (NATs)", Network Address Translators (NATs)",
draft-gont-behave-nat-security-03 (work in progress), draft-gont-behave-nat-security-03 (work in progress),
skipping to change at page 22, line 41 skipping to change at page 24, line 36
Yamagata, I., Nishitani, T., Miyakawa, S., Nakagawa, A., Yamagata, I., Nishitani, T., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for IP address sharing and H. Ashida, "Common requirements for IP address sharing
schemes", draft-nishitani-cgn-04 (work in progress), schemes", draft-nishitani-cgn-04 (work in progress),
March 2010. March 2010.
[I-D.shirasaki-nat444] [I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-01 (work and H. Ashida, "NAT444", draft-shirasaki-nat444-01 (work
in progress), March 2010. in progress), March 2010.
[I-D.thaler-port-restricted-ip-issues]
Thaler, D., "Issues With Port-Restricted IP Addresses",
draft-thaler-port-restricted-ip-issues-00 (work in
progress), February 2010.
[I-D.ymbk-aplusp] [I-D.ymbk-aplusp]
Bush, R., "The A+P Approach to the IPv4 Address Shortage", Bush, R., "The A+P Approach to the IPv4 Address Shortage",
draft-ymbk-aplusp-05 (work in progress), October 2009. draft-ymbk-aplusp-05 (work in progress), October 2009.
[IPv4_Report] [IPv4_Report]
Huston, G., "IPv4 Address Report", 2009, Huston, G., "IPv4 Address Report", 2009,
<http://www.potaroo.net/tools/ipv4/index.html>. <http://www.potaroo.net/tools/ipv4/index.html>.
[Mobile_Energy_Consumption] [Mobile_Energy_Consumption]
Haverinen, H., Siren, J., and P. Eronen, "Energy Haverinen, H., Siren, J., and P. Eronen, "Energy
skipping to change at page 23, line 30 skipping to change at page 25, line 30
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004. (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005. January 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
Network Address Translator (NAT) and a Network Address Network Address Translator (NAT) and a Network Address
Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[UPnP-IGD]
UPnP Forum, "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", November 2001,
<http://www.upnp.org/standardizeddcps/igd.asp>.
[Windows-Logo]
Microsoft, "Windows Logo Program Device Requirements",
2006, <http://www.microsoft.com/whdc/winlogo/
hwrequirements/default.mspx>.
Authors' Addresses Authors' Addresses
Mat Ford (editor) Mat Ford (editor)
Internet Society Internet Society
Geneva Geneva
Switzerland Switzerland
Email: ford@isoc.org Email: ford@isoc.org
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Email: mohamed.boucadair@orange-ftgroup.com Email: mohamed.boucadair@orange-ftgroup.com
Alain Durand Alain Durand
Comcast Juniper Networks
Email: Alain_Durand@cable.comcast.com Email: adurand@juniper.net
Pierre Levis Pierre Levis
France Telecom France Telecom
42 rue des Coutures 42 rue des Coutures
BP 6243 BP 6243
Caen Cedex 4 14066 Caen Cedex 4 14066
France France
Email: pierre.levis@orange-ftgroup.com Email: pierre.levis@orange-ftgroup.com
 End of changes. 79 change blocks. 
135 lines changed or deleted 245 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/