draft-ietf-intarea-shared-addressing-issues-05.txt   rfc6269.txt 
Internet Engineering Task Force M. Ford, Ed. Internet Engineering Task Force (IETF) M. Ford, Ed.
Internet-Draft Internet Society Request for Comments: 6269 Internet Society
Intended status: Informational M. Boucadair Category: Informational M. Boucadair
Expires: September 4, 2011 France Telecom ISSN: 2070-1721 France Telecom
A. Durand A. Durand
Juniper Networks Juniper Networks
P. Levis P. Levis
France Telecom France Telecom
P. Roberts P. Roberts
Internet Society Internet Society
March 03, 2011 June 2011
Issues with IP Address Sharing Issues with IP Address Sharing
draft-ietf-intarea-shared-addressing-issues-05
Abstract Abstract
The completion of IPv4 address allocations from IANA and the RIRs is The completion of IPv4 address allocations from IANA and the Regional
causing service providers around the world to question how they will Internet Registries (RIRs) is causing service providers around the
continue providing IPv4 connectivity service to their subscribers world to question how they will continue providing IPv4 connectivity
when there are no longer sufficient IPv4 addresses to allocate them service to their subscribers when there are no longer sufficient IPv4
one per subscriber. Several possible solutions to this problem are addresses to allocate them one per subscriber. Several possible
now emerging based around the idea of shared IPv4 addressing. These solutions to this problem are now emerging based around the idea of
solutions give rise to a number of issues and this memo identifies shared IPv4 addressing. These solutions give rise to a number of
those common to all such address sharing approaches. Such issues issues, and this memo identifies those common to all such address
include application failures, additional service monitoring sharing approaches. Such issues include application failures,
complexity, new security vulnerabilities and so on. Solution- additional service monitoring complexity, new security
specific discussions are out of scope. vulnerabilities, and so on. Solution-specific discussions are out of
scope.
Deploying IPv6 is the only perennial way to ease pressure on the Deploying IPv6 is the only perennial way to ease pressure on the
public IPv4 address pool without the need for address sharing public IPv4 address pool without the need for address sharing
mechanisms that give rise to the issues identified herein. mechanisms that give rise to the issues identified herein.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc6269.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 Simplified 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. Content Provider Example . . . . . . . . . . . . . . . . . . . 8 4. Content Provider Example . . . . . . . . . . . . . . . . . . . 8
5. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 8 5. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 11 5.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 11
5.2.2. Connection to a Well-Known Port Number . . . . . . . . 12 5.2.2. Connection to a Well-Known Port Number . . . . . . . . 12
5.2.3. Port Discovery Mechanisms . . . . . . . . . . . . . . 12 5.2.3. Port Discovery Mechanisms . . . . . . . . . . . . . . 12
6. Impact on Applications . . . . . . . . . . . . . . . . . . . . 12 6. Impact on Applications . . . . . . . . . . . . . . . . . . . . 12
7. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 14 7. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 14
8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 15 8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 15
9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18 13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18
13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 19 13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 19
13.3. SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.4. Port Randomisation . . . . . . . . . . . . . . . . . . . . 19 13.4. Port Randomization . . . . . . . . . . . . . . . . . . . . 19
13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.6. Policing Forwarding Behaviour . . . . . . . . . . . . . . 20 13.6. Policing Forwarding Behavior . . . . . . . . . . . . . . . 20
14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20 14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Parallel connections . . . . . . . . . . . . . . . . . . . 20 14.1. Parallel Connections . . . . . . . . . . . . . . . . . . . 20
14.2. Serial connections . . . . . . . . . . . . . . . . . . . . 21 14.2. Serial Connections . . . . . . . . . . . . . . . . . . . . 20
14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 21 14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 21
15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 21 15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 21
16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 21 16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 21
17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21 17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21
18. Introduction of Single Points of Failure . . . . . . . . . . . 22 18. Introduction of Single Points of Failure . . . . . . . . . . . 22
19. State Maintenance Reduces Battery Life . . . . . . . . . . . . 22 19. State Maintenance Reduces Battery Life . . . . . . . . . . . . 22
20. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 22 20. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 22
21. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 23 21. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 22
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 22. Security Considerations . . . . . . . . . . . . . . . . . . . 23
23. Security Considerations . . . . . . . . . . . . . . . . . . . 23 23. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
24. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 25. Informative References . . . . . . . . . . . . . . . . . . . . 23
26. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Classes of Address Sharing Solution . . . . . . . . . 27
26.1. Classes of Address Sharing Solution . . . . . . . . . . . 24 Appendix B. Address Space Multiplicative Factor . . . . . . . . . 27
26.2. Address Space Multiplicative Factor . . . . . . . . . . . 24
27. Informative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Allocations of IPv4 addresses from the Internet Assigned Numbers Allocations of IPv4 addresses from the Internet Assigned Numbers
Authority (IANA) were completed on February 3, 2011 [IPv4_Pool]. Authority (IANA) were completed on February 3, 2011 [IPv4_Pool].
Allocations from Regional Internet Registries (RIRs) are anticipated Allocations from Regional Internet Registries (RIRs) are anticipated
to be complete around a year later, although the exact date will vary to be complete around a year later, although the exact date will vary
from registry to registry. This is causing service providers around from registry to registry. This is causing service providers around
the world to start to question how they will continue providing IPv4 the world to start to question how they will continue providing IPv4
connectivity service to their subscribers when there are no longer connectivity service to their subscribers when there are no longer
sufficient IPv4 addresses to allocate them one per subscriber. sufficient IPv4 addresses to allocate them one per subscriber.
Several possible solutions to this problem are now emerging based Several possible solutions to this problem are now emerging based
around the idea of shared IPv4 addressing. These solutions give rise around the idea of shared IPv4 addressing. These solutions give rise
to a number of issues and this memo identifies those common to all to a number of issues, and this memo identifies those common to all
such address sharing approaches and collects them in a single such address sharing approaches and collects them in a single
document. document.
Deploying IPv6 is the only perennial way to ease pressure on the Deploying IPv6 is the only perennial way to ease pressure on the
public IPv4 address pool without the need for address sharing public IPv4 address pool without the need for address sharing
mechanisms that give rise to the issues identified herein. In the mechanisms that give rise to the issues identified herein. In the
short term, maintaining growth of IPv4 services in the presence of short term, maintaining growth of IPv4 services in the presence of
IPv4 address depletion will require address sharing. Address sharing IPv4 address depletion will require address sharing. Address sharing
will cause issues for end-users, service providers and third parties will cause issues for end-users, service providers, and third parties
such as law enforcement agencies and content providers. This memo is such as law enforcement agencies and content providers. This memo is
intended to highlight and briefly discuss these issues. intended to highlight and briefly discuss these issues.
Increased IPv6 deployment should reduce the burden being placed on an Increased IPv6 deployment should reduce the burden being placed on an
address sharing solution, and should reduce the costs of operating address sharing solution, and should reduce the costs of operating
that solution. Increasing IPv6 deployment should cause a reduction that solution. Increasing IPv6 deployment should cause a reduction
in the number of concurrent IPv4 sessions per subscriber. If the in the number of concurrent IPv4 sessions per subscriber. If the
percentage of end-to-end IPv6 traffic significantly increases, so percentage of end-to-end IPv6 traffic significantly increases, so
that the volume of IPv4 traffic begins decreasing, then the number of that the volume of IPv4 traffic begins decreasing, then the number of
IPv4 sessions will decrease. The smaller the number of concurrent IPv4 sessions will decrease. The smaller the number of concurrent
skipping to change at page 4, line 50 skipping to change at page 4, line 50
effect will only occur for subscribers who have both an IPv6 access effect will only occur for subscribers who have both an IPv6 access
and a shared IPv4 access. This motivates a strategy to and a shared IPv4 access. This motivates a strategy to
systematically bind a shared IPv4 access to an IPv6 access. It is systematically bind a shared IPv4 access to an IPv6 access. It is
difficult to foresee to what extent growing IPv6 traffic will reduce difficult to foresee to what extent growing IPv6 traffic will reduce
the number of concurrent IPv4 sessions, but in any event, IPv6 the number of concurrent IPv4 sessions, but in any event, IPv6
deployment and use should reduce the pressure on the available public deployment and use should reduce the pressure on the available public
IPv4 address pool. IPv4 address pool.
2. Shared Addressing Solutions 2. Shared Addressing Solutions
In many networks today a subscriber is provided with a single public In many networks today, a subscriber is provided with a single public
IPv4 address at their home or small business. For instance, in fixed IPv4 address at their home or small business. For instance, in fixed
broadband access, an IPv4 public address is assigned to each CPE broadband access, an IPv4 public address is assigned to each CPE
(Customer Premises Equipment). CPEs embed a NAT function which is (Customer Premises Equipment). CPEs embed a NAT function that is
responsible for translating private IPv4 addresses ([RFC1918] responsible for translating private IPv4 addresses ([RFC1918]
addresses) assigned to hosts within the local network, to the public addresses) assigned to hosts within the local network, to the public
IPv4 address assigned by the service provider (and vice versa). IPv4 address assigned by the service provider (and vice versa).
Therefore, devices located with the LAN share the single public IPv4 Therefore, devices located with the LAN share the single public IPv4
address and they are all associated with a single subscriber account address and they are all associated with a single subscriber account
and a single network operator. and a single network operator.
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
a.k.a., LSN for Large Scale NAT) [I-D.ietf-behave-lsn-requirements], a.k.a. LSN for Large Scale NAT) [LSN-REQS], Dual-Stack Lite
Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite], NAT64 [DS-Lite], NAT64 [RFC6145] [RFC6146], Address+Port (A+P) proposals
[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate], [A+P] [PORT-RANGE], and Stateless Address Mapping [SAM]. Appendix A
Address+Port (A+P) proposals [I-D.ymbk-aplusp], and Appendix B provide a classification of these different types of
[I-D.boucadair-port-range] and SAM [I-D.despres-sam]. Section 26 solutions and discuss some of the design considerations to be borne
provides a classification of these different types of solutions and in mind when deploying large-scale address sharing. Whether we're
discusses some of the design considerations to be borne in mind when talking about DS-Lite, A+P, NAT64, or CGN isn't especially important
deploying large-scale address sharing. Whether we're talking about -- it's the view from the outside that matters, and given that, most
DS-Lite, A+P, NAT64 or CGN isn't especially important - it's the view of the issues identified below apply regardless of the specific
from the outside that matters, and given that, most of the issues address sharing scenario in question.
identified below apply regardless of the specific address sharing
scenario in question.
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),
the operational paradigm described above would no longer apply. In so the operational paradigm described above would no longer apply.
this document we refer to this new paradigm as large-scale address In this document, we refer to this new paradigm as large-scale
sharing. All these proposals extend the address space by adding port address sharing. All these proposals extend the address space by
information, they differ in the way they manage the port value. adding port 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
multiple subscribers by any means, either moving the NAT multiple subscribers by any means, either moving the NAT
functionality from the home gateway to the core of the service functionality from the home gateway to the core of the service
provider network, or restricting the port choice in the subscriber's provider network or restricting the port choice in the subscriber's
NAT, creates additional issues for subscribers, content providers and NAT, creates additional issues for subscribers, content providers,
network operators. Many of these issues are created today by public and network operators. Many of these issues are created today by
Wi-Fi hotspot deployments. As such large-scale address sharing public Wi-Fi hotspot deployments. As such large-scale address
solutions become more widespread in the face of IPv4 address sharing solutions become more widespread in the face of IPv4 address
depletion, these issues will become both more severe and more depletion, these issues will become both more severe and more
commonly felt. NAT issues in the past typically only applied to a commonly felt. NAT issues in the past typically only applied to a
single legal entity; as large-scale address sharing becomes more single legal entity; as large-scale address sharing becomes more
prevalent these issues will increasingly span across multiple legal prevalent, these issues will increasingly span across multiple legal
entities simultaneously. entities simultaneously.
All large-scale address sharing proposals share technical and All large-scale address sharing proposals share technical and
operational issues and these are addressed in the sections that operational issues, and these are addressed in the sections that
follow. These issues are common to any service-provider NAT, follow. These issues are common to any service-provider NAT,
enterprise NAT, and also non-NAT solutions that share individual IPv4 enterprise NAT, and also non-NAT solutions that share individual IPv4
addresses across multiple subscribers. This document is intended to addresses across multiple subscribers. This document is intended to
bring all of these issues together in one place. bring all of these issues together in one place.
3. Analysis of Issues as they Relate to First and Third Parties 3. Analysis of Issues as They Relate to First and Third Parties
In this section we present an analysis of whether the issues In this section, we present an analysis of whether the issues
identified in the remainder of this document are applicable to the identified in the remainder of this document are applicable to the
organization deploying the shared addressing mechanism (and by organization 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.). parties (e.g., content providers, law enforcement agencies, etc.).
In this analysis, issues that affect end-users are deemed to affect In this analysis, issues that affect end-users are deemed to affect
1st parties, as end-users can be expected to complain to their first parties, as end-users can be expected to complain to their
service provider when problems arise. Where issues can expect to be service provider when problems arise. Where issues can expect to be
foreseen and addressed by the party deploying the shared addressing foreseen and addressed by the party deploying the shared addressing
solution, they are not attributed. solution, they are not attributed.
In Figure 1 we have also tried to indicate (with 'xx') where issues 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 are newly created in addition to what could be expected from the
introduction of a traditional NAT device. Issues marked with a introduction of a traditional NAT device. Issues marked with a
single 'x' are already present today in the case of typical CPE NAT, 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 however, they can be expected to be more severe and widespread in the
case of large-scale address sharing. case of large-scale address sharing.
+------------------------------------------------+--------+---------+ +------------------------------------------------+--------+---------+
| Issue | 1st | 3rd | | Issue | 1st | 3rd |
| | party | parties | | | party | parties |
+------------------------------------------------+--------+---------+ +------------------------------------------------+--------+---------+
| Restricted allocations of outgoing | x | | | Restricted allocations of outgoing | x | |
| ports will impact performance for end users | | | | ports will impact performance for end-users | | |
| | | | | | | |
| Incoming port negotiation mechanisms may fail | xx | | | Incoming port negotiation mechanisms may fail | xx | |
| | | | | | | |
| Incoming connections to Assigned Ports will | x | | | Incoming connections to Assigned Ports will | x | |
| not work | | | | not work | | |
| | | | | | | |
| Port discovery mechanisms will not work | x | | | Port discovery mechanisms will not work | x | |
| | | | | | | |
| Some applications will fail to operate | x | x | | Some applications will fail to operate | x | x |
| | | | | | | |
skipping to change at page 7, line 14 skipping to change at page 7, line 14
+------------------------------------------------+--------+---------+ +------------------------------------------------+--------+---------+
| Issue | 1st | 3rd | | Issue | 1st | 3rd |
| | party | parties | | | party | parties |
+------------------------------------------------+--------+---------+ +------------------------------------------------+--------+---------+
| TCP control block sharing will be affected | x | x | | TCP control block sharing will be affected | x | x |
| | | | | | | |
| 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 | xx | xx | | Amplification of security issues will occur | 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 may occur | | |
| | | | | | | |
| Port randomization will be affected | x | | | Port randomization will be affected | x | |
| | | | | | | |
| Service usage monitoring and abuse logging | xx | xx | | Service usage monitoring and abuse logging | xx | xx |
| 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 | xx | xx | | Penalty boxes will no longer work | xx | xx |
| | | | | | | |
| Spam blacklisting will be affected | xx | xx | | Spam blacklisting will be affected | xx | xx |
skipping to change at page 7, line 44 skipping to change at page 7, line 44
| | | | | | | |
| Load balancing algorithms may be impacted | | xx | | 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 | | xx | | Traceability of network usage and abusage will | | xx |
| be affected | | | | be affected | | |
| | | | | | | |
| IPv6 transition mechanisms will be affected | xx | | | IPv6 transition mechanisms will be affected | xx | |
| | | | | | | |
| Frequent keep-alives reduce battery life | x | | | Frequent keep-alives will 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. Several of these issues are specific to the introduction mechanism. Several of these issues are specific to the introduction
of large-scale address sharing as well. All of these issues are of large-scale address sharing as well. All of these issues are
discussed in further detail below. discussed in further detail below.
4. Content Provider Example 4. Content Provider Example
Taking a content provider as an example of a third-party, and Taking a content provider as an example of a third party, and
focusing on the issues that are created specifically by the presence focusing on the issues that are created specifically by the presence
of large-scale address sharing, we identify the following issues as of large-scale address sharing, we identify the following issues as
being of particular concern: being of particular concern:
o Degraded geolocation for targeted advertising and licensed content o Degraded geo-location for targeted advertising and licensed
restrictions (see Section 7). content restrictions (see Section 7).
o Additional latency due to indirect routing and degraded o Additional latency due to indirect routing and degraded geo-
geoproximity (see Section 7). proximity (see Section 7).
o Exposure to new amplification attacks (see Section 13). o Exposure to new amplification attacks (see Section 13).
o Service usage monitoring is made more complicated (see Section 8). o Service usage monitoring is made more complicated (see Section 8).
o Incoming port negotiation mechanisms may fail (see Section 5.2.1). o Incoming port negotiation mechanisms may fail (see Section 5.2.1).
o IP blocking for abuse/spam will cause collateral damage (see o IP blocking for abuse/spam will cause collateral damage (see
Section 13). Section 13).
o Load balancing algorithms may be impacted (see Section 16). o Load balancing algorithms may be impacted (see Section 16).
o Traceability of network usage and abuse will be impacted (see o Traceability of network usage and abuse will be impacted (see
Section 12). Section 12).
5. Port Allocation 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
outgoing connections and incoming connections. For outgoing between 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).
The total number of subscribers able to share a single IPv4 address The total number of subscribers able to share a single IPv4 address
will depend upon assumptions about the average number of ports will depend upon assumptions about the average number of ports
required per active subscriber, and the average number of required per active subscriber, and the average number of
simultaneously active subscribers. It is important to realize that simultaneously active subscribers. It is important to realize that
the TCP design makes it undesirable for clients to re-use ports while the TCP design makes it undesirable for clients to re-use ports while
they remain in the TIME-WAIT state (typically 4 minutes after the they remain in the TIME-WAIT state (typically 4 minutes after the
connection has concluded). TIME-WAIT state removes the hazard of old connection has concluded). TIME-WAIT state removes the hazard of old
duplicates for "fast" or "long" connections, in which clock-driven duplicates for "fast" or "long" connections, in which clock-driven
Initial Sequence Number selection is unable to prevent overlap of the Initial Sequence Number selection is unable to prevent overlap of the
old and new sequence spaces. The TIME-WAIT delay allows all old old and new sequence spaces. The TIME-WAIT delay allows all old
duplicate segments time enough to die in the Internet before the duplicate segments time enough to die in the Internet before the
connection is reopened [RFC1337]. Therefore ports in this state must connection is reopened [RFC1337]. Therefore, ports in this state
be included in calculations concerning port usage per subscriber. must be included in calculations concerning port usage per
subscriber.
Most of the time the source port selected by a client application Most of the time the source port selected by a client application
will be translated (unless there is direct knowledge of a port-range will be translated (unless there is direct knowledge of a port-range
restriction in the client's stack), either by a NAT in the 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. subscriber's device, or by a CPE NAT, or by a CPE NAT and a CGN.
[RFC1700] defines the Assigned Ports (both System and User). IANA [RFC1700] (which was replaced by an online database, as described by
[RFC3232]) defines the Assigned Ports (both System and User). IANA
has further classified the whole port space into three categories, as has further classified the whole port space into three categories, as
defined in [IANA_Ports] defined in [IANA_Ports]:
o The Well-Known Ports are those from 0 through 1023. o The Well-Known Ports are those from 0 through 1023.
o The Registered Ports are those from 1024 through 49151. o The Registered Ports are those from 1024 through 49151.
o The Dynamic and/or Private Ports are those from 49152 through o The Dynamic and/or Private Ports are those from 49152 through
65535. 65535.
[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.
5.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
skipping to change at page 10, line 36 skipping to change at page 10, line 38
However, static schemes for ports assignment may introduce security However, static schemes for ports assignment may introduce security
issues [RFC6056] when small contiguous port ranges are statically issues [RFC6056] when small contiguous port ranges are statically
assigned to subscribers. Another way to mitigate this issue is to assigned to subscribers. Another way to mitigate this issue is to
kill off (randomly) established connections when the port space runs kill off (randomly) established connections when the port space runs
out. A user with many connections will be proportionally more likely out. A user with many connections will be proportionally more likely
to get impacted. to get impacted.
Session failure due to NAT state overflow or timeout (when the NAT Session failure due to NAT state overflow or timeout (when the NAT
discards session state because it's run out of resource) can be discards session state because it's run out of resource) can be
experienced when the configured quota per user is reached or if the experienced when the configured quota per user is reached or if the
NAT is out of recourses. NAT is out of resources.
5.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
has no real notion of how long an application/service session is therefore has no real notion of how long an application/service
still ongoing and therefore requiring port stability. session is 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.
5.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 Universal Plug and Play either manually, or with a protocol such as the Universal Plug and
Internet Gateway Device (UPnP IGD) [UPnP-IGD]. If a CGN is present, Play Internet Gateway Device (UPnP IGD) [UPnP-IGD]. If a CGN is
the port must also be opened in the CGN. CGN makes subscribers present, the port must also be opened in the CGN. CGN makes
dependent on their service provider for this functionality. subscribers dependent on their service provider for this
functionality.
If the CPE and the CGN are required to co-operate in order for port CPE and CGN will need to cooperate in order for port forwarding
forwarding functionality to work, protocol development will be functionality to work. UPnP, or NAT-PMP proxy could be a solution if
required to provide an automated solution. If the CGN architecture there is a direct link (or tunnel) between the CPE and the CGN. An
is composed of only one NAT level (no NAT in the CPE) as for DS-Lite, alternative solution is a web interface to configure the incoming
the service provider will still be required to offer some means for port mapping on the CGN. Protocol development is underway in the
configuring incoming ports by their subscribers. This may be either IETF to provide a generalized, automated solution via the Port
via a PCP [I-D.ietf-pcp-base], UPnP or NAT-PMP proxy over a tunneled Control Protocol [PCP].
direct connection between the CPE and CGN, or a web interface to
configure the incoming port mapping on the CGN. Note, that such an Note that such an interface effectively makes public what was
interface effectively makes public what was previously a private previously a private management interface and this raises security
management interface and this raises security concerns that must be concerns that must be addressed.
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).
5.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
no, the application will typically try the next port in sequence, 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 until it either finds one that works or gives up after a limited
number of attempts. UPnP IGD 1.0 has no way to redirect the number of attempts. UPnP IGD 1.0 has no way to redirect the
application to use another port number. UPnP IGD 2.0 improves this application to use another port number. UPnP IGD 2.0 improves this
situation and allows for allocation of any available port. situation and allows for allocation of any available port.
5.2.1.2. NAT Port Mapping Protocol (NAT-PMP) 5.2.1.2. NAT Port Mapping Protocol (NAT-PMP)
NAT-PMP enables the NAT to redirect the requesting application to a NAT-PMP enables the NAT to redirect the requesting application to a
port deemed to be available for use by the NAT state mapping table. port deemed to be available for use by the NAT state mapping table.
5.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, inbound Once an IPv4-address sharing mechanism is in place, inbound
connections to well-known port numbers will not work in the general connections to well-known port numbers will not work in the general
case. Any application that is not port-agile cannot be expected to case. Any application that is not port-agile cannot be expected to
work. Some workaround (e.g., redirects to a port-specific URI) could work. Some workaround (e.g., redirects to a port-specific URI) could
be deployed given sufficient incentives. There exist several be deployed given sufficient incentives. There exist several
proposals for 'application service location' protocols which would proposals for 'application service location' protocols that would
provide a means of addressing this problem, but historically these provide a means of addressing this problem, but historically these
proposals have not gained much deployment traction. proposals have not 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 and many other noting that this mechanism is not applicable to HTTP and many other
protocols. protocols.
5.2.3. Port Discovery Mechanisms 5.2.3. Port Discovery Mechanisms
Port discovery using a UDP port to discover a service available on a Port discovery using a UDP port to discover a service available on a
corresponding TCP port, either through broadcast, multicast or corresponding TCP port, either through broadcast, multicast, or
unicast, is a commonly deployed mechanism. Unsolicited inbound UDP unicast, is a commonly deployed mechanism. Unsolicited inbound UDP
will be dropped by address sharing mechanisms as they have no live will be dropped by address sharing mechanisms as they have no live
mapping to enable them to forward the packet to the appropriate host. mapping to enable them to forward the packet to the appropriate host.
Address sharing thereby breaks this service discovery technique. Address sharing thereby breaks this service discovery technique.
6. 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 5.2 for more discussion of CGN-based solutions). See Section 5.2 for more discussion.
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. Note that ALGs are required in data is appropriately modified. Note that ALGs are required in
some cases, and in many other cases end-to-end protocol mechanisms some cases, and in many other cases end-to-end protocol mechanisms
have developed to work around a lack of ALGs in address have developed to work around a lack of ALGs in address
translators, to the point of it being preferable to avoid any translators, to the point of it being preferable to avoid any
support in the NAT; support in the NAT.
o Applications that use fixed ports - see Section 5.2.2 for more o Applications that use fixed ports - See Section 5.2.2 for more
discussion of this; discussion.
o Applications that do not use any port (e.g., ICMP echo) - will o Applications that do not use any port (e.g., ICMP echo) - Such
require special handling - see Section 9 for more discussion of applications will require special handling -- see Section 9 for
this; more discussion.
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 o Applications that do not use TCP or UDP for transport - All IP-
address sharing mechanisms proposed to date are limited to TCP, address sharing mechanisms proposed to date are limited to TCP,
UDP, and ICMP, thereby preventing end users from fully utilizing UDP, and ICMP, thereby preventing end-users from fully utilizing
the Internet (e.g., SCTP, DCCP, RSVP, protocol 41 (IPv6-over- the Internet (e.g., SCTP, DCCP, RSVP, protocol 41 (IPv6-over-
IPv4), protocol 50 (IPsec ESP)). 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. For set of ALGs that their service provider makes available. For
port-range solutions, ALGs will require modification to deal with port-range solutions, ALGs will require modification to deal with
the port-range restriction, but will otherwise have the same the port-range restriction, but will otherwise have the same
capabilities as today. Note that ALGs are required in some cases, capabilities as today. Note that ALGs are required in some cases,
and in many other cases end-to-end protocol mechanisms have and in many other cases end-to-end protocol mechanisms have
developed to work around lack of ALGs, to the point of it being developed to work around a lack of ALGs, to the point of it being
preferable to avoid any support in the NAT. preferable to avoid any support in the NAT.
o NAT Traversal Techniques: There are several commonly-deployed o NAT Traversal Techniques: There are several commonly deployed
mechanisms that support operating servers behind a NAT by mechanisms that support operating servers behind a NAT by
forwarding specific TCP or UDP ports to specific internal hosts forwarding specific TCP or UDP ports to specific internal hosts
([UPnP-IGD], [I-D.cheshire-nat-pmp], and manual configuration). ([UPnP-IGD], [NAT-PMP], and manual configuration). All of these
All of these mechanisms assume the NAT's WAN address is a mechanisms assume the NAT's WAN address is a publicly routable IP
publicly-routable IP address, and fail to work normally when that address, and fail to work normally when that assumption is wrong.
assumption is wrong. There have been attempts to avoid that There have been attempts to avoid that problem by automatically
problem by automatically disabling the NAT function and bridging disabling the NAT function and bridging traffic instead upon
traffic instead upon assignment of a private IP address to the WAN assignment of a private IP address to the WAN interface (as is
interface (as is required for [Windows-Logo] certification). required for [Windows-Logo] certification). Bridging (rather than
Bridging (rather than NATting) has other side effects (DHCP NATting) has other side effects (DHCP requests are served by an
requests are served by an upstream DHCP server which can increase upstream DHCP server that can increase complexity of in-home
complexity of in-home networking). networking).
7. 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. Using IP addresses in this fashion is a heuristic at best, located. Using IP addresses in this fashion is a heuristic at best,
and is already challenged today by other deployed capabilities, e.g., and is already challenged today by other deployed capabilities, e.g.,
tunnels. Geo-location services are used by content providers to tunnels. 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
customized content. Geo-location services are also necessary for customized 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.,
centralized CGN), shared addressing will reduce the level of centralized 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. Viewed from the content provider, a location services can provide. Viewed from the content provider, a
subscriber behind a CGN geolocates to wherever the prefix of the CGN subscriber behind a CGN geo-locates to wherever the prefix of the CGN
appears to be; very often that will be in a different city than the appears to be; very often that will be in a different city than the
subscriber. subscriber.
IP addresses are also used as input to geolocation services that IP addresses are also used as input to geo-location services that
resolve an IP address to a physical location using information from resolve an IP address to a physical location using information from
the network infrastructure. Current systems rely on resources such the network infrastructure. Current systems rely on resources such
as RADIUS databases and DHCP lease tables. The use of address as RADIUS databases and DHCP lease tables. The use of address
sharing will prevent these systems from resolving the location of a sharing will prevent these systems from resolving the location of a
host based on IP address alone. It will be necessary for users of host based on IP address alone. It will be necessary for users of
such systems to provide more information (e.g., TCP or UDP port such systems to provide more information (e.g., TCP or UDP port
numbers), and for the systems to use this information to query numbers), and for the systems to use this information to query
additional network resources (e.g., NAT-PT binding tables). Since additional network resources (e.g., Network Address Translation -
these new data elements tend to be more ephemeral than those Protocol Translation (NAT-PT) binding tables). Since these new data
currently used for geolocation, their use by geolocation systems may elements tend to be more ephemeral than those currently used for geo-
require them to be cached for some period of time. location, their use by geo-location systems may require them to be
cached for some period of time.
Other forms of geo-location will still work as usual. 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.
skipping to change at page 15, line 36 skipping to change at page 15, line 32
9. ICMP 9. ICMP
ICMP does not include a port field and is consequently problematic ICMP does not include a port field and is consequently problematic
for address sharing mechanisms. Some ICMP message types include a for address sharing mechanisms. Some ICMP message types include a
fragment of the datagram that triggered the signal to be sent, which fragment of the datagram that triggered the signal to be sent, which
is assumed to include port numbers. For some ICMP message types, the is assumed to include port numbers. For some ICMP message types, the
Identifier field has to be used as a de-multiplexing token. Sourcing Identifier field has to be used as a de-multiplexing token. Sourcing
ICMP echo messages from hosts behind an address sharing solution does ICMP echo messages from hosts behind an address sharing solution does
not pose problems, although responses to outgoing ICMP echo messages not pose problems, although responses to outgoing ICMP echo messages
will require special handling, such as making use of the ICMP will require special handling, such as making use of the ICMP
identifier value to route the response appropriately. Identifier value to route the response 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
provider. Where ICMP messages include a fragment of an outgoing provider. Where ICMP messages include a fragment of an outgoing
packet including port numbers it may be possible to forward the packet including port numbers, it may be possible to forward the
packet appropriately. In addition to these network signaling packet appropriately. In addition to these network signaling
messages, several applications (e.g., P2P applications) make use of messages, several applications (e.g., peer-to-peer applications) make
ICMP echo messages which include no hints that could be used to route use of ICMP echo messages that include no hints that could be used to
the packet correctly. Measurements derived by such applications in route the packet correctly. Measurements derived by such
the presence of an address sharing solution will be erroneous or fail applications in the presence of an address sharing solution will be
altogether. The second case is that of ICMP sourced from within the erroneous or fail altogether. The second case is that of ICMP
network of the address sharing solution provider (e.g., for network sourced from within the network of the address sharing solution
management, signaling and diagnostic purposes). In this case ICMP provider (e.g., for network management, signaling, and diagnostic
can be routed normally for CGN-based solutions owing to the presence purposes). In this case, ICMP can be routed normally for CGN-based
of locally unique private IP addresses for each CPE device. For solutions owing to the presence of locally unique private IP
port-range solutions, ICMP echo messages will not be routable without addresses for each CPE device. For port-range solutions, ICMP echo
special handling, e.g., placing a port number in the ICMP identifier messages will not be routable without special handling, e.g., placing
field, and having port-range routers make routing decisions based a port number in the ICMP Identifier field, and having port-range
upon that field. routers make routing decisions based upon that field.
Considerations related to ICMP message handling in NAT-based Considerations related to ICMP message handling in NAT-based
environments are specified in [RFC5508]. environments are specified in [RFC5508].
10. MTU 10. MTU
In applications where the end hosts are attempting to use path MTU In applications where the end hosts are attempting to use path MTU
Discovery [RFC1191] to optimize transmitted packet size with Discovery [RFC1191] to optimize transmitted packet size with
underlying network MTU, shared addressing has a number of items which underlying network MTU, shared addressing has a number of items that
must be considered. As covered in Section 9, ICMP "Packet Too Big" must be considered. As covered in Section 9, ICMP "Packet Too Big"
messages must be properly translated through the address sharing messages must be properly translated through the address sharing
solution in both directions. However, even when this is done solution in both directions. However, even when this is done
correctly, MTU can be a concern. Many end hosts cache PMTUd correctly, MTU can be a concern. Many end hosts cache information
information for a certain period of time. If the MTU behind the that was received via Path MTU Discovery (PMTUD) for a certain period
address sharing solution is inconsistent, the public end host may of time. If the MTU behind the address sharing solution is
have the incorrect MTU value cached. This may cause it to send inconsistent, the public end host may have the incorrect MTU value
packets that are too large, causing them to be dropped if the DF cached. This may cause it to send packets that are too large,
(Don't Fragment) bit is set, or causing them to be fragmented by the causing them to be dropped if the DF (Don't Fragment) bit is set, or
network, increasing load and overhead. Because the host eventually causing them to be fragmented by the network, increasing load and
will reduce MTU to the lowest common value for all hosts behind a overhead. Because the host eventually will reduce MTU to the lowest
given public address, it may also send packets that are below optimal common value for all hosts behind a given public address, it may also
size for the specific connection, increasing overhead and reducing send packets that are below optimal size for the specific connection,
throughput. increasing overhead and reducing throughput.
This issue also generates a potential attack vector, that a This issue also generates a potential attack vector -- a malevolent
malevolent user could send an ICMP "Packet Too Big" (Type 3, Code 4) user could send an ICMP "Packet Too Big" (Type 3, Code 4) message
message indicating a Next-Hop MTU of anything down to 68 octets. indicating a Next-Hop MTU of anything down to 68 octets. This value
This value will be cached by the off-net server for all subscribers will be cached by the off-net server for all subscribers sharing the
sharing the address of the malevolent user. This could lead to a DoS address of the malevolent user. This could lead to a denial of
against both the remote server and the large-scale NAT device itself service (DoS) against both the remote server and the large-scale NAT
(as they will both have to handle many more packets per second). device itself (as they will both have to handle many more packets per
second).
11. Fragmentation 11. 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. In addition, the IP Identifier may no longer be special handling. In addition, the IP Identifier may no longer be
unique as required by the receiver to aid in assembling the fragments unique as required by the receiver to aid in assembling the fragments
of a datagram. of a datagram.
skipping to change at page 17, line 23 skipping to change at page 17, line 23
However, where one public IPv4 address is shared between several However, where one public IPv4 address is shared between several
subscribers, the IPv4 address no longer uniquely identifies a subscribers, the IPv4 address no longer uniquely identifies a
subscriber. There are two solutions to this problem: subscriber. There are two solutions to this problem:
o The first solution is for servers to additionally log the source o The first solution is for servers to additionally log the source
port of incoming connections and for the legal request to include port of incoming connections and for the legal request to include
the source port. The legal request should include the the source port. The legal request should include the
information: [Source IP address, Source Port, Timestamp] (and information: [Source IP address, Source Port, Timestamp] (and
possibly other information). Accurate time-keeping (e.g., use of possibly other information). Accurate time-keeping (e.g., use of
NTP or SNTP) is vital because port assignments are dynamic. A NTP or Simple NTP) is vital because port assignments are dynamic.
densely populated CGN could mean even very small amounts of clock A densely populated CGN could mean even very small amounts of
skew between a third party's server and the CGN operator will clock skew between a third party's server and the CGN operator
result in ambiguity about which customer was using a specific port will result in ambiguity about which customer was using a specific
at a given time. port at a given time.
o The second solution considers it is unrealistic to expect all o The second solution considers it unrealistic to expect all servers
servers to log the source port number of incoming connections. To to log the source port number of incoming connections. To deal
deal with this, service providers using IPv4 address sharing may with this, service providers using IPv4 address sharing may need
need to log IP destination addresses. to log IP destination addresses.
Destination logging is imperfect if multiple subscribers are Destination logging is imperfect if multiple subscribers are
accessing the same (popular) server at nearly the same time, it can accessing the same (popular) server at nearly the same time; it can
be impossible to disambiguate which subscriber accessed the server, be impossible to disambiguate which subscriber accessed the server,
especially with protocols that involve several connections (e.g., especially with protocols that involve several connections (e.g.,
HTTP). Thus, logging the destination address on the NAT is inferior HTTP). Thus, logging the destination address on the NAT is inferior
to logging the source port at the server. to logging the source port at the server.
If neither solution is used (that is, the server is not logging If neither solution is used (that is, the server is not logging
source port numbers and the NAT is not logging destination IP source port numbers and the NAT is not logging destination IP
addresses), the service provider cannot trace a particular activity addresses), the service provider cannot trace a particular activity
to a specific subscriber. In this circumstance, the service provider to a specific subscriber. In this circumstance, the service provider
would need to disclose the identity of all subscribers who had active would need to disclose the identity of all subscribers who had active
skipping to change at page 18, line 14 skipping to change at page 18, line 14
all subscribers during one year (if the legal storage duration is one all subscribers during one year (if the legal storage duration is one
year). This may be challenging due to the volume of data requiring year). This may be challenging due to the volume of data requiring
storage, the volume of data to repeatedly transfer to the storage storage, the volume of data to repeatedly transfer to the storage
location, and the volume of data to search in response to a query. location, and the volume of data to search in 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 port groups, the ratio of public addresses to the sizes of these port groups, the ratio of public addresses to
subscribers, whether or not these groups timeout, the impact on subscribers, whether or not these groups timeout, and the impact on
logging requirements and port randomization security [RFC6056]. logging requirements and port randomization security [RFC6056].
13. Security 13. 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 10 for one example. ways. See Section 10 for one example.
13.1. Abuse Logging and Penalty Boxes 13.1. Abuse Logging and Penalty Boxes
skipping to change at page 18, line 39 skipping to change at page 18, line 39
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 services on the network today log the IPv4 source A number of services on the network today log the IPv4 source
addresses used in connection attempts to protect themselves from addresses used in connection attempts to protect themselves from
certain attacks. For example, if a server sees too many requests certain attacks. For example, if a server sees too many requests
from the same IPv4 address in a short period of time, it may decide from the same IPv4 address in a short period of time, it may decide
to put that address in a penalty box for a certain time during which 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 requests are denied, or it may require completion of a CAPTCHA
future requests. If an IPv4 address is shared by multiple (Completely Automated Public Turing test to tell Computers and Humans
Apart) 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.
In addition, there are web tie-ins into different blacklists that web In addition, there are web tie-ins into different blacklists that web
administrators subscribe to redirect users with infected machines administrators subscribe to in order to redirect users with infected
(e.g., detect the presence of a worm) to a URL that says "Hey, your machines (e.g., detect the presence of a worm) to a URL that says
machine is infected!". With address sharing, someone else's worm can "Hey, your machine is infected!". With address sharing, someone
interfere with the ability to access the service for other else's worm can interfere with the ability to access the service for
subscribers sharing the same IP address. other subscribers sharing the same IP address.
13.2. Authentication 13.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 5.1. requirement for dynamic assignments discussed in Section 5.1.
Address or DNS-name based signatures (e.g., some X.509 signatures) Address or DNS-name-based signatures (e.g., some X.509 signatures)
may also be affected by address sharing as the address itself is now may also be affected by address sharing as the address itself is now
a shared token, and the name to address mapping may not be current. a shared token, and the name to address mapping may not be current.
13.3. SPAM 13.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.
13.4. Port Randomisation 13.4. Port Randomization
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. [RFC6056] describes the transport protocol instance to be attacked. [RFC6056] describes
a number of methods for the random selection of the source port a number of methods for the random selection of the source port
number, such that the ability of an attacker to correctly guess the number, such that the ability of an attacker to correctly guess the
5-tuple is reduced. With shared IPv4 addresses, the port selection 5-tuple is reduced. With shared IPv4 addresses, the port selection
space is reduced. Preserving port randomization is important and may space is reduced. Preserving port randomization is important and may
be more or less difficult depending on the address sharing solution be more or less difficult depending on the address sharing solution
and the size of the port space that is being manipulated. Allocation and the size of the port space that is being manipulated. Allocation
of non-contiguous port ranges could help to mitigate this issue. of non-contiguous port ranges could help to mitigate this issue.
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. An in-window TCP sufficient to carry out a successful blind attack. An in-window TCP
Sequence Number (SN) should also be known or guessed. A TCP segment Sequence Number (SN) should also be known or guessed. A TCP segment
is processed only if all previous segments have been received, except is processed only if all previous segments have been received, except
for some Reset segment implementations which immediately process the for some Reset segment implementations that 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
randomization is one protection among others against blind attacks. randomization is one protection among others against blind attacks.
There is more detailed discussion of improving TCP's robustness to There is more detailed discussion of improving TCP's robustness to
Blind In-Window Attacks in [RFC5961]. Blind In-Window Attacks in [RFC5961].
13.5. IPsec 13.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]. [RFC5996] specifies Internet solve issues documented in [RFC3715]. [RFC5996] specifies Internet
Key Exchange (IKE) Protocol Version 2 which includes NAT traversal Key Exchange (IKE) Protocol Version 2, which includes NAT traversal
mechanisms that are now widely used to enable IPsec to work in the mechanisms that are now widely used to enable IPsec to work in the
presence of NATs in many cases. Nevertheless, service providers may presence of NATs in many cases. Nevertheless, service providers may
wish to ensure that CGN deployments do not inadvertently block NAT wish to ensure that CGN deployments do not inadvertently block NAT
traversal for security protocols such as IKE (refer to traversal for security protocols such as IKE (refer to [NAT-SEC] for
[I-D.gont-behave-nat-security] for more information). more information).
13.6. Policing Forwarding Behaviour 13.6. Policing Forwarding Behavior
[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 DoS attacks that use forged IP addresses. Following this
addresses. Following this recommendation, service providers recommendation, service providers operating shared-addressing
operating shared-addressing mechanisms should ensure that source mechanisms should ensure that source addresses, or source ports in
addresses, or source ports in the case of port-range schemes, are set the case of port-range schemes, are set correctly in outgoing packets
correctly in outgoing packets from their subscribers or they should 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 internal interface of a CGN. accept traffic on the internal interface of a CGN.
14. Transport Issues 14. Transport Issues
14.1. Parallel connections 14.1. Parallel Connections
Systems that assume that multiple simultaneous connections to a One issue is systems that assume that multiple simultaneous
single IP address implies connectivity to a single host - such connections to a single IP address implies connectivity to a single
systems may experience unexpected results. host -- such systems may experience unexpected results.
14.2. Serial connections 14.2. Serial Connections
Systems that assume that returning to a given IP address means Another issue is systems that assume that returning to a given IP
returning to the same physical host, as with stateful transactions. address means returning to the same physical host, as with stateful
This may also affect cookie-based systems. transactions. This may also affect cookie-based systems.
14.3. TCP Control Block Sharing 14.3. TCP Control Block Sharing
[RFC2140] defines a performance optimization for TCP based on sharing [RFC2140] defines a performance optimization 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 optimization assumes that an address says something connection. This optimization 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
skipping to change at page 21, line 49 skipping to change at page 21, line 43
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.
17. IPv6 Transition Issues 17. 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
utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize
Teredo [RFC4380]. Teredo [RFC4380].
Some routers enable 6to4 on their WAN link. 6to4 requires a publicly- Some routers enable 6to4 on their WAN link. 6to4 requires a publicly
routable IPv4 address. Enabling 6to4 when the apparently public IPv4 routable IPv4 address. Enabling 6to4 when the apparently public IPv4
WAN address is in fact behind a NAT creates a disconnected IPv6 WAN address is in fact behind a NAT creates a disconnected IPv6
island. island.
18. Introduction of Single Points of Failure 18. 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
skipping to change at page 23, line 7 skipping to change at page 22, line 44
20. Support of Multicast 20. 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.
21. Support of Mobile-IP 21. 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] [NAT64-MOBILITY].
22. IANA Considerations
This memo includes no request to IANA.
23. Security Considerations 22. Security Considerations
This memo does not define any protocol and therefore creates no new This memo does not define any protocol and therefore creates no new
security issues. Section 13 discusses some of the security and security issues. Section 13 discusses some of the security and
identity-related implications of IP address sharing. identity-related implications of IP address sharing.
24. 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.
25. Acknowledgments 24. Acknowledgments
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. Charnock, Martin Levy, Greg Wood, and Christian Jacquenet.
The authors are also grateful to Christian Jacquenet, Iain Calder, The authors are also grateful to Christian Jacquenet, Iain Calder,
Joel Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo Joel Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo
Bagnulo, Dan Wing and Wes George for their helpful comments and Bagnulo, Dan Wing, and Wes George for their helpful comments and
suggestions for improving the document. suggestions for improving the document.
This memo was created using the xml2rfc tool. This memo was created using the xml2rfc tool.
26. Annex 25. Informative References
26.1. Classes of Address Sharing Solution
IP address sharing solutions fall into two classes. Either a
service-provider operated NAT function is introduced and subscribers
are allocated addresses from [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.
o 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)
[I-D.ietf-behave-lsn-requirements], 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 [I-D.shirasaki-nat444] (two layers of
NAT) and [I-D.ietf-softwire-dual-stack-lite] (a single layer of
NAT).
o 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) [I-D.ymbk-aplusp],
or Port Range [I-D.boucadair-port-range], or SAM (Stateless
Address Mapping) [I-D.despres-sam].
26.2. Address Space Multiplicative Factor
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.
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:
o It would not be compatible with the service they are currently
subscribed to (for example: business subscriber).
o 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.
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.
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 [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.
27. Informative References [A+P] Bush, R., "The A+P Approach to the IPv4 Address Shortage",
Work in Progress, February 2011.
[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] [DS-Lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
"IPv4 Connectivity Access in the Context of IPv4 Address
Exhaustion: Port Range based IP Architecture",
draft-boucadair-port-range-02 (work in progress),
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]
Despres, R., "Scalable Multihoming across IPv6 Local-
Address Routing Zones Global-Prefix/Local-Address
Stateless Address Mapping (SAM)", draft-despres-sam-03
(work in progress), July 2009.
[I-D.gont-behave-nat-security]
Gont, F. and P. Srisuresh, "Security implications of
Network Address Translators (NATs)",
draft-gont-behave-nat-security-03 (work in progress),
October 2009.
[I-D.haddad-mext-nat64-mobility-harmful]
Haddad, W. and C. Perkins, "A Note on NAT64 Interaction
with Mobile IPv6",
draft-haddad-mext-nat64-mobility-harmful-01 (work in
progress), April 2010.
[I-D.ietf-behave-lsn-requirements]
Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida,
"Common requirements for IP address sharing schemes",
draft-ietf-behave-lsn-requirements-00 (work in progress),
October 2010.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
progress), September 2010.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-12 (work in
progress), July 2010.
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and F.
Dupont, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-06 (work in progress), February 2011.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work Exhaustion", Work in Progress, May 2011.
in progress), August 2010.
[I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
in progress), January 2011.
[I-D.ymbk-aplusp]
Bush, R., "The A+P Approach to the IPv4 Address Shortage",
draft-ymbk-aplusp-09 (work in progress), February 2011.
[IANA_Ports] [IANA_Ports]
Geoff Huston, "IANA Port Number Assignments", IANA, "Port Numbers", <http://www.iana.org>.
February 2011,
<http://www.iana.org/assignments/port-numbers>.
[IPv4_Pool] [IPv4_Pool]
Geoff Huston, "Available Pool of Unallocated IPv4 Internet ICANN, "Available Pool of Unallocated IPv4 Internet
Addresses Now Completely Emptied", 2011, Addresses Now Completely Emptied", February 2011,
<http://icann.org/en/news/releases/ <http://icann.org/en/news/releases/
release-03feb11-en.pdf>. release-03feb11-en.pdf>.
[LSN-REQS] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for IP address sharing
schemes", Work in Progress, March 2011.
[Mobile_Energy_Consumption] [Mobile_Energy_Consumption]
Haverinen, H., Siren, J., and P. Eronen, "Energy Haverinen, H., Siren, J., and P. Eronen, "Energy
Consumption of Always-On Applications in WCDMA Networks", Consumption of Always-On Applications in WCDMA Networks",
2007, <http://research.nokia.com/node/5597>. April 2007, <http://research.nokia.com/node/5597>.
[NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work
in Progress, April 2008.
[NAT-SEC] Gont, F. and P. Srisuresh, "Security implications of
Network Address Translators (NATs)", Work in Progress,
October 2009.
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", January 2011.
[NAT64-MOBILITY]
Haddad, W. and C. Perkins, "A Note on NAT64 Interaction
with Mobile IPv6", Work in Progress, March 2011.
[PCP] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", Work
in Progress, May 2011.
[PORT-RANGE]
Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
"IPv4 Connectivity Access in the Context of IPv4 Address
Exhaustion: Port Range based IP Architecture", Work
in Progress, July 2009.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992. RFC 1337, May 1992.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
skipping to change at page 28, line 4 skipping to change at page 25, line 21
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
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 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[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.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
skipping to change at page 28, line 49 skipping to change at page 26, line 21
August 2010. August 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, Protocol Port Randomization", BCP 156, RFC 6056,
January 2011. January 2011.
[UPnP-IGD] [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
UPnP Forum, "Universal Plug and Play (UPnP) Internet Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[SAM] Despres, R., "Scalable Multihoming across IPv6 Local-
Address Routing Zones Global-Prefix/Local-Address
Stateless Address Mapping (SAM)", July 2009.
[UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD) V 2.0", December 2010, Gateway Device (IGD) V 2.0", December 2010,
<http://upnp.org/specs/gw/igd2/>. <http://upnp.org/specs/gw/igd2/>.
[Windows-Logo] [Windows-Logo]
Microsoft, "Windows Logo Program Device Requirements", Microsoft, "Windows Logo Program Requirements and
2006, <http://www.microsoft.com/whdc/winlogo/ Policies", 2006, <http://www.microsoft.com/whdc/winlogo/
hwrequirements/default.mspx>. hwrequirements/default.mspx>.
Appendix A. Classes of Address Sharing Solution
IP address sharing solutions fall into two classes. Either a
service-provider-operated NAT function is introduced and subscribers
are allocated addresses from [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.
o 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) [LSN-REQS], 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 [NAT444] (two layers
of NAT) and [DS-Lite] (a single layer of NAT).
o 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 Address+Port [A+P], or Port Range
[PORT-RANGE], or Stateless Address Mapping [SAM].
Appendix B. Address Space Multiplicative Factor
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.
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:
o It would not be compatible with the service to which they are
currently subscribed (for example, business subscriber).
o 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.
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.
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 [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.
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
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange-ftgroup.com EMail: mohamed.boucadair@orange-ftgroup.com
Alain Durand Alain Durand
Juniper Networks Juniper Networks
Email: adurand@juniper.net 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
Phil Roberts Phil Roberts
Internet Society Internet Society
Reston, VA Reston, VA
USA USA
Email: roberts@isoc.org EMail: roberts@isoc.org
 End of changes. 124 change blocks. 
408 lines changed or deleted 376 lines changed or added

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