Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
Extracted elements (28)
DNS64 does not install any state in the NAT64. Because the IPv4-to-IPv6 address mapping is purely algorithmic (Pref64::/n concatenated with the IPv4 address), the NAT64 translates correctly as long as the IPv6 client uses an address derived from that algorithm, regardless of how it obtained the address.
Endpoint-Independent Mapping is mandated to enable compatibility with NAT traversal techniques such as ICE (RFC 5245). Without it, techniques that discover the external transport address and share it with remote peers would fail because different remote peers would see different mappings.
On receiving a TCP RST in ESTABLISHED state, the NAT64 moves to TRANS rather than CLOSED because it cannot be certain the peer will accept the RST. If no further data packets arrive within TCP_TRANS, the state is deleted; if packets continue, the state reverts to ESTABLISHED.
When an IPv4-initiated TCP SYN arrives and the destination is not in the BIB, the NAT64 stores the packet and creates only a Session Table Entry (no BIB entry) with a short TCP_INCOMING_SYN timer. This design supports simultaneous TCP open without permanently allocating a BIB entry for an unconfirmed connection.
NAT64 is compliant with RFC 4787 (NAT UDP requirements), RFC 5382 (TCP NAT requirements), and RFC 5508 (ICMP NAT requirements), and consequently supports both Endpoint-Independent Mapping and both Endpoint-Independent and Address-Dependent Filtering modes.
Only TCP, UDP, and ICMP are supported by this specification. IPv6 packets carrying other transport protocols (e.g., SCTP, DCCP) SHOULD be discarded with an ICMPv6 Destination Unreachable Code 4 (Port Unreachable); IPv4 packets with unknown protocols SHOULD receive ICMPv4 Destination Unreachable Code 2 (Protocol Unreachable).
BIB entries translate IPv6 source transport addresses to IPv4 source transport addresses, and IPv4 destination transport addresses to IPv6 destination transport addresses. IPv6 destination addresses and IPv4 source addresses are translated algorithmically, NOT via BIB lookup — a distinction required for correct hairpinning.
Each NAT64 device MUST have at least one unicast Pref64::/n IPv6 prefix assigned to it and MUST have one or more unicast IPv4 addresses assigned to it. Implementations MUST store all required binding and session information; externally visible behavior MUST match this specification.
For incoming IPv4 UDP packets with a zero checksum, the NAT64 MUST reassemble fragments and calculate the UDP checksum if resources permit; otherwise it MUST silently discard the packets. This behavior deviates from RFC 6145.
If the incoming tuple cannot be determined from an ICMP error message (insufficient embedded packet data), the packet MUST be silently discarded. ICMP error messages that themselves contain ICMP error messages are also silently discarded.
NAT64 MUST handle IP fragments, including out-of-order arrival. It MUST limit resources devoted to fragment storage to protect against DoS attacks, and MUST allow fragments to arrive over a configurable time interval whose default MUST be at least FRAGMENT_MIN.
NAT64 MUST support hairpinning: when an IPv6 packet's destination IPv6 address embeds an IPv4 address assigned to the NAT64 itself, the packet MUST be forwarded back out the IPv6 interface to the destination IPv6 host.
NAT64 MUST support the RFC 6052 Section 2.3 algorithm for generating IPv6 representations of IPv4 addresses. This SHOULD be the default algorithm, and the Well-Known Prefix 64:ff9b::/96 SHOULD be used when no Pref64::/n is configured.
NAT64 SHOULD support manually configured BIB entries for all three BIBs. Dynamically created entries are deleted when their last associated session is removed; manually configured entries persist until removed by an administrator.
Port allocation SHOULD preserve the port range (Well-Known 0–1023 vs. 1024–65535) and SHOULD preserve port parity (odd/even) per RFC 4787 REQ-3. If no port is available in the same range, the NAT64 MAY assign a port from another range.
The IPv6 representation algorithm MUST be reversible; inputs MUST be limited to the IPv4 address, Pref64::/n, and optional stable parameters. The prefix length MUST be less than or equal to 96.
The NAT64 MUST silently discard all incoming IPv6 packets whose source address contains Pref64::/n, and MUST only process IPv6 packets whose destination address contains Pref64::/n. Incoming IPv4 packets MUST only be processed if their destination address belongs to the NAT64's IPv4 pool.
The TCP session lifetime in ESTABLISHED state MUST NOT be less than TCP_EST (per RFC 5382), and the default SHOULD be TCP_EST. When the lifetime expires in ESTABLISHED state, the NAT64 SHOULD send a zero-data probe TCP segment before transitioning to TRANS.
The UDP session lifetime MUST NOT be less than UDP_MIN. The default SHOULD be at least UDP_DEFAULT and MAY be configurable. These constraints apply to sessions created in both the IPv6→IPv4 and IPv4→IPv6 directions.
When a V4 SYN arrives in CLOSED state and its destination transport address is not in the TCP BIB, the NAT64 MUST create a Session Table Entry with lifetime TCP_INCOMING_SYN and store the packet rather than drop it, to support simultaneous TCP open.
When allocating an IPv4 transport address for a new UDP BIB entry, the NAT64 SHOULD reuse an IPv4 address already mapped from the same IPv6 address in any BIB. The allocated (T,t) MUST NOT be in use in another entry within the same BIB, though it may be reused across different protocol BIBs.
NAT64 maintains three Binding Information Bases (BIBs) — one each for TCP, UDP, and ICMP Queries. Each BIB entry maps an IPv6 transport address (or IPv6 address plus ICMP Identifier) to an IPv4 transport address owned by the NAT64. A given IPv6 or IPv4 transport address may appear in at most one entry per BIB.
NAT64 maintains three Session Tables — for TCP, UDP, and ICMP Queries. Each TCP/UDP Session Table Entry (STE) stores source and destination IPv6 transport addresses, source and destination IPv4 transport addresses, and a lifetime timer. The ICMP Query STE stores the full 3-tuple in both address families plus the ICMP Identifier mapping.
A malicious IPv4 node can attempt to exhaust NAT64 IPv4 address pool, port, memory, and CPU resources by sending many packets. The NAT64 MUST limit resources for fragment storage and MAY apply filtering and rate-limiting to mitigate these attacks.
Address-Dependent Filtering can limit resource exhaustion attacks by ensuring the NAT64 only forwards IPv4 packets from an address to which the IPv6 host has previously sent packets. Administrators can also apply general IPv6 ingress filtering to control which IPv6 hosts can create NAT64 state.
Hairpinning loops are prevented by requiring the NAT64 to silently discard any incoming IPv6 packet whose source address contains Pref64::/n. Without this rule, a crafted packet could loop indefinitely inside the NAT64 or trigger traffic amplification.
NAT64 breaks end-to-end security: it modifies IP headers, preventing transparent use of IPsec AH and making IPsec ESP between IPv6 and IPv4 endpoints infeasible without additional mechanisms. Applications requiring end-to-end security must use application-layer security.
NAT64 tracks each TCP connection with an 8-state machine: CLOSED, V6 INIT (IPv6-side SYN sent), V4 INIT (IPv4-side SYN stored), ESTABLISHED, V4 FIN RCV, V6 FIN RCV, V6 FIN + V4 FIN RCV, and TRANS (post-RST or near-expiry). Transitions are triggered by V6/V4 SYN, FIN, RST packets, data packets, and timer expiry.