draft-ietf-intarea-shared-addressing-issues-03.txt   draft-ietf-intarea-shared-addressing-issues-04.txt 
Internet Engineering Task Force M. Ford, Ed. Internet Engineering Task Force M. Ford, Ed.
Internet-Draft Internet Society Internet-Draft Internet Society
Intended status: Informational M. Boucadair Intended status: Informational M. Boucadair
Expires: August 14, 2011 France Telecom Expires: August 26, 2011 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
February 10, 2011 February 22, 2011
Issues with IP Address Sharing Issues with IP Address Sharing
draft-ietf-intarea-shared-addressing-issues-03 draft-ietf-intarea-shared-addressing-issues-04
Abstract Abstract
The completion of IPv4 address allocations from IANA and the RIRs is The completion of IPv4 address allocations from IANA and the RIRs is
causing service providers around the world to question how they will causing service providers around the world to question how they will
continue providing IPv4 connectivity service to their subscribers continue providing IPv4 connectivity service to their subscribers
when there are no longer sufficient IPv4 addresses to allocate them when there are no longer sufficient IPv4 addresses to allocate them
one per subscriber. Several possible solutions to this problem are one per subscriber. Several possible solutions to this problem are
now emerging based around the idea of shared IPv4 addressing. These now emerging based around the idea of shared IPv4 addressing. These
solutions give rise to a number of issues and this memo identifies solutions give rise to a number of issues and this memo identifies
those common to all such address sharing approaches. Such issues those common to all such address sharing approaches. Such issues
include application failures, additional service monitoring include application failures, additional service monitoring
complexity, new security vulnerabilities and so on. Solution- complexity, new security vulnerabilities and so on. Solution-
specific discussions are out of scope. specific discussions are out of scope.
Over the long term, deploying IPv6 is the only way to ease pressure Deploying IPv6 is the only perennial way to ease pressure on the
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2011. This Internet-Draft will expire on August 26, 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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
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 . . . . . . . . . . . . . . . . . . . . 14 8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 15
9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18 13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18
13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 18 13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 19
13.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.3. SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.4. Port Randomisation . . . . . . . . . . . . . . . . . . . . 19 13.4. Port Randomisation . . . . . . . . . . . . . . . . . . . . 19
13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.6. Policing Forwarding Behaviour . . . . . . . . . . . . . . 19 13.6. Policing Forwarding Behaviour . . . . . . . . . . . . . . 20
14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20 14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Parallel connections . . . . . . . . . . . . . . . . . . . 20 14.1. Parallel connections . . . . . . . . . . . . . . . . . . . 20
14.2. Serial connections . . . . . . . . . . . . . . . . . . . . 20 14.2. Serial connections . . . . . . . . . . . . . . . . . . . . 21
14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 20 14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 21
15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 21
16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 20 16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 21
17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21 17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21
18. Introduction of Single Points of Failure . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . 22 21. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 23
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
23. Security Considerations . . . . . . . . . . . . . . . . . . . 22 23. Security Considerations . . . . . . . . . . . . . . . . . . . 23
24. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 24. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
26. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 26. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
26.1. Classes of Address Sharing Solution . . . . . . . . . . . 23 26.1. Classes of Address Sharing Solution . . . . . . . . . . . 24
26.2. Address Space Multiplicative Factor . . . . . . . . . . . 24 26.2. Address Space Multiplicative Factor . . . . . . . . . . . 24
27. Informative References . . . . . . . . . . . . . . . . . . . . 25 27. Informative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 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 Feburary 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.
Over the long term, deploying IPv6 is the only way to ease pressure Deploying IPv6 is the only perennial way to ease pressure on the
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
skipping to change at page 5, line 17 skipping to change at page 5, line 17
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.nishitani-cgn], Dual-Stack-Lite a.k.a., LSN for Large Scale NAT) [I-D.ietf-behave-lsn-requirements],
[I-D.ietf-softwire-dual-stack-lite], NAT64 Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite], NAT64
[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate] , [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate],
Address+Port (A+P) proposals [I-D.ymbk-aplusp], Address+Port (A+P) proposals [I-D.ymbk-aplusp],
[I-D.boucadair-port-range] and SAM [I-D.despres-sam]. Section 26 [I-D.boucadair-port-range] and SAM [I-D.despres-sam]. Section 26
provides a classification of these different types of solutions and provides a classification of these different types of solutions and
discusses some of the design considerations to be borne in mind when discusses some of the design considerations to be borne in mind when
deploying large-scale address sharing. Whether we're talking about deploying large-scale address sharing. Whether we're talking about
Dual-Stack-Lite, A+P, NAT64 or CGN isn't especially important - it's DS-Lite, A+P, NAT64 or CGN isn't especially important - it's the view
the view from the outside that matters, and given that, most of the from the outside that matters, and given that, most of the issues
issues identified below apply regardless of the specific address identified below apply regardless of the specific address sharing
sharing scenario in question. Issues specific to A+P proposals are scenario in question. Issues specific to A+P proposals are addressed
addressed in [I-D.thaler-port-restricted-ip-issues]. in [I-D.thaler-port-restricted-ip-issues].
In these new proposals, a single public IPv4 address would be shared In these new proposals, a single public IPv4 address would be shared
by multiple homes or small businesses (i.e., multiple subscribers) so by multiple homes or small businesses (i.e., multiple subscribers) so
the operational paradigm described above would no longer apply. In the operational paradigm described above would no longer apply. In
this document we refer to this new paradigm as large-scale address this document we refer to this new paradigm as large-scale address
sharing. All these proposals extend the address space by adding port sharing. All these proposals extend the address space by adding port
information, they differ in the way they manage the port value. information, they differ in the way they manage the port value.
Security issues associated with NAT have long been documented (see Security issues associated with NAT have long been documented (see
[RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across [RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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
organisation 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 1st 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
skipping to change at page 7, line 21 skipping to change at page 7, line 21
| | | | | | | |
| 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 | xx | xx |
| | | | | | | |
| Fragmentation will require special handling | x | | | Fragmentation will require special handling | x | |
| | | | | | | |
| Single points of failure and increased | x | | | Single points of failure and increased | x | |
| network instability | | | | network instability | | |
| | | | | | | |
| Port randomisation will be affected | x | | | Port 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 |
| | | | | | | |
| Geo-location services will be impacted | xx | xx | | Geo-location services will be impacted | xx | xx |
skipping to change at page 9, line 4 skipping to change at page 9, line 4
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 realise 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 must
be included in calculations concerning port usage per subscriber. 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.
[RFC1340] defines the Assigned Ports (both System and User). IANA [RFC1700] 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.
skipping to change at page 10, line 28 skipping to change at page 10, line 28
subscriber devices behind such a port-shared IPv4 address becomes subscriber devices behind such a port-shared IPv4 address becomes
infected with a worm, which then quickly sets about opening many infected with a worm, which then quickly sets about opening many
outbound connections in order to propagate itself. Such an infection outbound connections in order to propagate itself. Such an infection
could rapidly exhaust the shared resource of the single IPv4 address could rapidly exhaust the shared resource of the single IPv4 address
for all connected subscribers. It is therefore necessary to impose for all connected subscribers. It is therefore necessary to impose
limits on the total number of ports available to an individual limits on the total number of ports available to an individual
subscriber to ensure that the shared resource (the IPv4 address) subscriber to ensure that the shared resource (the IPv4 address)
remains available in some capacity to all the subscribers using it. remains available in some capacity to all the subscribers using it.
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. assigned to subscribers. Another way to mitigate this issue is to
kill off (randomly) established connections when the port space runs
out. A user with many connections will be proportionally more likely
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 recourses.
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
skipping to change at page 11, line 23 skipping to change at page 11, line 26
Internet Gateway Device (UPnP IGD) [UPnP-IGD]. If a CGN is present, Internet Gateway Device (UPnP IGD) [UPnP-IGD]. If a CGN is present,
the port must also be opened in the CGN. CGN makes subscribers the port must also be opened in the CGN. CGN makes subscribers
dependent on their service provider for this functionality. dependent on their service provider for this functionality.
If the CPE and the CGN are required to co-operate in order for port If the CPE and the CGN are required to co-operate in order for port
forwarding functionality to work, protocol development will be forwarding functionality to work, protocol development will be
required to provide an automated solution. If the CGN architecture required to provide an automated solution. If the CGN architecture
is composed of only one NAT level (no NAT in the CPE) as for DS-Lite, is composed of only one NAT level (no NAT in the CPE) as for DS-Lite,
the service provider will still be required to offer some means for the service provider will still be required to offer some means for
configuring incoming ports by their subscribers. This may be either configuring incoming ports by their subscribers. This may be either
via a UPnP or NAT-PMP relay over a tunnelled direct connection via a PCP [I-D.ietf-pcp-base], UPnP or NAT-PMP proxy over a tunneled
between the CPE and CGN, or a web interface to configure the incoming direct connection between the CPE and CGN, or a web interface to
port mapping on the CGN. Note, that such an interface effectively configure the incoming port mapping on the CGN. Note, that such an
makes public what was previously a private management interface and interface effectively makes public what was previously a private
this raises security concerns that must be addressed. management interface and this raises security concerns that must be
addressed.
For port-range solutions, port forwarding capabilities may still be For port-range solutions, port forwarding capabilities may still be
present at the CPE, with the limitation that the open incoming port present at the CPE, with the limitation that the open incoming port
must be within the allocated port-range (for instance it is not must be within the allocated port-range (for instance it is not
possible to open port 5002 for incoming connections if port 5002 is possible to open port 5002 for incoming connections if port 5002 is
not within the allocated port-range). not within the allocated port-range).
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 is
no, the application will typically try the next port in sequence, no, the application will typically try the next port in sequence,
until it either finds one that works or gives up after a limited until it either finds one that works or gives up after a limited
number of attempts. UPnP 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.
skipping to change at page 12, line 21 skipping to change at page 12, line 26
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 which 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. noting that this mechanism is not applicable to HTTP and many other
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.
skipping to change at page 13, line 9 skipping to change at page 13, line 15
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 of this;
o Applications that do not use any port (e.g., ICMP) - will require o Applications that do not use any port (e.g., ICMP echo) - will
special handling - see Section 9 for more discussion of this; require special handling - see Section 9 for more discussion of
this;
o Applications that assume the uniqueness of source addresses (e.g., o Applications that assume the uniqueness of source addresses (e.g.,
IP address as identifier) - such applications will fail to operate IP address as identifier) - such applications will fail to operate
correctly in the presence of multiple, discrete, simultaneous correctly in the presence of multiple, discrete, simultaneous
connections from the same source IP address; connections from the same source IP address;
o Applications that explicitly prohibit concurrent connections from o Applications that explicitly prohibit concurrent connections from
the same address - such applications will fail when multiple the same address - such applications will fail when multiple
subscribers sharing an IP address attempt to use them subscribers sharing an IP address attempt to use them
simultaneously. simultaneously.
skipping to change at page 14, line 15 skipping to change at page 14, line 24
interface (as is required for [Windows-Logo] certification). interface (as is required for [Windows-Logo] certification).
Bridging (rather than NATting) has other side effects (DHCP Bridging (rather than NATting) has other side effects (DHCP
requests are served by an upstream DHCP server which can increase requests are served by an upstream DHCP server which can increase
complexity of in-home networking). complexity of in-home 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
customised 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.,
centralised 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 geolocates 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. Other forms of geo-location will still work as usual. subscriber.
IP addresses are also used as input to geolocation services that
resolve an IP address to a physical location using information from
the network infrastructure. Current systems rely on resources such
as RADIUS databases and DHCP lease tables. The use of address
sharing will prevent these systems from resolving the location of a
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
numbers), and for the systems to use this information to query
additional network resources (e.g., NAT-PT binding tables). Since
these new data elements tend to be more ephemeral than those
currently used for geolocation, their use by geolocation systems may
require them to be cached for some period of time.
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.
8. Tracking Service Usage 8. Tracking Service Usage
skipping to change at page 15, line 11 skipping to change at page 15, line 32
between a service provider that has deployed address sharing and a between a service provider that has deployed address sharing and a
content provider will need to be upgraded to take account of the port content provider will need to be upgraded to take account of the port
value in addition to IP addresses. value in addition to IP addresses.
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 demuxing token. Sourcing ICMP Identifier field has to be used as a de-multiplexing token. Sourcing
echo messages from hosts behind an address sharing solution does not ICMP echo messages from hosts behind an address sharing solution does
pose problems, although responses to outgoing ICMP echo messages will not pose problems, although responses to outgoing ICMP echo messages
require special handling, such as making use of the ICMP identifier will require special handling, such as making use of the ICMP
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 signalling packet appropriately. In addition to these network signaling
messages, several applications (e.g., P2P applications) make use of messages, several applications (e.g., P2P applications) make use of
ICMP echo messages which include no hints that could be used to route ICMP echo messages which include no hints that could be used to route
the packet correctly. Measurements derived by such applications in the packet correctly. Measurements derived by such applications in
the presence of an address sharing solution will be erroneous or fail the presence of an address sharing solution will be erroneous or fail
altogether. The second case is that of ICMP sourced from within the altogether. The second case is that of ICMP sourced from within the
network of the address sharing solution provider (e.g., for network network of the address sharing solution provider (e.g., for network
management, signalling and diagnostic purposes). In this case ICMP management, signaling and diagnostic purposes). In this case ICMP
can be routed normally for CGN-based solutions owing to the presence can be routed normally for CGN-based solutions owing to the presence
of locally unique private IP addresses for each CPE device. For of locally unique private IP addresses for each CPE device. For
port-range solutions, ICMP echo messages will not be routable without port-range solutions, ICMP echo messages will not be routable without
special handling, e.g., placing a port number in the ICMP identifier special handling, e.g., placing a port number in the ICMP identifier
field, and having port-range routers make routing decisions based field, and having port-range routers make routing decisions based
upon that field. 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].
skipping to change at page 17, line 20 skipping to change at page 17, line 43
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 the offending 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
sessions on the NAT during the time period in question. This may be sessions on the NAT during the time period in question. This may be
a large number of subscribers. a large number of subscribers.
Address sharing solutions must record and store all mappings Address sharing solutions must record and store all mappings
(typically during 6-12 months, depending on the local jurisdiction) (typically during 6-12 months, depending on the local jurisdiction)
that they create. If we consider one mapping per session, a service that they create. If we consider one mapping per session, a service
provider should record and retain traces of all sessions created by provider should record and retain traces of all sessions created by
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, the impact on
logging requirements and port randomisation 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 32 skipping to change at page 19, line 5
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
administrators subscribe to redirect users with infected machines
(e.g., detect the presence of a worm) to a URL that says "Hey, your
machine is infected!". With address sharing, someone else's worm can
interfere with the ability to access the service for 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) may Address or DNS-name based signatures (e.g., some X.509 signatures)
also be affected by address sharing as the address itself is now a may also be affected by address sharing as the address itself is now
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 Randomisation
A blind attack that can be performed against TCP relies on the A blind attack that can be performed against TCP relies on the
attacker's ability to guess the 5-tuple (Protocol, Source Address, attacker's ability to guess the 5-tuple (Protocol, Source Address,
Destination Address, Source Port, Destination Port) that identifies Destination Address, Source Port, Destination Port) that identifies
the transport protocol instance to be attacked. [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 randomisation 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 which immediately process the
Reset as long as it is within the Window. If SN is randomly chosen Reset as long as it is within the Window. If SN is randomly chosen
it will be difficult to guess it (SN is 32 bits long); port it will be difficult to guess it (SN is 32 bits long); port
randomisation is one protection among others against blind attacks. 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 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
[I-D.gont-behave-nat-security] for more information). [I-D.gont-behave-nat-security] for more information).
13.6. Policing Forwarding Behaviour 13.6. Policing Forwarding Behaviour
[RFC2827] motivates and discusses a simple, effective, and [RFC2827] motivates and discusses a simple, effective, and
straightforward method for using ingress traffic filtering to straightforward method for using ingress traffic filtering to
skipping to change at page 20, line 10 skipping to change at page 20, line 38
operating shared-addressing mechanisms should ensure that source operating shared-addressing mechanisms should ensure that source
addresses, or source ports in the case of port-range schemes, are set addresses, or source ports in the case of port-range schemes, are set
correctly in outgoing packets from their subscribers or they should correctly in outgoing packets from their subscribers or they should
drop the packets. drop the packets.
If some form of IPv6 ingress filtering is deployed in the broadband If some form of IPv6 ingress filtering is deployed in the broadband
network and DS-Lite service is restricted to those subscribers, then network and DS-Lite service is restricted to those subscribers, then
tunnels terminating at the CGN and coming from registered subscriber tunnels terminating at the CGN and coming from registered subscriber
IPv6 addresses cannot be spoofed. Thus a simple access control list IPv6 addresses cannot be spoofed. Thus a simple access control list
on the tunnel transport source address is all that is required to on the tunnel transport source address is all that is required to
accept traffic on the southbound interface of a CGN. accept traffic on the 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 Systems that assume that multiple simultaneous connections to a
single IP address implies connectivity to a single host - such single IP address implies connectivity to a single host - such
systems may experience unexpected results. systems may experience unexpected results.
14.2. Serial connections 14.2. Serial connections
Systems that assume that returning to a given IP address means Systems that assume that returning to a given IP address means
returning to the same physical host, as with stateful transactions. returning to the same physical host, as with stateful transactions.
This may also affect cookie-based systems. This may also affect cookie-based systems.
14.3. TCP Control Block Sharing 14.3. TCP Control Block Sharing
[RFC2140] defines a performance optimisation 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 optimisation 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
problems for sharing TCP control block state across multiple problems for sharing TCP control block state across multiple
connections to a given IP address, large-scale address sharing will connections to a given IP address, large-scale address sharing will
make these issues more severe and more widespread. make these issues more severe and more widespread.
15. Reverse DNS 15. Reverse DNS
Many service providers populate forward and reverse DNS zones for the Many service providers populate forward and reverse DNS zones for the
skipping to change at page 21, line 27 skipping to change at page 22, line 12
IPv6 transition mechanisms, which were not designed with IPv4 IPv6 transition mechanisms, which were not designed with IPv4
shortage considerations in mind. With port-range solutions for shortage considerations in mind. With port-range solutions for
instance, incoming 6to4 packets should be able to find their way from instance, incoming 6to4 packets should be able to find their way from
a 6to4 relay to the appropriate 6to4 CPE router, despite the lack of a 6to4 relay to the appropriate 6to4 CPE router, despite the lack of
direct port range information (UDP/TCP initial source port did not direct port range information (UDP/TCP initial source port did not
pass through the CPE port range translation process). One solution pass through the CPE port range translation process). One solution
would be for a 6to4 IPv6 address to embed not only an IPv4 address would be for a 6to4 IPv6 address to embed not only an IPv4 address
but also a port range value. but also a port range value.
Subscribers allocated with private addresses will not be able to Subscribers allocated with private addresses will not be able to
utilise 6to4 to access IPv6, but may be able to utilise Teredo. utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize
Teredo [RFC4380].
Shared addresses should be drawn from space designated as such Some routers enable 6to4 on their WAN link. 6to4 requires a publicly-
[RFC1918]. Otherwise their use will break the widely implemented routable IPv4 address. Enabling 6to4 when the apparently public IPv4
assumption that public IPv4 addresses are globally unique addresses WAN address is in fact behind a NAT creates a disconnected IPv6
and hence break many protocols and applications, e.g., 6to4 island. Issues created by assigning the same public address space
[RFC3056]. Some routers enable 6to4 on their WAN link. 6to4 requires across multiple hosts are specifically addressed in
a publicly-routable IPv4 address. Enabling 6to4 when the apparently
public IPv4 WAN address is in fact behind a NAT creates a
disconnected IPv6 island. Issues created by sharing public address
space across multiple hosts are specifically addressed in
[I-D.thaler-port-restricted-ip-issues]. [I-D.thaler-port-restricted-ip-issues].
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
should consider the opportunity to add redundancy features in order should consider the opportunity to add redundancy features in order
to alleviate the impact on the robustness of the offered IP to alleviate the impact on the robustness of the offered IP
skipping to change at page 23, line 42 skipping to change at page 24, line 19
IP address sharing solutions fall into two classes. Either a IP address sharing solutions fall into two classes. Either a
service-provider operated NAT function is introduced and subscribers service-provider operated NAT function is introduced and subscribers
are allocated addresses from [RFC1918] space, or public IPv4 are allocated addresses from [RFC1918] space, or public IPv4
addresses are shared across multiple subscribers by restricting the addresses are shared across multiple subscribers by restricting the
range of ports available to each subscriber. These classes of range of ports available to each subscriber. These classes of
solution are described in a bit more detail below. solution are described in a bit more detail below.
o CGN-based solutions: These solutions propose the introduction of a o CGN-based solutions: These solutions propose the introduction of a
NAPT function in the service provider's network, denoted also as NAPT function in the service provider's network, denoted also as
Carrier Grade NAT (CGN), or Large Scale NAT (LSN) Carrier Grade NAT (CGN), or Large Scale NAT (LSN)
[I-D.nishitani-cgn] , or Provider NAT. The CGN is responsible for [I-D.ietf-behave-lsn-requirements], or Provider NAT. The CGN is
translating private addresses to publicly routable addresses. responsible for translating private addresses to publicly routable
Private addresses are assigned to subscribers, a pool of public addresses. Private addresses are assigned to subscribers, a pool
addresses is assigned to the CGN, and the number of public of public addresses is assigned to the CGN, and the number of
addresses is smaller than the number of subscribers. A public public addresses is smaller than the number of subscribers. A
IPv4 address in the CGN pool is shared by several subscribers at public IPv4 address in the CGN pool is shared by several
the same time. Solutions making use of a service provider-based subscribers at the same time. Solutions making use of a service
NAT include [I-D.shirasaki-nat444] (two layers of NAT) and provider-based NAT include [I-D.shirasaki-nat444] (two layers of
[I-D.ietf-softwire-dual-stack-lite] (a single layer of NAT). 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 o Port-range solutions: These solutions avoid the presence of a CGN
function. A single public IPv4 address is assigned to several function. A single public IPv4 address is assigned to several
subscribers at the same time. A restricted port range is also subscribers at the same time. A restricted port range is also
assigned to each subscriber so that two subscribers with the same assigned to each subscriber so that two subscribers with the same
IPv4 address have two different port ranges that do not overlap. IPv4 address have two different port ranges that do not overlap.
These solutions are called A+P (Address+Port) [I-D.ymbk-aplusp] , These solutions are called A+P (Address+Port) [I-D.ymbk-aplusp],
or Port Range [I-D.boucadair-port-range] , or SAM (Stateless or Port Range [I-D.boucadair-port-range], or SAM (Stateless
Address Mapping) [I-D.despres-sam] . Address Mapping) [I-D.despres-sam].
26.2. Address Space Multiplicative Factor 26.2. Address Space Multiplicative Factor
The purpose of sharing public IPv4 addresses is to increase the The purpose of sharing public IPv4 addresses is to increase the
addressing space. A key parameter is the factor by which service addressing space. A key parameter is the factor by which service
providers want or need to multiply their IPv4 public address space; providers want or need to multiply their IPv4 public address space;
and the consequence is the number of subscribers sharing the same and the consequence is the number of subscribers sharing the same
public IPv4 address. We refer to this parameter as the address space public IPv4 address. We refer to this parameter as the address space
multiplicative factor, the inverse is called the compression ratio. multiplicative factor, the inverse is called the compression ratio.
skipping to change at page 24, line 48 skipping to change at page 25, line 26
may have an existing address pool that will only need a small may have an existing address pool that will only need a small
extension to cope with the next few years, assuming that this address extension to cope with the next few years, assuming that this address
pool can be re-purposed for an address sharing solution (small pool can be re-purposed for an address sharing solution (small
multiplicative factor, less than 10). A new entrant or a new line of multiplicative factor, less than 10). A new entrant or a new line of
business will need a much bigger multiplicative factor (e.g., 1000). business will need a much bigger multiplicative factor (e.g., 1000).
A mobile operator may see its addressing needs grow dramatically as A mobile operator may see its addressing needs grow dramatically as
the IP-enabled mobile handset market grows. the IP-enabled mobile handset market grows.
When the multiplicative factor is large, the average number of ports When the multiplicative factor is large, the average number of ports
per subscriber is small. Given the large measured disparity between per subscriber is small. Given the large measured disparity between
average and peak port consumption [CGN_Viability] , this will create average and peak port consumption [CGN_Viability], this will create
service problems in the event that ports are allocated statically. service problems in the event that ports are allocated statically.
In this case, it is essential for port allocation to map to need as In this case, it is essential for port allocation to map to need as
closely as possible, and to avoid allocating ports for longer than closely as possible, and to avoid allocating ports for longer than
necessary. Therefore, the larger the multiplicative factor, the more necessary. Therefore, the larger the multiplicative factor, the more
dynamic the port assignment has to be. dynamic the port assignment has to be.
27. Informative References 27. Informative References
[CGN_Viability] [CGN_Viability]
Alcock, S., "Research into the Viability of Service- Alcock, S., "Research into the Viability of Service-
skipping to change at page 25, line 42 skipping to change at page 26, line 21
Network Address Translators (NATs)", Network Address Translators (NATs)",
draft-gont-behave-nat-security-03 (work in progress), draft-gont-behave-nat-security-03 (work in progress),
October 2009. October 2009.
[I-D.haddad-mext-nat64-mobility-harmful] [I-D.haddad-mext-nat64-mobility-harmful]
Haddad, W. and C. Perkins, "A Note on NAT64 Interaction Haddad, W. and C. Perkins, "A Note on NAT64 Interaction
with Mobile IPv6", with Mobile IPv6",
draft-haddad-mext-nat64-mobility-harmful-01 (work in draft-haddad-mext-nat64-mobility-harmful-01 (work in
progress), April 2010. 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] [I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
progress), September 2010. progress), September 2010.
[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-12 (work in draft-ietf-behave-v6v4-xlate-stateful-12 (work in
progress), July 2010. 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-05 (work in progress), February 2011.
[I-D.ietf-softwire-dual-stack-lite] [I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 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", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 2010. in progress), August 2010.
[I-D.nishitani-cgn]
Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida,
"Common requirements for IP address sharing schemes",
draft-nishitani-cgn-05 (work in progress), July 2010.
[I-D.shirasaki-nat444] [I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
in progress), January 2011. in progress), January 2011.
[I-D.thaler-port-restricted-ip-issues] [I-D.thaler-port-restricted-ip-issues]
Thaler, D., "Issues With Port-Restricted IP Addresses", Thaler, D., "Issues With Port-Restricted IP Addresses",
draft-thaler-port-restricted-ip-issues-00 (work in draft-thaler-port-restricted-ip-issues-00 (work in
progress), February 2010. progress), February 2010.
[I-D.ymbk-aplusp] [I-D.ymbk-aplusp]
Bush, R., "The A+P Approach to the IPv4 Address Shortage", Bush, R., "The A+P Approach to the IPv4 Address Shortage",
draft-ymbk-aplusp-08 (work in progress), January 2011. draft-ymbk-aplusp-09 (work in progress), February 2011.
[IANA_Ports] [IANA_Ports]
"IANA Port Number Assignments", February 2011, Geoff Huston, "IANA Port Number Assignments",
February 2011,
<http://www.iana.org/assignments/port-numbers>. <http://www.iana.org/assignments/port-numbers>.
[IPv4_Pool] [IPv4_Pool]
ICANN, ICANN., "Available Pool of Unallocated IPv4 Geoff Huston, "Available Pool of Unallocated IPv4 Internet
Internet Addresses Now Completely Emptied", 2011, Addresses Now Completely Emptied", 2011,
<http://icann.org/en/news/releases/ <http://icann.org/en/news/releases/
release-03feb11-en.pdf>. release-03feb11-en.pdf>.
[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>. 2007, <http://research.nokia.com/node/5597>.
[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.
[RFC1340] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
July 1992. October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
April 1997. April 1997.
[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",
skipping to change at page 27, line 40 skipping to change at page 28, line 26
[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.
[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
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
Network Address Translator (NAT) and a Network Address Network Address Translator (NAT) and a Network Address
Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508, Behavioral Requirements for ICMP", BCP 148, RFC 5508,
skipping to change at page 28, line 17 skipping to change at page 29, line 7
[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] [UPnP-IGD]
UPnP Forum, "Universal Plug and Play (UPnP) Internet 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 Device Requirements",
2006, <http://www.microsoft.com/whdc/winlogo/ 2006, <http://www.microsoft.com/whdc/winlogo/
hwrequirements/default.mspx>. hwrequirements/default.mspx>.
Authors' Addresses Authors' Addresses
Mat Ford (editor) Mat Ford (editor)
 End of changes. 61 change blocks. 
110 lines changed or deleted 147 lines changed or added

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