doc: Add RFC documents

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