Mapping of Address and Port using Translation (MAP-T)
Extracted elements (25)
MAP-T uses IPv4-IPv6 stateless NAT64 translation rather than encapsulation (as in MAP-E) to eliminate encapsulation overhead and allow IPv4 and IPv6 traffic to be treated as similarly as possible, and to enable IPv4-only nodes to correspond directly with IPv6 nodes bearing IPv4-embedded IPv6 addresses.
A MAP node receiving an IPv4 fragmented packet from outside the MAP domain SHOULD reassemble the packet before forwarding it into the MAP domain, because the transport-protocol destination port needed for address mapping is only present in the first fragment. An optimization using a forwarding cache for the initial fragment is possible but outside scope.
The MAP-T CE's NAT64 function is by default compatible with RFC 6146 stateful NAT64 devices placed in the operator's network: configuring the CE's DMR prefix to match the NAT64 device prefix allows MAP-T CEs to act as customer-side translators (CLAT, per RFC 6877) in environments using stateful NAT64.
The NAT64 mechanism is not lossless: when IPv4-originated communication traverses a double NAT64 function (NAT464), IPv4 PMTUD using DF=1/MF=1 as specified in RFC 4821 ceases to be fully reliable, because double NAT64 translation converts that combination to DF=0/MF=1.
A CE processing IPv6-to-IPv4 packets MUST check that each received packet's transport-layer destination port is within the range allowed by the CE's BMR configuration, and MUST silently drop any nonconforming packet while incrementing an appropriate counter.
A MAP CE SHOULD implement DHCPv6 options as per RFC 7598 for conveying MAP configuration parameters. Other configuration methods (TR-069, NETCONF, manual) MAY be used but SHOULD follow the same data model.
A MAP CE SHOULD rewrite the IPv4 fragmentation identifier to a value equivalent to a port from its allocated port set, because two CEs sharing the same IPv4 address could otherwise generate the same fragmentation ID and cause incorrect reassembly at the destination.
A MAP-T BR receiving an IPv6 packet MUST select the matching MAP Rule via longest source-address match, verify the CE is using its allowed address and port range, and MUST drop packets whose source port is outside the allowed range (SHOULD respond with ICMPv6 Type 1, Code 5).
At a CE performing IPv4-to-IPv6 forwarding, the source address and source port range of packets after NAPT44 processing MUST correspond to the IPv4 address and port range assigned via the BMR. The CE MUST support a Default Mapping Rule and SHOULD support one or more Forwarding Mapping Rules.
For a given MAP domain, the BR and CE MUST be configured with the same MAP parameters: the Basic Mapping Rule (and optionally FMRs), hub-and-spoke or Mesh mode selection, use of IPv4-IPv6 translation (MAP-T), and the BR's IPv6 prefix for the DMR.
In MAP address-sharing mode, the NAT44 operation MUST be restricted to port numbers derived via the Basic Mapping Rule. The NAT44 SHOULD conform to behavioral best practices documented in RFC 4787, RFC 5508, and RFC 5382.
MAP-T CEs and BRs MUST follow ICMP/ICMPv6 translation per RFC 6145. When receiving IPv4 ICMP messages, the MAP-T CE MUST rewrite the ICMP ID field to a port value derived from the CE's Port Set ID, to identify the sending host in the absence of separate source/destination port fields.
The DMR IPv6 prefix length SHOULD be 64 bits by default and MUST NOT exceed 96 bits. Any trailing bits after the embedded IPv4 address are set to 0x0.
The IPv6 MTU on the CE WAN-side interface SHOULD be configured so that no fragmentation occurs within the MAP domain boundary. Fragmentation in MAP-T domains SHOULD be handled as described in Sections 4 and 5 of RFC 6145.
The MAP BR MUST be configured with the same MAP elements as the MAP CEs operating within the same domain. The BR IPv6 prefix MAY be shared across a given MAP domain for load balancing; since MAP is stateless, any BR may handle forwarding at any time.
When a CE receives a packet whose source IP address longest-matches an FMR prefix and the source port number is outside the 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).
When constructing the IPv4 packet at the BR (IPv6-to-IPv4), the BR MUST derive source and destination IPv4 addresses per Section 5 and translate headers per RFC 6145. For IPv4-to-IPv6 at the BR, the BR MUST compute IPv6 destination addresses from the IPv4 destination and port via the FMR, and MUST compute IPv6 source addresses using the DMR (IPv4-embedded IPv6 address with the BR's IPv6 prefix).
A MAP-T domain consists of one or more MAP Customer Edge (CE) routers and Border Relays (BRs) connected by an IPv6 network and sharing a common set of MAP Rules. CEs implement NAPT44 plus stateless NAT64; BRs connect MAP domains to native IPv4 networks via stateless NAT64.
MAP-T allows communication with native IPv6-only servers in the MAP-T domain by configuring those servers with IPv4-mapped IPv6 addresses drawn from the DMR IPv6 prefix space. Such servers SHOULD have both A and AAAA DNS records; DNS64 is only required when IPv6-only servers need to initiate connections to external IPv4-only hosts.
Mesh mode enables direct CE-to-CE forwarding by activating Forwarding Mapping Rules covering the destination IPv4 prefix and port range. Hub-and-spoke mode, the default when only a BMR is configured, routes all CE traffic via a BR. The mode is governed by which FMRs are provisioned.
The Default Mapping Rule (DMR) represents IPv4-addressed destinations outside the MAP domain using IPv4-embedded IPv6 addresses (per RFC 6052) constructed from the BR's IPv6 prefix. A CE installs an IPv4 default route using the DMR; the BR uses the DMR to translate all outside IPv4 source addresses into the MAP domain.
ICMP flooding is a foreseeable attack vector because BR and CE nodes must process and translate ICMP and ICMPv6 messages. Mitigation requires policing the rate of ICMP messages and the rate at which MAP nodes process them, combined with identification and blocking of attack sources.
In MAP domains with shared IPv4 addresses, the need for IPv4 datagram reassembly introduces a denial-of-service attack vector; this is inherent to address sharing and common with DS-Lite and NAT64/DNS64. To mitigate port-guessing attacks enabled by restricted port sets, the MAP CE's NAT44 filtering behavior SHOULD be 'Address-Dependent Filtering' (RFC 4787 Section 5), and CEs SHOULD use a DNS transport proxy sourcing DNS from IPv6 interfaces not assigned to MAP-T.
MAP's consistency checks between IPv4 and IPv6 sources on packets received by MAP nodes (at both CE and BR) ensure that MAP does not introduce new spoofing attack opportunities beyond those already present in IPv6. The BR validates that the CE's source address and port match the Forwarding Mapping Rule, preventing routing loop attacks documented in RFC 6324.
The MAP-T IPv6 Interface Identifier is 128-n-o-s bits wide and structured as: 16 bits of zeros, followed by a 32-bit IPv4 address field (right-padded with zeros for prefixes), followed by a 16-bit PSID field (left-padded with zeros). If the end-user IPv6 prefix length exceeds 64, the most significant parts of the interface identifier are overwritten by the prefix.