summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6269.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6269.txt')
-rw-r--r--doc/rfc/rfc6269.txt1627
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc6269.txt b/doc/rfc/rfc6269.txt
new file mode 100644
index 0000000..256a995
--- /dev/null
+++ b/doc/rfc/rfc6269.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Ford, Ed.
+Request for Comments: 6269 Internet Society
+Category: Informational M. Boucadair
+ISSN: 2070-1721 France Telecom
+ A. Durand
+ Juniper Networks
+ P. Levis
+ France Telecom
+ P. Roberts
+ Internet Society
+ June 2011
+
+
+ Issues with IP Address Sharing
+
+Abstract
+
+ The completion of IPv4 address allocations from IANA and the Regional
+ Internet Registries (RIRs) is causing service providers around the
+ world to question how they will continue providing IPv4 connectivity
+ service to their subscribers when there are no longer sufficient IPv4
+ addresses to allocate them one per subscriber. Several possible
+ solutions to this problem are now emerging based around the idea of
+ shared IPv4 addressing. These solutions give rise to a number of
+ issues, and this memo identifies those common to all such address
+ sharing approaches. Such issues include application failures,
+ additional service monitoring complexity, new security
+ vulnerabilities, and so on. Solution-specific discussions are out of
+ scope.
+
+ Deploying IPv6 is the only perennial way to ease pressure on the
+ public IPv4 address pool without the need for address sharing
+ mechanisms that give rise to the issues identified herein.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ 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.
+
+
+
+
+
+
+Ford, et al. Informational [Page 1]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6269.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford, et al. Informational [Page 2]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Shared Addressing Solutions . . . . . . . . . . . . . . . . . 4
+ 3. Analysis of Issues as They Relate to First and Third
+ Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Content Provider Example . . . . . . . . . . . . . . . . . . . 8
+ 5. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 11
+ 5.2.2. Connection to a Well-Known Port Number . . . . . . . . 12
+ 5.2.3. Port Discovery Mechanisms . . . . . . . . . . . . . . 12
+ 6. Impact on Applications . . . . . . . . . . . . . . . . . . . . 12
+ 7. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 14
+ 8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 15
+ 9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18
+ 13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 19
+ 13.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 13.4. Port Randomization . . . . . . . . . . . . . . . . . . . . 19
+ 13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 13.6. Policing Forwarding Behavior . . . . . . . . . . . . . . . 20
+ 14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20
+ 14.1. Parallel Connections . . . . . . . . . . . . . . . . . . . 20
+ 14.2. Serial Connections . . . . . . . . . . . . . . . . . . . . 20
+ 14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 21
+ 15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21
+ 18. Introduction of Single Points of Failure . . . . . . . . . . . 22
+ 19. State Maintenance Reduces Battery Life . . . . . . . . . . . . 22
+ 20. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 22
+ 21. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 22
+ 22. Security Considerations . . . . . . . . . . . . . . . . . . . 23
+ 23. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
+ 25. Informative References . . . . . . . . . . . . . . . . . . . . 23
+ Appendix A. Classes of Address Sharing Solution . . . . . . . . . 27
+ Appendix B. Address Space Multiplicative Factor . . . . . . . . . 27
+
+
+
+
+
+
+
+Ford, et al. Informational [Page 3]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+1. Introduction
+
+ Allocations of IPv4 addresses from the Internet Assigned Numbers
+ Authority (IANA) were completed on February 3, 2011 [IPv4_Pool].
+ Allocations from Regional Internet Registries (RIRs) are anticipated
+ to be complete around a year later, although the exact date will vary
+ from registry to registry. This is causing service providers around
+ the world to start to question how they will continue providing IPv4
+ connectivity service to their subscribers when there are no longer
+ sufficient IPv4 addresses to allocate them one per subscriber.
+ Several possible solutions to this problem are now emerging based
+ around the idea of shared IPv4 addressing. These solutions give rise
+ to a number of issues, and this memo identifies those common to all
+ such address sharing approaches and collects them in a single
+ document.
+
+ Deploying IPv6 is the only perennial way to ease pressure on the
+ public IPv4 address pool without the need for address sharing
+ mechanisms that give rise to the issues identified herein. In the
+ short term, maintaining growth of IPv4 services in the presence of
+ IPv4 address depletion will require address sharing. Address sharing
+ will cause issues for end-users, service providers, and third parties
+ such as law enforcement agencies and content providers. This memo is
+ intended to highlight and briefly discuss these issues.
+
+ Increased IPv6 deployment should reduce the burden being placed on an
+ address sharing solution, and should reduce the costs of operating
+ that solution. Increasing IPv6 deployment should cause a reduction
+ in the number of concurrent IPv4 sessions per subscriber. If the
+ percentage of end-to-end IPv6 traffic significantly increases, so
+ that the volume of IPv4 traffic begins decreasing, then the number of
+ IPv4 sessions will decrease. The smaller the number of concurrent
+ IPv4 sessions per subscriber, the higher the number of subscribers
+ able to share the same IPv4 public address, and consequently, the
+ lower the number of IPv4 public addresses required. However, this
+ effect will only occur for subscribers who have both an IPv6 access
+ and a shared IPv4 access. This motivates a strategy to
+ systematically bind a shared IPv4 access to an IPv6 access. It is
+ difficult to foresee to what extent growing IPv6 traffic will reduce
+ the number of concurrent IPv4 sessions, but in any event, IPv6
+ deployment and use should reduce the pressure on the available public
+ IPv4 address pool.
+
+2. Shared Addressing Solutions
+
+ In many networks today, a subscriber is provided with a single public
+ IPv4 address at their home or small business. For instance, in fixed
+ broadband access, an IPv4 public address is assigned to each CPE
+
+
+
+Ford, et al. Informational [Page 4]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ (Customer Premises Equipment). CPEs embed a NAT function that is
+ responsible for translating private IPv4 addresses ([RFC1918]
+ addresses) assigned to hosts within the local network, to the public
+ IPv4 address assigned by the service provider (and vice versa).
+ Therefore, devices located with the LAN share the single public IPv4
+ address and they are all associated with a single subscriber account
+ and a single network operator.
+
+ A number of proposals currently under consideration in the IETF rely
+ upon the mechanism of multiplexing multiple subscribers' connections
+ over a smaller number of shared IPv4 addresses. This is a
+ significant change. These proposals include Carrier Grade NAT (CGN
+ a.k.a. LSN for Large Scale NAT) [LSN-REQS], Dual-Stack Lite
+ [DS-Lite], NAT64 [RFC6145] [RFC6146], Address+Port (A+P) proposals
+ [A+P] [PORT-RANGE], and Stateless Address Mapping [SAM]. Appendix A
+ and Appendix B provide a classification of these different types of
+ solutions and discuss some of the design considerations to be borne
+ in mind when deploying large-scale address sharing. Whether we're
+ talking about DS-Lite, A+P, NAT64, or CGN isn't especially important
+ -- it's the view from the outside that matters, and given that, most
+ of the issues identified below apply regardless of the specific
+ address sharing scenario in question.
+
+ In these new proposals, a single public IPv4 address would be shared
+ by multiple homes or small businesses (i.e., multiple subscribers),
+ so the operational paradigm described above would no longer apply.
+ In this document, we refer to this new paradigm as large-scale
+ address sharing. All these proposals extend the address space by
+ adding port information; they differ in the way they manage the port
+ value.
+
+ Security issues associated with NAT have long been documented (see
+ [RFC2663] and [RFC2993]). However, sharing IPv4 addresses across
+ multiple subscribers by any means, either moving the NAT
+ functionality from the home gateway to the core of the service
+ provider network or restricting the port choice in the subscriber's
+ NAT, creates additional issues for subscribers, content providers,
+ and network operators. Many of these issues are created today by
+ public Wi-Fi hotspot deployments. As such large-scale address
+ sharing solutions become more widespread in the face of IPv4 address
+ depletion, these issues will become both more severe and more
+ commonly felt. NAT issues in the past typically only applied to a
+ single legal entity; as large-scale address sharing becomes more
+ prevalent, these issues will increasingly span across multiple legal
+ entities simultaneously.
+
+
+
+
+
+
+Ford, et al. Informational [Page 5]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ All large-scale address sharing proposals share technical and
+ operational issues, and these are addressed in the sections that
+ follow. These issues are common to any service-provider NAT,
+ enterprise NAT, and also non-NAT solutions that share individual IPv4
+ addresses across multiple subscribers. This document is intended to
+ bring all of these issues together in one place.
+
+3. Analysis of Issues as They Relate to First and Third Parties
+
+ In this section, we present an analysis of whether the issues
+ identified in the remainder of this document are applicable to the
+ organization deploying the shared addressing mechanism (and by
+ extension their subscribers) and/or whether these issues impact third
+ parties (e.g., content providers, law enforcement agencies, etc.).
+ In this analysis, issues that affect end-users are deemed to affect
+ first parties, as end-users can be expected to complain to their
+ service provider when problems arise. Where issues can expect to be
+ foreseen and addressed by the party deploying the shared addressing
+ solution, they are not attributed.
+
+ In Figure 1, we have also tried to indicate (with 'xx') where issues
+ are newly created in addition to what could be expected from the
+ introduction of a traditional NAT device. Issues marked with a
+ single 'x' are already present today in the case of typical CPE NAT;
+ however, they can be expected to be more severe and widespread in the
+ case of large-scale address sharing.
+
+ +------------------------------------------------+--------+---------+
+ | Issue | 1st | 3rd |
+ | | party | parties |
+ +------------------------------------------------+--------+---------+
+ | Restricted allocations of outgoing | x | |
+ | ports will impact performance for end-users | | |
+ | | | |
+ | Incoming port negotiation mechanisms may fail | xx | |
+ | | | |
+ | Incoming connections to Assigned Ports will | x | |
+ | not work | | |
+ | | | |
+ | Port discovery mechanisms will not work | x | |
+ | | | |
+ | Some applications will fail to operate | x | x |
+ | | | |
+ | Assumptions about parallel/serial connections | x | x |
+ | may fail | | |
+ | | | |
+ +------------------------------------------------+--------+---------+
+
+
+
+
+Ford, et al. Informational [Page 6]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ +------------------------------------------------+--------+---------+
+ | Issue | 1st | 3rd |
+ | | party | parties |
+ +------------------------------------------------+--------+---------+
+ | TCP control block sharing will be affected | x | x |
+ | | | |
+ | Reverse DNS will be affected | x | x |
+ | | | |
+ | Inbound ICMP will fail in many cases | x | x |
+ | | | |
+ | Amplification of security issues will occur | xx | xx |
+ | | | |
+ | Fragmentation will require special handling | x | |
+ | | | |
+ | Single points of failure and increased | x | |
+ | network instability may occur | | |
+ | | | |
+ | Port randomization will be affected | x | |
+ | | | |
+ | Service usage monitoring and abuse logging | xx | xx |
+ | will be impacted for all elements in the chain | | |
+ | between service provider and content provider | | |
+ | | | |
+ | Penalty boxes will no longer work | xx | xx |
+ | | | |
+ | Spam blacklisting will be affected | xx | xx |
+ | | | |
+ | Geo-location services will be impacted | xx | xx |
+ | | | |
+ | Geo-proximity mechanisms will be impacted | xx | xx |
+ | | | |
+ | Load balancing algorithms may be impacted | | xx |
+ | | | |
+ | Authentication mechanisms may be impacted | | x |
+ | | | |
+ | Traceability of network usage and abusage will | | xx |
+ | be affected | | |
+ | | | |
+ | IPv6 transition mechanisms will be affected | xx | |
+ | | | |
+ | Frequent keep-alives will reduce battery life | x | |
+ | | | |
+ +------------------------------------------------+--------+---------+
+
+ Figure 1: Shared addressing issues for first and third parties
+
+
+
+
+
+
+Ford, et al. Informational [Page 7]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ As can be seen from Figure 1, deployment of large-scale address
+ sharing will create almost as many problems for third parties as it
+ does for the service provider deploying the address sharing
+ mechanism. Several of these issues are specific to the introduction
+ of large-scale address sharing as well. All of these issues are
+ discussed in further detail below.
+
+4. Content Provider Example
+
+ Taking a content provider as an example of a third party, and
+ focusing on the issues that are created specifically by the presence
+ of large-scale address sharing, we identify the following issues as
+ being of particular concern:
+
+ o Degraded geo-location for targeted advertising and licensed
+ content restrictions (see Section 7).
+
+ o Additional latency due to indirect routing and degraded geo-
+ proximity (see Section 7).
+
+ o Exposure to new amplification attacks (see Section 13).
+
+ o Service usage monitoring is made more complicated (see Section 8).
+
+ o Incoming port negotiation mechanisms may fail (see Section 5.2.1).
+
+ o IP blocking for abuse/spam will cause collateral damage (see
+ Section 13).
+
+ o Load balancing algorithms may be impacted (see Section 16).
+
+ o Traceability of network usage and abuse will be impacted (see
+ Section 12).
+
+5. Port Allocation
+
+ When we talk about port numbers, we need to make a distinction
+ between outgoing connections and incoming connections. For outgoing
+ connections, the actual source port number used is usually
+ irrelevant. (While this is true today, in a port-range solution, it
+ is necessary for the source port to be within the allocated range.)
+ But for incoming connections, the specific port numbers allocated to
+ subscribers matter because they are part of external referrals (used
+ by third parties to contact services run by the subscribers).
+
+ The total number of subscribers able to share a single IPv4 address
+ will depend upon assumptions about the average number of ports
+ required per active subscriber, and the average number of
+
+
+
+Ford, et al. Informational [Page 8]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ simultaneously active subscribers. It is important to realize that
+ the TCP design makes it undesirable for clients to re-use ports while
+ they remain in the TIME-WAIT state (typically 4 minutes after the
+ connection has concluded). TIME-WAIT state removes the hazard of old
+ duplicates for "fast" or "long" connections, in which clock-driven
+ Initial Sequence Number selection is unable to prevent overlap of the
+ old and new sequence spaces. The TIME-WAIT delay allows all old
+ duplicate segments time enough to die in the Internet before the
+ connection is reopened [RFC1337]. Therefore, ports in this state
+ must be included in calculations concerning port usage per
+ subscriber.
+
+ Most of the time the source port selected by a client application
+ will be translated (unless there is direct knowledge of a port-range
+ restriction in the client's stack), either by a NAT in the
+ subscriber's device, or by a CPE NAT, or by a CPE NAT and a CGN.
+
+ [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
+ defined in [IANA_Ports]:
+
+ o The Well-Known Ports are those from 0 through 1023.
+
+ o The Registered Ports are those from 1024 through 49151.
+
+ o The Dynamic and/or Private Ports are those from 49152 through
+ 65535.
+
+ [RFC4787] notes that current NATs have different policies with regard
+ to this classification; some NATs restrict their translations to the
+ use of dynamic ports, some also include registered ports, some
+ preserve the port if it is in the well-known range. [RFC4787] makes
+ it clear that the use of port space (1024-65535) is safe: "mapping a
+ source port to a source port that is already registered is unlikely
+ to have any bad effects". Therefore, for all address sharing
+ solutions, there is no reason to only consider a subset of the port
+ space (1024-65535) for outgoing source ports.
+
+5.1. Outgoing Ports
+
+ According to measurements, the average number of outgoing ports
+ consumed per active subscriber is much, much smaller than the maximum
+ number of ports a subscriber can use at any given time. However, the
+ distribution is heavy-tailed, so there are typically a small number
+ of subscribers who use a very high number of ports [CGN_Viability].
+ This means that an algorithm that dynamically allocates outgoing port
+ numbers from a central pool will typically allow more subscribers to
+
+
+
+Ford, et al. Informational [Page 9]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ share a single IPv4 address than algorithms that statically divide
+ the resource by pre-allocating a fixed number of ports to each
+ subscriber. Similarly, such an algorithm should be more able to
+ accommodate subscribers wishing to use a relatively high number of
+ ports.
+
+ It is important to note here that the desire to dynamically allocate
+ outgoing port numbers will make a service provider's job of
+ maintaining records of subscriber port number allocations
+ considerably more onerous (see Section 12). The number of records
+ per subscriber will increase from 1 in a scheme where ports are
+ statically allocated, to a much larger number equivalent to the total
+ number of outgoing ports consumed by that subscriber during the time
+ period for which detailed logs must be kept.
+
+ A potential problem with dynamic allocation occurs when one of the
+ subscriber devices behind such a port-shared IPv4 address becomes
+ infected with a worm, which then quickly sets about opening many
+ outbound connections in order to propagate itself. Such an infection
+ could rapidly exhaust the shared resource of the single IPv4 address
+ for all connected subscribers. It is therefore necessary to impose
+ limits on the total number of ports available to an individual
+ subscriber to ensure that the shared resource (the IPv4 address)
+ remains available in some capacity to all the subscribers using it.
+ However, static schemes for ports assignment may introduce security
+ issues [RFC6056] when small contiguous port ranges are statically
+ 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
+ discards session state because it's run out of resource) can be
+ experienced when the configured quota per user is reached or if the
+ NAT is out of resources.
+
+5.2. Incoming Ports
+
+ It is desirable to ensure that incoming ports remain stable over
+ time. This is challenging as the network doesn't know anything in
+ particular about the applications that it is supporting, and
+ therefore has no real notion of how long an application/service
+ session is still ongoing and therefore requiring port stability.
+
+ Early measurements [CGN_Viability] also seem to indicate that, on
+ average, only very few ports are used by subscribers for incoming
+ connections. However, a majority of subscribers accept at least one
+ inbound connection.
+
+
+
+Ford, et al. Informational [Page 10]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ This means that it is not necessary to pre-allocate a large number of
+ incoming ports to each subscriber. It is possible to either pre-
+ allocate a small number of ports for incoming connections or do port
+ allocation on demand when the application wishing to receive a
+ connection is initiated. The bulk of incoming ports can be reserved
+ as a centralized resource shared by all subscribers using a given
+ public IPv4 address.
+
+5.2.1. Port Negotiation
+
+ In current deployments, one important and widely used feature of many
+ CPE devices is the ability to open incoming ports (port forwarding)
+ either manually, or with a protocol such as the Universal Plug and
+ Play Internet Gateway Device (UPnP IGD) [UPnP-IGD]. If a CGN is
+ present, the port must also be opened in the CGN. CGN makes
+ subscribers dependent on their service provider for this
+ functionality.
+
+ CPE and CGN will need to cooperate in order for port forwarding
+ functionality to work. UPnP, or NAT-PMP proxy could be a solution if
+ there is a direct link (or tunnel) between the CPE and the CGN. An
+ alternative solution is a web interface to configure the incoming
+ port mapping on the CGN. Protocol development is underway in the
+ IETF to provide a generalized, automated solution via the Port
+ Control Protocol [PCP].
+
+ Note that such an interface effectively makes public what was
+ previously a private management interface and this raises security
+ concerns that must be addressed.
+
+ For port-range solutions, port forwarding capabilities may still be
+ present at the CPE, with the limitation that the open incoming port
+ must be within the allocated port range (for instance, it is not
+ possible to open port 5002 for incoming connections if port 5002 is
+ not within the allocated port range).
+
+5.2.1.1. Universal Plug and Play (UPnP)
+
+ Using the UPnP semantic, an application asks "I want to use port
+ number X, is that OK?", and the answer is yes or no. If the answer
+ is no, the application will typically try the next port in sequence,
+ until it either finds one that works or gives up after a limited
+ number of attempts. UPnP IGD 1.0 has no way to redirect the
+ application to use another port number. UPnP IGD 2.0 improves this
+ situation and allows for allocation of any available port.
+
+
+
+
+
+
+Ford, et al. Informational [Page 11]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+5.2.1.2. NAT Port Mapping Protocol (NAT-PMP)
+
+ 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.
+
+5.2.2. Connection to a Well-Known Port Number
+
+ Once an IPv4-address sharing mechanism is in place, inbound
+ connections to well-known port numbers will not work in the general
+ case. Any application that is not port-agile cannot be expected to
+ work. Some workaround (e.g., redirects to a port-specific URI) could
+ be deployed given sufficient incentives. There exist several
+ proposals for 'application service location' protocols that would
+ provide a means of addressing this problem, but historically these
+ proposals have not gained much deployment traction.
+
+ For example, the use of DNS SRV records [RFC2782] provides a
+ potential solution for subscribers wishing to host services in the
+ presence of a shared-addressing scheme. SRV records make it possible
+ to specify a port value related to a service, thereby making services
+ accessible on ports other than the well-known ports. It is worth
+ noting that this mechanism is not applicable to HTTP and many other
+ protocols.
+
+5.2.3. Port Discovery Mechanisms
+
+ Port discovery using a UDP port to discover a service available on a
+ corresponding TCP port, either through broadcast, multicast, or
+ unicast, is a commonly deployed mechanism. Unsolicited inbound UDP
+ will be dropped by address sharing mechanisms as they have no live
+ mapping to enable them to forward the packet to the appropriate host.
+ Address sharing thereby breaks this service discovery technique.
+
+6. Impact on Applications
+
+ Address sharing solutions will have an impact on the following types
+ of applications:
+
+ o Applications that establish inbound communications - These
+ applications will have to ensure that ports selected for inbound
+ communications are either within the allocated range (for port-
+ range solutions) or are forwarded appropriately by the CGN (for
+ CGN-based solutions). See Section 5.2 for more discussion.
+
+ o Applications that carry address and/or port information in their
+ payload - Where translation of port and/or address information is
+ performed at the IP and transport layers by the address sharing
+ solution, an ALG will also be required to ensure application-layer
+
+
+
+Ford, et al. Informational [Page 12]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ data is appropriately modified. Note that ALGs are required in
+ some cases, and in many other cases end-to-end protocol mechanisms
+ have developed to work around a lack of ALGs in address
+ translators, to the point of it being preferable to avoid any
+ support in the NAT.
+
+ o Applications that use fixed ports - See Section 5.2.2 for more
+ discussion.
+
+ o Applications that do not use any port (e.g., ICMP echo) - Such
+ applications will require special handling -- see Section 9 for
+ more discussion.
+
+ o Applications that assume the uniqueness of source addresses (e.g.,
+ IP address as identifier) - Such applications will fail to operate
+ correctly in the presence of multiple, discrete, simultaneous
+ connections from the same source IP address.
+
+ o Applications that explicitly prohibit concurrent connections from
+ the same address - Such applications will fail when multiple
+ subscribers sharing an IP address attempt to use them
+ simultaneously.
+
+ o Applications that do not use TCP or UDP for transport - All IP-
+ address sharing mechanisms proposed to date are limited to TCP,
+ UDP, and ICMP, thereby preventing end-users from fully utilizing
+ the Internet (e.g., SCTP, DCCP, RSVP, protocol 41 (IPv6-over-
+ IPv4), protocol 50 (IPsec ESP)).
+
+ Applications already frequently implement mechanisms in order to
+ circumvent the presence of NATs (typically CPE NATs):
+
+ o Application Layer Gateways (ALGs): Many CPE devices today embed
+ ALGs that allow applications to behave correctly despite the
+ presence of NAT on the CPE. When the NAT belongs to the
+ subscriber, the subscriber has flexibility to tailor the device to
+ his or her needs. For CGNs, subscribers will be dependent on the
+ set of ALGs that their service provider makes available. For
+ port-range solutions, ALGs will require modification to deal with
+ the port-range restriction, but will otherwise have the same
+ capabilities as today. Note that ALGs are required in some cases,
+ and in many other cases end-to-end protocol mechanisms have
+ developed to work around a lack of ALGs, to the point of it being
+ preferable to avoid any support in the NAT.
+
+ o NAT Traversal Techniques: There are several commonly deployed
+ mechanisms that support operating servers behind a NAT by
+ forwarding specific TCP or UDP ports to specific internal hosts
+
+
+
+Ford, et al. Informational [Page 13]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ ([UPnP-IGD], [NAT-PMP], and manual configuration). All of these
+ mechanisms assume the NAT's WAN address is a publicly routable IP
+ address, and fail to work normally when that assumption is wrong.
+ There have been attempts to avoid that problem by automatically
+ disabling the NAT function and bridging traffic instead upon
+ assignment of a private IP address to the WAN interface (as is
+ required for [Windows-Logo] certification). Bridging (rather than
+ NATting) has other side effects (DHCP requests are served by an
+ upstream DHCP server that can increase complexity of in-home
+ networking).
+
+7. Geo-location and Geo-proximity
+
+ IP addresses are frequently used to indicate, with some level of
+ granularity and some level of confidence, where a host is physically
+ located. Using IP addresses in this fashion is a heuristic at best,
+ and is already challenged today by other deployed capabilities, e.g.,
+ tunnels. Geo-location services are used by content providers to
+ allow them to conform with regional content licensing restrictions,
+ to target advertising at specific geographic areas, or to provide
+ customized content. Geo-location services are also necessary for
+ emergency services provision. In some deployment contexts (e.g.,
+ centralized CGN), shared addressing will reduce the level of
+ confidence and level of location granularity that IP-based geo-
+ location services can provide. Viewed from the content provider, a
+ subscriber behind a CGN geo-locates to wherever the prefix of the CGN
+ appears to be; very often that will be in a different city than the
+ subscriber.
+
+ IP addresses are also used as input to geo-location 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., Network Address Translation -
+ Protocol Translation (NAT-PT) binding tables). Since these new data
+ elements tend to be more ephemeral than those currently used for geo-
+ 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.
+
+ A slightly different use of an IP address is to calculate the
+ proximity of a connecting host to a particular service delivery
+ point. This use of IP address information impacts the efficient
+
+
+
+Ford, et al. Informational [Page 14]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ delivery of content to an end-user. If a CGN is introduced in
+ communications and it is far from an end-user connected to it,
+ application performance may be degraded insofar as IP-based geo-
+ proximity is a factor.
+
+8. Tracking Service Usage
+
+ As large-scale address sharing becomes more commonplace, monitoring
+ the number of unique users of a service will become more complex than
+ simply counting the number of connections from unique IP addresses.
+ While this is a somewhat inexact methodology today due to the
+ widespread use of CPE NAT, it will become a much less useful approach
+ in the presence of widespread large-scale address sharing solutions.
+ In general, all elements that monitor usage or abusage in the chain
+ between a service provider that has deployed address sharing and a
+ content provider will need to be upgraded to take account of the port
+ value in addition to IP addresses.
+
+9. ICMP
+
+ ICMP does not include a port field and is consequently problematic
+ for address sharing mechanisms. Some ICMP message types include a
+ fragment of the datagram that triggered the signal to be sent, which
+ is assumed to include port numbers. For some ICMP message types, the
+ Identifier field has to be used as a de-multiplexing token. Sourcing
+ ICMP echo messages from hosts behind an address sharing solution does
+ not pose problems, although responses to outgoing ICMP echo messages
+ will require special handling, such as making use of the ICMP
+ Identifier value to route the response appropriately.
+
+ For inbound ICMP there are two cases. The first case is that of ICMP
+ sourced from outside the network of the address sharing solution
+ provider. Where ICMP messages include a fragment of an outgoing
+ packet including port numbers, it may be possible to forward the
+ packet appropriately. In addition to these network signaling
+ messages, several applications (e.g., peer-to-peer applications) make
+ use of ICMP echo messages that include no hints that could be used to
+ route the packet correctly. Measurements derived by such
+ applications in the presence of an address sharing solution will be
+ erroneous or fail altogether. The second case is that of ICMP
+ sourced from within the network of the address sharing solution
+ provider (e.g., for network management, signaling, and diagnostic
+ purposes). In this case, ICMP can be routed normally for CGN-based
+ solutions owing to the presence of locally unique private IP
+ addresses for each CPE device. For port-range solutions, ICMP echo
+ messages will not be routable without special handling, e.g., placing
+ a port number in the ICMP Identifier field, and having port-range
+ routers make routing decisions based upon that field.
+
+
+
+Ford, et al. Informational [Page 15]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ Considerations related to ICMP message handling in NAT-based
+ environments are specified in [RFC5508].
+
+10. MTU
+
+ In applications where the end hosts are attempting to use path MTU
+ Discovery [RFC1191] to optimize transmitted packet size with
+ underlying network MTU, shared addressing has a number of items that
+ must be considered. As covered in Section 9, ICMP "Packet Too Big"
+ messages must be properly translated through the address sharing
+ solution in both directions. However, even when this is done
+ correctly, MTU can be a concern. Many end hosts cache information
+ that was received via Path MTU Discovery (PMTUD) for a certain period
+ of time. If the MTU behind the address sharing solution is
+ inconsistent, the public end host may have the incorrect MTU value
+ cached. This may cause it to send packets that are too large,
+ causing them to be dropped if the DF (Don't Fragment) bit is set, or
+ causing them to be fragmented by the network, increasing load and
+ overhead. Because the host eventually will reduce MTU to the lowest
+ common value for all hosts behind a given public address, it may also
+ send packets that are below optimal size for the specific connection,
+ increasing overhead and reducing throughput.
+
+ This issue also generates a potential attack vector -- a malevolent
+ user could send an ICMP "Packet Too Big" (Type 3, Code 4) message
+ indicating a Next-Hop MTU of anything down to 68 octets. This value
+ will be cached by the off-net server for all subscribers sharing the
+ address of the malevolent user. This could lead to a denial of
+ service (DoS) against both the remote server and the large-scale NAT
+ device itself (as they will both have to handle many more packets per
+ second).
+
+11. Fragmentation
+
+ When a packet is fragmented, transport-layer port information (either
+ UDP or TCP) is only present in the first fragment. Subsequent
+ fragments will not carry the port information and so will require
+ special handling. In addition, the IP Identifier may no longer be
+ unique as required by the receiver to aid in assembling the fragments
+ of a datagram.
+
+
+
+
+
+
+
+
+
+
+
+Ford, et al. Informational [Page 16]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+12. Traceability
+
+ In many jurisdictions, service providers are legally obliged to
+ provide the identity of a subscriber upon request to the appropriate
+ authorities. Such legal requests have traditionally included the
+ source IPv4 address and date (and usually the time), which is
+ sufficient information when subscribers are assigned IPv4 addresses
+ for a long duration.
+
+ However, where one public IPv4 address is shared between several
+ subscribers, the IPv4 address no longer uniquely identifies a
+ subscriber. There are two solutions to this problem:
+
+ o The first solution is for servers to additionally log the source
+ port of incoming connections and for the legal request to include
+ the source port. The legal request should include the
+ information: [Source IP address, Source Port, Timestamp] (and
+ possibly other information). Accurate time-keeping (e.g., use of
+ NTP or Simple NTP) is vital because port assignments are dynamic.
+ A densely populated CGN could mean even very small amounts of
+ clock skew between a third party's server and the CGN operator
+ will result in ambiguity about which customer was using a specific
+ port at a given time.
+
+ o The second solution considers it unrealistic to expect all servers
+ to log the source port number of incoming connections. To deal
+ with this, service providers using IPv4 address sharing may need
+ to log IP destination addresses.
+
+ Destination logging is imperfect if multiple subscribers are
+ accessing the same (popular) server at nearly the same time; it can
+ be impossible to disambiguate which subscriber accessed the server,
+ especially with protocols that involve several connections (e.g.,
+ HTTP). Thus, logging the destination address on the NAT is inferior
+ to logging the source port at the server.
+
+ If neither solution is used (that is, the server is not logging
+ source port numbers and the NAT is not logging destination IP
+ addresses), the service provider cannot trace a particular activity
+ to a specific subscriber. In this circumstance, the service provider
+ would need to disclose the identity of all subscribers who had active
+ sessions on the NAT during the time period in question. This may be
+ a large number of subscribers.
+
+ Address sharing solutions must record and store all mappings
+ (typically during 6-12 months, depending on the local jurisdiction)
+ that they create. If we consider one mapping per session, a service
+ provider should record and retain traces of all sessions created by
+
+
+
+Ford, et al. Informational [Page 17]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ all subscribers during one year (if the legal storage duration is one
+ year). This may be challenging due to the volume of data requiring
+ storage, the volume of data to repeatedly transfer to the storage
+ location, and the volume of data to search in response to a query.
+
+ Address sharing solutions may mitigate these issues to some extent by
+ pre-allocating groups of ports. Then only the allocation of the
+ group needs to be recorded, and not the creation of every session
+ binding within that group. There are trade-offs to be made between
+ the sizes of these port groups, the ratio of public addresses to
+ subscribers, whether or not these groups timeout, and the impact on
+ logging requirements and port randomization security [RFC6056].
+
+13. Security
+
+ Before noting some specific security-related issues caused by large-
+ scale address sharing, it is perhaps worth noting that, in general,
+ address sharing creates a vector for attack amplification in numerous
+ ways. See Section 10 for one example.
+
+13.1. Abuse Logging and Penalty Boxes
+
+ When an abuse is reported today, it is usually done in the form: IPv4
+ address X has done something bad at time T0. This is not enough
+ information to uniquely identify the subscriber responsible for the
+ abuse when that IPv4 address is shared by more than one subscriber.
+ Law enforcement authorities may be particularly impacted because of
+ this. This particular issue can be fixed by logging port numbers,
+ although this will increase logging data storage requirements.
+
+ A number of services on the network today log the IPv4 source
+ addresses used in connection attempts to protect themselves from
+ certain attacks. For example, if a server sees too many requests
+ from the same IPv4 address in a short period of time, it may decide
+ to put that address in a penalty box for a certain time during which
+ requests are denied, or it may require completion of a CAPTCHA
+ (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
+ ways. First it may become the natural behavior to see many login
+ attempts from the same address because it is now shared across a
+ potentially large number of subscribers. Second and more likely is
+ that one user who fails a number of login attempts may block out
+ other users who have not made any previous attempts but who will now
+ fail on their first attempt. In the presence of widespread large-
+ scale address sharing, penalty box solutions to service abuse simply
+ will not work.
+
+
+
+
+Ford, et al. Informational [Page 18]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ In addition, there are web tie-ins into different blacklists that web
+ administrators subscribe to in order 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
+
+ Simple address-based identification mechanisms that are used to
+ populate access control lists will fail when an IP address is no
+ longer sufficient to identify a particular subscriber. Including
+ port numbers in access control list definitions may be possible at
+ the cost of extra complexity, and may also require the service
+ provider to make static port assignments, which conflicts with the
+ requirement for dynamic assignments discussed in Section 5.1.
+
+ 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
+ a shared token, and the name to address mapping may not be current.
+
+13.3. Spam
+
+ Another case of identifying abusers has to do with spam blacklisting.
+ When a spammer is behind a CGN or using a port-shared address,
+ blacklisting of their IP address will result in all other subscribers
+ sharing that address having their ability to source SMTP packets
+ restricted to some extent.
+
+13.4. Port Randomization
+
+ A blind attack that can be performed against TCP relies on the
+ attacker's ability to guess the 5-tuple (Protocol, Source Address,
+ Destination Address, Source Port, Destination Port) that identifies
+ the transport protocol instance to be attacked. [RFC6056] describes
+ a number of methods for the random selection of the source port
+ number, such that the ability of an attacker to correctly guess the
+ 5-tuple is reduced. With shared IPv4 addresses, the port selection
+ space is reduced. Preserving port randomization is important and may
+ be more or less difficult depending on the address sharing solution
+ and the size of the port space that is being manipulated. Allocation
+ of non-contiguous port ranges could help to mitigate this issue.
+
+ It should be noted that guessing the port information may not be
+ sufficient to carry out a successful blind attack. An in-window TCP
+ Sequence Number (SN) should also be known or guessed. A TCP segment
+ is processed only if all previous segments have been received, except
+ for some Reset segment implementations that immediately process the
+
+
+
+Ford, et al. Informational [Page 19]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ 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
+ randomization is one protection among others against blind attacks.
+ There is more detailed discussion of improving TCP's robustness to
+ Blind In-Window Attacks in [RFC5961].
+
+13.5. IPsec
+
+ The impact of large-scale IP address sharing for IPsec operation
+ should be evaluated and assessed. [RFC3947] proposes a solution to
+ solve issues documented in [RFC3715]. [RFC5996] specifies Internet
+ Key Exchange (IKE) Protocol Version 2, which includes NAT traversal
+ mechanisms that are now widely used to enable IPsec to work in the
+ presence of NATs in many cases. Nevertheless, service providers may
+ wish to ensure that CGN deployments do not inadvertently block NAT
+ traversal for security protocols such as IKE (refer to [NAT-SEC] for
+ more information).
+
+13.6. Policing Forwarding Behavior
+
+ [RFC2827] motivates and discusses a simple, effective, and
+ straightforward method for using ingress traffic filtering to
+ prohibit DoS attacks that use forged IP addresses. Following this
+ recommendation, service providers operating shared-addressing
+ mechanisms should ensure that source addresses, or source ports in
+ the case of port-range schemes, are set correctly in outgoing packets
+ from their subscribers or they should drop the packets.
+
+ If some form of IPv6 ingress filtering is deployed in the broadband
+ network and DS-Lite service is restricted to those subscribers, then
+ tunnels terminating at the CGN and coming from registered subscriber
+ IPv6 addresses cannot be spoofed. Thus, a simple access control list
+ on the tunnel transport source address is all that is required to
+ accept traffic on the internal interface of a CGN.
+
+14. Transport Issues
+
+14.1. Parallel Connections
+
+ One issue is systems that assume that multiple simultaneous
+ connections to a single IP address implies connectivity to a single
+ host -- such systems may experience unexpected results.
+
+14.2. Serial Connections
+
+ Another issue is systems that assume that returning to a given IP
+ address means returning to the same physical host, as with stateful
+ transactions. This may also affect cookie-based systems.
+
+
+
+Ford, et al. Informational [Page 20]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+14.3. TCP Control Block Sharing
+
+ [RFC2140] defines a performance optimization for TCP based on sharing
+ state between TCP control blocks that pertain to connections to the
+ same host, as opposed to maintaining state for each discrete
+ connection. This optimization assumes that an address says something
+ about the properties of the path between two hosts, which is clearly
+ not the case if the address in question is shared by multiple hosts
+ at different physical network locations. While CPE NAT today causes
+ problems for sharing TCP control block state across multiple
+ connections to a given IP address, large-scale address sharing will
+ make these issues more severe and more widespread.
+
+15. Reverse DNS
+
+ Many service providers populate forward and reverse DNS zones for the
+ public IPv4 addresses that they allocate to their subscribers. In
+ the case where public addresses are shared across multiple
+ subscribers, such strings are, by definition, no longer sufficient to
+ identify an individual subscriber without additional information.
+
+16. Load Balancing
+
+ Algorithms used to balance traffic load for popular destinations may
+ be affected by the introduction of address sharing. Where balancing
+ is achieved by deterministically routing traffic from specific source
+ IP addresses to specific servers, imbalances in load may be
+ experienced as address sharing is enabled for some of those source IP
+ addresses. This will require re-evaluation of the algorithms used in
+ the load-balancing design. In general, as the scale of address
+ sharing grows, load-balancing designs will need to be re-evaluated
+ and any assumptions about average load per source IP address
+ revisited.
+
+17. IPv6 Transition Issues
+
+ IPv4 address sharing solutions may interfere with existing IPv4 to
+ IPv6 transition mechanisms, which were not designed with IPv4
+ shortage considerations in mind. With port-range solutions, for
+ instance, incoming 6to4 packets should be able to find their way from
+ a 6to4 relay to the appropriate 6to4 CPE router, despite the lack of
+ direct port-range information (UDP/TCP initial source port did not
+ pass through the CPE port range translation process). One solution
+ would be for a 6to4 IPv6 address to embed not only an IPv4 address
+ but also a port range value.
+
+
+
+
+
+
+Ford, et al. Informational [Page 21]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ Subscribers allocated with private addresses will not be able to
+ utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize
+ Teredo [RFC4380].
+
+ Some routers enable 6to4 on their WAN link. 6to4 requires a publicly
+ routable IPv4 address. Enabling 6to4 when the apparently public IPv4
+ WAN address is in fact behind a NAT creates a disconnected IPv6
+ island.
+
+18. Introduction of Single Points of Failure
+
+ In common with all deployments of new network functionality, the
+ introduction of new nodes or functions to handle the multiplexing of
+ multiple subscribers across shared IPv4 addresses could create single
+ points of failure in the network. Any IP address sharing solution
+ should consider the opportunity to add redundancy features in order
+ to alleviate the impact on the robustness of the offered IP
+ connectivity service. The ability of the solution to allow hot
+ swapping from one machine to another should be considered. This is
+ especially important where the address sharing solution in question
+ requires the creation of per-flow state in the network.
+
+19. State Maintenance Reduces Battery Life
+
+ In order for hosts to maintain network state in the presence of NAT,
+ keep-alive messages have to be sent at frequent intervals. For
+ battery-powered devices, sending these keep-alive messages can result
+ in significantly reduced battery performance than would otherwise be
+ the case [Mobile_Energy_Consumption].
+
+20. Support of Multicast
+
+ [RFC5135] specifies requirements for a NAT that supports Any Source
+ IP Multicast or Source-Specific IP Multicast. Port-range routers
+ that form part of port-range solutions will need to support similar
+ requirements if multicast support is required.
+
+21. Support of Mobile-IP
+
+ IP address sharing within the context of Mobile IP deployments (in
+ the home network and/or in the visited network) will require Home
+ Agents and/or Foreign Agents to be updated so as to take into account
+ the relevant port information. There may also be issues raised when
+ an additional layer of encapsulation is required thereby causing, or
+ increasing the need for, fragmentation and reassembly.
+
+ Issues for Mobile-IP in the presence of NAT are discussed in
+ [NAT64-MOBILITY].
+
+
+
+Ford, et al. Informational [Page 22]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+22. Security Considerations
+
+ This memo does not define any protocol and therefore creates no new
+ security issues. Section 13 discusses some of the security and
+ identity-related implications of IP address sharing.
+
+23. Contributors
+
+ This document is based on sources co-authored by J.L. Grimault and A.
+ Villefranque of France Telecom.
+
+24. Acknowledgments
+
+ This memo was partly inspired by conversations that took place as
+ part of Internet Society (ISOC) hosted roundtable events for
+ operators and content providers deploying IPv6. Participants in
+ those discussions included John Brzozowski, Leslie Daigle, Tom
+ Klieber, Yiu Lee, Kurtis Lindqvist, Wes George, Lorenzo Colliti, Erik
+ Kline, Igor Gashinsky, Jason Fesler, Rick Reed, Adam Bechtel, Larry
+ Campbell, Tom Coffeen, David Temkin, Pete Gelbman, Mark Winter, Will
+ Charnock, Martin Levy, Greg Wood, and Christian Jacquenet.
+
+ The authors are also grateful to Christian Jacquenet, Iain Calder,
+ Joel Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo
+ Bagnulo, Dan Wing, and Wes George for their helpful comments and
+ suggestions for improving the document.
+
+ This memo was created using the xml2rfc tool.
+
+25. Informative References
+
+ [A+P] Bush, R., "The A+P Approach to the IPv4 Address Shortage",
+ Work in Progress, February 2011.
+
+ [CGN_Viability]
+ Alcock, S., "Research into the Viability of Service-
+ Provider NAT", 2008, <http://www.wand.net.nz/~salcock/
+ someisp/flow_counting/result_page.html>.
+
+ [DS-Lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+ Stack Lite Broadband Deployments Following IPv4
+ Exhaustion", Work in Progress, May 2011.
+
+ [IANA_Ports]
+ IANA, "Port Numbers", <http://www.iana.org>.
+
+
+
+
+
+
+Ford, et al. Informational [Page 23]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ [IPv4_Pool]
+ ICANN, "Available Pool of Unallocated IPv4 Internet
+ Addresses Now Completely Emptied", February 2011,
+ <http://icann.org/en/news/releases/
+ 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]
+ Haverinen, H., Siren, J., and P. Eronen, "Energy
+ Consumption of Always-On Applications in WCDMA Networks",
+ 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,
+ November 1990.
+
+ [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
+ RFC 1337, May 1992.
+
+ [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
+ October 1994.
+
+
+
+
+Ford, et al. Informational [Page 24]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+ E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, February 1996.
+
+ [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
+ April 1997.
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations",
+ RFC 2663, August 1999.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP Source
+ Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+ [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
+ November 2000.
+
+ [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+ 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
+ (NAT) Compatibility Requirements", RFC 3715, March 2004.
+
+ [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
+ "Negotiation of NAT-Traversal in the IKE", RFC 3947,
+ 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
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
+ Network Address Translator (NAT) and a Network Address
+ Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
+
+
+
+
+
+Ford, et al. Informational [Page 25]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
+ Behavioral Requirements for ICMP", BCP 148, RFC 5508,
+ April 2009.
+
+ [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
+ Robustness to Blind In-Window Attacks", RFC 5961,
+ August 2010.
+
+ [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+ "Internet Key Exchange Protocol Version 2 (IKEv2)",
+ RFC 5996, September 2010.
+
+ [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
+ Protocol Port Randomization", BCP 156, RFC 6056,
+ January 2011.
+
+ [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+ 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,
+ <http://upnp.org/specs/gw/igd2/>.
+
+ [Windows-Logo]
+ Microsoft, "Windows Logo Program Requirements and
+ Policies", 2006, <http://www.microsoft.com/whdc/winlogo/
+ hwrequirements/default.mspx>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford, et al. Informational [Page 26]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+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).
+
+
+
+
+
+
+
+Ford, et al. Informational [Page 27]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford, et al. Informational [Page 28]
+
+RFC 6269 Issues with IP Address Sharing June 2011
+
+
+Authors' Addresses
+
+ Mat Ford (editor)
+ Internet Society
+ Geneva
+ Switzerland
+
+ EMail: ford@isoc.org
+
+
+ Mohamed Boucadair
+ France Telecom
+ Rennes 35000
+ France
+
+ EMail: mohamed.boucadair@orange-ftgroup.com
+
+
+ Alain Durand
+ Juniper Networks
+
+ EMail: adurand@juniper.net
+
+
+ Pierre Levis
+ France Telecom
+ 42 rue des Coutures
+ BP 6243
+ Caen Cedex 4 14066
+ France
+
+ EMail: pierre.levis@orange-ftgroup.com
+
+
+ Phil Roberts
+ Internet Society
+ Reston, VA
+ USA
+
+ EMail: roberts@isoc.org
+
+
+
+
+
+
+
+
+
+
+
+Ford, et al. Informational [Page 29]
+