RFC 6346
The Address plus Port (A+P) Approach to the IPv4 Address Shortage
RFC 6346: The Address plus Port (A+P) Approach to the IPv4 Address Shortage 🎀
Okay bestie, this is RFC 6346 💖 It's an Experimental doc, so it's not a Standards Track thing and nobody's forcing it on anyone 🧪. R. Bush, Ed. from Internet Initiative Japan wrote it, and it came out in August 2011 🌸. It's an IETF product with ISSN 2070-1721 ✨. The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Abstract ✨
Okay so the IANA IPv4 free address pool is running out 😭. IPv6 isn't deployed widely enough to fully replace IPv4 yet, and it's not realistic to think that'll change before IPv4 addresses run dry 💀. So the real question is how to let hosts talk seamlessly in an IPv4 world without giving every one of them a unique, globally routable IPv4 address. Hard problem, bestie.
This doc proposes an IPv4 address sharing scheme that treats some of the port number bits as part of an extended IPv4 address, called Address plus Port, or A+P 🦋. Instead of giving one IPv4 address to one customer device, we extend the address field using bits from the port number range in the TCP/UDP header as extra endpoint identifiers. That leaves a smaller range of ports for applications to use 🧚. So the same IPv4 address gets shared across multiple clients (like Customer Premises Equipment (CPE) and mobile phones), and each one gets its own port range 🌈. When IPv4 addresses are running out, needing addresses matters more than being able to address thousands of applications on a single host, and that's the whole vibe 👑. If address translation is needed, the end-user should be in control of it, not some smart boxes in the core 🔥.
Status of This Memo ✨
This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪.
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 📚.
For the current status, any errata, and how to give feedback, go to 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) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document 📜. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🙈.
Table of Contents 🍓
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 . . . . . . . . . . . . . . . . . . . . . 371. Introduction 🌸
This doc describes a technique for the imminent IPv4 address space exhaustion 😩. Lots of big Internet Service Providers (ISPs) have customer edges so large that they soon won't be able to give each customer a unique public IPv4 address. So address sharing, the same way NAT does it, is inevitable. Undesirable? Yes. Inevitable? Also yes 🙃.
To allow end-to-end connectivity between IPv4-speaking applications, we propose extending the semantics of the IPv4 address with bits from the UDP/TCP header 🦋. Say we could limit the applications' port addressing to any number of bits lower than 16. Then we can increase the effective size of an IPv4 address by the remaining additional bits, up to 16 ✨. In this setup, 1 to 65536 customers could be multiplexed on the same IPv4 address, and each one gets a fixed or dynamic range of 1 to 65536 ports 🧚. Customers could get an initial fixed port range defined by the operator, then dynamically request more blocks depending on their contract 💅. We call this "extended addressing" or "A+P" (Address plus Port) addressing. The main perk of A+P is that it preserves the Internet "end-to-end" paradigm, because it doesn't require translating the IP address (at least for some ports) 🫶.
1.1. Problems with Carrier Grade NATs ⚠️
Various forms of NATs will be installed at different levels and places in the IPv4 Internet to get address compression. This document argues for mechanisms where that happens as close to the edge of the network as possible 🌿. That way you minimize damage to the End-to-End Principle and end-customers keep control over address and port translation. So it's essential to build mechanisms that "bypass" NATs in the core, when that's applicable, and keep control with the end-user 👑.
With Carrier Grade NATs (CGNs) in the core of the network, the user is trapped behind unchangeable application policies 😤. And deploying new applications gets blocked, because the matching Application Level Gateways (ALGs) would have to be implemented on the CGNs. That's the opposite of the Internet's "end-to-end" model, bestie 💀.
With the smarts at the edges, you can easily deploy new applications between consenting endpoints by just tweaking the NATs at the corresponding CPE 🛠️. You could even upgrade them to a new version that supports a specific ALG ✨.
Today's NATs are usually softened up by giving customers limited control over them, like port forwarding, Universal Plug and Play or the NAT Port Mapping Protocol (UPnP/NAT-PMP) 🎀. But that's not expected to work with CGNs. CGN proposals, other than DS-Lite [RFC6333] with A+P or the Port Control Protocol (PCP) [PCP-BASE], admit that applications needing a specific port assignment or port mapping from the NAT box are not expected to keep working 🙈.
Another issue with CGNs is the trade-off between session state and network placement. The farther from the edge the CGN sits, the more session state has to be kept, because subscriber aggregation is bigger, and the more disruption happens when something fails 😬. To reduce the state, CGNs would end up somewhere closer to the edge. So the CGN trades scalability for how much state it has to keep, which makes placing a CGN optimally a hard engineering problem 🧠.
In some deployment scenarios, a CGN can be the single point of failure, so one CGN device can hurt the availability of delivered services 😱. You'd need ways to ensure state synchronization and failover so service continuity holds whenever something fails 🔁.
Intra-domain paths may not be optimal for communications between two nodes connected to the same domain that deploys CGNs. They may lead to path stretches 🌀.
1.2. Requirements Language 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫡.
2. Terminology 🧾
This document makes use of the following terms:
- Public Realm: This realm contains only public routable IPv4 addresses. Packets in this realm are forwarded based on the destination IPv4 address.
- A+P Realm: This realm contains both public routable IPv4 and A+P addresses.
- A+P Packet: A regular IPv4 packet is forwarded based on the destination IPv4 address and the TCP/UDP port numbers.
- Private Realm: This realm contains IPv4 addresses that are not globally routed. They may be taken from the [RFC1918] range. However, this document does not make that assumption. We regard as private address space any IPv4 address that needs to be translated in order to gain global connectivity, 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 💖
The problem of address space shortage is first felt by providers with a very large end-user customer base, like broadband providers and mobile service providers 📶. The cases and requirements are slightly different, but they share lots of commonalities 🫶. In the following text, we develop a set of overall design constraints for solutions that address the IPv4 address shortage problem 🔍.
3.1. Design Constraints ✨
okay so we have a few constraints that are super important for our design 💅
- End-to-end is under customer control 🦋: Customers need to be able to deploy new application protocols whenever they want. Running out of IPv4 addresses is NOT an excuse to break the Internet's end-to-end paradigm 🙅♀️
- Backward compatibility 🫶: The approach should be invisible to users who don't know about it. Devices and existing apps should keep working without any changes, and new applications shouldn't get blocked from showing up.
- Highly scalable and minimal state core 🌈: Keep the state as minimal as possible inside the ISP's network. If the operator rolls out A+P bit by bit, it's understood that there may be state in the core in the non-A+P part of that rollout.
- Efficiency versus complexity ⚖️: Operators should be able to choose how they balance port multiplexing efficiency against scalability and end-to-end transparency.
- "Double-NAT" should be avoided 🙈: A path might have several gateway devices in it, and once one of them has done some translation, those packets should not get translated again.
- Legal traceability 🔍: ISPs need to be able to work out a customer's identity from just the IPv4 public address and the port. This should affect the ISP's storage as little as reasonably possible. We assume NATs on customer premises aren't much of a problem, but provider NATs need to keep additional logs 📝
- IPv6 deployment should be encouraged 🧚: NAT444 strongly pushes users toward using RFC 1918 addressing, and we want to avoid that 🌸
Constraint 5 is a big deal, ngl 👑 Lots of techniques have been deployed so applications can work through a NAT, but being able to traverse cascaded NATs is crucial if NATs are going to live in the core of a provider network 😭
3.2. A+P Functions 💜
The A+P architecture breaks down into three distinct functions: encaps/decaps, NAT, and signaling 🎀
Encaps/decaps function 🚇: This is what forwards port-restricted A+P packets across intermediate legacy devices. The encapsulation part takes an IPv4 packet, looks at its IP and TCP/UDP headers, and drops the packet into the right tunnel. The state needed for this is basically like a forwarding table. The decapsulation device SHOULD check whether the source address and port of packets coming out of the tunnel are legitimate (e.g., see [BCP38]). Depending on what that check finds, the packet MAY be forwarded untranslated, MAY be discarded, or MAY be NATed ✨ In this document, we call a device that provides this encaps/decaps functionality a Port-Range Router (PRR) 🦋
Network Address Translation (NAT) function 🌷: This connects legacy end-hosts. Unless they've been upgraded, end-hosts or end-systems don't know about A+P restrictions, so they assume they have a full IP address. The NAT function handles any address or port translation, including Application Level Gateways (ALGs) whenever they're needed. The state this function keeps is the mapping of which external addresses and ports map to which internal addresses and ports, just like CPEs with NAT today do. Here's a subtle but very important difference 👀: the customer can control the NATing process or might choose to "bypass" the NAT. When that happens, we call the NAT a Large-Scale NAT (LSN). But if the NAT does NOT let the customer control the translation process, we call it a CGN 💅
Signaling function 📣: This lets A+P-aware devices find out which ports are assigned to pass through untranslated, and what happens to packets outside the assigned port range (for example, they could be NATed or discarded). Signaling can also be used to learn the encapsulation method and any needed endpoint information. On top of that, the signaling function can be used to dynamically assign the requested port range 🌈
3.3. Overview of the A+P Solution 🍓
As I mentioned earlier, the core architectural elements of the A+P solution are three separate and independent functions: the NAT function, the encaps/decaps function, and the signaling function 🧚 The NAT function is basically a NAT as we know it today: it translates between two different address realms. When the external realm is public IPv4 address space, we assume the translation is many-to-one, so we can multiplex lots of customers onto a single public IPv4 address 🫶 The only difference from a traditional NAT (Figure 1) is that the translator might only be able to use a restricted range of ports when mapping multiple internal addresses onto an external one. In other words, the external address realm might be port-restricted 💖
"internal-side" "external-side"
+-----+
internal | N | external
address <---| A |---> address
realm | T | realm
+-----+
Figure 1: Traditional NATThe encaps/decaps function is different: it's the ability to set up a tunnel with another endpoint that provides the same function 🦋 That requires some form of signaling to establish the tunnel. You can think of this signaling as being integrated with DHCP, or as a separate service. Section 3.3.1 covers 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. Also, having a tunnel means unmodified, naive, or even legacy devices can sit between the two endpoints 🌸
Two or more devices that provide the encaps/decaps function get linked by tunnels to form an A+P subsystem 👑 Each gateway's job is to encapsulate or decapsulate, respectively. Figure 2 shows the simplest possible A+P subsystem: two devices providing the encaps/decaps function.
+------------------------------------+
Private | +----------+ tunnel +----------+ | Public
address --|-| gateway |==========| gateway |-|-- address
realm | +----------+ +----------+ | realm
+------------------------------------+
A+P subsystem
Figure 2: A Simple A+P SubsystemInside an A+P subsystem, the public address realm gets extended by using bits from the port number when forwarding packets 🎀 Each device is assigned one address from the external realm plus a range of port numbers. So devices that are part of an A+P subsystem can talk to the public realm without any address translation, which keeps end-to-end packet integrity intact ✨ An A+P packet that starts inside the A+P subsystem can just be forwarded over the tunnels to the endpoint, where it gets decapsulated and routed in the external realm 🚀
3.3.1. Signaling 📡
Every gateway in the A+P subsystem needs to have the following information available. It's expected that there will be signaling protocols such as [PR-ADDR-ASSIGN], [SHARED-ADDR-OPT], [PORT-RANGE-OPT], or [PCP-BASE] 💜
The information that needs to be shared is:
- a set of public IPv4 addresses,
- for each IPv4 address, a starting point for the allocated port range,
- the number of delegated ports,
- the optional key that enables partial or full preservation of entropy in port randomization -- see [PR-ADDR-ASSIGN],
- the lifetime for each IPv4 address and set of allocated ports,
- the tunneling technology to be used (e.g.,
"IPv6-encapsulation"), - addresses of the tunnel endpoints (e.g., IPv6 address of tunnel endpoints),
- whether or not NAT function is provided by the gateway,
- a device identification number and some authentication mechanisms, and
- a version number and some reserved bits for future use.
Note that the encapsulation and decapsulation functions have been separated from the NAT function 🧩 But to accommodate legacy hosts, NATing is likely to be provided at some point in the path, so the availability or absence of NATing MUST be communicated in signaling, since A+P doesn't care where the NAT sits 🙌
Port ranges can be allocated in two different ways 🎀
- If applications or end-hosts behind the CPE are not UPnPv2/NAT-PMP-aware, then the CPE SHOULD request ports via mechanisms, e.g., as described in [PR-ADDR-ASSIGN] and [PORT-RANGE-OPT]. 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's up to the ISP to put mechanisms in place (to prevent denial-of-service attacks) that decide what percentage of already allocated port ranges should be used up before a CPE may request additional ranges, how often the CPE can request additional ranges, and so on 🛡️
- 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 whether the requested ports are available (and if they aren't, some alternatives should be offered). Again, to prevent potential denial-of-service attacks, mechanisms should be in place to stop UPnPv2/NAT-PMP packet storms and fast port allocation. A detailed description of this mechanism, called PCP, is in [PCP-BASE] 🔥
Whatever signaling mechanism gets used inside the tunnels (DHCP, IP Control Protocol (IPCP), or PCP-based), synchronization between the signaling server and PRR has to be established in both directions 🔄 For example, if we use DHCP as the signaling mechanism, the PRR must tell the DHCP server at least its IP range. The DHCP server then starts allocating IP addresses and port ranges to CPEs, and it tells the PRR back which IP and port range went to which CPE, so the PRR knows which tunnel to redirect incoming traffic to. On top of that, DHCP MUST also communicate the lifetimes of port ranges assigned to CPEs via the PRR. The DHCP server can be co-located with the PRR function to make address management easier and to avoid needing a communication protocol between the PRR and DHCP 🫶
If UPnPv2/NAT-PMP is used as the dynamic port allocation mechanism, the PRR also has to tell the DHCP (or IPCP) server to avoid those ports 🙅♀️ The PRR has to somehow (e.g., using DHCP or IPCP options) tell the CPE that the port allocation worked, so the CPE adds those ports to its existing port ranges ✨
One more thing, and it's a good one 🌈 The operation can be even simpler if a fixed length of port ranges is assigned to all customers and no differentiation is implemented based on port-range length. In that case, the binding table maintained by the PRR can be built dynamically as soon as it receives the first packet from a port-restricted device 💖
3.3.2. Address Realm ✨
okay so bestie, each gateway inside the A+P subsystem looks after its own little slice of A+P address space 🦋. That slice is a chunk of IPv4 space that gets stretched out by borrowing bits from the port number. It could even be just one single, port-restricted IPv4 address 🎀. A gateway MAY use its managed A+P address space for a couple of things:
- Handing a sub-portion of that space to other authenticated A+P gateways in the subsystem. This is called delegation 💅. The piece you hand out is called the delegated address space.
- Swapping (untranslated) packets with the external address realm 🌸. For this to work, those packets MUST use a source address and port from the non-delegated address space 😭.
If the gateway can also do the NAT function, it MAY translate packets coming in on an internal interface that sit outside its managed A+P address space, turning them into non-delegated address space 🫶.
So a provider can end up with little 'islands' of A+P as they roll it out bit by bit 🧚. They don't have to swap out every CPE all at once. They can give the A+P function to an island of users, or even to one single user chilling in a sea of non-A+P users 💜.
Here's the handshake 🤝. An A+P gateway ("A") accepts incoming connections from other A+P gateways ("B"). Once the connection is up (as long as the authentication checks out), B "asks" A for a delegation of an A+P address 🙈. Then A tells B its public IPv4 address and delegates a chunk of its port range to B 👑. A also negotiates the encaps/decaps function with B 🌈, like letting B know the address of the decaps device at the far end of the tunnel.
This could be done with something NAT-PMP-like or DHCP-like ✨. The general rule is this: a sub-portion of the managed A+P address space gets delegated as long as the devices below it ask for it 💖. If nobody asks, private IPv4 is handed out to keep legacy hosts happy 🍓.
The examples below use an IPv4 address from the blocks reserved for documentation, as defined in [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 ExampleFigure 3 shows a sample setup 🎀. Heads up: A might actually be three separate devices. One handles the signaling requests from B. One does the encapsulation and decapsulation. And, if there's one, another device does the NATing function (an LSN, for example) 🔥. Packets are assumed to flow like this: on the "outbound" side, a packet comes in from the private address realm to B. Like we said, B has two choices: it can apply the NAT function or skip it. That depends on the specific configuration and/or what A and B can do 🙈. NAT functionality is REQUIRED to support legacy hosts, but it can happen at either A or B 💅. The word "NAT" here means translating the packet into the managed A+P address (in the example above, B has address 192.0.2.1 and ports 2560-3071). After that, there are two options:
- B NATs the packet. The translated packet then gets tunneled to A. A notices the packet was already translated because the source address and port match the delegated space. A decapsulates it and releases it onto the public Internet 🌈.
- B does not NAT the packet. The untranslated packet gets tunneled to A. A sees that the packet hasn't been translated, so A forwards it to a co-located NATing device, which translates it and routes it onto the public Internet ✨. This device (an LSN, for example) MUST store the mapping between the source port used for NAT and the tunnel the packet came from, so it can route the reply correctly 💖. Heads up that A cannot use a port number from the range that was delegated to B 😭. So A has to assign part of its non-delegated address space to the NATing function 🫶.
"Inbound" packets get handled like this: a packet from the public realm arrives at A. A looks at the destination port number to figure out whether the packet needs NATing 👑.
- If the destination port number is in the range A delegated to B, then A tunnels the packet to B. B NATs the packet using its stored mapping and forwards the translated packet into the private domain 🦋.
- If the destination port number is from the address space of the LSN, then A passes the packet to the co-located LSN. The LSN uses its stored mapping to NAT the packet into B's private address realm 🧚. The appropriate tunnel also gets stored in the mapping of the initial NAT. The LSN then encapsulates the packet to B, which decapsulates it and normally routes it within its private realm 💜.
- Finally, if the destination port number falls in neither a delegated range nor the LSN's address range, A discards the packet 💀. If the packet gets passed to the LSN but no mapping can be found, the LSN discards it too 🙈.
Here's the important bit 🔥: A MUST be able to receive all IPv4 packets destined to the public IPv4 address (192.0.2.1 in the example), so it can make routing decisions based on the port number 👑. B, on the other hand, only receives IPv4 packets destined to the public IPv4 address through the established tunnel with A 🌸. In other words, B uses the public IPv4 address just for translation purposes. It is not used to make routing decisions 🎀. This keeps the routing logic at B as simple as described above, while still letting A+P devices that share the same public IPv4 address talk to each other seamlessly ✨.
private +-----+ +-----+ public
address ---| B |==========| A |--- Internet
realm 1 +-----+ +-----+
|
private +-----+ |
address ---| C |============/
realm 2 +-----+
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
Address space realm of C:
public IPv4 address = 192.0.2.1
port range = 0-2559
Figure 4: Hierarchical A+PCheck out Figure 4 🧚. Both B and C use the encaps/decaps function to set up a tunnel with A, and they've been given the same public IPv4 address with different, non-overlapping port ranges 💅. Say a host in B's private realm sends a packet to address 192.0.2.1 and port 2000, and B has been told to NAT all packets destined to 192.0.2.1 🫶. Under those assumptions, B gets the packet and NATs it using its own public IPv4 address (192.0.2.1) and a port picked from its configured port range (for example, 3000) 🌈. Then B tunnels the translated packet to A. When A gets the packet through the tunnel, it looks at the destination address and port, spots C's delegated range, and tunnels the packet to C 🔥. Notice that, apart from stripping the tunnel header, A handles the packet as if it came from the public Internet 👑. When C gets the packet, it NATs the destination address into one address chosen from its private address realm, while keeping the source address (192.0.2.1) and port (3000) untranslated 💖. Return traffic is handled the same way 🦋. This mechanism lets hosts behind A+P devices talk seamlessly, even when they share the same public IPv4 address 💜.
Please refer to Section 4 for a discussion of an alternative A+P mechanism that doesn't incur path-stretch penalties for intra-domain communication 🍓.
3.3.3. Reasons for Allowing Multiple A+P Gateways 🧚
okay so every device in an A+P subsystem does the encaps/decaps function, which means new devices can set up tunnels and become part of an A+P subsystem too 🫶. like we said before, being part of an A+P subsystem means you can talk to the external address realm with no translation at all. specifically, as in the previous section, device X in an A+P subsystem can be reached from the outside just by using the public IPv4 address and a port that was delegated to X. Figure 5 shows three devices chained together 🔗. so basically, A+P signaling can be used to extend end-to-end connectivity to the devices in an A+P subsystem. this lets A+P-aware applications (or OSes) running on end-hosts enter an A+P subsystem and use that untranslated connectivity, which is so iconic 💖
There are two modes where end-hosts get fine-grained control over end-to-end connectivity 👑. In the first, the actual end-hosts do the NAT function and the encaps/decaps function needed to join the A+P subsystem. this works kind of like the NAT-in-the-host trick that virtualization software such as VMware uses, where the guest operating system is connected via a NAT to the host operating system 💻. In the second mode, applications ask for an A+P address on their own and use it to join the A+P subsystem. this one is literally necessary for some apps that need end-to-end connectivity, like apps that need to be contacted from outside 🦋
+---------+ +---------+ +---------+
internal | gateway | | gateway | | gateway | external
realm --| 1 |======| 2 |======| 3 |-- realm
+---------+ +---------+ +---------+
Figure 5: An A+P Subsystem with Multiple DevicesWhatever the reasons, the Internet was built on the idea that end-to-end connectivity matters a lot 🌈. A+P keeps that possible even when address shortage forces ISPs to use NATs at various levels. in that sense, A+P can be seen as a way to bypass NATs ✨
+---+ (customer2)
|A+P|-. +---+
+---+ \ NAT|A+P|-.
\ +---+ |
\ | forward if in range
+---+ \+---+ +---+ /
|A+P|------|A+P|----|A+P|----
+---+ /+---+ +---+ \
/ NAT if necessary
/ (cust1) (prov. (e.g., provider NAT)
+---+ / router)
|A+P|-'
+---+
Figure 6: A Complex A+P SubsystemFigure 6 is the complicated one 😭. Here the A+P subsystem is made of multiple devices arranged in a hierarchy. Each A+P gateway decapsulates the packet and then re-encapsulates it into the next tunnel. it's giving layers 🧅
A packet can get NATed when it enters the A+P subsystem, at intermediate devices, or when it exits the A+P subsystem. For example, this could be a gateway installed inside the provider's network, together with an LSN. then each customer runs its own CPE. but behind the CPE, applications might also be A+P-aware and run their own A+P gateways, and that lets them have end-to-end connectivity 🎀
One limitation applies when "delayed translation" is used (e.g., translation at the LSN instead of the CPE). If devices using "delayed translation" want to talk to each other, they SHOULD use A+P addresses or out-of-band addressing. 🙈
3.3.4. Overall A+P Architecture 🌸
A+P architecture
IPv4 Full-A+P AFTR CGN
| | | |
<-- Full IPv4 ---- Port range ---- Port range ---- Provider --->
allocated & dynamic & LSN NAT ONLY
allocation (NAT on CPE (No mechanism)
(no NAT) (NAT on CPE) and on LSN) for customer to
bypass CGN)
Figure 7: A+P Overall ArchitectureThe A+P architecture covers a bunch of deployment options inside an ISP 🍓. Figure 7 shows the whole spectrum. On the far left is the most common setup for broadband subscribers today: an IPv4 address with the full port range, no restrictions. Full-A+P means a port-range allocation from the ISP. the customer has to run an A+P-aware CPE device, and the ISP doesn't provide any NATing functionality. The Address Family Transition Router (AFTR), such as DS-Lite [RFC6333], is kind of a hybrid 🦋. there is NAT in the core (called LSN in this document), but the user can "bypass" that NAT one way or another, for example via A+P, NAT-PMP, etc. Finally, a service provider that only deploys CGN puts a NAT in the provider's core and doesn't let the customer "bypass" the translation process or modify ALGs on the NAT. the customer is provider-locked 😤. Notice that every option (besides full IPv4) needs some form of tunneling mechanism (e.g., 4in6) and a signaling mechanism (see Section 3.3.1).
3.4. A+P Experiments 🧪
There are implementations of A+P as well as documented experiments. France Telecom ran experiments that are described in [A+P-EXPERIMENTS]. As that experiment showed, most tested applications are unaffected. the problems are with the torrent protocol and applications, since the listening port is outside the A+P port range, and some UPnP may be needed to make it work with A+P 🌧️
Problems with BitTorrent have already shown up in the wild for users trapped behind a non-UPnP-capable CPE. the current workaround for end-users is to statically map ports, which can also be done in the A+P scenario 💅
BitTorrent tests and experiments in shared IP and port-range environments are well described in [BITTORRENT-ADDR-SHARING]. the conclusions in that document tell us that two limitations were experienced. The first happened when two clients sharing the same IP address tried to retrieve the SAME file from a SINGLE remote peer at the same time. The second happened when a client tried to download a file from several seeders that shared the same IP address. Mutual file sharing between hosts with the same IP address has also been checked. Indeed, machines with the same IP address can share files with no alteration compared to current IP architectures 👯
Working implementations of A+P can be found in:
- Internet Systems Consortium AFTR (
http://www.isc.org/software/aftr), - FT Orange opensource A+P (
http://opensourceaplusp.weebly.com/) developed by Xiaoyu Zhao, Xiaohong Deng, Tao Zheng, and - 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
SMAP stands for Stateless A+P Mapping. This function is responsible for, in a stateless scheme, encapsulating IPv4 packets in IPv6 ones and decapsulating IPv4 packets from IPv6 ones. An SMAP function may be hosted in a PRR, an end-user device, etc. 💖
As mentioned in Section 4.1 of [RFC6052], the suffix part may enclose the port.
The Stateless A+P Mapping (SMAP) gateway consists of two basic functions, as shown in Figure 8 🧩.
- 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.
- 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.
+-------------------+
| |----IPv6---\
----IPv4---\| |----IPv4---\\
-----------/| |-----------//
| |-----------/
| SMAP |
| | /--IPv6-----
/---IPv4----| |//---IPv4----
\-----------| |\\-----------
| | \-----------
+-------------------+
Figure 8: Stateless A+P Mapping Gateway FunctionAn SMAP-enabled node will perform the stateless 6/4 mapping function for all public shared IPv4 addresses for which it was designated as a stateless 6/4 mapping gateway 🌈.
To perform the stateless 6/4 mapping function, an SMAP gateway must:
- be provided with an IPv6 prefix (i.e., Pref6). The SMAP gateway uses this prefix to construct IPv6 source addresses for all IPv4 shared addresses for which it was designated as an SMAP gateway. The IPv6 prefix may be provisioned statically or dynamically (e.g., DHCP).
- be able to know the IPv6 prefix of the node serving as another SMAP gateway for IPv4 destination addresses. This prefix may be known in various ways:
- Default or Well-Known Prefix (i.e.,
64:ff9b::/96) that was provisioned statically or dynamically; - Retained at the reception of incoming IPv4-in-IPv6 encapsulated packets;
- Discovered at the start of communication, thanks to mechanisms such as DNS resolution, for example.
- Default or Well-Known Prefix (i.e.,
When the SMAP-enabled node receives IPv4 packets with IPv4 source addresses for which it was not designated as an smap gateway, it will not perform the stateless 6/4 mapping function for those packets. Those packets will be handled in a classical way (i.e., forwarded, dropped, or locally processed). 🙅♀️
When the SMAP-enabled node receives IPv6 packets with IPv6 addresses that do not match its IPv6 prefix, it will not perform the stateless 6/4 mapping function for those packets. Those packets will be handled in a classical way (i.e., forwarded, dropped, or locally processed). 💜
4.2. Implementation Mode ✨
okay so in this setup, node A runs the stateless mapping function on incoming IPv4 traffic (wrapped up inside IPv6 packets) before it goes to node B 🎀 Node B then runs the stateless mapping function on that IPv6 traffic, unwrapping the IPv4 packets, and forwards the IPv4 traffic to whatever destination is identified by the IPv4 destination address and port number. 💅
Going the other way, and same as before, node B runs the stateless mapping function on incoming IPv4 traffic, encapsulating it in IPv6 packets, before sending it to node A. Node A runs the stateless mapping function on that IPv6 traffic (extracting the IPv4 packets) and then forwards the IPv4 traffic to the point identified by the IPv4 destination address and port number. 🦋 The main thing to know is that only IPv6 traffic is managed on the network segment between nodes A and B. Iconic. 👑
+------+ +------+
| |----IPv6---\ | |
----IPv4---\| |----IPv4---\\| |----IPv4---\
-----------/| |-----------//| |-----------/
| |-----------/ | |
| SMAP | | SMAP |
| | /----IPv6---| |
/---IPv4----| |//---IPv4----| |/---IPv4----
\-----------| |\\-----------| |\-----------
| | \-----------| |
+------+ +------+
node A node B
Figure 9Figure 9
Several deployment scenarios for the SMAP function can be imagined in the context of port-range-based solutions. 🌸
- An SMAP function is embedded in a port-restricted device. Other SMAP-enabled nodes sit at the boundaries between IPv6-enabled realms and IPv4 ones. This scenario may be deployed particularly for intra-domain communications, so that heterogeneous realms (i.e., IPv6/IPv4) within the same Autonomous System (AS) can be interconnected. 🧚
- An SMAP function is embedded in a port-restricted device. Other SMAP-enabled nodes are deployed in the interconnection segment (with adjacent IPv4-only ones) of a given AS. This is a better fit for service providers aiming to deploy IPv6, since it eases the migration to full IPv6. Core nodes are not required to keep both IPv4 and IPv6 transfer capabilities turned on. 🍓
Other considerations about interconnecting SMAP-enabled domains should be elaborated. What follows is a non-exhaustive list of interconnection schemes. 💜
- The interconnection of two domains implementing the SMAP function may be deployed over the IPv4 Internet (Figure 10). This means IPv4 packets encapsulated in IPv6 packets travel over IPv6 until they reach the first SMAP-enabled node. There, they are decapsulated and forwarded using IPv4 transfer capabilities. A remote SMAP-enabled node receives those packets and performs an IPv4-in-IPv6 encapsulation. The packets are then routed normally until they reach the port-restricted devices that decapsulate them. 🌈
+------+ +------+ +--------+ +------+ +------+
| |--IPv6--\ | | | | | |---IPv6--\ | |
| |--IPv4--\\| |---|-IPv4---|--\| |---IPv4--\\| |
| |--------//| |---|--------|--/| |---------//| |
| |--------/ | | |Internet| | |---------/ | |
| SMAP | | SMAP | | IPv4 | | SMAP | | SMAP |
| | /--IPv6--| | | | | | /---IPv6--| |
| |//--IPv4--| |/--|-IPv4---|---| |//--IPv4---| |
| |\\--------| |\--|--------|---| |\\---------| |
| | \--------| | | | | | \---------| |
+------+ +------+ +--------+ +------+ +------+
Source node A node B DestinationFigure 10: Interconnection Scenario 1
- A second scheme uses IPv6 to interconnect two realms that implement the SMAP function (Figure 11). An IPv6 prefix (i.e., Pref6) assigned by IANA is used for this service. With appropriate routing configurations in place, the IPv6-encapsulated packets are routed all the way to the final destination. 🛤️ To make this model work, IPv4-inferred IPv6 prefixes are required to be injected into the IPv6 inter-domain routing tables.
+------+ +------------+ +------+
| | | | | |
| |----IPv6-----|----IPv6----|----IPv6----\ | |
| |----IPv4-----|------------|----IPv4----\\| |
| |-------------|------------|------------//| |
| |-------------|------------|------------/ | |
| SMAP | | Internet v6| | SMAP |
| | /-----IPv6--|------------|-----IPv6-----| |
| |//---IPv4----|------------|-------IPv4---| |
| |\\-----------|------------|--------------| |
| | \-----------|------------|--------------| |
| | | | | |
+------+ +------------+ +------+
Source DestinationFigure 11: Interconnection Scenario 2
4.3. Towards IPv6-Only Networks
Rolling out the SMAP function lets networks migrate smoothly to an IPv6-only setup while still delivering IPv4 connectivity to customers. 🦋 Delivering IPv4 connectivity over an IPv6-only network doesn't need any stateful function on the core network. Because of this, A+P mode keeps IPv4 service continuous and makes the move to an IPv6-only model much easier. 🫶
4.4. PRR: On Stateless and Binding Table Modes
The SMAP section (Section 4) talks about two modes: the binding mode and the stateless mode. Dynamic port allocation isn't 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. 🙈
- Stateless Mode: Complete stateless mapping means the IPv4 address and the significant bits that code the port range are reflected inside the IPv6 prefix assigned to the port-restricted device. This can be done 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 a stateless mapping is to be enabled:
- use the IPv6 prefix already used for native IPv6 traffic, or
- provide two prefixes to the port-restricted device: one for the native IPv6 traffic and one for the IPv4 traffic.
Note that:
- Providing two IPv6 prefixes is great because it allows a /64 prefix for the port-restricted device along with another prefix (e.g., a /56 or /64) for native IPv6 traffic. This option lets the service provider line up the native IPv6 addressing plan with the IPv4 addressing plan. The downside is having to allocate two prefixes to each port-restricted device and route them both. On top of that, an address selection issue may come up. 😭
- Providing one prefix for both needs (e.g., a /56 or a /64) lets the service provider handle two types of IPv6 prefix for the port-restricted device, both in routing tables. But the drawback is that it tightly links the IPv4 addressing plan to the allocated IPv6 prefixes. 💀
As mentioned in Section 4.1 of [RFC6052], the suffix part may enclose the port.
- Binding Table Mode: Another option is to assign a "normal" IPv6 prefix to the port-restricted device and use a binding table. That table can be hosted by a service node and correlates 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 close to the port-restricted devices. If it's hosted at the interconnection segment, the number of required entries would equal the number of subscribed users (one per port-restricted device). 🌸
4.5. General Recommendations on SMAP
If a Stateless A+P Mapping (SMAP) type of implementation is deployed over intermediate IPv6-only-capable devices, it is recommended that default routes are configured, and that the IPv4 routing table is not "leaked" into the IPv6 routing table in terms of having reachability for packets heading towards the Internet. 🧚
One of the stateless A+P variants is 4rd [4rd]. ✨
5. Deployment Scenarios 🎀
5.1. A+P Deployment Models
5.1.1. A+P for Broadband Providers
Some large broadband providers won't have enough public IPv4 address space to give every customer a single IP address. 😭 The natural fix is sharing one IP address among many customers. Multiplexing customers is usually done by allocating different port numbers to different customers somewhere inside the provider's network. 🌈
When the provider wants to enable A+P for a customer or a range of customers, the CPE can be upgraded or replaced to support A+P encaps/decaps functionality. Ideally, the CPE also provides NATing functionality. It's also expected that at least one other component in the ISP network provides the matching A+P functionality, so it can set up an A+P subsystem with the CPE. This device is called an A+P router or Port-Range Router (PRR), and it could sit close to PE routers. The core of the network MUST support the tunneling protocol (which SHOULD be IPv6, as per Constraint 7), but MAY use another tunneling technology when necessary. 👑 We also don't want to shut down any initiative from customers who might want to run an A+P-capable network on or behind their CPE. 💖
To satisfy both Constraints 1 and 2, unmodified legacy hosts should keep working seamlessly, while upgraded or new end-systems should get the chance to use enhanced features. 🫶 Main character energy for the whole network, honestly. 💅
5.1.2. A+P for Mobile Providers 📱
okay so mobile providers are a little different, bestie 🫶 The A+P border is assumed to be the gateway (e.g., Gateway GPRS Support Node (GGSN) / Packet Data Network (PDN) gateway (GW) of 3GPP, or Access Service Network (ASN) GW of Worldwide Interoperability for Microwave Access (WiMAX)). The need to extend the address is not within the provider network, but on the edge between the mobile phone devices and the gateway. While desirable, IPv6 connectivity may or may not be provided.
For mobile providers, we use the following terms and assumptions:
- provider network (PN)
- gateway (GW)
- mobile phone device (phone)
- devices behind the phone, e.g., laptop computer connecting via phone to Internet
We expect that the gateway has a pool of IPv4 addresses and is always in the data-path of the packets. Transport between the gateway and phone devices is assumed to be an end-to-end layer-2 tunnel. We assume that the phone as well as gateway can be upgraded to support A+P. However, some applications running on the phone or devices behind the phone (such as laptop computers connecting via the phone) are not expected to be upgraded. Again, while we do not expect that devices behind the phone will be A+P-aware or upgraded, we also do not want to hinder their evolution. In this sense, the mobile phone would be comparable to the CPE in the broadband provider case; it would be the gateway to the PRR/LSN box in the network of the broadband provider. 🌸
5.1.3. A+P from the Provider Network Perspective 🧚
ISPs suffering from IPv4 address space exhaustion are interested in achieving a high address space compression ratio. In this respect, an A+P subsystem allows much more flexibility than traditional NATs: the NAT can be placed at the customer and/or in the provider network. In addition, hosts or applications can request ports and thus have untranslated end-to-end connectivity. 💅
+---------------------------+
private | +------+ A+P-in +-----+ | dual-stacked
(RFC 1918) --|-| CPE |==-IPv6-==| PRR |-|-- network
space | +------+ tunnel +-----+ | (public addresses)
| ^ +-----+ |
| | IPv6-only | LSN | |
| | network +-----+ |
+----+----------------- ^ --+
| |
on customer within provider
premises and control networkFigure 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 CPE or at the LSN. In order to establish the A+P subsystem, the CPE will be configured automatically (e.g., via a signaling protocol that conforms to the requirements stated above). 🎀
Note that the CPE in the example above is provisioned with only an IPv6 address on the external interface.
+------------ IPv6-only transport ------------+
| +---------------+ | | |
| |A+P-application| | +--------+ | +-----+ | dual-stacked
| | on end-host |=|==| CPE w/ |==|==| PRR |-|-- network
| +---------------+ | +--------+ | +-----+ | (public addresses)
+---------------+ | +--------+ | +-----+ |
private IPv4 <-*--+->| NAT | | | LSN | |
address space \ | +--------+ | +-----+ |
for legacy +|--------------|----------+
hosts | |
| |
end-host with | CPE device | provider
upgraded | on customer | network
application | premises |Figure 13: An Extended A+P Subsystem with End-Host Running A+P-Aware Applications
Figure 13 shows an example of how an upgraded application running on a legacy end-host can connect to another host in the public realm. The legacy host is provisioned with a private IPv4 address allocated by the CPE. Any packet sent from the legacy host will be NATed either at the CPE (if configured to do so) or at the LSN (if available). ✨
An A+P-aware application running on the end-host MAY use the signaling described in 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 in that part of the topology MUST support NAT functionality. For reasons of scalability, it is assumed that the PRR is located within the access portion of the network. The CPE would be configured automatically (e.g., via an extended DHCP or NAT-PMP, which has the signaling requirements stated above) with the address of the PRR and of the LSN (if one is being provided). Figure 12 illustrates a possible deployment scenario. 🌈
5.2. Dynamic Allocation of Port Ranges 🎀
Allocating a fixed number of ports to all CPEs may lead to exhaustion of ports for high-usage customers. This is a perfect recipe for upsetting more demanding customers. On the other hand, allocating to all customers ports sufficiently to match the needs of peak users will not be very efficient. A mechanism for dynamic allocation of port ranges allows the ISP to achieve two goals: a more efficient compression ratio of the number of customers on one IPv4 address and, on the other hand, no limit of the more demanding customers' communication. 👑
Additional allocation of ports or port ranges may be made after an initial static allocation of ports.
The mechanism would prefer allocations of port ranges from the same IP address as the initial allocation. If it is not possible to allocate an additional port range from the same IP, then the mechanism can allocate a port range from another IP within the same subnet. With every additional port range allocation, the PRR updates its routing table. The mechanism for allocating additional port ranges may be part of normal signaling that is used to authenticate the CPE to the ISP.
The ISP controls the dynamic allocation of port ranges by the PRR by setting the initial allocation size and maximum number of allocations per CPE, or the maximum allocations per subscription, depending on subscription level. There is a general observation that the more demanding customer uses around 1024 ports when heavily communicating. So, for example, a first suggestion might be 128 ports initially and then dynamic allocations of ranges of 128 ports up to 511 more allocations maximum. A configured maximum number of allocations could be used to prevent one customer acting in a destructive manner should they become infected. The maximum number of allocations might also be more finely grained, with parameters of how many allocations a user may request per some time frame. If this is used, evasive applications may need to be limited in their bad behavior; for example, one additional allocation per minute would considerably slow a port request storm. 🙅♀️
There is likely no minimum request size. This is because A+P-aware applications running on end-hosts MAY request a single port (or a few ports) for the CPE to be contacted on (e.g., Voice over IP (VoIP) clients register a public IP and a single delegated port from the CPE, and accept incoming calls on that port). The implementation on the CPE or PRR will dictate how to handle such requests for smaller blocks: for example, half of available blocks might be used for "block-allocations", 1/6 for single port requests, and the rest for NATing. 📞
Another possible mechanism to allocate additional ports is UPnP/NAT-PMP (as defined in 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 ✨
okay bestie, this section walks through a whole A+P setup 💖 It follows one packet from an end-host on an A+P service provider's network to any host on the IPv4 Internet, then shows how the replies find their way back 🦋 The example uses an A+P-unaware end-host, where the NATing happens at the CPE. Figure 14 shows how the CPE gets an IPv4 packet from the end-user device 🎀 First up is the case where the CPE has been set up to do the NAT itself, either because the customer configured it through a website or because of automatic signaling. We're going to call a packet that gets translated at the CPE an "A+P-forwarded packet" 🌸 It's an analogy to the port-forwarding that today's CPEs already do, so it's giving familiar vibes. When the CPE gets a packet from the internal interface, it translates the packet, encapsulates it, and forwards it to the PRR. The NAT on the CPE is assumed to have a default route to the public realm through its tunnel interface 🧚
When the PRR gets the A+P-forwarded packet, it decapsulates the inner IPv4 packet and checks the source address. If the source address falls within the range assigned to A+P-enabled CPEs, the PRR just forwards the decapsulated packet onward 💅 This is always the case for A+P-forwarded packets. Otherwise, the PRR assumes the packet isn't A+P-forwarded and hands it to the LSN function, which translates the packet and forwards it based on the destination address. Figure 14 shows the packet flow for an outgoing A+P-forwarded packet 👑
+-----------+
| Host |
+-----+-----+
| | 198.51.100.2
IPv4 datagram 1 | |
| |
v | 198.51.100.1
+---------|---------+
|CPE | |
+--------|||--------+
| ||| 2001:db8::2
| ||| 192.0.2.3 (100-200)
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6
| |||
-----|-|||-------
/ | ||| \
| ISP access network |
\ | ||| /
-----|-|||-------
| |||
v ||| 2001:db8::1
+--------|||--------+
|PRR ||| |
+---------|---------+
| | 192.0.2.1
IPv4 datagram 3 | |
-----|--|--------
/ | | \
| ISP network / |
\ Internet /
-----|--|--------
| |
v | 203.0.113.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 14: Forwarding of Outgoing A+P-Forwarded Packets +-----------------+--------------+-----------------------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------------------+
| IPv4 datagram 1 | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 198.51.100.2 |
| | TCP Dst | 80 |
| | TCP Src | 8000 |
| --------------- | ------------ | --------------------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8::1 |
| | IPv6 Src | 2001:db8::2 |
| | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 192.0.2.3 |
| | TCP Dst | 80 |
| | TCP Src | 100 |
| --------------- | ------------ | --------------------------- |
| IPv4 datagram 3 | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 192.0.2.3 |
| | TCP Dst | 80 |
| | TCP Src | 100 |
+-----------------+--------------+-----------------------------+
Datagram Header ContentsNow the reverse trip 🔄 An incoming packet goes through the mirror-image process. When the PRR gets an IPv4 packet on an external interface, it first checks whether the destination address falls within the A+P CPE delegated range. If the address space was delegated, the PRR encapsulates the incoming packet and sends it through the right tunnel for that IP/port range 🫶 If the address space wasn't delegated, the packet goes to the LSN to check whether a mapping exists.
Figure 15 shows how an incoming packet gets forwarded, assuming the port number matches the port range that was delegated to the CPE 🌈
+-----------+
| Host |
+-----+-----+
^ | 198.51.100.2
IPv4 datagram 3 | |
| |
| | 198.51.100.1
+---------|---------+
|CPE | |
+--------|||--------+
^ ||| 2001:db8::2
| ||| 192.0.2.3 (100-200)
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6
| |||
-----|-|||-------
/ | ||| \
| ISP access network |
\ | ||| /
-----|-|||-------
| |||
| ||| 2001:db8::1
+--------|||--------+
|PRR ||| |
+---------|---------+
^ | 192.0.2.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| ISP network / |
\ Internet /
-----|--|--------
| |
| | 203.0.113.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 15: Forwarding of Incoming A+P-Forwarded Packets +-----------------+--------------+-----------------------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------------------+
| IPv4 datagram 1 | IPv4 Dst | 198.51.100.3 |
| | IPv4 Src | 203.0.113.1 |
| | TCP Dst | 100 |
| | TCP Src | 80 |
| --------------- | ------------ | --------------------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8::2 |
| | IPv6 Src | 2001:db8::1 |
| | IPv4 Dst | 198.51.100.3 |
| | IP Src | 203.0.113.1 |
| | TCP Dst | 100 |
| | TCP Src | 80 |
| --------------- | ------------ | --------------------------- |
| IPv4 datagram 3 | IPv4 Dst | 198.51.100.2 |
| | IPv4 Src | 203.0.113.1 |
| | TCP Dst | 8000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------------------+
Datagram Header ContentsLowkey the best part: datagram 1 travels untranslated all the way up to the CPE 💜 So the customer keeps the same control over translation that they have today, which is basically a home gateway with customizable port-forwarding 🍓
5.3.1. Forwarding of Standard Packets
Packets with no matching port-forwarding rule on the CPE get tunneled to the PRR that provides the LSN function 🦋 I need to underline this one: the LSN MUST NOT use the delegated space for NATing 🚫 For network diagrams showing the packet flow in this case, check out [RFC6333] 💅
5.3.2. Handling ICMP
ICMP is a problem for all NATs because it has no port numbers 😭 A+P routing makes it even messier.
Most ICMP messages fall into one of two categories: error reports, or ECHO/ECHO replies (the ones commonly called "pings") 🙈 For error reports, the offending packet header is embedded inside the ICMP packet. NAT devices can rewrite that portion and route the packet to the actual destination host. This still works the same with A+P, except the PRR needs to look at the embedded header to pull out the port number, while the A+P gateway does the rewriting 🔥
ECHO and ECHO replies are the messier ones 💀 For ECHO, the A+P gateway device has to rewrite the "Identifier" and perhaps the "Sequence Number" fields in the ICMP request, treating them as if they were port numbers. That way, the PRR can build the correct A+P address for the returning ECHO replies, so they get routed back to the right host just like TCP/UDP packets 🧚 Pings that come from the public realm (Internet) toward an A+P device are not supported ❌
5.3.3. Fragmentation
To deliver a fragmented IP packet to its final destination (among those sharing the same IP address), the PRR should activate a dedicated procedure similar to the one in [RFC6146], Section 3.5. It works in the sense that the PRR should reassemble the fragments so it can look at the destination port number ✨
It is recommended to use a Path MTU Discovery (PMTUD) mechanism (e.g., [RFC1191]) 🌸
Security issues related to fragmentation are out of scope for this document. For more details, refer to [RFC1858] 🔐
5.3.4. Limitations of the A+P Approach 🙈
Okay, real talk, A+P has a limitation it shares with every IP-address-sharing mechanism: the well-known ports. Customers who share one IP address get told apart by their port numbers, so two customers on the same shared IP cannot both run a service on the same port (like port 80) 😭. Working around that usually means application-specific hacks, like HTTP and HTTPS redirection, and those are out of scope for this document. 🫶
A provider might charge extra to give a customer the well-known port range, 0..1024, so the customer can host externally available services. 💰 Lots of apps need well-known ports, but they aren't expected to work in an A+P environment unless they can adapt to use different ports. And honestly? Those same apps don't work behind today's NATs either, so this isn't a new drama. 💅
Another problem every NAT has is playing nicely with IPsec. A NAT that also translates port numbers stops the Authentication Header (AH) and Encapsulating Security Payload (ESP) from working properly, in both tunnel mode and transport mode. 😬 The good news is that an A+P subsystem acts externally just like a NAT, so the well-known workarounds, like the ones in [RFC3715], can be used. ✨
A+P, like every other port-sharing solution, has the issues written up in [RFC6269]. Sigh. That's something we'll just have to live with. 🥲
For host-based A+P, the issues with apps trying to bind to an out-of-range port still need to be looked at further. 🔍 Extensions to the host-based model have been proposed before, for example the Port-Enhanced Address Resolution Protocol (ARP) extension documented at http://software.merit.edu/pe-arp/. 🧚
5.3.5. Port Allocation Strategy Agnostic 🎀
The issues raised in [PR-IP-ISSUES] were analyzed in [STATELESS-4v6]. As that document shows, most of those issues apply to host-based port-sharing solutions. A+P is not meant to be a host-based port-sharing solution, so that's a different vibe entirely. 🦋
The conclusion of [STATELESS-4v6] is that the issues specifically attributed to A+P either don't apply to CPE-based flavors or can be mitigated. 👑 A+P is a reasonable trade-off compared to the alternatives in areas like binding logging (for data storage purposes) and ease of deployment and operations. All of those are actually made easier by this approach. 🌈
6. Security Considerations 🚨
Okay, this one is serious, bestie. With CGNs/LSNs, tracing hackers, spammers, and other criminals is going to be really hard, because you'd need to log, record, and store all of the connection-based mapping information. 😱 That storage requirement is a trade-off. On one hand, LSNs can manage addresses and ports as dynamically as possible to maximize aggregation. On the other hand, the faster the mapping between private and public space changes, the more information has to be recorded. That worries law enforcement and privacy advocates alike. 🙈
A+P has a better set of trade-offs. All that needs to be logged is the allocation of a range of port numbers to a customer. By design, that happens rarely, which helps scalability. ✨ If the NAT functionality is moved further up the tree, the logging requirement moves up with it. That increases the load on one node, but it also gives that node more resources to allocate to a busy customer, which might lower how often allocation requests happen. 🧠
The other extreme is A+P NAT on the customer premises. A node like that would be no different from today's NAT boxes, which don't do this kind of logging. 📦
So, our conclusion: A+P is no worse than today's situation, and it's considerably better than CGNs. 💖
7. Acknowledgments 🫶
The authors especially want to thank Remi Despres and Pierre Levis for helping develop the A+P approach. 🌸 They also thank David Ward for reviewing it, giving constructive criticism, and asking interminable questions, and Dave Thaler for useful criticism on "stackable" A+P gateways. 💅 Finally, they'd like to thank the following people for their feedback on earlier versions of this work: Rob Austein, Gert Doering, Dino Farinacci, Russ Housley, Ruediger Volk, Tina Tsou, and Pasi Sarolahti. 💜
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.8.2. Informative References
[4rd] Despres, R., Matsushima, S., Murakami, T., and O. Troan,
"IPv4 Residual Deployment across IPv6-Service networks
(4rd) ISP-NAT's made optional", Work in Progress,
March 2011.
[A+P-EXPERIMENTS]
Deng, X., Boucadair, M., and F. Telecom, "Implementing A+P
in the provider's IPv6-only network", Work in Progress,
March 2011.
[BCP38] 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.
[BITTORRENT-ADDR-SHARING]
Boucadair, M., Grimault, J., Levis, P., and A.
Villefranque, "Behavior of BitTorrent service in an IP
Shared Address Environment", Work in Progress, March 2011.
[PCP-BASE]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", Work in Progress,
July 2011.
[PORT-RANGE-OPT]
Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
T. ZOU), "Huawei Port Range Configuration Options for PPP
IPCP", Work in Progress, June 2011.
[PR-ADDR-ASSIGN]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment", Work in Progress,
September 2010.
[PR-IP-ISSUES]
Thaler, D., "Issues With Port-Restricted IP Addresses",
Work in Progress, February 2010.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[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.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, 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 🌷
This document has nine primary authors. 🥰
Gabor Bajko
Nokia
EMail: gabor.bajko@nokia.com
Mohamed Boucadair
France Telecom
3, Av Francois Chateaux
Rennes 35000
France
EMail: mohamed.boucadair@orange-ftgroup.co
Steven M. Bellovin
Columbia University
1214 Amsterdam Avenue
MC 0401
New York, NY 10027
US
Phone: +1 212 939 7149
EMail: bellovin@acm.org
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington 98110
US
Phone: +1 206 780 0431 x1
EMail: randy@psg.com
Luca Cittadini
Universita' Roma Tre
via della Vasca Navale, 79
Rome, 00146
Italy
Phone: +39 06 5733 3215
EMail: luca.cittadini@gmail.com
Olaf Maennel
Loughborough University
Department of Computer Science - N.2.03
Loughborough
United Kingdom
Phone: +44 115 714 0042
EMail: o@maennel.net
Reinaldo Penno
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, California 94089
US
EMail: rpenno@juniper.net
Teemu Savolainen
Nokia
Hermiankatu 12 D
TAMPERE, FI-33720
Finland
EMail: teemu.savolainen@nokia.com
Jan Zorz
Go6 Institute Slovenia
Frankovo naselje 165
Skofja Loka, 4220
Slovenia
EMail: jan@go6.siEditor's Address ✨
Randy Bush (editor)
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington 98110
US
Phone: +1 206 780 0431 x1
EMail: randy@psg.comThat's the whole thing, bestie! 🌈💖 RFC 6346 is officially wrapped. Literally iconic. 👑
📦 where this page comes from
- ietf: rfc6346 2011-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms