RFC 6146
Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
RFC 6146: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers 🦋
Bestie, this one is from April 2011 and it's a Standards Track document, so it's real Internet standard stuff 💅. It was written by M. Bagnulo (UC3M), P. Matthews (Alcatel-Lucent), and I. van Beijnum (IMDEA Networks). Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's nothing to add there ✨
Abstract
okay so this doc is all about stateful NAT64 translation, which lets IPv6-only clients contact IPv4 servers using unicast UDP, TCP, or ICMP 🎀 One or more public IPv4 addresses assigned to a NAT64 translator get shared among several IPv6-only clients, which is so smart 🧚 When stateful NAT64 is used together with DNS64, the IPv6 client or the IPv4 server usually doesn't need any changes at all 🫶
Status of This Memo
This is an Internet Standards Track document. 🌸
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6146 🔗
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 cover 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. Features of Stateful NAT64 . . . . . . . . . . . . . . . . 5
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Stateful NAT64 Solution Elements . . . . . . . . . . . 6
1.2.2. Stateful NAT64 Behavior Walk-Through . . . . . . . . . 8
1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 10
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Stateful NAT64 Normative Specification . . . . . . . . . . . . 14
3.1. Binding Information Bases . . . . . . . . . . . . . . . . 14
3.2. Session Tables . . . . . . . . . . . . . . . . . . . . . . 15
3.3. Packet Processing Overview . . . . . . . . . . . . . . . . 17
3.4. Determining the Incoming Tuple . . . . . . . . . . . . . . 18
3.5. Filtering and Updating Binding and Session Information . . 20
3.5.1. UDP Session Handling . . . . . . . . . . . . . . . . . 21
3.5.1.1. Rules for Allocation of IPv4 Transport
Addresses for UDP . . . . . . . . . . . . . . . . 23
3.5.2. TCP Session Handling . . . . . . . . . . . . . . . . . 24
3.5.2.1. State Definition . . . . . . . . . . . . . . . . . 24
3.5.2.2. State Machine for TCP Processing in the NAT64 . . 25
3.5.2.3. Rules for Allocation of IPv4 Transport
Addresses for TCP . . . . . . . . . . . . . . . . 33
3.5.3. ICMP Query Session Handling . . . . . . . . . . . . . 33
3.5.4. Generation of the IPv6 Representations of IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . 36
3.6. Computing the Outgoing Tuple . . . . . . . . . . . . . . . 36
3.6.1. Computing the Outgoing 5-Tuple for TCP, UDP, and
for ICMP Error Messages Containing a TCP or UDP
Packets . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.2. Computing the Outgoing 3-Tuple for ICMP Query
Messages and for ICMP Error Messages Containing an
ICMP Query . . . . . . . . . . . . . . . . . . . . . . 38
3.7. Translating the Packet . . . . . . . . . . . . . . . . . . 38
3.8. Handling Hairpinning . . . . . . . . . . . . . . . . . . . 39
4. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
5.1. Implications on End-to-End Security . . . . . . . . . . . 40
5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Attacks on NAT64 . . . . . . . . . . . . . . . . . . . . . 41
5.4. Avoiding Hairpinning Loops . . . . . . . . . . . . . . . . 42
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Normative References . . . . . . . . . . . . . . . . . . . 43
8.2. Informative References . . . . . . . . . . . . . . . . . . 441. Introduction ✨
So this doc specifies stateful NAT64, a mechanism for IPv4-IPv6 transition and IPv4-IPv6 coexistence 🦋 Together with DNS64 [RFC6147], these two mechanisms let an IPv6-only client start communications with an IPv4-only server. They also enable peer-to-peer communication between an IPv4 node and an IPv6 node, where the communication can begin when either end uses existing NAT-traversal, peer-to-peer techniques, like Interactive Connectivity Establishment (ICE) [RFC5245]. Stateful NAT64 also supports IPv4-initiated communications to a subset of the IPv6 hosts, through statically configured bindings in the stateful NAT64 🧚
Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and back again 💖 The translation happens by translating the packet headers according to the IP/ICMP Translation Algorithm defined in [RFC6145]. The IPv4 addresses of IPv4 hosts get algorithmically translated to and from IPv6 addresses, using the algorithm defined in [RFC6052] and an IPv6 prefix assigned to the stateful NAT64 for this specific purpose. The IPv6 addresses of IPv6 hosts get translated to and from IPv4 addresses by installing mappings in the normal Network Address Port Translation (NAPT) manner [RFC3022]. The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols are out of scope for this spec, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec 🙈
DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs 🍓 The IPv6 address inside the synthetic AAAA RR is algorithmically generated from the IPv4 address and the IPv6 prefix assigned to a NAT64 device, using the same algorithm defined in [RFC6052].
Together, these two mechanisms let an IPv6-only client (that's a host with a networking stack that only implements IPv6, a host with a networking stack that implements both protocols but only has IPv6 connectivity, or a host running an IPv6-only application) start communications with an IPv4-only server, which is basically the IPv6-only host situation but flipped 👑
These mechanisms are expected to play a critical role in IPv4-IPv6 transition and coexistence 🔥 Because of IPv4 address depletion, the new clients will likely be IPv6-only in the future, and they'll want to connect to the existing IPv4-only servers. Stateful NAT64 and DNS64 are super easy to deploy, since they don't need changes to either the IPv6 client or the IPv4 server 🎀
For basic functionality, the approach only needs stateful NAT64 deployed in the devices that connect an IPv6-only network to the IPv4-only network, plus a few DNS64-enabled name servers reachable by the IPv6-only hosts. An analysis of the application scenarios can be found in [RFC6144] 🌈
For brevity, the rest of the document refers to stateful NAT64 either as stateful NAT64 or simply as NAT64 💅
1.1. Features of Stateful NAT64 🌸
The features of NAT64 are:
- NAT64 is compliant with the recommendations for how NATs should handle UDP [RFC4787], TCP [RFC5382], and ICMP [RFC5508]. As such, NAT64 only supports Endpoint-Independent Mappings and supports both Endpoint-Independent and Address-Dependent Filtering. Because it complies with those requirements, NAT64 is compatible with current NAT traversal techniques, such as ICE [RFC5245], and with other NAT traversal techniques 💖
- In the absence of preexisting state in a NAT64, only IPv6 nodes can initiate sessions to IPv4 nodes. This works for roughly the same class of applications that work through IPv4-to-IPv4 NATs 🦋
- Depending on the filtering policy used (Endpoint-Independent, or Address-Dependent), IPv4 nodes might be able to initiate sessions to a given IPv6 node, if the NAT64 somehow has an appropriate mapping (i.e., state) for that IPv6 node, via one of the following mechanisms:
- The IPv6 node has recently initiated a session to the same or another IPv4 node. This is also the case if the IPv6 node has used a NAT-traversal technique (such as ICE) 🧚
- A statically configured mapping exists for the IPv6 node ✨
- IPv4 address sharing: NAT64 allows multiple IPv6-only nodes to share an IPv4 address to access the IPv4 Internet. This helps with the forthcoming IPv4 exhaustion 🫶
- As currently defined in this NAT64 specification, only TCP, UDP, and ICMP are supported. Support for other protocols (such as other transport protocols and IPsec) is to be defined in separate documents 🍓
Part 2 is next, bestie, and we pick up right at Section 1.2 🧚💜
1.2. Overview ✨
okay so this section is a chill, non-normative intro to NAT64 🌸 We're gonna look at one simple setup with a single NAT64 device, a single DNS64, and a basic network topology. The goal is just to give you the general vibe of how NAT64 works. It's not trying to cover every possible configuration, and it's not the official normative spec either 🙈 For clarity, this overview only talks about TCP and UDP. ICMP, fragmentation, and the other translation details are intentionally left out here. The real normative spec lives in Section 3 💅
So the NAT64 mechanism lives in a device with (at least) two interfaces: an IPv4 interface plugged into the IPv4 network, and an IPv6 interface plugged into the IPv6 network 🦋 Packets that start in the IPv6 network and are headed for a receiver in the IPv4 network get routed through the IPv6 network to the NAT64 device. NAT64 translates them and forwards them out as IPv4 packets through the IPv4 network to the IPv4 receiver. It goes the other way too, for packets from IPv4-network hosts heading to an IPv6 receiver. ngl, NAT64 is not symmetric 💀 To do IPv6-to-IPv4 translation, NAT64 needs state. That state is a binding of an IPv6 address and TCP/UDP port (we'll call this an IPv6 transport address) to an IPv4 address and TCP/UDP port (we'll call this an IPv4 transport address) ✨
That binding state can be statically configured in the NAT64, or it gets created when the first packet flowing from the IPv6 network to the IPv4 network gets translated 🧚 Once the binding exists, packets flowing in both directions on that flow get translated. So in the general case, NAT64 only supports communications initiated by the IPv6-only node toward an IPv4-only node 😭 If you need an IPv4-only node to start a conversation with an IPv6-only node, you'd need some extra mechanisms (like ICE) or static binding configuration. iykyk 🫶
1.2.1. Stateful NAT64 Solution Elements 🎀
Here we break down the different pieces that make up the NAT64 approach 💜
The main star of the show is the translator itself 👑 It basically has two parts: the address translation mechanism and the protocol translation mechanism.
Protocol translation, meaning going from an IPv4 packet header to an IPv6 packet header and back, follows the IP/ICMP Translation Algorithm [RFC6145]. It's giving precision 🔥
Address translation maps IPv6 transport addresses to IPv4 transport addresses and vice versa. To make those mappings happen, the NAT64 has two pools of addresses: an IPv6 address pool (to represent IPv4 addresses in the IPv6 network) and an IPv4 address pool (to represent IPv6 addresses in the IPv4 network) 🌈
The IPv6 address pool is one or more IPv6 prefixes assigned to the translator itself. We'll call this pool Pref64::/n. If the NAT64 has more than one prefix, everything said about Pref64::/n applies to each of them 💖 The NAT64 uses Pref64::/n to build IPv4-Converted IPv6 addresses, as defined in [RFC6052]. There's so much IPv6 address space that you can assign one or more Pref64::/ns, and each one can be equal to or even bigger than the entire IPv4 address space ✨ That means every IPv4 address can get mapped to its own unique IPv6 address, just by sticking a Pref64::/n, the IPv4 address, and a suffix together 🦋 How to provision the Pref64::/n and the address format are both covered in [RFC6052] 📚
The IPv4 address pool is a set of IPv4 addresses, usually a prefix the local admin assigned 🍓 IPv4 space is scarce, so this pool is small and usually not big enough for permanent one-to-one mappings with IPv6 addresses. So, except for the static or manually created ones, mappings from the IPv4 pool get created and released dynamically 🌸 Also, because IPv4 is so scarce, the usual move for NAT64 is to bind IPv6 transport addresses to IPv4 transport addresses, instead of binding IPv6 addresses straight to IPv4 addresses. That way the limited IPv4 pool gets used way more efficiently 🧠 Basically, this means NAT64 does both address and port translation 💅
Here's the tea: the IPv6-to-IPv4 mapping is dynamic, but the IPv4-to-IPv6 mapping is static 🫶 Because of that, it's way simpler to allow communication started from the IPv6 side toward an IPv4 node, whose address gets algorithmically mapped into an IPv6 address, than to allow communication started from IPv4-only nodes toward an IPv6 node. In the second case, an IPv4 address has to be dynamically associated with the IPv6 node's address, which is a whole thing 😭
Using a mechanism like DNS64, an IPv6 client gets an IPv6 address that embeds the IPv4 address of the IPv4 server, then sends a packet to that IPv6 address 🧚 The NAT64 device intercepts those packets. It picks an IPv4 transport address out of its IPv4 pool and links it to the initiator's IPv6 transport address, creating binding state. That lets reply packets get translated and forwarded back to the initiator 💜 The binding state sticks around while packets keep flowing. Once the flow stops, a timer kicks in, and the IPv4 transport address goes back into the IPv4 address pool so it can be reused for other communications ⏳
To let an IPv6 initiator do a DNS lookup and find out the responder's address, DNS64 [RFC6147] synthesizes AAAA RRs from the A RRs 🌈 The IPv6 addresses in those synthetic AAAA RRs contain a Pref64::/n assigned to the NAT64, plus the responder's IPv4 address 🎀 The synthetic AAAA RRs get passed back to the IPv6 initiator, which then starts an IPv6 communication with an IPv6 address tied to the IPv4 receiver. That packet gets routed to the NAT64 device, which creates the IPv6-to-IPv4 address mapping just like we talked about before 👑✨
1.2.2. Stateful NAT64 Behavior Walk-Through ✨
okay so bestie, let's walk through what NAT64 actually does 🦋 we've got an IPv6 node that lives in an IPv6-only site, and it starts a TCP connection to an IPv4-only node sitting out in the IPv4 network. lowkey the coolest part is watching the packets hop back and forth 💖
here's the setup 🌸
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | network |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +-------+ | 192.0.2.1 |
|2001:db8::1|------| NAT64 |----| |
| | +-------+ | |
| | | | |
+---------------------+ +---------------+so H1 is the IPv6 node with the address 2001:db8::1 🎀 and H2 is the IPv4 node with the address 192.0.2.1. H2 goes by h2.example.com as its Fully Qualified Domain Name (FQDN) 💅
the NAT64 is the bridge between the two worlds ✨ it uses the Well-Known Prefix 64:ff9b::/96 from [RFC6052] to represent IPv4 addresses inside the IPv6 address space. it also has one IPv4 address, 203.0.113.1, on its IPv4 interface. the routing is set up so that any IPv6 packet headed for something in 64:ff9b::/96 gets sent to the IPv6 side of the NAT64 device 🧚
there's also a local name server with DNS64 functionality 🍓 it uses that same Well-Known Prefix 64:ff9b::/96 to build the IPv6 addresses inside the synthetic RRs.
for this example, assume the usual DNS setup, where IPv6 hosts only have stub resolvers and the local name server is the one doing the recursive lookups 🙈
here's how H1 gets to talk to H2 🫶
- H1 does a DNS query for
h2.example.comand gets back a synthetic AAAA RR from the local name server that does DNS64. the AAAA record holds an IPv6 address made from the Well-Known Prefix plus H2's IPv4 address, which is64:ff9b::192.0.2.1💜 - H1 sends a TCP SYN packet to H2 🔥 the packet goes from the source transport address
(2001:db8::1,1500)to the destination transport address(64:ff9b::192.0.2.1,80). H1 sets the ports itself. - the packet gets routed to the IPv6 interface of the NAT64, because that's how the IPv6 routing was configured 🌈
- the NAT64 gets the packet and does the following 👑
- the NAT64 picks an unused port (for example,
2000) on its IPv4 address203.0.113.1and makes the mapping entry(2001:db8::1,1500) <--> (203.0.113.1,2000)✨ - the NAT64 translates the IPv6 header into an IPv4 header using the IP/ICMP Translation Algorithm [RFC6145] 🦋
- the NAT64 puts
(203.0.113.1,2000)in as the source transport address of the packet, and(192.0.2.1,80)as the destination transport address. note that192.0.2.1gets pulled straight out of the destination IPv6 address of the received IPv6 packet that's being translated 🧠 the destination port80on the translated packet is the same as the destination port on the received IPv6 packet.
- the NAT64 picks an unused port (for example,
- the NAT64 sends the translated packet out of its IPv4 interface, and the packet shows up at H2 🎉
- H2 responds with a TCP SYN+ACK packet. the destination transport address is
(203.0.113.1,2000)and the source transport address is(192.0.2.1,80)💖 - since
203.0.113.1is assigned to the IPv4 interface of the NAT64 device, the packet gets routed to the NAT64 device. the NAT64 goes looking for an existing mapping that contains(203.0.113.1,2000)🔍 and since the mapping(2001:db8::1,1500) <--> (203.0.113.1,2000)exists, the NAT64 does the following:- the NAT64 translates the IPv4 header into an IPv6 header using the IP/ICMP Translation Algorithm [RFC6145] 💅
- the NAT64 puts
(2001:db8::1,1500)in as the destination transport address of the packet, and(64:ff9b::192.0.2.1,80)as the source transport address. note that192.0.2.1gets pulled straight out of the source IPv4 address of the received IPv4 packet that's being translated 🫧 the source port80on the translated packet is the same as the source port on the received IPv4 packet.
- the translated packet gets sent out of the IPv6 interface to H1 🌸
the packet exchange between H1 and H2 keeps going, and the packets get translated in the different directions the way we just described 🎀
here's the really important part, bestie 🚨 the translation still works even if the IPv6 initiator H1 learns H2's IPv6 representation (64:ff9b::192.0.2.1) through some method other than a DNS lookup. why? because DNS64 processing does NOT install any state in the NAT64, and mapping the IPv4 address to an IPv6 address is just a matter of sticking the Well-Known Prefix onto the original IPv4 address. no extra state, no drama 💜
that's the whole trick: the NAT64 only builds state when real traffic flows, not when DNS answers get handed out. iconic 👑
1.2.3. Filtering 🌷
okay next up is filtering 🦋 NAT64 can do filtering, which means it only lets a packet in through an interface when certain conditions are met. the NAT64 can filter IPv6 packets based on administrative rules, and those rules decide when entries get created in the binding and session tables. the filtering can be flexible and general, but the whole point is to give administrators the control they need to prevent denial-of-service (DoS) attacks that would drain the NAT64's IPv4 address, port, memory, and CPU resources 😭 filtering for incoming IPv6 packets isn't specific to NAT64, so this specification doesn't describe it 💅
filtering of incoming IPv4 packets is different, though. it's tightly coupled to the NAT64 state, so this specification does describe it ✨ in this document, the NAT64 may do no filtering, or it may filter incoming IPv4 packets 🌈
NAT64 filtering of incoming IPv4 packets is consistent with the recommendations of [RFC4787] and [RFC5382] 🙌 so the NAT64 in this spec supports both Endpoint-Independent Filtering and Address-Dependent Filtering, for both TCP and UDP, plus filtering of ICMP packets. main character energy 💖
if a NAT64 does Endpoint-Independent Filtering of incoming IPv4 packets, then an incoming IPv4 packet gets dropped unless the NAT64 has state for the destination transport address of that incoming packet 🫶
if a NAT64 does Address-Dependent Filtering of incoming IPv4 packets, then an incoming IPv4 packet gets dropped unless the NAT64 has state involving the destination transport address of that packet and the particular source IP address of that packet 🔥
2. Terminology ✨
okay bestie, this section is the glossary 📖 every term the doc uses gets defined here, so we're all on the same page 🫶
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].
Here are the extra terms the doc uses 💅
3-Tuple: this is (source IP address, destination IP address, ICMP Identifier) 🧚 It uniquely identifies an ICMP Query session. When an ICMP Query session goes through a NAT64, each session ends up with two different 3-tuples: one with IPv4 addresses and one with IPv6 addresses. Iconic.
5-Tuple: this is (source IP address, source port, destination IP address, destination port, transport protocol) 🎀 It uniquely identifies a UDP/TCP session. When a UDP/TCP session goes through a NAT64, each session gets two different 5-tuples too: one with IPv4 addresses and one with IPv6 addresses. Same energy as the 3-tuple, just more fields 💖
BIB: short for Binding Information Base 🌸 It's a table of bindings kept by a NAT64. Each NAT64 has a BIB for each translated protocol. An implementation that follows this doc would have one BIB for TCP, one for UDP, and one for ICMP Queries. Extra BIBs would get added to support other protocols, like SCTP.
Endpoint-Independent Mapping: in NAT64, this means using the same mapping for all the sessions involving a given IPv6 transport address of an IPv6 host, no matter what transport address the IPv4 host is using in the communication 🦋 It's super important for peer-to-peer communication. For the definitions of the different mapping types in IPv4-to-IPv4 NATs, check [RFC4787].
Filtering, Endpoint-Independent: the NAT64 only filters incoming IPv4 packets headed for a transport address that has no state in the NAT64, regardless of the source IPv4 transport address. Any packets headed for a transport address it has state for get forwarded. So having state for a given transport address is enough to let packets back to the internal endpoint ✨ For the different filtering types in IPv4-to-IPv4 NATs, see [RFC4787].
Filtering, Address-Dependent: the NAT64 filters incoming IPv4 packets headed for a transport address with no state, same as Endpoint-Independent Filtering 🙈 On top of that, it also filters out incoming IPv4 packets that come from a given IPv4 address X and are headed for a transport address it has state for, if the NAT64 hasn't sent packets to X before (no matter what port X used). So to receive packets from one specific IPv4 endpoint, the IPv6 endpoint has to send packets to that exact IPv4 endpoint's IP address first 🔥
Hairpinning: this is when a packet does a "U-turn" inside a NAT and comes back out the same side it came in on 🔄 If the destination IPv6 address and its embedded IPv4 address are both assigned to the NAT64 itself, then the packet is going to another IPv6 host connected to that same NAT64. A packet like that is called a 'hairpin packet'. A NAT64 that forwards hairpin packets back to the IPv6 host is said to support "hairpinning". This matters for peer-to-peer apps, because there are cases where two hosts on the same side of a NAT can only talk through sessions that hairpin 🫠 Hairpin packets can be TCP or UDP. For a more detailed explanation and UDP examples, look at [RFC4787].
ICMP Query packet: these are ICMP packets that aren't ICMP error messages 💅 For ICMPv6, ICMPv6 Query Messages are the ICMPv6 Informational messages defined in [RFC4443]. For ICMPv4, ICMPv4 Query messages are all ICMPv4 messages that aren't ICMPv4 error messages.
Mapping or Binding: a mapping between an IPv6 transport address and an IPv4 transport address, or a mapping between an (IPv6 address, ICMPv6 Identifier) pair and an (IPv4 address, ICMPv4 Identifier) pair 🎀 It's used to translate the addresses and ports / ICMP Identifiers of packets flowing between the IPv6 host and the IPv4 host. In NAT64, the IPv4 address and port / ICMPv4 Identifier is always one assigned to the NAT64 itself, while the IPv6 address and port / ICMPv6 Identifier belongs to some IPv6 host 🧚
Session: the flow of packets between two different hosts. This can be TCP, UDP, or ICMP Queries 🌈 In NAT64, usually one host is an IPv4 host and the other is an IPv6 host. But because of hairpinning, both hosts might be IPv6 hosts too.
Session table: a table of sessions kept by a NAT64 💖 Each NAT64 has three session tables: one for TCP, one for UDP, and one for ICMP Queries.
Stateful NAT64: a function that keeps per-flow state and translates IPv6 packets to IPv4 packets and back again, for TCP, UDP, and ICMP ✨ The NAT64 uses binding state to do the translation between IPv6 and IPv4 addresses. In this document, "stateful NAT64" is also just called "NAT64".
Stateful NAT64 device: the device where the NAT64 function runs 🦋 In this document, it's also called the "NAT64 device".
Transport Address: the combo of an IPv6 or IPv4 address and a port 🌸 It's usually written as (IP address,port), like (192.0.2.15,8001).
Tuple: refers to either a 3-tuple or a 5-tuple, as defined above 🫶
For a deep understanding of this document, you should also be familiar with NAT terminology in [RFC4787]. 🤓
3. Stateful NAT64 Normative Specification 💅
okay this is the part with the actual rules 📜 A NAT64 is a device with at least one IPv6 interface and at least one IPv4 interface. Each NAT64 device MUST have at least one unicast /n IPv6 prefix assigned to it, which is written as Pref64::/n. More details about Pref64::/n are in Section 3.5.4. A NAT64 MUST have one or more unicast IPv4 addresses assigned to it 🎀
A NAT64 uses these conceptual dynamic data structures:
- UDP Binding Information Base
- UDP Session Table
- TCP Binding Information Base
- TCP Session Table
- ICMP Query Binding Information Base
- ICMP Query Session Table
These tables hold the info the NAT64 needs for its processing 🧚 The info is split into six tables just to make the behavior easier to describe. NAT64 implementations are free to use different data structures, but they MUST store all the required information, and the externally visible outcome MUST be the same as what's described in this document. No cap, that's the important bit 🔥
Here's the notation the doc uses: uppercase letters are IPv4 addresses, uppercase letters with a prime (') are IPv6 addresses, lowercase letters are ports, IPv6 prefixes of length n are written as P::/n, and mappings are written as (X,x) <--> (Y',y) 🌈
3.1. Binding Information Bases 🦋
A NAT64 has three Binding Information Bases (BIBs): one for TCP, one for UDP, and one for ICMP Queries 💖 For the UDP and TCP BIBs, each entry specifies a mapping between an IPv6 transport address and an IPv4 transport address:
(X',x) <--> (T,t)Here X' is some IPv6 address, T is an IPv4 address, and x and t are ports. T will always be one of the IPv4 addresses assigned to the NAT64 ✨ The BIB has two columns: the BIB IPv6 transport address and the BIB IPv4 transport address. A given IPv6 or IPv4 transport address can show up in at most one entry in a BIB. For example, (2001:db8::17, 49832) can appear in at most one TCP BIB entry and at most one UDP BIB entry 🎀 TCP and UDP get separate BIBs because their port number spaces are distinct. If the BIBs are implemented as specified in this document, the NAT64 ends up with Endpoint-Independent Mappings 🫶 The info in the BIBs is also used to implement Endpoint-Independent Filtering. (Address-Dependent Filtering is implemented using the session tables described below 🙈)
For the ICMP Query BIB, each entry specifies a mapping between an (IPv6 address, ICMPv6 Identifier) pair and an (IPv4 address, ICMPv4 Identifier) pair:
(X',i1) <--> (T,i2)Here X' is some IPv6 address, T is an IPv4 address, i1 is an ICMPv6 Identifier, and i2 is an ICMPv4 Identifier. T will always be one of the IPv4 addresses assigned to the NAT64 💅 A given (IPv6 or IPv4 address, ICMPv6 or ICMPv4 Identifier) pair can show up in at most one entry in the ICMP Query BIB.
Entries in any of the three BIBs can get created dynamically from the flow of packets (more on that in Section 3.5), but an administrator can also create them manually. NAT64 implementations SHOULD support manually configured BIB entries for any of the three BIBs 🌸 Dynamically created entries get deleted from their BIB once the last session tied to that BIB entry is removed from the session table. Manually configured BIB entries aren't deleted just because there's no corresponding session table entry, and only an administrator can delete them 🔥
3.2. Session Tables 🎀
okay so a NAT64 has three session tables 📚: one for TCP sessions, one for UDP sessions, and one for ICMP Query sessions. Each entry keeps info on the state of its session. In the TCP and UDP session tables, each entry maps a pair of IPv6 transport addresses to a pair of IPv4 transport addresses:
(X',x),(Y',y) <--> (T,t),(Z,z)where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and x, y, z, and t are ports. T will always be one of the IPv4 addresses assigned to the NAT64 🫶. Y' is always the IPv6 representation of the IPv4 address Z, so Y' is obtained from Z using the algorithm the NAT64 uses to create IPv6 representations of IPv4 addresses. And y will always be equal to z 💅.
For each TCP or UDP Session Table Entry (STE), there are then five columns. The STE columns are written from the point of view of an incoming IPv6 packet being translated into an outgoing IPv4 packet 👀. The columns are:
- The STE source IPv6 transport address;
(X',x)in the example above. - The STE destination IPv6 transport address;
(Y',y)in the example above. - The STE source IPv4 transport address;
(T,t)in the example above. - The STE destination IPv4 transport address;
(Z,z)in the example above. - The STE lifetime.
In the ICMP Query session table, each entry maps a 3-tuple of IPv6 source address, IPv6 destination address, and ICMPv6 Identifier to a 3-tuple of IPv4 source address, IPv4 destination address, and ICMPv4 Identifier 🧚:
(X',Y',i1) <--> (T,Z,i2)where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, i1 is an ICMPv6 Identifier, and i2 is an ICMPv4 Identifier. T will always be one of the IPv4 addresses assigned to the NAT64. Y' is always the IPv6 representation of the IPv4 address Z, so Y' is obtained from Z using the algorithm the NAT64 uses to create IPv6 representations of IPv4 addresses. 🌸
For each ICMP Query Session Table Entry (STE), there are then seven columns:
- The STE source IPv6 address;
X'in the example above. - The STE destination IPv6 address;
Y'in the example above. - The STE ICMPv6 Identifier;
i1in the example above. - The STE source IPv4 address;
Tin the example above. - The STE destination IPv4 address;
Zin the example above. - The STE ICMPv4 Identifier;
i2in the example above. - The STE lifetime.
3.3. Packet Processing Overview 🦋
okay so the NAT64 uses the session state info to figure out when a session is completed 🏁, and it also uses session info for Address-Dependent Filtering. A session can be uniquely identified by either an incoming tuple or an outgoing tuple 💜.
For each TCP or UDP session, there's a matching BIB entry, uniquely specified by either the source IPv6 transport address (in the IPv6 --> IPv4 direction) or the destination IPv4 transport address (in the IPv4 --> IPv6 direction). For each ICMP Query session, there's a matching BIB entry, uniquely specified by either the source IPv6 address and ICMPv6 Identifier (in the IPv6 --> IPv4 direction) or the destination IPv4 address and the ICMPv4 Identifier (in the IPv4 --> IPv6 direction). BUT, for all the BIBs, a single BIB entry can have multiple corresponding sessions 🙈. When the last corresponding session is deleted, if the BIB entry was dynamically created, the BIB entry gets deleted too.
The NAT64 receives packets through its interfaces 📦. These packets can be IPv6 packets or IPv4 packets, and they may carry TCP traffic, UDP traffic, or ICMP traffic. The processing of the packets is described next. When the processing is common to all of those types, we'll just call the packet the incoming IP packet in general. When the processing is specific to IPv6 packets, we explicitly call it an incoming IPv6 packet, and the same goes for IPv4 packets ✨.
The processing of an incoming IP packet takes the following steps:
- Determining the incoming tuple
- Filtering and updating binding and session information
- Computing the outgoing tuple
- Translating the packet
- Handling hairpinning
The details of these steps are in the subsections below 📝.
This breakdown of the NAT64 behavior into processing steps is done just to make it easier to present. A NAT64 MAY perform the steps in a different order or MAY perform different steps, but the externally visible outcome MUST be the same as the one described in this document 🔥.
3.4. Determining the Incoming Tuple 🔍
this step attaches an incoming tuple to every incoming IP packet so the later steps can use it 🫧. For TCP, UDP, and ICMP error packets, the tuple is a 5-tuple made of the source IP address, source port, destination IP address, destination port, and transport protocol. For ICMP Queries, the tuple is a 3-tuple made of the source IP address, destination IP address, and ICMP Identifier.
If the incoming IP packet contains a complete (un-fragmented) UDP or TCP protocol packet, the 5-tuple is computed by pulling the right fields out of the received packet 💖.
If the incoming packet is a complete (un-fragmented) ICMP Query message (i.e., an ICMPv4 Query message or an ICMPv6 Informational message), the 3-tuple is the source IP address, the destination IP address, and the ICMP Identifier.
If the incoming IP packet contains a complete (un-fragmented) ICMP error message that contains a UDP or a TCP packet, the incoming 5-tuple is computed by pulling the right fields out of the IP packet embedded inside the ICMP error message 🕵️♀️. BUT the roles of source and destination get swapped here: the embedded source IP address becomes the destination IP address in the incoming 5-tuple, the embedded source port becomes the destination port in the incoming 5-tuple, and so on. If it's not possible to determine the incoming 5-tuple (maybe because not enough of the embedded packet is included in the ICMP message), then the incoming IP packet MUST be silently discarded 💀.
If the incoming IP packet contains a complete (un-fragmented) ICMP error message that contains an ICMP error message, then the packet is silently discarded 🙅♀️.
If the incoming IP packet contains a complete (un-fragmented) ICMP error message that contains an ICMP Query message, the incoming 3-tuple is computed by pulling the right fields out of the IP packet embedded inside the ICMP error message. Again the source and destination roles get swapped: the embedded source IP address becomes the destination IP address in the incoming 3-tuple, the embedded destination IP address becomes the source address in the incoming 3-tuple, and the embedded ICMP Identifier is used as the ICMP Identifier of the incoming 3-tuple. If it's not possible to determine the incoming 3-tuple (maybe because not enough of the embedded packet is included in the ICMP message), then the incoming IP packet MUST be silently discarded 🌈.
If the incoming IP packet contains a fragment, more processing might be needed 🧩. This specification leaves the exact details of how a NAT64 handles fragments up to the implementer, and it just requires that the external behavior of the NAT64 follows these conditions:
- The NAT64 MUST handle fragments. In particular, the NAT64 MUST handle fragments arriving out of order, conditional on the following:
- The NAT64 MUST limit the amount of resources devoted to storing fragmented packets, to protect against DoS attacks 🛡️.
- As long as the NAT64 has available resources, the NAT64 MUST allow the fragments to arrive over a time interval. The time interval SHOULD be configurable, and the default value MUST be of at least
FRAGMENT_MIN⏰. - The NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the fragment that has fragment offset equal to zero.
For incoming packets carrying TCP or UDP fragments with a non-zero checksum, the NAT64 MAY choose to queue the fragments as they arrive and translate all the fragments at the same time. In this case, the incoming tuple is determined as documented above for the un-fragmented packets. Alternatively, a NAT64 MAY translate the fragments as they arrive, by storing info that lets it compute the 5-tuple for fragments other than the first. In the latter case, later fragments may arrive before the first one, and the rules (in the bulleted list above) about how the NAT64 handles (out-of-order) fragments apply 🦄.
For incoming IPv4 packets carrying UDP packets with a zero checksum, if the NAT64 has enough resources, the NAT64 MUST reassemble the packets and MUST calculate the checksum. If the NAT64 doesn't have enough resources, then it MUST silently discard the packets. The handling of fragmented and un-fragmented UDP packets with a zero checksum, as specified above, deviates from what is specified in [RFC6145] 🤯.
Implementers of NAT64 should be aware that there are a number of well-known attacks against IP fragmentation; see [RFC1858] and [RFC3128]. Implementers should also be aware of additional issues with reassembling packets at high rates, described in [RFC4963] 😭.
If the incoming packet is an IPv6 packet that contains a protocol other than TCP, UDP, or ICMPv6 in the last Next Header, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 4 (Port Unreachable) to the source address of the received packet. NOTE: This behavior may be updated by future documents that define how other protocols, such as SCTP or DCCP, are processed by NAT64 🧃.
If the incoming packet is an IPv4 packet that contains a protocol other than TCP, UDP, or ICMPv4, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv4 Destination Unreachable error message with Code 2 (Protocol Unreachable) to the source address of the received packet. NOTE: This behavior may be updated by future documents that define how other protocols, such as SCTP or DCCP, are processed by NAT64 🌸.
3.5. Filtering and Updating Binding and Session Information 🫶
Okay so this step is where the NAT64 updates the binding and session info in the right tables 💅 and it may also filter incoming packets, if it wants to ✨
The details depend on the protocol, so UDP, TCP, or ICMP 🦋. The behaviors for UDP, TCP, and ICMP Queries get their own sections: Section 3.5.1, Section 3.5.2, and Section 3.5.3, respectively. ICMP error messages are the plot twist 🙈 because they don't affect the BIBs or the session tables in any way, so there's no processing for them in this section. Their processing picks up again in Section 3.6.
Irrespective of the transport protocol, the NAT64 MUST silently discard all incoming IPv6 packets containing a source address that contains the Pref64::/n. This is required to prevent hairpinning loops, which Section 5 covers in detail 🌀. The NAT64 MUST only process incoming IPv6 packets that contain a destination address that contains Pref64::/n. Likewise, the NAT64 MUST only process incoming IPv4 packets that contain a destination address that belongs to the IPv4 pool assigned to the NAT64 🍓
3.5.1. UDP Session Handling 🌸
The following state information is stored for a UDP session:
Binding:(X',x),(Y',y) <--> (T,t),(Z,z)Lifetime: a timer that tracks the remaining lifetime of the UDP session. When the timer expires, the UDP session is deleted. If all the UDP sessions corresponding to a dynamically created UDP BIB entry are deleted, then the UDP BIB entry is also deleted ⏳
An IPv6 incoming packet with an incoming tuple with source transport address (X',x) and destination transport address (Y',y) is processed like this:
The NAT64 searches for a UDP BIB entry that contains the BIB IPv6 transport address that matches the IPv6 source transport address (X',x). If no such entry exists, the NAT64 tries to create a new one (if resources and policy permit). The source IPv6 transport address of the packet (X',x) becomes the BIB IPv6 transport address, and the BIB IPv4 transport address is set to (T,t), which is allocated using the rules in Section 3.5.1.1. The result is a BIB entry that looks like this:
(X',x) <--> (T,t)The NAT64 searches for the Session Table Entry corresponding to the incoming 5-tuple. If no such entry is found, the NAT64 tries to create a new one (if resources and policy permit). The information in the session table is as follows:
- The STE source IPv6 transport address is set to (X',x), i.e., the source IPv6 transport address contained in the received IPv6 packet.
- The STE destination IPv6 transport address is set to (Y',y), i.e., the destination IPv6 transport address contained in the received IPv6 packet.
- The STE source IPv4 transport address is extracted from the corresponding UDP BIB entry, i.e., it is set to (T,t).
- The STE destination IPv4 transport is set to (Z(Y'),y), with y being the same port as the STE destination IPv6 transport address, and Z(Y') being algorithmically generated from the IPv6 destination address (i.e., Y') using the reverse algorithm (see Section 3.5.4) 🧚
The result is a Session Table Entry that looks like this:
(X',x),(Y',y) <--> (T,t),(Z(Y'),y)The NAT64 sets (or resets) the timer in the Session Table Entry to the maximum session lifetime. The maximum session lifetime MAY be configurable, and the default SHOULD be at least UDP_DEFAULT. The maximum session lifetime MUST NOT be less than UDP_MIN. The packet is then translated and forwarded as described in the following sections ✨
An IPv4 incoming packet, with an incoming tuple with source IPv4 transport address (W,w) and destination IPv4 transport address (T,t), is processed like this:
The NAT64 searches for a UDP BIB entry that contains the BIB IPv4 transport address matching (T,t), i.e., the IPv4 destination transport address in the incoming IPv4 packet. If no such entry exists, the packet MUST be dropped. An ICMP error message with Type 3 (Destination Unreachable) MAY be sent to the original sender of the packet 📬
If the NAT64 applies Address-Dependent Filters on its IPv4 interface, then the NAT64 checks whether the incoming packet is allowed according to the Address-Dependent Filtering rule. To do this, it searches for a Session Table Entry with an STE source IPv4 transport address equal to (T,t), i.e., the destination IPv4 transport address in the incoming packet, and an STE destination IPv4 address equal to W, i.e., the source IPv4 address in the incoming packet. If such an entry is found (there may be more than one), packet processing continues. Otherwise, the packet is discarded. If the packet is discarded, an ICMP error message MAY be sent to the original sender of the packet. The ICMP error message, if sent, has Type 3 (Destination Unreachable) and Code 13 (Communication Administratively Prohibited) 🚫
In case the packet is not discarded in the previous processing (either because the NAT64 is not filtering, or because the packet is compliant with the Address-Dependent Filtering rule), the NAT64 searches for the Session Table Entry containing the STE source IPv4 transport address equal to (T,t) and the STE destination IPv4 transport address equal to (W,w). If no such entry is found, the NAT64 tries to create a new one (if resources and policy permit). If a new UDP Session Table Entry is created, it contains the following information:
- The STE source IPv6 transport address is extracted from the corresponding UDP BIB entry.
- The STE destination IPv6 transport address is set to (Y'(W),w), with w being the same port w as the source IPv4 transport address, and Y'(W) being the IPv6 representation of W, generated using the algorithm described in Section 3.5.4.
- The STE source IPv4 transport address is set to (T,t), i.e., the destination IPv4 transport address contained in the received IPv4 packet.
- The STE destination IPv4 transport is set to (W,w), i.e., the source IPv4 transport address contained in the received IPv4 packet.
The NAT64 sets (or resets) the timer in the Session Table Entry to the maximum session lifetime. The maximum session lifetime MAY be configurable, and the default SHOULD be at least UDP_DEFAULT. The maximum session lifetime MUST NOT be less than UDP_MIN. The packet is then translated and forwarded as described in the following sections 💖
3.5.1.1. Rules for Allocation of IPv4 Transport Addresses for UDP 🎀
When a new UDP BIB entry is created for a source transport address of (S',s), the NAT64 allocates an IPv4 transport address for this BIB entry like this:
If there exists some other BIB entry containing S' as the IPv6 address and mapping it to some IPv4 address T, then the NAT64 SHOULD use T as the IPv4 address. Otherwise, it uses any IPv4 address of the IPv4 pool assigned to the NAT64 for translation.
If the port s is in the Well-Known port range 0-1023, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port. (This behavior is recommended in REQ 3-a of [RFC4787].)
If the port s is in the range 1024-65535, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port. (This behavior is recommended in REQ 3-a of [RFC4787].)
The NAT64 SHOULD preserve the port parity (odd/even), as per Section 4.2.2 of [RFC4787]).
In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but it can be in use in other BIBs (e.g., the UDP and TCP BIBs) 🔒
If it is not possible to allocate an appropriate IPv4 transport address or create a BIB entry, then the packet is discarded. The NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Address Unreachable) 🥺
3.5.2. TCP Session Handling 🌈
In this section, we describe how the TCP BIB and session table are populated. We do so by defining the state machine that the NAT64 uses for TCP. We first describe the states and the information contained in them, and then we describe the actual state machine and state transitions 🧠
3.5.2.1. State Definition
Okay bestie, let's talk about what the NAT64 actually stores for each TCP session 💅✨
Binding: (X',x),(Y',y) <--> (T,t),(Z,z)
Lifetime: a timer that tracks how much life the TCP session has left 🕰️ When the timer runs out, the TCP session gets deleted. And if every TCP session hanging off a TCP BIB entry is gone, then the dynamically created TCP BIB entry gets deleted too. Tidy 🧹🫶
Because the TCP session inactivity lifetime is set to at least 2 hours and 4 minutes (as per [RFC5382]), it is super important that each TCP Session Table Entry matches an existing TCP session 👀 So for every TCP session that gets established, the TCP connection state is tracked with the following state machine. It's giving organization 📋🦋
Here are the states:
CLOSED: Analogous to [RFC0793], CLOSED is a fictional state 👻 It just means there's no state for this particular 5-tuple, so there's no connection at all.V4 INIT: An IPv4 packet containing a TCP SYN came into the NAT64, which means a TCP connection is starting from the IPv4 side 🌸 The NAT64 is now waiting for a matching IPv6 packet with the TCP SYN going the opposite way.V6 INIT: An IPv6 packet containing a TCP SYN was received, translated, and forwarded by the NAT64, which means a TCP connection is starting from the IPv6 side 🧚 The NAT64 is now waiting for a matching IPv4 packet with the TCP SYN going the opposite way.ESTABLISHED: The connection is open and data can flow both ways 🔥 Main character energy.V4 FIN RCV: An IPv4 packet containing a TCP FIN came into the NAT64. Data can still flow in the connection, and the NAT64 is waiting for a matching TCP FIN going the other direction 🍓V6 FIN RCV: An IPv6 packet containing a TCP FIN came into the NAT64. Data can still flow in the connection, and the NAT64 is waiting for a matching TCP FIN going the other direction 💜V6 FIN + V4 FIN RCV: Both an IPv4 packet containing a TCP FIN and an IPv6 packet containing a TCP FIN for this connection came through the NAT64 ✨ The NAT64 keeps the connection state alive and forwards packets in both directions for a short while, so the leftover packets (especially the ACKs) can still get delivered 🫶TRANS: The lifetime of the connection's state is set toTCP_TRANSminutes. This happens either because a packet containing a TCP RST came through the NAT64 for this connection, or because the connection's lifetime has run down and onlyTCP_TRANSminutes are left ⏳ The NAT64 keeps the state forTCP_TRANSminutes. If no other data packets for that connection show up in that time, the state gets terminated 💀
3.5.2.2. State Machine for TCP Processing in the NAT64
Here's the state machine the NAT64 uses for TCP session processing 🦋 It handles all TCP segments received through the IPv6 and IPv4 interfaces. There's one state machine per TCP connection that could potentially get established through the NAT64. After the NAT64 device bootstraps, every TCP session is in the CLOSED state. Like we said above, CLOSED is fictional, meaning there's no state for that particular connection in the NAT64 🙈
Also, because there's one state machine per connection, only packets that belong to a given connection are inputs to that connection's state machine. So when the state machine below says a packet is received, it's implied that the incoming 5-tuple of the data packet matches the one for that state machine 🎀
A TCP segment with the SYN flag set that is received through the IPv6 interface is called a V6 SYN. Similarly, we have V4 SYN, V4 FIN, V6 FIN, V6 FIN + V4 FIN, V6 RST, and V4 RST 💖
The figure below is a simplified version of the state machine. For the full specification, refer to the text 📖
+-----------------------------+
| |
V |
V6 +------+ V4 |
+----SYN------|CLOSED|-----SYN------+ |
| +------+ | |
| ^ | |
| |TCP_TRANS T.O. | |
V | V |
+-------+ +-------+ +-------+ |
|V6 INIT| | TRANS | |V4 INIT| |
+-------+ +-------+ +-------+ |
| | ^ | |
| data pkt | | |
| | V4 or V6 RST | |
| | TCP_EST T.O. | |
V4 SYN V | V6 SYN |
| +--------------+ | |
+--------->| ESTABLISHED |<---------+ |
+--------------+ |
| | |
V4 FIN V6 FIN |
| | |
V V |
+---------+ +----------+ |
| V4 FIN | | V6 FIN | |
| RCV | | RCV | |
+---------+ +----------+ |
| | |
V6 FIN V4 FIN TCP_TRANS
| | T.O.
V V |
+---------------------+ |
| V4 FIN + V6 FIN RCV |--------------------+
+---------------------+Now the transitions, the fun part 🎉
CLOSED
If a V6 SYN is received with an incoming tuple whose source transport address is (X',x) and whose destination transport address is (Y',y) (this is a TCP connection started from the IPv6 side 🌈), the processing goes like this:
- The NAT64 looks for a TCP BIB entry that matches the IPv6 source transport address (X',x).
If no such entry exists, the NAT64 tries to create a new BIB entry (if resources and policy allow) 🙌 The BIB IPv6 transport address is set to (X',x), which is the source IPv6 transport address of the packet. The BIB IPv4 transport address is set to an IPv4 transport address allocated using the rules in Section 3.5.2.3. Then processing continues as described in bullet 2.
If the entry already exists, processing continues as described in bullet 2.
- Then the NAT64 tries to create a new TCP session entry in the TCP session table (if resources and policy allow) 🧁 The information in the session table looks like this:
- The STE source IPv6 transport address is set to (X',x), which is the source transport address in the received V6 SYN packet.
- The STE destination IPv6 transport address is set to (Y',y), which is the destination transport address in the received V6 SYN packet.
- The STE source IPv4 transport address is set to the BIB IPv4 transport address of the matching TCP BIB entry.
- The STE destination IPv4 transport address contains the port y (the same port as the IPv6 destination transport address) and the IPv4 address that is algorithmically generated from the IPv6 destination address (that is, Y') using the reverse algorithm in Section 3.5.4 🦋
- The lifetime of the TCP Session Table Entry is set to at least
TCP_TRANS(the transitory connection idle timeout defined in [RFC5382]) ⏰
- The state of the session moves to
V6 INIT🚀 - The NAT64 translates and forwards the packet as described in the following sections.
If a V4 SYN packet is received with an incoming tuple whose source IPv4 transport address is (Y,y) and whose destination IPv4 transport address is (X,x) (this is a TCP connection started from the IPv4 side 🌍), the processing goes like this:
- If the security policy says to silently drop externally initiated TCP connections, then the packet gets silently discarded 🚫
- Otherwise, if the destination transport address in the incoming V4 SYN (that is, (X,x)) is not in use in the TCP BIB, then:
- The NAT64 tries to create a new Session Table Entry in the TCP session table (if resources and policy allow), containing the following information:
- The STE source IPv4 transport address is set to (X,x), which is the destination transport address in the V4 SYN.
- The STE destination IPv4 transport address is set to (Y,y), which is the source transport address in the V4 SYN.
- The STE transport IPv6 source address is left unspecified and may be filled in by other protocols that are outside the scope of this specification 🧩
- The STE destination IPv6 transport address contains the port y (the same port as the STE destination IPv4 transport address) and the IPv6 representation of Y (that is, the IPv4 address of the STE destination IPv4 transport address), generated using the algorithm described in Section 3.5.4 ✨
- The state moves to
V4 INIT🌸 - The lifetime of the STE entry is set to
TCP_INCOMING_SYNas per [RFC5382], and the packet is stored. The result is that the NAT64 won't drop the packet based on filtering, and it won't create a BIB entry either. Instead, it only creates the Session Table Entry and stores the packet. The reason for this is to support simultaneous open of TCP connections 🤝
- The NAT64 tries to create a new Session Table Entry in the TCP session table (if resources and policy allow), containing the following information:
- If the destination transport address in the incoming V4 SYN (that is, (X,x)) is in use in the TCP BIB, then:
- The NAT64 tries to create a new Session Table Entry in the TCP session table (if resources and policy allow), containing the following information:
- The STE source IPv4 transport address is set to (X,x), which is the destination transport address in the V4 SYN.
- The STE destination IPv4 transport address is set to (Y,y), which is the source transport address in the V4 SYN.
- The STE transport IPv6 source address is set to the IPv6 transport address contained in the corresponding TCP BIB entry 💜
- The NAT64 tries to create a new Session Table Entry in the TCP session table (if resources and policy allow), containing the following information:
The STE destination IPv6 transport address has port y (the same port as the STE destination IPv4 transport address) and the IPv6 representation of Y (the IPv4 address in the STE destination IPv4 transport address). It's generated with the algorithm in Section 3.5.4 💖
The state moves to V4 INIT 🌸
If the NAT64 is doing Address-Dependent Filtering, the STE lifetime gets set to TCP_INCOMING_SYN as per [RFC5382], and the packet gets stored. Why keep the Session Table Entry and store the packet instead of just dropping it because of the filtering? So simultaneous open of TCP connections still works 🦋
If the NAT64 is not doing Address-Dependent Filtering, the STE lifetime is set to at least TCP_TRANS (the transitory connection idle timeout as defined in [RFC5382]), and it translates and forwards the packet as described in the following sections ✨
For any other packet in this connection:
If there's a matching entry in the TCP BIB, the packet SHOULD be translated and forwarded if the security policy allows it. The state stays the same 🎀
If there's no matching entry in the TCP BIB, the packet gets silently discarded 🙈
V4 INIT 🧚
If a V6 SYN comes in with an incoming tuple whose source transport address is (X',x) and destination transport address is (Y',y), the lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default for the maximum session lifetime SHOULD be TCP_EST. The packet gets translated and forwarded, and the state moves to ESTABLISHED 💅
If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code 3) carrying the stored IPv4 SYN packet is sent back to the source of the v4 SYN, the Session Table Entry is deleted, and the state moves to CLOSED 💀
For any other packet, the packet SHOULD be translated and forwarded if the security policy allows it. The state stays the same 🌈
V6 INIT 👑
If a V4 SYN comes in (with or without the ACK flag set), with an incoming tuple whose source IPv4 transport address is (Y,y) and destination IPv4 transport address is (X,x), the state moves to ESTABLISHED. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. That maximum MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default for the maximum session lifetime SHOULD be TCP_EST. The packet gets translated and forwarded ✨
If the lifetime expires, the Session Table Entry is deleted and the state moves to CLOSED 🫶
If a V6 SYN packet is received, it gets translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least TCP_TRANS. The state stays the same 🦋
For any other packet, the packet SHOULD be translated and forwarded if the security policy allows it. The state stays the same 🌸
ESTABLISHED 💖
If a V4 FIN packet is received, it gets translated and forwarded. The state moves to V4 FIN RCV 👋
If a V6 FIN packet is received, it gets translated and forwarded. The state moves to V6 FIN RCV 👋
If a V4 RST or a V6 RST packet is received, it gets translated and forwarded. The lifetime is set to TCP_TRANS and the state moves to TRANS. This one's a little dramatic 😭 The NAT64 isn't sure the peer will accept the RST, so instead of jumping straight to CLOSED, it goes to TRANS, which has a shorter lifetime. If no other packets show up for this connection during that short timer, the NAT64 assumes the peer accepted the RST and moves to CLOSED. If packets keep flowing, it assumes the peer did not accept the RST and moves back to the ESTABLISHED state. The TRANS state processing description below covers this 🔥
If any other packet is received, it gets translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. That maximum MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default for the maximum session lifetime SHOULD be TCP_EST. The state stays ESTABLISHED 💅
If the lifetime expires, the NAT64 SHOULD send a probe packet (defined next) to at least one of the endpoints of the TCP connection. The probe packet is a TCP segment for the connection with no data. The sequence number and the acknowledgment number are both set to zero. All flags except the ACK flag are set to zero. The state moves to TRANS 🍓
When the probe packet arrives, the endpoint replies with an ACK containing the expected sequence number for that connection. Heads up 👀 for an active connection, every probe packet ends up generating one packet from each end, because the first endpoint's reply to the probe triggers a reply from the other endpoint ✨
V4 FIN RCV 🌈
If a V6 FIN packet is received, it gets translated and forwarded. The lifetime is set to TCP_TRANS and the state moves to V6 FIN + V4 FIN RCV 🎀
If any packet other than a V6 FIN is received, it gets translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. That maximum MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default for the maximum session lifetime SHOULD be TCP_EST. The state stays V4 FIN RCV 🫶
If the lifetime expires, the Session Table Entry is deleted and the state moves to CLOSED 💀
V6 FIN RCV 🧚
If a V4 FIN packet is received, it gets translated and forwarded. The lifetime is set to TCP_TRANS and the state moves to V6 FIN + V4 FIN RCV 🎀
If any packet other than a V4 FIN is received, it gets translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. That maximum MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default for the maximum session lifetime SHOULD be TCP_EST. The state stays V6 FIN RCV 🦋
If the lifetime expires, the Session Table Entry is deleted and the state moves to CLOSED 💀
V6 FIN + V4 FIN RCV 🏁
All packets get translated and forwarded ✨
If the lifetime expires, the Session Table Entry is deleted and the state moves to CLOSED 💀
TRANS 🌙
If a packet other than a RST packet is received, the lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. That maximum MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default for the maximum session lifetime SHOULD be TCP_EST. The state moves to ESTABLISHED 💖
If the lifetime expires, the Session Table Entry is deleted and the state moves to CLOSED 💀
3.5.2.3. Rules for Allocation of IPv4 Transport Addresses for TCP 🎀
When a new TCP BIB entry gets created for a source transport address of (S',s), the NAT64 allocates an IPv4 transport address for this BIB entry like so:
If there's already some other BIB entry in any of the BIBs that has S' as its IPv6 address and maps it to some IPv4 address T, then T SHOULD be used as the IPv4 address. Otherwise, use any IPv4 address from the IPv4 pool assigned to the NAT64 for translation 🌸
If the port s is in the Well-Known port range 0-1023, and the NAT64 has an available port t in that same range, then the NAT64 SHOULD allocate port t. If the NAT64 doesn't have a port available in that range, the NAT64 MAY assign a port t from another range where it has one available 🧚
If the port s is in the range 1024-65535, and the NAT64 has an available port t in that same range, then the NAT64 SHOULD allocate port t. If the NAT64 doesn't have a port available in that range, the NAT64 MAY assign a port t from another range where it has one available 🦋
In all cases, the allocated IPv4 transport address (T,t) MUST NOT already be in use by another entry in the same BIB, though it can be in use in other BIBs (for example, the UDP and TCP BIBs) 👑
If it's not possible to allocate an appropriate IPv4 transport address or create a BIB entry, the packet is discarded. The NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Address Unreachable) 🙈
3.5.3. ICMP Query Session Handling
okay so this is where the ICMP Query sessions get their own little table and their own life cycle 🧚💖 each session gets stored as a binding, (X',Y',i1) <--> (T,Z,i2), and it has a lifetime timer ⏳ that ticks down. when the timer hits zero the session is deleted, and if every session hanging off a dynamically created ICMP Query BIB entry is gone, that BIB entry gets deleted too. no loose ends bestie 💅
When an incoming ICMPv6 Informational packet shows up with IPv6 source address X', IPv6 destination address Y', and ICMPv6 Identifier i1, here's the vibe:
- If local security policy says ICMPv6 Informational packets get filtered, the packet is silently discarded 🙈
- Otherwise, the NAT64 looks for an ICMP Query BIB entry matching the (X',i1) pair. If there isn't one, it tries to make a new entry (if resources and policy allow) with:
- the BIB IPv6 address set to X' (aka the source IPv6 address of the packet) 🎀
- the BIB ICMPv6 Identifier set to i1 (aka the ICMPv6 Identifier)
- if some other BIB entry in any of the BIBs already has the same IPv6 address X' and maps it to an IPv4 address T, then T becomes the BIB IPv4 address for this new entry. otherwise, any IPv4 address assigned to the IPv4 interface works 🌸
- any available value as the BIB ICMPv4 Identifier, meaning any identifier value where no other entry already has the same (IPv4 address, ICMPv4 Identifier) pair ✨
Then the NAT64 searches for an ICMP Query Session Table Entry matching the incoming 3-tuple (X',Y',i1). If none is found, it tries to create one (if resources and policy allow), and the new entry looks like this:
- STE IPv6 source address = X' (the address in the received IPv6 packet) 🦋
- STE IPv6 destination address = Y' (the address in the received IPv6 packet) 🦋
- STE ICMPv6 Identifier = i1 (the identifier in the received IPv6 packet) 🦋
- STE IPv4 source address = the IPv4 address in the matching BIB entry 🍓
- STE ICMPv4 Identifier = the IPv4 identifier in the matching BIB entry 🍓
- STE IPv4 destination address = algorithmically generated from Y' using the reverse algorithm in Section 3.5.4 🧚
The NAT64 sets (or resets) the session's timer to the maximum session lifetime. By default the maximum session lifetime is ICMP_DEFAULT, and the maximum lifetime value SHOULD be configurable 🫶. Then the packet gets translated and forwarded, as the following sections explain.
When an incoming ICMPv4 Query packet shows up with source IPv4 address Y, destination IPv4 address X, and ICMPv4 Identifier i2, the NAT64 does this:
- It looks for an ICMP Query BIB entry that has X as the IPv4 address and i2 as the ICMPv4 Identifier. If there isn't one, the packet is dropped. An ICMP error message MAY be sent back to the original sender, and if it is, it has Type 3, Code 1 (Host Unreachable) 💀
- If the NAT64 filters on its IPv4 interface, it checks whether the packet is allowed under the Address-Dependent Filtering rule. It searches for a Session Table Entry with STE source IPv4 address equal to X, STE ICMPv4 Identifier equal to i2, and STE destination IPv4 address equal to Y. If one is found (there can be more than one), processing continues. Otherwise the packet is discarded, and an ICMP error message MAY be sent to the original sender. If sent, that error has Type 3 (Destination Unreachable) and Code 13 (Communication Administratively Prohibited) 🔥
- If the packet survived the steps above (either because the NAT64 isn't filtering, or because the packet follows the Address-Dependent Filtering rule), the NAT64 searches for a Session Table Entry with STE source IPv4 address equal to X, STE ICMPv4 Identifier equal to i2, and STE destination IPv4 address equal to Y. If none is found, it tries to create one (if resources and policy allow) with:
- STE source IPv4 address = X 🌈
- STE ICMPv4 Identifier = i2 🌈
- STE destination IPv4 address = Y 🌈
- STE source IPv6 address = the IPv6 address of the matching BIB entry 👑
- STE ICMPv6 Identifier = the ICMPv6 Identifier of the matching BIB entry 👑
- STE destination IPv6 address = the IPv6 representation of the IPv4 address Y, generated with the algorithm in Section 3.5.4 👑
- the timer set to the maximum session lifetime (the NAT64 sets or resets it). By default that's ICMP_DEFAULT, and the maximum lifetime value SHOULD be configurable. Then the packet is translated and forwarded as the following sections describe ✨
3.5.4. Generation of the IPv6 Representations of IPv4 Addresses
ngl this section is the glue that makes the whole NAT64 thing reversible 🧠 NAT64 supports multiple algorithms for turning an IPv4 address into its IPv6 representation and back again 🔄 The constraints on those algorithms are:
- The algorithm MUST be reversible. In other words, it MUST be possible to get the original IPv4 address back from the IPv6 representation 💖
- The input to the algorithm MUST be limited to the IPv4 address, the IPv6 prefix (written Pref64::/n) used in the IPv6 representations, and optionally a set of stable parameters configured in the NAT64 (like a fixed string used as a suffix) 🎀
If the length of the prefix Pref64::/n is n, then n MUST be less than or equal to 96. If a Pref64::/n is configured in the NAT64 by any means (manually, or through other automatic means not specified in this document), the default algorithm MUST use that prefix. If no prefix is available, the algorithm SHOULD use the Well-Known Prefix (64:ff9b::/96) defined in [RFC6052] 🌸
NAT64 MUST support the algorithm for generating IPv6 representations of IPv4 addresses defined in Section 2.3 of [RFC6052]. That algorithm SHOULD be used as the default algorithm 🦋
3.6. Computing the Outgoing Tuple
this step is where the outgoing tuple gets made by translating the IP addresses and port numbers (or ICMP Identifier) in the incoming tuple 💅
In the text below, "BIB" means the TCP BIB, the UDP BIB, or the ICMP Query BIB, whichever one applies 🧚
NOTE: Not all addresses get translated using the BIB! BIB entries are only used to translate IPv6 source transport addresses to IPv4 source transport addresses, and IPv4 destination transport addresses to IPv6 destination transport addresses. They are NOT used to translate IPv6 destination transport addresses to IPv4 destination transport addresses, or IPv4 source transport addresses to IPv6 source transport addresses. Those cases use the algorithmic transformation from Section 3.5.4 instead. This distinction matters a lot, because without it, hairpinning doesn't work correctly 😭
3.6.1. Computing the Outgoing 5-Tuple for TCP, UDP, and for ICMP Error Messages Containing a TCP or UDP Packets
the transport protocol in the outgoing 5-tuple is always the same as the one in the incoming 5-tuple 🫶 When translating from IPv4 ICMP to IPv6 ICMP, the protocol number in the last next header field of the protocol chain is set to 58 (IPv6-ICMP). When translating from IPv6 ICMP to IPv4 ICMP, the protocol number in the protocol field of the IP header is set to 1 (ICMP) 🌈
When translating in the IPv6 --> IPv4 direction, let the source and destination transport addresses in the incoming 5-tuple be (S',s) and (D',d), respectively. The outgoing source transport address is computed like this: if the BIB contains an entry (S',s) <--> (T,t), then the outgoing source transport address is (T,t) ✨
The outgoing destination address is computed algorithmically from D' using the address transformation in Section 3.5.4 🧚
When translating in the IPv4 --> IPv6 direction, let the source and destination transport addresses in the incoming 5-tuple be (S,s) and (D,d), respectively. The outgoing source transport address is computed as follows:
- The outgoing source transport address is generated from S using the address transformation algorithm in Section 3.5.4 💜
- The BIB table is searched for an entry (X',x) <--> (D,d), and if one is found, the outgoing destination transport address is set to (X',x) 🍓
3.6.2. Computing the Outgoing 3-Tuple for ICMP Query Messages and for ICMP Error Messages Containing an ICMP Query
When translating in the IPv6 --> IPv4 direction, let the source and destination addresses in the incoming 3-tuple be S' and D', respectively, and the ICMPv6 Identifier be i1. The outgoing source address is computed as follows: if the BIB contains an entry (S',i1) <--> (T,i2), then the outgoing source address is T and the ICMPv4 Identifier is i2 🌸
The outgoing IPv4 destination address is computed algorithmically from D' using the address transformation in Section 3.5.4 💖
When translating in the IPv4 --> IPv6 direction, let the source and destination addresses in the incoming 3-tuple be S and D, respectively, and the ICMPv4 Identifier be i2. The outgoing source address is generated from S using the address transformation algorithm in Section 3.5.4. The BIB is searched for an entry containing (X',i1) <--> (D,i2), and, if found, the outgoing destination address is X' and the outgoing ICMPv6 Identifier is i1 🦋
3.7. Translating the Packet ✨
Okay bestie, this is where the packet gets its glow-up 💅 It goes from IPv6 to IPv4 (or the other way around) 🦋
The translation follows Sections 4 and 5 of the IP/ICMP Translation Algorithm [RFC6145], with a few extra tweaks:
- When translating an IP header (Sections 4.1 and 5.1 of [RFC6145]), the source and destination IP address fields get set to the source and destination IP addresses from the outgoing tuple, as determined in Section 3.6 🎀
- When the protocol after the IP header is TCP or UDP, the source and destination ports get changed to the source and destination ports from the outgoing 5-tuple. The TCP or UDP checksum also needs an update to match the translated addresses and ports, since that checksum covers the pseudo-header holding the source and destination IP addresses. There's an algorithm for updating these checksums efficiently in [RFC3022] 🧚
- When the protocol after the IP header is ICMP and it's an ICMP Query message, the ICMP Identifier gets set to the one from the outgoing 3-tuple, as determined in Section 3.6.2 🌸
- When the protocol after the IP header is ICMP and it's an ICMP error message, the source and destination transport addresses in the embedded packet get set to the destination and source transport addresses from the outgoing 5-tuple. Yes, they swap! Main character plot twist 🔥
Packet size, and whether fragmentation is needed, is handled according to the behaviour defined in the IP/ICMP Translation Algorithm [RFC6145]. Bestie, read that one twice 💜
3.8. Handling Hairpinning ✨
Okay, so here's the hairpin situation 🙈 If the destination IP address of the translated packet is an IPv4 address assigned to the NAT64 itself, then the packet is a hairpin packet. Hairpin packets get processed like this:
- The outgoing 5-tuple becomes the incoming 5-tuple.
- The packet is treated as if it was received on the outgoing interface.
- Processing of the packet continues at step 2 -- "Filtering and Updating Binding and Session Information" (Section 3.5).
4. Protocol Constants 🎀
Here are the timer and constant values, all in one cute little list 💖
UDP_MIN: 2 minutes (as defined in [RFC4787])UDP_DEFAULT: 5 minutes (as defined in [RFC4787])TCP_TRANS: 4 minutes (as defined in [RFC5382])TCP_EST: 2 hours (The minimum lifetime for an established TCP session defined in [RFC5382] is 2 hours and 4 minutes, which is achieved by adding the 2 hours with this timer and the 4 minutes with theTCP_TRANStimer.) ⏰TCP_INCOMING_SYN: 6 seconds (as defined in [RFC5382])FRAGMENT_MIN: 2 secondsICMP_DEFAULT: 60 seconds (as defined in [RFC5508])
5. Security Considerations 🚨
Okay, this part is serious, so let's actually pay attention 🫶
5.1. Implications on End-to-End Security
Any protocols that protect IP header information are basically incompatible with NAT64. Fr fr. That means end-to-end IPsec verification will fail when the Authentication Header (AH) is used (in both transport and tunnel mode), and when ESP is used in transport mode. This is inherent to any network-layer translation mechanism, so it's not a NAT64 bug, it's just physics 😭 End-to-end IPsec protection can be restored by using UDP encapsulation, as described in [RFC3948]. The actual extensions to support IPsec are out of scope for this document.
5.2. Filtering
NAT64 creates binding state using packets flowing from the IPv6 side to the IPv4 side. Following the procedures in this document and the guidelines in [RFC4787], a NAT64 MUST offer "Endpoint-Independent Mapping". Here's what that means:
For any IPv6 packet with source (S'1,s1) and destination
(Pref64::D1,d1) that creates an external mapping to (S1,s1v4),
(D1,d1), for any subsequent packet from (S'1,s1) to
(Pref64::D2,d2) that creates an external mapping to (S2,s2v4),
(D2,d2), within a given binding timer window,
(S1,s1v4) = (S2,s2v4) for all values of D2,d2Implementations MAY also support "Address-Dependent Mapping", which is also defined in this document. They should follow the guidelines defined in [RFC4787] for it too 🦋
Now the tea ☕ The security properties are determined by which packets the NAT64 filter lets in and which it doesn't. They come from the filtering behaviour and filtering configuration in the filtering portions of the NAT64, not from the address mapping behaviour. For example:
Without filtering - When "Endpoint-Independent Mapping" is used in
NAT64, once a binding is created in the IPv6 ---> IPv4 direction,
packets from any node on the IPv4 side destined to the IPv6
transport address will traverse the NAT64 gateway and be forwarded
to the IPv6 transport address that created the binding. However,
With filtering - When "Endpoint-Independent Mapping" is used in
NAT64, once a binding is created in the IPv6 ---> IPv4 direction,
packets from any node on the IPv4 side destined to the IPv6
transport address will first be processed against the filtering
rules. If the source IPv4 address is permitted, the packets will
be forwarded to the IPv6 transport address. If the source IPv4
address is explicitly denied -- or the default policy is to deny
all addresses not explicitly permitted -- then the packet will be
discarded. A dynamic filter may be employed whereby the filter
will only allow packets from the IPv4 address to which the
original packet that created the binding was sent. This means
that only the IPv4 addresses to which the IPv6 host has initiated
connections will be able to reach the IPv6 transport address, and
no others. This essentially narrows the effective operation of
the NAT64 device to an "Address-Dependent Mapping" behavior,
though not by its mapping behavior, but instead by its filtering
behavior.As currently specified, the NAT64 only requires filtering traffic based on the 5-tuple. In some cases (for example, statically configured mappings), this may make it easy for an attacker to guess. An attacker doesn't need to guess other fields, like the TCP sequence number, to get a packet through the NAT64. Sure, that traffic might be dropped by the final destination, but it doesn't protect against bandwidth or CPU attacks aimed at the internal network 💀 To avoid this kind of abuse, a NAT64 MAY keep track of the sequence number of TCP packets, so it can verify the proper sequencing of exchanged segments, particularly those of the SYNs and the FINs 🔒
5.3. Attacks on NAT64
The NAT64 device is itself a potential victim of different attacks. In particular, the NAT64 can be a victim of DoS attacks. It has a limited number of resources that attackers can consume, and a limited number of IPv4 addresses it uses to create bindings. Even though the NAT64 does address and port translation, an attacker could consume all the IPv4 transport addresses by sending IPv6 packets with different source IPv6 transport addresses. This attack can only be launched from the IPv6 side, since IPv4 packets aren't used to create binding state 🙅♀️ DoS attacks can also affect other limited resources in the NAT64, like memory or link capacity. For instance, an attacker could DoS the NAT64's memory by sending fragments that the NAT64 stores for a given period. If there are enough fragments, the NAT64's memory could be exhausted.
Similarly, a DoS attack against the NAT64 can be crafted by sending either V4 or V6 SYN packets that eat up memory in the form of session and/or binding table entries. With IPv4 SYNs, it's even worse, because the NAT64 also has to store the data packets for a given amount of time, which takes even more memory. NAT64 devices MUST implement proper protection against such attacks. For example, they can allocate a limited amount of memory for fragmented packet storage, as specified in Section 3.4 🛡️
Another concern related to NAT64 resource depletion is the preservation of binding state. Attackers may try to keep a binding alive forever by sending periodic packets that refresh it. To let the NAT64 defend against this, the NAT64 MAY choose not to extend the session entry lifetime for a specific entry when it receives packets for that entry through the external interface. As described in the framework document [RFC6144], the NAT64 can be deployed in multiple scenarios. In some of them, the Internet side is the IPv6 one, and in others, it's the IPv4 one. So it's really important to set which side is the Internet side of the NAT64 correctly in each configuration 🌐
5.4. Avoiding Hairpinning Loops
If an IPv6-only client can guess the IPv4 binding address that will be created, it can use the IPv6 representation of that address as the source address when creating this binding. Then any packet sent to the binding's IPv4 address could loop in the NAT64. The current specification prevents this by filtering incoming packets that contain Pref64::/n in the source address, as described below 🔁
Here's an example:
Suppose that the IPv4 pool is 192.0.2.0/24
Then, the IPv6-only client sends this to NAT64:
Source: [Pref64::192.0.2.1]:500
Destination: anyThe NAT64 allocates 192.0.2.1:500 as the IPv4 binding address. Now anything sent to 192.0.2.1:500, whether it's a hairpinned IPv6 packet or an IPv4 packet, could loop 😱
It's not hard to guess the IPv4 address that will be allocated. First, the attacker creates a binding and uses, for example, Simple Traversal of the UDP Protocol through NAT (STUN) [RFC5389] to learn its external IPv4 address. New bindings will always have this address. Then the attacker uses a source port in the range 1-1023. This raises the chances to 1/512, since range and parity are preserved by NAT64 in UDP 🎯
To address this vulnerability, the NAT64 MUST drop IPv6 packets whose source address is in Pref64::/n, as defined in Section 3.5. No exceptions, bestie 🚫
6. Contributors 💜
Huge thanks to these people for their work on the spec ✨
- George Tsirtsis
- Qualcomm
- tsirtsis@googlemail.com
- Greg Lebovitz
- Juniper
- gregory.ietf@gmail.com
- Simon Perreault
- Viagenie
- simon.perreault@viagenie.ca
7. Acknowledgements 🫶
Dave Thaler, Dan Wing, Alberto Garcia-Martinez, Reinaldo Penno, Ranjana Rao, Lars Eggert, Senthil Sivakumar, Zhen Cao, Xiangsong Cui, Mohamed Boucadair, Dong Zhang, Bryan Ford, Kentaro Ebisawa, Charles Perkins, Magnus Westerlund, Ed Jankiewicz, David Harrington, Peter McCann, Julien Laganier, Pekka Savola, and Joao Damas reviewed the document and gave really useful comments to make it better 👑
The content was also improved thanks to discussions with Christian Huitema, Fred Baker, and Jari Arkko 🌸
Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program 🇪🇺
8. References 📚
8.1. Normative References 📚✨
okay so these are the docs this whole spec literally can't function without 💅 if you want the full picture, you gotta read these too:
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🎀
- [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 🌸
- [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. 🦋
- [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. 💜
- [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009. 🧚
- [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. ⭐
- [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. 👑
8.2. Informative References 🫶
these ones are more of a "good to know" vibe, not a "must read or the code breaks" vibe, but honestly they're iconic and you'll want them 🍓
- [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 💅
- [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. 🙈
- [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 🌈
- [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001. 🔥
- [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. 🩷
- [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007. 💀
- [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. 🎀
- [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. 🦋
- [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011. 🌸
- [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, April 2011. ✨
Authors' Addresses 💌
the people who wrote this, and how to reach them if you're feeling brave 🫶
Marcelo Bagnulo
UC3M
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +34-91-6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Philip Matthews
Alcatel-Lucent
600 March Road
Ottawa, Ontario
Canada
Phone: +1 613-592-4343 x224
EMail: philip_matthews@magma.ca
Iljitsch van Beijnum
IMDEA Networks
Avda. del Mar Mediterraneo, 22
Leganes, Madrid 28918
Spain
EMail: iljitsch@muada.comthat's the whole thing, bestie 🌈💖 you made it through the entire RFC, I'm so proud of you 😭🎀
📦 where this page comes from
- ietf: rfc6146 2011-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms