RFC 7599
Mapping of Address and Port using Translation (MAP-T)
RFC 7599: Mapping of Address and Port using Translation (MAP-T) 🦋
okay bestie, this one is a whole vibe ✨ Here's the title block tea 🫖:
- Category: Standards Track, so this is an Internet Standards Track document 👑
- Date: July 2015 📅
- ISSN: 2070-1721 🔢
- Authors: X. Li, C. Bao (Tsinghua University), W. Dec (Ed.), O. Troan (Cisco Systems), S. Matsushima (SoftBank Telecom), and T. Murakami (IP Infusion) 🧚
- Obsoletes / Updates: the title block doesn't list any, so this doc doesn't obsolete or update anything 🙈
The RFC number is 7599 and it's published by the IETF 💖
Abstract
bestie, this doc lays out the solution architecture built on the "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) approach 🌸. The goal is to give shared or non-shared IPv4 address connectivity to and across an IPv6 network, so everyone gets online ✨
Status of This Memo
okay so the status part says this is an Internet Standards Track document 🎀. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 💅. If you want more on Internet Standards, check Section 2 of RFC 5741 📚.
For info on the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7599 🔗
Copyright Notice
Copyright (c) 2015 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 cover 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 they're provided without warranty as described in the Simplified BSD License ⚠️
Table of Contents
1. Introduction ....................................................4
2. Conventions .....................................................4
3. Terminology .....................................................5
4. Architecture ....................................................6
5. Mapping Rules ...................................................8
5.1. Destinations outside the MAP Domain ........................8
6. The IPv6 Interface Identifier ...................................9
7. MAP-T Configuration ............................................10
7.1. MAP CE ....................................................10
7.2. MAP BR ....................................................11
8. MAP-T Packet Forwarding ........................................11
8.1. IPv4 to IPv6 at the CE ....................................11
8.2. IPv6 to IPv4 at the CE ....................................12
8.3. IPv6 to IPv4 at the BR ....................................12
8.4. IPv4 to IPv6 at the BR ....................................13
9. ICMP Handling ..................................................13
10. Fragmentation and Path MTU Discovery ..........................14
10.1. Fragmentation in the MAP Domain ..........................14
10.2. Receiving IPv4 Fragments on the MAP Domain Borders .......14
10.3. Sending IPv4 Fragments to the Outside ....................14
11. NAT44 Considerations ..........................................15
12. Usage Considerations ..........................................15
12.1. EA-Bit Length 0 ..........................................15
12.2. Mesh and Hub-and-Spoke Modes .............................15
12.3. Communication with IPv6 Servers in the MAP-T Domain ......15
12.4. Compatibility with Other NAT64 Solutions .................16
13. Security Considerations .......................................16
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................18
Appendix A. Examples of MAP-T Translation .........................21
Appendix B. Port-Mapping Algorithm ................................24
Acknowledgements ..................................................25
Contributors ......................................................25
Authors' Addresses ................................................261. Introduction 🌷
okay so early service provider IPv6 rollouts, like the one described in [RFC6219], show that you can move to IPv6 while still supporting legacy IPv4 users, and you don't need a full end-to-end dual-IP-stack deployment to do it 💖. The catch is that public IPv4 address exhaustion means you need an IPv6 technology that supports IPv4 users on shared IPv4 addressing, and that also lets the operator run things around IPv6 network practices 🧠. Double NAT64 translation-based solutions are an optimal way to handle this, especially when you pair them with stateless translation techniques that cut down the operational challenges listed in [Solutions-4v6] 🔥
The Mapping of Address and Port using Translation (MAP-T) architecture in this document is exactly that kind of double stateless NAT64-based solution 👑. It builds on the existing stateless NAT64 techniques in [RFC6145], plus the stateless algorithmic address and transport-layer port-mapping scheme from the Mapping of Address and Port with Encapsulation (MAP-E) spec in [RFC7597] 🧚. The big difference from MAP-E is that MAP-T uses IPv4-IPv6 translation, not encapsulation, as the way traffic crosses the IPv6 domain 🦋. Translation is the better pick when encapsulation overhead, or IPv6 operational practices (for example, using IPv6-only servers, or relying on IPv6 + protocol headers for traffic classification), rule encapsulation out 🙈. Those scenarios are covered in [MAP-T-Use-Cases] 📚
2. Conventions 💅
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] 🎀
3. Terminology 📖
Let's go through the vocab, bestie, because every term here matters 💜
MAP-T: Mapping of Address and Port using Translation.
MAP Customer Edge (CE): A device acting as a Customer Edge router in a MAP deployment. A typical MAP CE that adopts MAP Rules serves a residential site with one WAN-side IPv6-addressed interface and one or more LAN-side interfaces addressed using private IPv4 addressing 🏠
MAP Border Relay (BR): A MAP-enabled router, managed by the service provider, sitting at the edge of a MAP domain. A BR has at least an IPv6-enabled interface and an IPv4 interface connected to the native IPv4 network. Within MAP, a MAP BR may also be called simply a "BR" 🌐
MAP domain: One or more MAP CEs and BRs connected over an IPv6 network and sharing a common set of MAP Rules. A service provider may deploy a single MAP domain or use multiple MAP domains 🧁
MAP Rule: A set of parameters describing the mapping between an IPv4 prefix, an IPv4 address, or a shared IPv4 address, and an IPv6 prefix or address. Each MAP domain uses a different mapping rule set ✨
MAP rule set: A rule set is made up of all the MAP Rules communicated to a device that determine that device's IP+port mapping and forwarding operations. This doc uses "MAP rule set" interchangeably with "MAP rule table" or just "rule table". Two specific types of rules, the Basic Mapping Rule (BMR) and the Forwarding Mapping Rule (FMR), are defined in Section 5 of [RFC7597]. The Default Mapping Rule (DMR) is defined in this document 🌸
MAP rule table: See MAP rule set.
MAP node: A device that implements MAP 💖
Port set: Each node has its own part of the transport-layer port space, and this part is called a port set 🦋
Port Set ID (PSID): Algorithmically identifies a set of ports exclusively assigned to a CE 🔢
Shared IPv4 address: An IPv4 address shared among multiple CEs. Only ports that belong to the assigned port set can be used for communication. This is also known as a port-restricted IPv4 address 🫶
End-user IPv6 prefix: The IPv6 prefix given to an End-user CE by means other than MAP itself. For example, it can be provisioned using DHCPv6 Prefix Delegation (PD) [RFC3633], assigned via Stateless Address Autoconfiguration (SLAAC) [RFC4862], or configured manually. It's unique for each CE 🌈
MAP IPv6 address: The IPv6 address used to reach the MAP function of a CE from other CEs and from BRs 🧚
Rule IPv6 prefix: An IPv6 prefix assigned by a service provider for a MAP Rule 👑
Rule IPv4 prefix: An IPv4 prefix assigned by a service provider for a MAP Rule 🍓
Embedded Address (EA) bits: The IPv4 EA-bits in the IPv6 address identify an IPv4 prefix/address (or part of one) or a shared IPv4 address (or part of one), along with a Port Set Identifier 💜
4. Architecture ✨
okay bestie, so Figure 1 is the big picture of MAP-T 🦋. It shows a bunch of privately addressed IPv4 users (N and M) hooking up through MAP-T CEs to an IPv6 network that has one or more MAP-T BRs. CEs and BRs that share the same MAP configuration parameters (called "MAP Rules") form a MAP-T domain 💜.
Here's the vibe: the MAP-T CE and BR borrow some well-established building blocks and level them up so IPv4 users can talk to nodes on the public IPv4 network or on the IPv6 network. The main pieces are:
- A (NAT44) Network Address and Port Translation (NAPT) [RFC2663] function on a MAP CE gets an upgrade. It can now restrict which TCP/UDP ports are allowed for a given IPv4 address. The IPv4 address and port range come from the MAP provisioning process and are identical to MAP-E [RFC7597] 🎀.
- A stateless NAT64 function [RFC6145] gets extended so it can statelessly map IPv4 and transport-layer port ranges into the IPv6 address space ✨.
User N
Private IPv4
| Network
|
O--+---------------O
| | MAP-T CE |
| +-----+--------+ |
| NAPT44| MAP-T | |
| +-----+ | +-._ ,-------. .------.
| +--------+ | ,-' `-. ,-' `-.
O------------------O / \ O---------O / Public \
/ IPv6-only \ | MAP-T |/ IPv4 \
( Network --+ Border +- Network )
\ / | Relay |\ /
O------------------O \ / O---------O \ /
| MAP-T CE | ;". ,-' `-. ,-'
| +-----+--------+ | ," `----+--' ------'
| NAPT44| MAP-T | |, |
| +-----+ | + IPv6 node(s)
| | +--------+ | (with IPv4-embedded IPv6 address)
O---+--------------O
|
User M
Private IPv4
Network
Figure 1: MAP-T ArchitectureEach MAP-T CE gets a regular IPv6 prefix from the operator's IPv6 network 🌸. Combine that with the MAP domain configuration settings and the MAP procedures, and you can compute a MAP IPv6 address plus a matching IPv4 address. Want IPv4 address sharing? The CE may also need a TCP/UDP port range, identified by a MAP Port Set Identifier (PSID) value 💅. Each CE is in charge of forwarding traffic between a user's private IPv4 address space and the MAP domain's IPv6 address space. The IPv4-IPv6 adaptation uses stateless NAT64, plus the MAP algorithm for address computation. Lowkey genius 🧚.
The MAP-T BR connects one or more MAP-T domains to external IPv4 networks using stateless NAT64, as extended by the MAP-T behavior in this document 🌈.
Now here's the plot twist 👀. Compared to MAP-E, the architecture uses NAT64 technology for two purposes. First, it cuts down on encapsulation overhead and lets IPv4 and IPv6 traffic get treated as similarly as possible. Second, it lets IPv4-only nodes talk directly to IPv6 nodes in the MAP-T domain that have IPv4-embedded IPv6 addresses, as defined in [RFC6052] 🦋✨.
The MAP-T architecture rests on these three key properties:
- Algorithmic IPv4-IPv6 address mapping, codified as MAP Rules, as described in Section 5 💖
- A MAP IPv6 address identifier, as described in Section 6 🫶
- MAP-T IPv4-IPv6 forwarding behavior, as described in Section 8 👑
5. Mapping Rules
The MAP-T algorithmic mapping rules are identical to the ones in Section 5 of the MAP-E specification [RFC7597]. There's one exception, though: forwarding traffic to and from IPv4 destinations outside a MAP-T domain is done as described in this document, not in Section 5.4 of the MAP-E specification 🙈.
5.1. Destinations outside the MAP Domain
IPv4 traffic sent by MAP nodes that are all within the same MAP domain gets translated to IPv6. The IPv6 source address is the sender's MAP IPv6 address, derived via the Basic Mapping Rule (BMR). The IPv6 destination address is the recipient's MAP IPv6 address, derived via the Forwarding Mapping Rule (FMR) 🌸.
IPv4-addressed destinations outside the MAP domain are represented with IPv4-embedded IPv6 addresses as per [RFC6052], using the BR's IPv6 prefix 🎀. When a CE sends traffic to any of these destinations, the IPv6 packet's source address is the CE's MAP IPv6 address, and the destination IPv6 address is the destination IPv4-embedded IPv6 address. This address mapping follows the MAP-T Default Mapping Rule (DMR), which is defined in terms of the IPv6 prefix advertised by one or more BRs that provide external connectivity. A typical MAP-T CE installs an IPv4 default route using this rule. And a BR uses this rule when translating all outside IPv4 source addresses to the IPv6 MAP domain 💅.
The DMR IPv6 prefix length SHOULD be 64 bits long by default, and in any case it MUST NOT exceed 96 bits 🧚. The mapping of the IPv4 destination behind the IPv6 prefix follows the /64 rule from [RFC6052] by default. Any trailing bits after the IPv4 address are set to 0x0 ✨.
6. The IPv6 Interface Identifier
The interface identifier format of a MAP-T node is the same as the format described in Section 6 of [RFC7597]. Here's the format diagram, just for convenience 💜:
| 128-n-o-s bits |
| 16 bits| 32 bits | 16 bits|
+--------+----------------+--------+
| 0 | IPv4 address | PSID |
+--------+----------------+--------+
Figure 2: IPv6 Interface IdentifierIf it's an IPv4 prefix, the IPv4 address field gets right-padded with zeros up to 32 bits. The PSID gets left-padded with zeros to make a 16-bit field. For an IPv4 prefix or a complete IPv4 address, the PSID field is zero 🍓.
If the End-user IPv6 prefix length is larger than 64, the most significant parts of the interface identifier get overwritten by the prefix. Yes, the prefix wins 👑.
7. MAP-T Configuration
For a given MAP domain, the BR and CE MUST be configured with the following MAP parameters 🔥. The values for these parameters are identical for all CEs and BRs within a given MAP-T domain.
- The Basic Mapping Rule and, optionally, the Forwarding Mapping Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and Length of embedded address bits
- Use of hub-and-spoke mode or Mesh mode (if all traffic should be sent to the BR, or if direct CE-to-CE correspondence should be supported)
- Use of IPv4-IPv6 translation (MAP-T)
- The BR's IPv6 prefix used in the DMR
7.1. MAP CE
For a given MAP domain, the MAP configuration parameters are the same across all CEs in that domain 💖. These values may be conveyed and configured on the CEs using a variety of methods, including DHCPv6, the Broadband Forum's "TR-69" Residential Gateway management interface [TR069], the Network Configuration Protocol (NETCONF), or manual configuration. This document doesn't prescribe any of these methods, but it does recommend that a MAP CE SHOULD implement DHCPv6 options as per [RFC7598] 🫶. Other configuration and management methods may use the data model described by this option, for consistency and convenience of implementation on CEs that support multiple configuration methods.
Besides the MAP configuration parameters, a CE needs an IPv6 prefix assigned to it. This End-user IPv6 prefix is configured as part of getting IPv6 Internet access, and it's acquired using standard IPv6 means that apply in the network where the CE is located 🌈.
The MAP provisioning parameters, and therefore the IPv4 service itself, are tied to the End-user IPv6 prefix. So the MAP service is also tied to it for authorization, accounting, and so on 🙈.
A single MAP CE MAY be connected to more than one MAP domain, just like any router can have more than one IPv4-enabled service-provider-facing interface and more than one set of addresses assigned by DHCPv6 🦋. Each domain a given CE operates in would need its own set of MAP configuration elements and would generate its own IPv4 address. Each MAP domain requires a distinct End-user IPv6 prefix ✨.
7.2. MAP BR
The MAP BR MUST be configured with the same MAP elements as the MAP CEs operating within the same domain 👑.
For increased reliability and load balancing, the BR IPv6 prefix MAY be shared across a given MAP domain. MAP is stateless, so any BR may be used for forwarding to and from the domain at any time 🧚.
Since MAP uses provider address space, no specific IPv6 or IPv4 routes need to be advertised externally, outside the service provider's network, for MAP to operate. However, the BR prefix does need to be advertised in the service provider's IGP 💅.
8. MAP-T Packet Forwarding
The end-to-end packet flow in MAP-T involves an IPv4 or IPv6 packet being forwarded by a CE or BR in one of two directions for each such case. This section gives a conceptual view of the operations involved in that forwarding 🎀.
8.1. IPv4 to IPv6 at the CE
A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing and create any necessary NAPT44 bindings 🌸. The source address and source port range of the packets that result from NAPT44 processing MUST correspond to the source IPv4 address and source transport port range assigned to the CE by means of the MAP Basic Mapping Rule (BMR) 💖.
The IPv4 packet goes through a longest IPv4 destination address + port match MAP Rule selection. That selection determines the parameters for the subsequent NAT64 operation. By default, all traffic is matched to the DMR and goes through the stateless NAT64 operation using the DMR parameters for NAT64 (Section 5.1) 🫶. Packets matched to (optional) Forwarding Mapping Rules (FMRs) go through the stateless NAT64 operation using the FMR parameters (Section 5) for the MAP algorithm 🌈. In all cases, the CE's MAP IPv6 address (Section 6) is used as a source address 👑.
A MAP-T CE MUST support a Default Mapping Rule and SHOULD support one or more Forwarding Mapping Rules 🔥💅
8.2. IPv6 to IPv4 at the CE 💅
okay so when a MAP-T CE gets an IPv6 packet, it first does all its regular IPv6 stuff (filtering, pre-routing, etc.) 🧚 Only packets addressed to the CE's MAP-T IPv6 addresses, and with source addresses matching the IPv6 MAP Rule prefixes of a DMR or FMR, get processed by the MAP-T CE. The DMR or FMR gets picked by longest match 🎀 The CE MUST check that each MAP-T received packet's transport-layer destination port number is in the range allowed by the CE's MAP BMR configuration. Any nonconforming packet MUST be silently dropped, and the CE MUST increment an appropriate counter 🙈 When a packet's source IP address longest matches an FMR prefix, the CE MUST check that the source address is consistent with the allowed values from the derived allocated source port range. If the source port number is outside that allocated range, the CE MUST drop the packet and SHOULD respond with an ICMPv6 "Destination Unreachable, source address failed ingress/egress policy" (Type 1, Code 5) 🚫
For every MAP-T processed packet, the CE's NAT64 function MUST compute an IPv4 source and destination address 🦋 The IPv4 destination address comes from pulling the relevant info out of the IPv6 destination plus the info stored in the BMR, as per Section 5. The IPv4 source address is formed by classifying the packet's source as longest matching a DMR or FMR rule prefix, and then using that rule's parameters for the NAT64 operation.
Then the resulting IPv4 packet goes to the CE's NAPT44 function, where the destination IPv4 address and port number MUST be mapped back to their original values before it gets forwarded under the CE's regular IPv4 rules ✨ When NAPT44 isn't enabled (that's a MAP configuration thing), the traffic from the stateless NAT64 function just goes straight out under the CE's IPv4 rules 💖
8.3. IPv6 to IPv4 at the BR 🌸
A MAP-T BR that receives an IPv6 packet MUST select a matching MAP Rule by longest address match of the packet's source address against the MAP Rules on the BR 👑 Together with the Port Set ID derived from the packet's source IPv6 address, that selected MAP Rule lets the BR check that the CE is using its allowed address and port range. So the BR MUST validate that the source is consistent with the allowed values from the identified port range. If the packet's source port number is outside the allowed range, the BR MUST drop the packet and increment a counter to log the event. The BR SHOULD also respond with an ICMPv6 "Destination Unreachable, source address failed ingress/egress policy" (Type 1, Code 5) 💀
When the BR builds the IPv4 packet, it MUST derive the source and destination IPv4 addresses as per Section 5 of this document and translate the IPv6-to-IPv4 headers as per [RFC6145] 🍓 The resulting IPv4 packet then goes to regular IPv4 forwarding.
8.4. IPv4 to IPv6 at the BR 🦋
A MAP-T BR receiving IPv4 packets does a longest match IPv4 + transport-layer port lookup to find the target MAP-T domain and select the FMR and DMR rules 🔥 The MAP-T BR MUST then compute and apply the IPv6 destination addresses from the IPv4 destination address and port, as per the selected FMR. It MUST ALSO compute and apply the IPv6 source addresses from the IPv4 source address as per Section 5.1 (so basically, it takes the IPv4 source plus the BR's IPv6 prefix and forms an IPv6-embedded IPv4 address) 🧚 The generic IPv4-to-IPv6 header translation procedures in [RFC6145] apply the whole way through. The resulting IPv6 packets then go to regular IPv6 forwarding.
Note that when a BR is forwarding to or from MAP-T domains defined without IPv4 address sharing, it works the same as stateless NAT64 IPv4/IPv6 translation. no notes, it's just that simple 🌈
9. ICMP Handling 🙈
MAP-T CEs and BRs MUST follow the ICMP/ICMPv6 translation in [RFC6145] ✨ BUT there's extra behavior needed because of NAPT44 (it's giving plot twist). Unlike TCP and UDP, which have two transport-protocol port fields for source and destination, the ICMP/ICMPv6 [RFC792] [RFC4443] Query message header has only one ID field, and that field has to be used to identify a sending IPv4 host 🎀 So when the MAP-T CE receives IPv4 ICMP messages, it MUST rewrite the ID field to a port value derived from the CE's Port Set ID.
A MAP-T BR that gets an IPv4 ICMP packet whose ID field is bound for a shared address in the MAP-T domain SHOULD use the ID value as a substitute for the destination port when working out the IPv6 destination address. In all other cases, the MAP-T BR MUST derive the destination IPv6 address by simply mapping the destination IPv4 address, with no extra port info 💜
10. Fragmentation and Path MTU Discovery 🧚
okay so the IPv4 and IPv6 headers are different sizes, which means handling the max packet size matters for anything connecting the two address families 😭 There are three mechanisms for this: Path MTU Discovery (PMTUD), fragmentation, and transport-layer negotiation like the TCP Maximum Segment Size (MSS) option [RFC879]. MAP can use all three to handle different cases 🌸
Note: The NAT64 [RFC6145] mechanism is not lossless. When IPv4-originated communication goes through a double NAT64 function (a.k.a. NAT464), any IPv4-originated ICMP-independent Path MTU Discovery, as specified in [RFC4821], stops being fully reliable. That's because the DF=1/MF=1 combo defined in [RFC4821] turns into DF=0/MF=1 after a double NAT64 translation. 💀
10.1. Fragmentation in the MAP Domain 🫶
Translating an IPv4 packet so it can cross the MAP domain makes it bigger (typically by 20 bytes) 🍓 The MTU in the MAP domain should be well managed, and the IPv6 MTU on the CE WAN-side interface SHOULD be configured so that no fragmentation happens inside the boundary of the MAP domain. Fragmentation in MAP-T domains SHOULD be handled as described in Sections 4 and 5 of [RFC6145] ✨
10.2. Receiving IPv4 Fragments on the MAP Domain Borders 🦋
Forwarding an IPv4 packet that came from outside the MAP domain needs the IPv4 destination address and the transport-protocol destination port 👑 But the transport-protocol info only shows up in the first fragment. As described in Section 5.3.3 of [RFC6346], a MAP node that receives an IPv4 fragmented packet from outside SHOULD reassemble it before sending it onto the MAP domain. If the first packet received has the transport-protocol info, you can optimize this by using a cache and forwarding the fragments unchanged. The caching algorithm itself is outside the scope of this document 🧚
10.3. Sending IPv4 Fragments to the Outside 🎀
Two IPv4 hosts behind two different MAP CEs can share the same IPv4 address. If they both send fragments to an IPv4 destination host outside the domain, they might accidentally use the same IPv4 fragmentation identifier, and then the destination host reassembles the fragments wrong 😭 The IPv4 fragmentation identifier is a 16-bit field, so it can be used kinda like port ranges. That means a MAP CE SHOULD rewrite the IPv4 fragmentation identifier to a value equivalent to a port in its allocated port set 💖
11. NAT44 Considerations 💅
The NAT44 implemented in the MAP CE SHOULD conform to the behavior and best current practices documented in [RFC4787], [RFC5508], and [RFC5382] 🌈 In MAP address-sharing mode (set by the MAP domain / rule configuration parameters), the NAT44 MUST be restricted to the available port numbers derived via the Basic Mapping Rule. no port wandering, bestie 🙅♀️
12. Usage Considerations 🦋
12.1. EA-Bit Length 0 🍓
The MAP solution supports domains where a BMR has an EA-bit length of 0 ✨ That means the IPv6 prefix assigned to the CE and the IPv4 address and/or port range used by MAP are totally independent of each other 🧚 The k-bits of PSID information can be derived from the BMR in this case.
The catch is that each MAP domain like this has to be made up of just one MAP CE with a predetermined IPv6 end-user prefix. The BR would be configured with an FMR for each such Customer Premises Equipment (CPE), where the rule uniquely associates the IPv4 address + optional PSID with that CE's IPv6 prefix 👑
12.2. Mesh and Hub-and-Spoke Modes 💜
Hub-and-spoke mode (all traffic from a MAP-T CE goes through a BR) and Mesh mode (a CE can forward traffic directly to another CE) are both controlled by which Forwarding Mapping Rules are active, the ones that cover the IPv4-prefix destination and port-index range 🌸 By default, a MAP CE that's only configured with a BMR, per this specification, uses it to set its IPv4 parameters and IPv6 MAP address, and Mesh mode stays off 🙅♀️
12.3. Communication with IPv6 Servers in the MAP-T Domain 🌈
By default, MAP-T allows communication between IPv4-only devices and any IPv6-enabled devices, plus native IPv6-only servers, as long as those servers are configured with an IPv4-mapped IPv6 address ✨ That address could be part of the IPv6 prefix the DMR uses in the MAP-T domain. This is how IPv6 servers (like an HTTP server or a web content cache device) can serve IPv6 users and IPv4-only users alike, all over IPv6 🔥 Any such IPv6-only servers SHOULD have both A and AAAA records in DNS. DNS64 [RFC6147] will be required only when IPv6 servers in the MAP-T domain are themselves expected to start communication with external IPv4-only hosts 🫶
12.4. Compatibility with Other NAT64 Solutions 🧚
The MAP-T CE's NAT64 function is compatible by default with [RFC6146] stateful NAT64 devices placed in the operator's network. In that case, the MAP-T CE's DMR prefix is configured to match the NAT64 device prefix. This basically lets you use MAP-T CEs in environments that need statistical multiplexing of IPv4 addresses while using stateful NAT64 devices, and it can take on the role of a customer-side translator (CLAT) as defined in [RFC6877] 👑✨
13. Security Considerations 🔐
okay bestie, this section is SERIOUS but also kind of iconic, so let's go 💅
Spoofing attacks: 🎭 MAP has consistency checks between the IPv4 and IPv6 sources on the packets that MAP nodes receive, so it doesn't add any new way to spoof stuff that wouldn't already exist in IPv6. no notes 💖
Denial-of-service attacks: 🚨 in MAP domains where IPv4 addresses get shared, the IPv4 datagram reassembly might be needed, and that opens up a chance for DoS attacks. this is just part of address sharing, and it shows up in other approaches too, like Dual-Stack Lite (DS-Lite) and NAT64/DNS64. the best defense is to speed up IPv6 support in both clients and servers. ✨
Routing loop attacks: 🔁 these can happen in some "automatic tunneling" setups, and they're written up in [RFC6324]. but they can't happen with MAP, because each BR checks that the IPv6 source address of a received IPv6 packet is a CE address based on the Forwarding Mapping Rule. 🙅♀️
Attacks facilitated by restricted port set: 🎯 from hosts that aren't subject to ingress filtering [RFC2827], an attacker can inject spoofed packets during ongoing transport connections [RFC4953] [RFC5961] [RFC6056]. these attacks depend on guessing which ports the target hosts are currently using. using an unrestricted port set is preferable, meaning native IPv6 connections that aren't subject to MAP port-range restrictions. to cut down on these attacks when you're using a restricted port set, the MAP CE's NAT44 filtering behavior SHOULD be "Address-Dependent Filtering" as described in Section 5 of [RFC4787]. also, the MAP CEs SHOULD use a DNS transport proxy function to handle DNS traffic and send that traffic from IPv6 interfaces that aren't assigned to MAP-T. the practical side of these methods is covered in Section 5.9 of [Stateless-4Via6]. 🧚
ICMP Flooding: 🌊 since the BR and CE nodes have to process and translate ICMP and ICMPv6 messages, a flood of those messages could totally saturate a node's ICMP computing resources. this attack isn't specific to MAP, and the fix is a mix of rate-policing the ICMP messages, rate-policing how fast MAP nodes process them, and of course spotting and blocking the source(s) of that traffic. 🛡️
[RFC6269] lays out the general issues with IPv4 address sharing. 📚
14. References 📖
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
<http://www.rfc-editor.org/info/rfc6145>.
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
the IPv4 Address Shortage", RFC 6346,
DOI 10.17487/RFC6346, August 2011,
<http://www.rfc-editor.org/info/rfc6346>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.14.2. Informative References
[MAP-T-Use-Cases]
Maglione, R., Ed., Dec, W., Leung, I., and E. Mallette,
"Use cases for MAP-T", Work in Progress,
draft-maglione-softwire-map-t-scenarios-05, October 2014.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<http://www.rfc-editor.org/info/rfc792>.
[RFC879] Postel, J., "The TCP Maximum Segment Size and Related
Topics", RFC 879, DOI 10.17487/RFC0879, November 1983,
<http://www.rfc-editor.org/info/rfc879>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<http://www.rfc-editor.org/info/rfc2663>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787,
January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, DOI 10.17487/RFC4953, July 2007,
<http://www.rfc-editor.org/info/rfc4953>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008,
<http://www.rfc-editor.org/info/rfc5382>.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
DOI 10.17487/RFC5508, April 2009,
<http://www.rfc-editor.org/info/rfc5508>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
DOI 10.17487/RFC5961, August 2010,
<http://www.rfc-editor.org/info/rfc5961>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011,
<http://www.rfc-editor.org/info/rfc6056>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<http://www.rfc-editor.org/info/rfc6147>.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
China Education and Research Network (CERNET) IVI
Translation Design and Deployment for the IPv4/IPv6
Coexistence and Transition", RFC 6219,
DOI 10.17487/RFC6219, May 2011,
<http://www.rfc-editor.org/info/rfc6219>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011,
<http://www.rfc-editor.org/info/rfc6269>.
[RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using
IPv6 Automatic Tunnels: Problem Statement and Proposed
Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011,
<http://www.rfc-editor.org/info/rfc6324>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<http://www.rfc-editor.org/info/rfc6877>.
[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
Configuration of Softwire Address and Port-Mapped
Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
<http://www.rfc-editor.org/info/rfc7598>.
[Solutions-4v6]
Boucadair, M., Ed., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Carrier-side
Stateless IPv4 over IPv6 Migration Solutions", Work in
Progress, draft-ietf-softwire-stateless-4v6-motivation-05,
November 2012.
[Stateless-4Via6]
Dec, W., Asati, R., Bao, C., Deng, H., and M. Boucadair,
"Stateless 4Via6 Address Sharing", Work in Progress,
draft-dec-stateless-4v6-04, October 2011.
[TR069] Broadband Forum TR-069, "CPE WAN Management Protocol",
Amendment 5, CWMP Version: 1.4, November 2013,
<https://www.broadband-forum.org>.Appendix A. Examples of MAP-T Translation 🎀
Okay, bestie, the examples are where it all clicks. We're going to walk through five little scenarios, and I'll show you exactly what every field looks like. 💅
Example 1 - Basic Mapping Rule
Okay so we start with a MAP CE that's been given an end-user IPv6 prefix and a MAP domain setup. Here's the info:
End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix),
192.0.2.0/24 (Rule IPv4 prefix),
16 (Rule EA-bit length)}
PSID length: (16 - (32 - 24) = 8 (sharing ratio of 256)
PSID offset: 6 (default)A MAP node (CE or BR) can, via the BMR or equivalent FMR, work out the IPv4 address and port set. It's giving math, honestly 🧮
EA bits offset: 40
IPv4 suffix bits (p): Length of IPv4 address (32) -
IPv4 prefix length (24) = 8
IPv4 address: 192.0.2.18 (0xc0000212)
PSID start: 40 + p = 40 + 8 = 48
PSID length (q): o - p = (End-user prefix len -
Rule IPv6 prefix len) - p
= (56 - 40) - 8 = 8
PSID: 0x34Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
63696-63699, 64720-64723The BMR info lets the MAP CE figure out its full IPv6 address inside that End-user IPv6 prefix. Iconic ✨
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034Example 2 - BR
Next up, a MAP-T BR that's configured with a FMR. It gets a packet with these characteristics:
IPv4 source address: 10.2.3.4 (0x0a020304)
TCP source port: 80
IPv4 destination address: 192.0.2.18 (0xc0000212)
TCP destination port: 1232The FMR looks like this:
Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix),
192.0.2.0/24 (Rule IPv4 prefix),
16 (Rule EA-bit length)}And the BR's prefix (the DMR) is:
MAP-T BR Prefix (DMR): 2001:db8:ffff::/64So the BR can derive the mapped destination IPv6 address for the MAP-T CE, plus the source IPv6 address for the mapped IPv4 source address. Here's how the numbers shake out:
IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12))
PSID length: 8
PSID: 0 x34 (1232)And the resulting IPv6 packet has these header fields:
IPv6 source address: 2001:db8:ffff:0:000a:0203:0400::
IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034
TCP source port: 80
TCP destination port: 1232Example 3 - FMR
Now flip it around! An IPv4 host behind a MAP-T CE (set up like in the earlier examples) is talking to IPv4 host 10.2.3.4. Its packets get converted into IPv6 using the DMR that's configured on the MAP-T CE. The DMR is:
Default Mapping Rule: {2001:db8:ffff::/64 (Rule IPv6 prefix),
0.0.0.0/0 (Rule IPv4 prefix)}And the packet fields are:
IPv4 source address: 192.0.2.18
IPv4 destination address: 10.2.3.4
IPv4 source port: 1232
IPv4 destination port: 80
MAP-T CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034
IPv6 destination address: 2001:db8:ffff:0:000a:0203:0400::Example 4 - Rule with no embedded address bits and no address sharing
This one's a super simple vibe. No embedded address bits, no address sharing. 🌸
End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
192.0.2.1/32 (Rule IPv4 prefix),
0 (Rule EA-bit length)}
PSID length: 0 (sharing ratio is 1)
PSID offset: n/aA MAP node can, via the BMR or equivalent FMR, work out the IPv4 address and port set like this:
EA bits offset: 0
IPv4 suffix bits (p): Length of IPv4 address -
IPv4 prefix length = 32 - 32 = 0
IPv4 address: 192.0.2.18 (0xc0000212)
PSID start: 0
PSID length: 0
PSID: nullThe BMR info also lets a MAP CE determine (complete) its full IPv6 address, by combining the IPv6 prefix with the MAP interface identifier (the one that embeds the IPv4 address):
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0201:0000Example 5 - Rule with no embedded address bits and address sharing (sharing ratio of 256)
Same rule vibes as Example 4, but now we've got address sharing going on! 🦋
End-user IPv6 prefix: 2001:db8:0012:3400::/56
Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
192.0.2.18/32 (Rule IPv4 prefix),
0 (Rule EA-bit length)}
PSID length: (16 - (32 - 24)) = 8 (sharing ratio of 256;
provisioned with DHCPv6)
PSID offset: 6 (default)
PSID: 0x20 (provisioned with DHCPv6)A MAP node can, via the BMR, work out the IPv4 address and port set like so:
EA bits offset: 0
IPv4 suffix bits (p): Length of IPv4 address -
IPv4 prefix length = 32 - 32 = 0
IPv4 address 192.0.2.18 (0xc0000212)
PSID start: 0
PSID length: 8
PSID: 0x34Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
63696-63699, 64720-64723The BMR info also lets a MAP CE determine (complete) its full IPv6 address, by combining the IPv6 prefix with the MAP interface identifier (which embeds the IPv4 address and the PSID):
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034Heads up! The IPv4 address and PSID are NOT derived from the IPv6 prefix assigned to the CE. They're provisioned separately, using, for example, MAP options in DHCPv6. 🙈
Appendix B. Port-Mapping Algorithm 🧚
Okay, so if you want the driving principles and the math behind the MAP mapping algorithm, go check out Appendix B of [RFC7597]. It's all there, bestie 💜
Acknowledgements ✨
This document is built on the ideas of so many people, but a huge shoutout goes to Remi Despres, who has put so much tireless work into generalized mechanisms for stateless address mapping 👑
The authors also want to thank Mohamed Boucadair, Guillaume Gottard, Dan Wing, Jan Zorz, Nejc Skoberne, Tina Tsou, Gang Chen, Maoke Chen, Xiaohong Deng, Jouni Korhonen, Tomek Mrugalski, Jacni Qin, Chunfa Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta Maglione, and Hongyu Chen for their review and comments. You all are literally the best 🫶
Contributors 🌈
These individuals authored major contributions to this document and made the document possible. Iconic behaviour from all of them! 💅
Chongfeng Xie
China Telecom
Room 708, No. 118, Xizhimennei Street
Beijing 100035
China
Phone: +86-10-58552116
Email: xiechf@ctbri.com.cn
Qiong Sun
China Telecom
Room 708, No. 118, Xizhimennei Street
Beijing 100035
China
Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn
Rajiv Asati
Cisco Systems
7025-6 Kit Creek Road
Research Triangle Park, NC 27709
United States
Email: rajiva@cisco.com
Gang Chen
China Mobile
29, Jinrong Avenue
Xicheng District, Beijing 100033
China
Email: phdgang@gmail.com, chengang@chinamobile.com
Wentao Shang
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
China
Email: wentaoshang@gmail.com
Guoliang Han
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
China
Email: bupthgl@gmail.com
Yu Zhai
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
China
Email: jacky.zhai@gmail.comAuthors' Addresses 💖
Here's where you can find the authors. Slide into those DMs! 🍓
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
China
Email: xing@cernet.edu.cn
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
China
Email: congxiao@cernet.edu.cn
Wojciech Dec (editor)
Cisco Systems
Haarlerbergpark Haarlerbergweg 13-19
Amsterdam, NOORD-HOLLAND 1101 CH
The Netherlands
Email: wdec@cisco.com
Ole Troan
Cisco Systems
Philip Pedersens vei 1
Lysaker 1366
Norway
Email: ot@cisco.com
Satoru Matsushima
SoftBank Telecom
1-9-1 Higashi-Shinbashi, Munato-ku
Tokyo
Japan
Email: satoru.matsushima@g.softbank.co.jp
Tetsuya Murakami
IP Infusion
1188 East Arques Avenue
Sunnyvale, CA 94085
United States
Email: tetsuya@ipinfusion.com📦 where this page comes from
- ietf: rfc7599 2015-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms