rfc-7597

Mapping of Address and Port with Encapsulation (MAP-E)

O. Troan (Editor), W. Dec, X. Li, C. Bao, S. Matsushima, T. Murakami, T. Taylor (Editor)
date2015-07 streamIETF areaint wgsoftwire statusPROPOSED STANDARD pages35 canonicalhttps://www.rfc-editor.org/rfc/rfc7597 doi10.17487/RFC7597
This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports.

Extracted elements (26)

design-rationale §Appendix B

The Generalized Modulus Algorithm (GMA) was chosen for port-mapping because it supports both non-contiguous uniformly-distributed port sets (maximizing PSID embedding flexibility) and contiguous port ranges (a=0 case), with a reversible PSID derivation from any port number via bitmask operations, and supports a broad range of address-sharing ratios.

ip, v6ops

design-rationale §5.1

The port-mapping algorithm uses an infix representation (PSID embedded in the middle of the port number) rather than a prefix/suffix representation. This minimizes restrictions on possible PSID values when the PSID is embedded in the End-user IPv6 prefix, reducing dependencies between the IPv6 prefix and the assigned port set. Well-known ports are excluded by restricting the high-order A field rather than the PSID.

ip, v6ops

interoperability-note §8.3.2

A MAP node receiving an IPv4 fragmented packet from outside the MAP domain must reassemble the packet before forwarding it onto the MAP link, because the transport-protocol destination port (needed for PSID lookup) is only in the first fragment. Implementations should be aware of known attacks against IP fragmentation (RFC 1858, RFC 3128) and high-rate reassembly issues (RFC 4963).

ip, v6ops

interoperability-note §5.4

MAP relies on IPv6 encapsulation as specified in RFC 2473. The BR connects MAP domains to external IPv4 networks and forwards traffic using normal MAP forwarding rules. Traffic to destinations outside the MAP domain is encapsulated with the BR's IPv6 address as the destination, acting as a point-to-point IPv4-over-IPv6 tunnel.

ip, v6ops

interoperability-note §8.3.1

When multiple BRs share the same anycast source address, fragmented packets from different BRs to the same CE may collide on fragment IDs, causing incorrect reassembly. RFC 4459 Section 3.4 suggests solving this by fragmenting the inner packet.

ip, v6ops

normative-requirement §8.3.1 SHOULD NOT

A MAP BR using an anycast source address SHOULD NOT by default use Path MTU Discovery across the MAP domain, because ICMP error messages generated on the path may be sent to a different BR, making dynamic tunnel MTU (per RFC 2473 Section 6.7) subject to IPv6 Path MTU black holes.

ip, v6ops

normative-requirement §5 MUST

A MAP IPv6 address formed from the BMR Rule IPv6 prefix MUST be assigned to an interface of the MAP node and is used to terminate all MAP traffic sent or received to the node.

ip, v6ops

normative-requirement §4 MUST NOT

A shared IPv4 address MUST NOT be used to identify an interface; it is restricted to use only as the global (outside) address of the NAPT running on the CE.

ip, v6ops, nat

normative-requirement §4 MUST

For a shared IPv4 address, the CE NAPT MUST translate transport identifiers (TCP and UDP port numbers) so that they fall within the CE's assigned port range.

ip, v6ops, nat

normative-requirement §5 MUST

In hub-and-spoke mode, all traffic MUST be forwarded directly to the BR; there are no Forwarding Mapping Rules. All MAP CEs MUST implement support for both BMR and FMR rule types regardless of deployment mode.

ip, v6ops

normative-requirement §7.2 MUST

The BR MUST be configured with corresponding mapping rules for each MAP domain for which it acts as a BR. If the BR IPv6 address is anycast, the relay MUST use this anycast IPv6 address as the source address in packets relayed to CEs.

ip, v6ops

normative-requirement §7 MUST

The BR MUST be configured with the BR and CE with the same MAP elements for a given domain: Basic Mapping Rule (and optional FMRs including Rule IPv6 prefix, Rule IPv4 prefix, EA-bit length) and hub-and-spoke vs. mesh mode. The CE additionally MUST be configured with the IPv6 address(es) of the MAP BR.

ip, v6ops

normative-requirement §8.1 MUST

The CE router MUST drop packets received on the MAP virtual interface (after IPv6 decapsulation) for IPv4 destinations not matching its own IPv4 shared address, full IPv4 address, or IPv4 prefix.

ip, v6ops

normative-requirement §8.2 MUST

The NAT44 in the MAP CE MUST implement ICMP behavior conforming to RFC 5508. If a MAP CE receives an ICMP message with the ICMP Identifier field, the NAT44 MUST rewrite this field to a value assigned from the CE's port set.

ip, v6ops, nat

normative-requirement §9 MUST

The NAT44 in the MAP CE SHOULD conform to RFC 4787, RFC 5508, and RFC 5382. In MAP address-sharing mode, NAT44 operation MUST be restricted to port numbers derived via the Basic Mapping Rule.

ip, v6ops, nat

normative-requirement §5.1 MUST

The offset 'a' (number of offset bits in the port-mapping algorithm) MUST be the same for every MAP CE sharing the same IPv4 address. Similarly, the PSID length 'k' MUST be the same for every MAP CE sharing the same address, to guarantee non-overlapping port sets.

ip, v6ops

normative-requirement §8.1 MUST

To prevent IPv4 address spoofing, any MAP node (CE and BR) MUST validate received packets by extracting the embedded IPv4 address/prefix and PSID from the source IPv6 address and verifying them against the source IPv4 address and port in the encapsulated packet. Packets failing validation MUST be silently discarded with a counter incremented.

ip, v6ops, security

protocol-element §3

A MAP domain consists of one or more MAP Customer Edge (CE) devices and Border Relays (BRs) connected to the same virtual link. A MAP Rule is a set of parameters describing the mapping between an IPv4 prefix, IPv4 address, or shared IPv4 address and an IPv6 prefix or address. Each domain uses a different mapping rule set.

ip, v6ops

protocol-element §5.2

Embedded Address (EA) bits in the IPv6 address encode CE-specific IPv4 address and port information. The EA bit field length (o) can be 0 to 48 bits; 0 means no IPv4/port info is embedded, 48 means the complete IPv4 address and a single port are embedded. The sum of the Rule IPv6 Prefix length and Rule EA-bit length MUST be less than or equal to the End-user IPv6 prefix length.

ip, v6ops

protocol-element §5.2

If o + r < 32, an IPv4 prefix is assigned. If o + r = 32, a full IPv4 address is assigned by concatenating the Rule IPv4 prefix with EA-bits. If o + r > 32, a shared IPv4 address is assigned with p = 32 - r IPv4 suffix bits and q = o - p PSID bits in the EA field.

ip, v6ops

protocol-element §5

Two types of mapping rules exist: the Basic Mapping Rule (BMR), which is mandatory and used by a CE to provision its IPv4 address/prefix/shared address, and the Forwarding Mapping Rule (FMR), which is optional and used in mesh mode for direct CE-to-CE connectivity. Both rules share parameters: Rule IPv6 prefix, Rule IPv4 prefix, and Rule EA-bit length.

ip, v6ops

security-consideration §10

In MAP domains with shared IPv4 addresses, IPv4 datagram reassembly introduces a DoS attack opportunity. This is inherent in address sharing and common to DS-Lite and NAT64/DNS64. To minimize port-guessing attacks on restricted port sets, MAP CE NAT44 filtering SHOULD use 'Address-Dependent Filtering' (RFC 4787 Section 5), and CEs SHOULD use a DNS transport proxy (RFC 5625) to source DNS traffic from IPv6 interfaces not assigned to MAP.

security, ip, v6ops, nat

security-consideration §10

MAP provides consistency checks between IPv4 and IPv6 sources on received packets, preventing new spoofing attack opportunities beyond those already present in IPv6. Routing loop attacks (documented in RFC 6324) cannot occur because each BR checks that the IPv6 source address of a received packet is a valid CE address based on the FMR.

security, ip, v6ops

wire-format §6

The IPv6 interface identifier for MAP nodes is 128-n-o-s bits wide, structured as: 16-bit zero field, 32-bit IPv4 address, and 16-bit PSID. For IPv4 prefixes, the IPv4 address field is right-padded with zeros; for full addresses or prefixes without sharing, the PSID field is zero.

ip, v6ops

wire-format §5.2

The MAP IPv6 address format consists of: n-bit Rule IPv6 prefix, o-bit EA bits (encoding IPv4 address/prefix and PSID), s-bit subnet ID, and (128-n-o-s)-bit interface identifier. The End-user IPv6 prefix spans the Rule IPv6 prefix plus the EA bits fields.

ip, v6ops

wire-format §5.1

The port-restricted port field is a 16-bit value structured as: a-bit field A (must be >0 to exclude system ports), k-bit PSID (Port Set Identifier), and m-bit index j. The default value of 'a' is 6, which excludes system ports 0-1023.

ip, v6ops