EXPERIMENTAL

Internet Engineering Task Force (IETF) R. Bush, Ed. Request for Comments: 6346 Internet Initiative Japan Category: Experimental August 2011 ISSN: 2070-1721 The Address plus Port (A+P) Approach to the IPv4 Address Shortage Abstract We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. Bush Experimental [Page 1]

RFC 6346 A+P Addressing Extension August 2011 Section 2 of RFC 5741. 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/rfc6346. 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. Bush Experimental [Page 2]

RFC 6346 A+P Addressing Extension August 2011 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problems with Carrier Grade NATs . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Constraints and Functions . . . . . . . . . . . . . . . 6 3.1. Design Constraints . . . . . . . . . . . . . . . . . . . . 6 3.2. A+P Functions . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Overview of the A+P Solution . . . . . . . . . . . . . . . 8 3.3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. Address Realm . . . . . . . . . . . . . . . . . . . . 11 3.3.3. Reasons for Allowing Multiple A+P Gateways . . . . . . 15 3.3.4. Overall A+P Architecture . . . . . . . . . . . . . . . 16 3.4. A+P Experiments . . . . . . . . . . . . . . . . . . . . . 17 4. Stateless A+P Mapping Function . . . . . . . . . . . . . . . . 18 4.1. Stateless A+P Mapping (SMAP) Gateway Function Description . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Implementation Mode . . . . . . . . . . . . . . . . . . . 20 4.3. Towards IPv6-Only Networks . . . . . . . . . . . . . . . . 22 4.4. PRR: On Stateless and Binding Table Modes . . . . . . . . 22 4.5. General Recommendations on SMAP . . . . . . . . . . . . . 23 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 24 5.1. A+P Deployment Models . . . . . . . . . . . . . . . . . . 24 5.1.1. A+P for Broadband Providers . . . . . . . . . . . . . 24 5.1.2. A+P for Mobile Providers . . . . . . . . . . . . . . . 24 5.1.3. A+P from the Provider Network Perspective . . . . . . 25 5.2. Dynamic Allocation of Port Ranges . . . . . . . . . . . . 27 5.3. Example of A+P-Forwarded Packets . . . . . . . . . . . . . 28 5.3.1. Forwarding of Standard Packets . . . . . . . . . . . . 32 5.3.2. Handling ICMP . . . . . . . . . . . . . . . . . . . . 32 5.3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 33 5.3.4. Limitations of the A+P Approach . . . . . . . . . . . 33 5.3.5. Port Allocation Strategy Agnostic . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . . 35 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 37 Bush Experimental [Page 3]

RFC 6346 A+P Addressing Extension August 2011 1 . Introduction 1.1 . Problems with Carrier Grade NATs Bush Experimental [Page 4]

RFC 6346 A+P Addressing Extension August 2011 RFC6333] with A+P or the Port Control Protocol (PCP) [PCP-BASE] -- admit that it is not expected that applications that require specific port assignment or port mapping from the NAT box will keep working. Another issue with CGNs is the trade-off between session state and network placement. The farther from the edge the CGN is placed, the more session state needs to be kept due to larger subscriber aggregation and the more disruption that occurs in the case of a failure. In order to reduce the state, CGNs would end up somewhere closer to the edge. Thus, the CGN trades scalability for the amount of state that needs to be kept, which makes optimally placing a CGN a hard engineering problem. In some deployment scenarios, a CGN can be seen as the single point of failure, and therefore the availability of delivered services can be impacted by a single CGN device. Means to ensure state synchronization and failover would be required to allow for service continuity whenever a failure occurs. Intra-domain paths may not be optimal for communications between two nodes connected to the same domain deploying CGNs; they may lead to path stretches. 1.2 . Requirements Language RFC 2119 [RFC2119]. 2 . Terminology Bush Experimental [Page 5]

RFC 6346 A+P Addressing Extension August 2011 RFC1918] range. However, this document does not make such an assumption. We regard as private address space any IPv4 address that needs to be translated in order to gain global connectivity, irrespective of whether or not it falls in [RFC1918] space. Port-Range Router (PRR): A device that forwards A+P packets. Customer Premises Equipment (CPE): cable or DSL modem. Provider Edge (PE) Router: Customer aggregation router. Provider Border Router (BR): Provider's edge to other providers. Network Core Routers (Core): Provider routers that are not at the edges. 3 . Design Constraints and Functions 3.1 . Design Constraints Bush Experimental [Page 6]

RFC 6346 A+P Addressing Extension August 2011 RFC 1918 addressing. Constraint 5 is important: while many techniques have been deployed to allow applications to work through a NAT, traversing cascaded NATs is crucial if NATs are being deployed in the core of a provider network. 3.2 . A+P Functions BCP38]). Based on the result of such a check, the packet MAY be forwarded untranslated, MAY be discarded, or MAY be NATed. In this document, we refer to a device that provides this encaps/decaps functionality as a Port-Range Router (PRR). Network Address Translation (NAT) function: is used to connect legacy end-hosts. Unless upgraded, end-hosts or end-systems are not aware of A+P restrictions and therefore assume a full IP address. The NAT function performs any address or port translation, including Application Level Gateways (ALGs) whenever required. The state that has to be kept to implement this function is the mapping for which external addresses and ports have been mapped to which internal addresses and ports, just as in CPEs embedding NAT today. A subtle, Bush Experimental [Page 7]

RFC 6346 A+P Addressing Extension August 2011 3.3 . Overview of the A+P Solution Section 3.3.1 discusses the constraints of this signaling function. The tunnel can be an IPv6 or IPv4 encapsulation, a layer-2 tunnel, or some other form of softwire. Note that the presence of a tunnel allows unmodified, naive, or even legacy devices between the two endpoints. Bush Experimental [Page 8]

RFC 6346 A+P Addressing Extension August 2011 3.3.1 . Signaling PR-ADDR-ASSIGN], [SHARED-ADDR-OPT], [PORT-RANGE-OPT], or [PCP-BASE]. The information that needs to be shared is the following: o a set of public IPv4 addresses, o for each IPv4 address, a starting point for the allocated port range, o the number of delegated ports, o the optional key that enables partial or full preservation of entropy in port randomization -- see [PR-ADDR-ASSIGN], o the lifetime for each IPv4 address and set of allocated ports, o the tunneling technology to be used (e.g., "IPv6-encapsulation"), Bush Experimental [Page 9]

RFC 6346 A+P Addressing Extension August 2011 PR-ADDR-ASSIGN] and [PORT-RANGE-OPT]. Note that different port ranges can have different lifetimes, and the CPE is not entitled to use them after they expire -- unless it refreshes those ranges. It is up to the ISP to put mechanisms in place (to prevent denial-of-service attacks) that determine what percentage of already allocated port ranges should be exhausted before a CPE may request additional ranges, how often the CPE can request additional ranges, and so on. o If applications behind the CPE are UPnPv2/NAT-PMP-aware, additional ports MAY be requested through that mechanism. In this case, the CPE should forward those requests to the LSN, and the LSN should reply reporting if the requested ports are available or not (and if they are not available, some alternatives should be offered). Here again, to prevent potential denial-of-service attacks, mechanisms should be in place to prevent UPnPv2/NAT-PMP packet storms and fast port allocation. A detailed description of this mechanism, called PCP, is in [PCP-BASE]. Whatever signaling mechanism is used inside the tunnels -- DHCP, IP Control Protocol (IPCP), or PCP based, synchronization between the signaling server and PRR must be established in both directions. For example, if we use DHCP as the signaling mechanism, the PRR must communicate to the DHCP server at least its IP range. The DHCP server then starts to allocate IP addresses and port ranges to CPEs and communicates back to the PRR which IP and port range have been allocated to which CPE, so the PRR knows to which tunnel to redirect incoming traffic. In addition, DHCP MUST also communicate lifetimes Bush Experimental [Page 10]

RFC 6346 A+P Addressing Extension August 2011 RFC5737]. private +-----+ +-----+ public address ---| B |==========| A |--- Internet realm +-----+ +-----+ Address space realm of A: public IPv4 address = 192.0.2.1 port range = 0-65535 Address space realm of B: public IPv4 address = 192.0.2.1 port range = 2560-3071 Figure 3: Configuration Example Figure 3 illustrates a sample configuration. Note that A might actually consist of three different devices: one that handles signaling requests from B; one that performs encapsulation and decapsulation; and, if provided, one device that performs the NATing function (e.g., an LSN). Packet forwarding is assumed to be as follows: in the "outbound" case, a packet arrives from the private address realm to B. As stated above, B has two options: it can either apply or not apply the NAT function. The decision depends upon the specific configuration and/or the capabilities of A and B. Note that NAT functionality is required to support legacy hosts; however, this can be done at either of the two devices A or B. The term "NAT" refers to translating the packet into the managed A+P address (B has address 192.0.2.1 and ports 2560-3071 in the example above). We then have two options: 1) B NATs the packet. The translated packet is then tunneled to A. A recognizes that the packet has already been translated because the source address and port match the delegated space. A decapsulates the packet and releases it in the public Internet. Bush Experimental [Page 12]

RFC 6346 A+P Addressing Extension August 2011 Bush Experimental [Page 13]

RFC 6346 A+P Addressing Extension August 2011 Section 4 for a discussion of an alternative A+P mechanism that does not incur path-stretch penalties for intra-domain communication. Bush Experimental [Page 14]

RFC 6346 A+P Addressing Extension August 2011 3.3.3 . Reasons for Allowing Multiple A+P Gateways Bush Experimental [Page 15]

RFC 6346 A+P Addressing Extension August 2011 RFC6333], is a hybrid. There is NAT present in the core (in this document, referred to as LSN), but the user has the option to "bypass" that NAT in one form or an other, for example, via A+P, NAT-PMP, etc. Finally, a service provider that only deploys CGN will place a NAT in the provider's core and does not allow the customer to "bypass" the translation process or modify ALGs on the NAT. The customer is provider-locked. Notice that all options (besides full IPv4) require some form of tunneling mechanism (e.g., 4in6) and a signaling mechanism (see Section 3.3.1). 3.4 . A+P Experiments BITTORRENT-ADDR-SHARING]. Conclusions in that document tell us that two limitations were experienced. The first occurred when two clients sharing the same IP address tried to simultaneously retrieve the SAME file located in a SINGLE remote peer. The second limitation occurred when a client tried to download a file located on several seeders, when those seeders shared the same IP address. Mutual file sharing between hosts having the same IP address has been checked. Indeed, machines having the same IP address can share files with no alteration compared to current IP architectures. Working implementations of A+P can be found in: o Internet Systems Consortium AFTR (http://www.isc.org/software/aftr), Bush Experimental [Page 17]

RFC 6346 A+P Addressing Extension August 2011 http://opensourceaplusp.weebly.com/) developed by Xiaoyu Zhao, Xiaohong Deng, Tao Zheng, and o 4rd (IPv4 Residual Deployment) from ipinfusion.com, which is stateless A+P. 4 . Stateless A+P Mapping Function 4.1 . Stateless A+P Mapping (SMAP) Gateway Function Description Section 4.1 of [RFC6052], the suffix part may enclose the port. The Stateless A+P Mapping (SMAP) gateway consists in two basic functions as described in Figure 8. 1. SMAP encapsulates an IPv4 packet, destined to a shared IPv4 address, in an IPv6 one. The IPv6 source address is constructed using an IPv4-embedded IPv6 address [RFC6052] from the IPv4 source address and port number plus the IPv6 prefix that has been provisioned to the node performing the SMAP function. The destination IPv6 address is constructed using the shared IPv4 destination address and port number plus the IPv6 prefix that has been provisioned to the SMAP function and that is dedicated to IPv4 destination addresses. 2. SMAP extracts IPv4 incoming packets from IPv6 incoming ones that have IPv6 source addresses belonging to the prefix of the node performing the SMAP function. Extracted IPv4 packets are then forwarded to the point identified by the IPv4 destination address and port number. Bush Experimental [Page 18]

RFC 6346 A+P Addressing Extension August 2011 Bush Experimental [Page 19]

RFC 6346 A+P Addressing Extension August 2011 Bush Experimental [Page 21]

RFC 6346 A+P Addressing Extension August 2011 4.3 . Towards IPv6-Only Networks 4.4 . PRR: On Stateless and Binding Table Modes Section 4) discusses two modes: the binding and the stateless modes. Dynamic port allocation is not a feature of the stateless mode, but it is supported in the binding mode. In the binding mode, distinct external IPv4 addresses may be used, but this is not recommended. o Stateless Mode Complete stateless mapping implies that the IPv4 address and the significant bits coding the port range are reflected inside the IPv6 prefix assigned to the port-restricted device. This can be achieved either by embedding the full IPv4 address and the significant bits in the IPv6 prefix or by applying an algorithmic approach. Two alternatives are offered when such a stateless mapping is to be enabled: - use the IPv6 prefix already used for native IPv6 traffic, or Bush Experimental [Page 22]

RFC 6346 A+P Addressing Extension August 2011 Section 4.1 of [RFC6052], the suffix part may enclose the port. o Binding Table Mode Another alternative is to assign a "normal" IPv6 prefix to the port-restricted device and to use a binding table, which can be hosted by a service node to correlate the (shared IPv4 address, port range) with an IPv6 address part of the assigned IPv6 prefix. For scalability reasons, this table should be instantiated within PRR-enabled nodes that are close to the port-restricted devices. The number of required entries if hosted at the interconnection segment would be equal to the amount of subscribed users (one per port-restricted device). 4.5 . General Recommendations on SMAP 4rd]. Bush Experimental [Page 23]

RFC 6346 A+P Addressing Extension August 2011 5.1.3 . A+P from the Provider Network Perspective RFC 1918) --|-| CPE |==-IPv6-==| PRR |-|-- network space | +------+ tunnel +-----+ | (public addresses) | ^ +-----+ | | | IPv6-only | LSN | | | | network +-----+ | +----+----------------- ^ --+ | | on customer within provider premises and control network Figure 12: A Simple A+P Subsystem Example Consider the deployment scenario in Figure 12, where an A+P subsystem is formed by the CPE and a PRR within the ISP core network and preferably is close to the customer edge. Inside the subsystem, packets are forwarded based on address and port. The provider MAY deploy an LSN co-located with the PRR to handle packets that have not been translated by the CPE. In such a configuration, the ISP allows the customer to freely decide whether the translation is done at the Bush Experimental [Page 25]

RFC 6346 A+P Addressing Extension August 2011 Section 3.3.1 to connect to the A+P subsystem. In this case, the application will be delegated some space in the A+P address realm, and will be able to contact the public realm (i.e., the public Internet) without the need for translation. Note that part of A+P signaling is that the NATs are optional. However, if neither the CPE nor the PRR provides NATing functionality, then it will not be possible to connect legacy end- hosts. To enable packet forwarding with A+P, the ISP MUST install at its A+P border a PRR that encaps/decaps packets. However, to achieve a higher address space compression ratio and/or to support CPEs without NATing functionality, the ISP MAY decide to provide an LSN as well. If no LSN is installed in some part of the ISP's topology, all CPEs Bush Experimental [Page 26]

RFC 6346 A+P Addressing Extension August 2011 5.2 . Dynamic Allocation of Port Ranges Bush Experimental [Page 27]

RFC 6346 A+P Addressing Extension August 2011 Section 3.3.1), if applications behind CPE support it. In the case of the LSN implementation (DS-Lite), as described in Section 3.3.4 about the A+P overall architecture, signaling packets are simply forwarded by the CPE to the LSN and back to the host running the application that requested the ports, and the PRR allocates the requested port to the appropriate CPE. The same behavior may be chosen with AFTR, if requested ports are outside of the static initial port allocation. If a full A+P implementation is selected, then UPnPv2/NAT-PMP packets are accepted by the CPE, processed, and the requested port number is communicated through the normal signaling mechanism between CPE and PRR tunnel endpoints (PCP). 5.3 . Example of A+P-Forwarded Packets Bush Experimental [Page 28]

RFC 6346 A+P Addressing Extension August 2011 Bush Experimental [Page 29]

RFC 6346 A+P Addressing Extension August 2011 Bush Experimental [Page 30]

RFC 6346 A+P Addressing Extension August 2011 Bush Experimental [Page 31]

RFC 6346 A+P Addressing Extension August 2011 5.3.1 . Forwarding of Standard Packets RFC6333] for network diagrams that illustrate the packet flow in this case. 5.3.2 . Handling ICMP Bush Experimental [Page 32]

RFC 6346 A+P Addressing Extension August 2011 5.3.3 . Fragmentation RFC6146], Section 3.5, in the sense that it should reassemble the fragments in order to look at the destination port number. Note that it is recommended to use a Path MTU Discovery (PMTUD) mechanism (e.g., [RFC1191]). Security issues related to fragmentation are out of scope of this document. For more details, refer to [RFC1858]. 5.3.4 . Limitations of the A+P Approach RFC3715]) can be employed. Bush Experimental [Page 33]

RFC 6346 A+P Addressing Extension August 2011 RFC6269], but that's something we'll have to live with. For the host-based A+P, issues related to application conflicts when trying to bind to an out-of-range port are to be further assessed. Note that extensions to the host-based model have been proposed in the past (e.g., the Port-Enhanced Address Resolution Protocol (ARP) extension documented in http://software.merit.edu/pe-arp/). 5.3.5 . Port Allocation Strategy Agnostic PR-IP-ISSUES] have been analyzed in [STATELESS-4v6]. As seen in that document, most of the issues apply to host-based port-sharing solutions. A+P is not intended to be a host-based port-sharing solution. The conclusion of [STATELESS-4v6] is that the set of issues specifically attributed to A+P either do not apply to CPE-based flavors or can be mitigated. The A+P solution represents a reasonable trade-off compared to alternatives in areas such as binding logging (for data storage purposes) and ease of deployment and operations, all of which are actually facilitated by such a solution. 6 . Security Considerations Bush Experimental [Page 34]

RFC 6346 A+P Addressing Extension August 2011 SHARED-ADDR-OPT] Boucadair, M., Levis, P., Grimault, J., Savolainen, T., and G. Bajko, "Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP Addresses Solutions", Work in Progress, December 2009. [STATELESS-4v6] Dec, W., Asati, R., Bao, C., and H. Deng, "Stateless 4Via6 Address Sharing", Work in Progress, July 2011. 9 . Contributing Authors Bush Experimental [Page 37]