diff options
Diffstat (limited to 'doc/rfc/rfc6146.txt')
| -rw-r--r-- | doc/rfc/rfc6146.txt | 2523 |
1 files changed, 2523 insertions, 0 deletions
diff --git a/doc/rfc/rfc6146.txt b/doc/rfc/rfc6146.txt new file mode 100644 index 0000000..d8228ae --- /dev/null +++ b/doc/rfc/rfc6146.txt @@ -0,0 +1,2523 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Bagnulo +Request for Comments: 6146 UC3M +Category: Standards Track P. Matthews +ISSN: 2070-1721 Alcatel-Lucent + I. van Beijnum + IMDEA Networks + April 2011 + + + Stateful NAT64: Network Address and Protocol Translation + from IPv6 Clients to IPv4 Servers + +Abstract + + This document describes stateful NAT64 translation, which allows + IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or + ICMP. One or more public IPv4 addresses assigned to a NAT64 + translator are shared among several IPv6-only clients. When stateful + NAT64 is used in conjunction with DNS64, no changes are usually + required in the IPv6 client or the IPv4 server. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6146. + + + + + + + + + + + + + + + + + +Bagnulo, et al. Standards Track [Page 1] + +RFC 6146 Stateful NAT64 April 2011 + + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo, et al. Standards Track [Page 2] + +RFC 6146 Stateful NAT64 April 2011 + + +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 . . . . . . . . . . . . . . . . . . 44 + + + + + +Bagnulo, et al. Standards Track [Page 3] + +RFC 6146 Stateful NAT64 April 2011 + + +1. Introduction + + This document specifies stateful NAT64, a mechanism for IPv4-IPv6 + transition and IPv4-IPv6 coexistence. Together with DNS64 [RFC6147], + these two mechanisms allow an IPv6-only client to initiate + communications to an IPv4-only server. They also enable peer-to-peer + communication between an IPv4 and an IPv6 node, where the + communication can be initiated when either end uses existing, NAT- + traversal, peer-to-peer communication techniques, such as 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 vice versa. The translation is done by translating the + packet headers according to the IP/ICMP Translation Algorithm defined + in [RFC6145]. The IPv4 addresses of IPv4 hosts are algorithmically + translated to and from IPv6 addresses by 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 are + 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, including the Stream Control + Transmission Protocol (SCTP), the Datagram Congestion Control + Protocol (DCCP), and IPsec, are out of the scope of this + specification. + + DNS64 is a mechanism for synthesizing AAAA resource records (RRs) + from A RRs. The IPv6 address contained in the synthetic AAAA RR is + algorithmically generated from the IPv4 address and the IPv6 prefix + assigned to a NAT64 device by using the same algorithm defined in + [RFC6052]. + + Together, these two mechanisms allow an IPv6-only client (i.e., a + host with a networking stack that only implements IPv6, a host with a + networking stack that implements both protocols but with only IPv6 + connectivity, or a host running an IPv6-only application) to initiate + communications to an IPv4-only server (which is analogous to the + IPv6-only host above). + + These mechanisms are expected to play a critical role in IPv4-IPv6 + transition and IPv4-IPv6 coexistence. Due to IPv4 address depletion, + it is likely that in the future, the new clients will be IPv6-only + and they will want to connect to the existing IPv4-only servers. The + stateful NAT64 and DNS64 mechanisms are easily deployable, since they + do not require changes to either the IPv6 client or the IPv4 server. + + + +Bagnulo, et al. Standards Track [Page 4] + +RFC 6146 Stateful NAT64 April 2011 + + + For basic functionality, the approach only requires the deployment of + the stateful NAT64 function in the devices connecting an IPv6-only + network to the IPv4-only network, along with the deployment of a few + DNS64-enabled name servers accessible to the IPv6-only hosts. An + analysis of the application scenarios can be found in [RFC6144]. + + For brevity, in the rest of the document, we will refer to the + stateful NAT64 either as stateful NAT64 or simply as NAT64. + +1.1. Features of Stateful NAT64 + + The features of NAT64 are: + + o 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 of the compliance with the aforementioned requirements, + NAT64 is compatible with current NAT traversal techniques, such as + ICE [RFC5245], and with other NAT traversal techniques. + + o 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. + + o 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 an 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. + + o 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. + + o 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. + + + + + + +Bagnulo, et al. Standards Track [Page 5] + +RFC 6146 Stateful NAT64 April 2011 + + +1.2. Overview + + This section provides a non-normative introduction to NAT64. This is + achieved by describing the NAT64 behavior involving a simple setup + that involves a single NAT64 device, a single DNS64, and a simple + network topology. The goal of this description is to provide the + reader with a general view of NAT64. It is not the goal of this + section to describe all possible configurations nor to provide a + normative specification of the NAT64 behavior. So, for the sake of + clarity, only TCP and UDP are described in this overview; the details + of ICMP, fragmentation, and other aspects of translation are + purposefully avoided in this overview. The normative specification + of NAT64 is provided in Section 3. + + The NAT64 mechanism is implemented in a device that has (at least) + two interfaces, an IPv4 interface connected to the IPv4 network, and + an IPv6 interface connected to the IPv6 network. Packets generated + in the IPv6 network for a receiver located in the IPv4 network will + be routed within the IPv6 network towards the NAT64 device. The + NAT64 will translate them and forward them as IPv4 packets through + the IPv4 network to the IPv4 receiver. The reverse takes place for + packets generated by hosts connected to the IPv4 network for an IPv6 + receiver. NAT64, however, is not symmetric. In order to be able to + perform IPv6-IPv4 translation, NAT64 requires state. The state + contains the binding of an IPv6 address and TCP/UDP port (hereafter + called an IPv6 transport address) to an IPv4 address and TCP/UDP port + (hereafter called an IPv4 transport address). + + Such binding state is either statically configured in the NAT64 or it + is created when the first packet flowing from the IPv6 network to the + IPv4 network is translated. After the binding state has been + created, packets flowing in both directions on that particular flow + are translated. The result is that, in the general case, NAT64 only + supports communications initiated by the IPv6-only node towards an + IPv4-only node. Some additional mechanisms (like ICE) or static + binding configuration can be used to provide support for + communications initiated by an IPv4-only node to an IPv6-only node. + +1.2.1. Stateful NAT64 Solution Elements + + In this section, we describe the different elements involved in the + NAT64 approach. + + The main component of the proposed solution is the translator itself. + The translator has essentially two main parts, the address + translation mechanism and the protocol translation mechanism. + + + + + +Bagnulo, et al. Standards Track [Page 6] + +RFC 6146 Stateful NAT64 April 2011 + + + Protocol translation from an IPv4 packet header to an IPv6 packet + header and vice versa is performed according to the IP/ICMP + Translation Algorithm [RFC6145]. + + Address translation maps IPv6 transport addresses to IPv4 transport + addresses and vice versa. In order to create these mappings, 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. Hereafter, we will call the IPv6 address pool + Pref64::/n; in the case there is more than one prefix assigned to the + NAT64, the comments made about Pref64::/n apply to each of them. + Pref64::/n will be used by the NAT64 to construct IPv4-Converted IPv6 + addresses as defined in [RFC6052]. Due to the abundance of IPv6 + address space, it is possible to assign one or more Pref64::/n, each + of them being equal to or even bigger than the size of the whole IPv4 + address space. This allows each IPv4 address to be mapped into a + different IPv6 address by simply concatenating a Pref64::/n with the + IPv4 address being mapped and a suffix. The provisioning of the + Pref64::/n as well as the address format are defined in [RFC6052]. + + The IPv4 address pool is a set of IPv4 addresses, normally a prefix + assigned by the local administrator. Since IPv4 address space is a + scarce resource, the IPv4 address pool is small and typically not + sufficient to establish permanent one-to-one mappings with IPv6 + addresses. So, except for the static/manually created ones, mappings + using the IPv4 address pool will be created and released dynamically. + Moreover, because of the IPv4 address scarcity, the usual practice + for NAT64 is likely to be the binding of IPv6 transport addresses + into IPv4 transport addresses, instead of IPv6 addresses into IPv4 + addresses directly, enabling a higher utilization of the limited IPv4 + address pool. This implies that NAT64 performs both address and port + translation. + + Because of the dynamic nature of the IPv6-to-IPv4 address mapping and + the static nature of the IPv4-to-IPv6 address mapping, it is far + simpler to allow communications initiated from the IPv6 side toward + an IPv4 node, whose address is algorithmically mapped into an IPv6 + address, than communications initiated from IPv4-only nodes to an + IPv6 node. In that case, an IPv4 address needs to be associated with + the IPv6 node's address dynamically. + + Using a mechanism such as DNS64, an IPv6 client obtains an IPv6 + address that embeds the IPv4 address of the IPv4 server and sends a + packet to that IPv6 address. The packets are intercepted by the + NAT64 device, which associates an IPv4 transport address out of its + + + +Bagnulo, et al. Standards Track [Page 7] + +RFC 6146 Stateful NAT64 April 2011 + + + IPv4 pool to the IPv6 transport address of the initiator, creating + binding state, so that reply packets can be translated and forwarded + back to the initiator. The binding state is kept while packets are + flowing. Once the flow stops, and based on a timer, the IPv4 + transport address is returned to the IPv4 address pool so that it can + be reused for other communications. + + To allow an IPv6 initiator to do a DNS lookup to learn the address of + the responder, DNS64 [RFC6147] is used to synthesize AAAA RRs from + the A RRs. The IPv6 addresses contained in the synthetic AAAA RRs + contain a Pref64::/n assigned to the NAT64 and the IPv4 address of + the responder. The synthetic AAAA RRs are passed back to the IPv6 + initiator, which will initiate an IPv6 communication with an IPv6 + address associated to the IPv4 receiver. The packet will be routed + to the NAT64 device, which will create the IPv6-to-IPv4 address + mapping as described before. + +1.2.2. Stateful NAT64 Behavior Walk-Through + + In this section, we provide a simple example of the NAT64 behavior. + We consider an IPv6 node that is located in an IPv6-only site and + that initiates a TCP connection to an IPv4-only node located in the + IPv4 network. + + The scenario for this case is depicted in the following figure: + + +---------------------+ +---------------+ + |IPv6 network | | IPv4 | + | | +-------------+ | network | + | |--| Name server |--| | + | | | with DNS64 | | +----+ | + | +----+ | +-------------+ | | H2 | | + | | H1 |---| | | +----+ | + | +----+ | +-------+ | 192.0.2.1 | + |2001:db8::1|------| NAT64 |----| | + | | +-------+ | | + | | | | | + +---------------------+ +---------------+ + + The figure above shows an IPv6 node H1 with an IPv6 address + 2001:db8::1 and an IPv4 node H2 with IPv4 address 192.0.2.1. H2 has + h2.example.com as its Fully Qualified Domain Name (FQDN). + + A NAT64 connects the IPv6 network to the IPv4 network. This NAT64 + uses the Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to + represent IPv4 addresses in the IPv6 address space and a single IPv4 + address 203.0.113.1 assigned to its IPv4 interface. The routing is + + + + +Bagnulo, et al. Standards Track [Page 8] + +RFC 6146 Stateful NAT64 April 2011 + + + configured in such a way that the IPv6 packets addressed to a + destination address in 64:ff9b::/96 are routed to the IPv6 interface + of the NAT64 device. + + Also shown is a local name server with DNS64 functionality. The + local name server uses the Well-Known Prefix 64:ff9b::/96 to create + the IPv6 addresses in the synthetic RRs. + + For this example, assume the typical DNS situation where IPv6 hosts + have only stub resolvers, and the local name server does the + recursive lookups. + + The steps by which H1 establishes communication with H2 are: + + 1. H1 performs a DNS query for h2.example.com and receives the + synthetic AAAA RR from the local name server that implements the + DNS64 functionality. The AAAA record contains an IPv6 address + formed by the Well-Known Prefix and the IPv4 address of H2 (i.e., + 64:ff9b::192.0.2.1). + + 2. H1 sends a TCP SYN packet to H2. The packet is sent from a + source transport address of (2001:db8::1,1500) to a destination + transport address of (64:ff9b::192.0.2.1,80), where the ports are + set by H1. + + 3. The packet is routed to the IPv6 interface of the NAT64 (since + IPv6 routing is configured that way). + + 4. The NAT64 receives the packet and performs the following actions: + + * The NAT64 selects an unused port (e.g., 2000) on its IPv4 + address 203.0.113.1 and creates 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 includes (203.0.113.1,2000) as the source transport + address in the packet and (192.0.2.1,80) as the destination + transport address in the packet. Note that 192.0.2.1 is + extracted directly from the destination IPv6 address of the + received IPv6 packet that is being translated. The + destination port 80 of the translated packet is the same as + the destination port of the received IPv6 packet. + + 5. The NAT64 sends the translated packet out of its IPv4 interface + and the packet arrives at H2. + + + + +Bagnulo, et al. Standards Track [Page 9] + +RFC 6146 Stateful NAT64 April 2011 + + + 6. H2 node responds by sending a TCP SYN+ACK packet with the + destination transport address (203.0.113.1,2000) and source + transport address (192.0.2.1,80). + + 7. Since the IPv4 address 203.0.113.1 is assigned to the IPv4 + interface of the NAT64 device, the packet is routed to the NAT64 + device, which will look for an existing mapping containing + (203.0.113.1,2000). Since the mapping (2001:db8::1,1500) <--> + (203.0.113.1,2000) exists, the NAT64 performs the following + operations: + + * The NAT64 translates the IPv4 header into an IPv6 header using + the IP/ICMP Translation Algorithm [RFC6145]. + + * The NAT64 includes (2001:db8::1,1500) as the destination + transport address in the packet and (64:ff9b::192.0.2.1,80) as + the source transport address in the packet. Note that + 192.0.2.1 is extracted directly from the source IPv4 address + of the received IPv4 packet that is being translated. The + source port 80 of the translated packet is the same as the + source port of the received IPv4 packet. + + 8. The translated packet is sent out of the IPv6 interface to H1. + + The packet exchange between H1 and H2 continues, and packets are + translated in the different directions as previously described. + + It is important to note that the translation still works if the IPv6 + initiator H1 learns the IPv6 representation of H2's IPv4 address + (i.e., 64:ff9b::192.0.2.1) through some scheme other than a DNS + lookup. This is because the DNS64 processing does NOT result in any + state being installed in the NAT64 and because the mapping of the + IPv4 address into an IPv6 address is the result of concatenating the + Well-Known Prefix to the original IPv4 address. + +1.2.3. Filtering + + NAT64 may do filtering, which means that it only allows a packet in + through an interface under certain circumstances. The NAT64 can + filter IPv6 packets based on the administrative rules to create + entries in the binding and session tables. The filtering can be + flexible and general, but the idea of the filtering is to provide the + administrators necessary control to avoid denial-of-service (DoS) + attacks that would result in exhaustion of the NAT64's IPv4 address, + port, memory, and CPU resources. Filtering techniques of incoming + IPv6 packets are not specific to the NAT64 and therefore are not + described in this specification. + + + + +Bagnulo, et al. Standards Track [Page 10] + +RFC 6146 Stateful NAT64 April 2011 + + + Filtering of IPv4 packets, on the other hand, is tightly coupled to + the NAT64 state and therefore is described in this specification. In + this document, we consider that 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]. Because of that, the + NAT64 as specified in this document supports both Endpoint- + Independent Filtering and Address-Dependent Filtering, both for TCP + and UDP as well as filtering of ICMP packets. + + If a NAT64 performs Endpoint-Independent Filtering of incoming IPv4 + packets, then an incoming IPv4 packet is dropped unless the NAT64 has + state for the destination transport address of the incoming IPv4 + packet. + + If a NAT64 performs Address-Dependent Filtering of incoming IPv4 + packets, then an incoming IPv4 packet is dropped unless the NAT64 has + state involving the destination transport address of the IPv4 + incoming packet and the particular source IP address of the incoming + IPv4 packet. + +2. Terminology + + This section provides a definitive reference for all the terms used + in this document. + + 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]. + + The following additional terms are used in this document: + + 3-Tuple: The tuple (source IP address, destination IP address, ICMP + Identifier). A 3-tuple uniquely identifies an ICMP Query session. + When an ICMP Query session flows through a NAT64, each session has + two different 3-tuples: one with IPv4 addresses and one with IPv6 + addresses. + + 5-Tuple: The tuple (source IP address, source port, destination IP + address, destination port, transport protocol). A 5-tuple + uniquely identifies a UDP/TCP session. When a UDP/TCP session + flows through a NAT64, each session has two different 5-tuples: + one with IPv4 addresses and one with IPv6 addresses. + + + + + + + +Bagnulo, et al. Standards Track [Page 11] + +RFC 6146 Stateful NAT64 April 2011 + + + BIB: Binding Information Base. A table of bindings kept by a NAT64. + Each NAT64 has a BIB for each translated protocol. An + implementation compliant to this document would have a BIB for + TCP, one for UDP, and one for ICMP Queries. Additional BIBs would + be added to support other protocols, such as SCTP. + + Endpoint-Independent Mapping: In NAT64, using the same mapping for + all the sessions involving a given IPv6 transport address of an + IPv6 host (irrespectively of the transport address of the IPv4 + host involved in the communication). Endpoint-Independent Mapping + is important for peer-to-peer communication. See [RFC4787] for + the definition of the different types of mappings in IPv4-to-IPv4 + NATs. + + Filtering, Endpoint-Independent: The NAT64 only filters incoming + IPv4 packets destined to a transport address for which there is no + state in the NAT64, regardless of the source IPv4 transport + address. The NAT forwards any packets destined to any transport + address for which it has state. In other words, having state for + a given transport address is sufficient to allow any packets back + to the internal endpoint. See [RFC4787] for the definition of the + different types of filtering in IPv4-to-IPv4 NATs. + + Filtering, Address-Dependent: The NAT64 filters incoming IPv4 + packets destined to a transport address for which there is no + state (similar to the Endpoint-Independent Filtering). + Additionally, the NAT64 will filter out incoming IPv4 packets + coming from a given IPv4 address X and destined for a transport + address for which it has state if the NAT64 has not sent packets + to X previously (independently of the port used by X). In other + words, for receiving packets from a specific IPv4 endpoint, it is + necessary for the IPv6 endpoint to send packets first to that + specific IPv4 endpoint's IP address. + + Hairpinning: Having a packet do a "U-turn" inside a NAT and come + back out the same side as it arrived on. If the destination IPv6 + address and its embedded IPv4 address are both assigned to the + NAT64 itself, then the packet is being sent to another IPv6 host + connected to the same NAT64. Such a packet is called a 'hairpin + packet'. A NAT64 that forwards hairpin packets back to the IPv6 + host is defined as supporting "hairpinning". Hairpinning support + is important for peer-to-peer applications, as there are cases + when two different hosts on the same side of a NAT can only + communicate using sessions that hairpin through the NAT. Hairpin + packets can be either TCP or UDP. More detailed explanation of + hairpinning and examples for the UDP case can be found in + [RFC4787]. + + + + +Bagnulo, et al. Standards Track [Page 12] + +RFC 6146 Stateful NAT64 April 2011 + + + ICMP Query packet: ICMP packets that are not ICMP error messages. + For ICMPv6, ICMPv6 Query Messages are the ICMPv6 Informational + messages as defined in [RFC4443]. For ICMPv4, ICMPv4 Query + messages are all ICMPv4 messages that are not ICMPv4 error + messages. + + Mapping or Binding: A mapping between an IPv6 transport address and + a IPv4 transport address or a mapping between an (IPv6 address, + ICMPv6 Identifier) pair and an (IPv4 address, ICMPv4 Identifier) + pair. 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 may + be TCP, UDP, or ICMP Queries. In NAT64, typically one host is an + IPv4 host, and the other one is an IPv6 host. However, due to + hairpinning, both hosts might be IPv6 hosts. + + 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 has per-flow state that translates + IPv6 packets to IPv4 packets and vice versa, for TCP, UDP, and + ICMP. The NAT64 uses binding state to perform the translation + between IPv6 and IPv4 addresses. In this document, we also refer + to stateful NAT64 simply as NAT64. + + Stateful NAT64 device: The device where the NAT64 function is + executed. In this document, we also refer to stateful NAT64 + device simply as NAT64 device. + + Transport Address: The combination of an IPv6 or IPv4 address and a + port. Typically written as (IP address,port), e.g., + (192.0.2.15,8001). + + Tuple: Refers to either a 3-tuple or a 5-tuple as defined above. + + For a detailed understanding of this document, the reader should also + be familiar with NAT terminology [RFC4787]. + + + + + + + + + +Bagnulo, et al. Standards Track [Page 13] + +RFC 6146 Stateful NAT64 April 2011 + + +3. Stateful NAT64 Normative Specification + + 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, denoted Pref64::/n. Additional + considerations about the Pref64::/n are presented in Section 3.5.4. + A NAT64 MUST have one or more unicast IPv4 addresses assigned to it. + + A NAT64 uses the following conceptual dynamic data structures: + + o UDP Binding Information Base + + o UDP Session Table + + o TCP Binding Information Base + + o TCP Session Table + + o ICMP Query Binding Information Base + + o ICMP Query Session Table + + These tables contain information needed for the NAT64 processing. + The actual division of the information into six tables is done in + order to ease the description of the NAT64 behavior. 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 the one described in this document. + + The notation used is the following: uppercase letters are IPv4 + addresses; uppercase letters with a prime(') are IPv6 addresses; + lowercase letters are ports; IPv6 prefixes of length n are indicated + by "P::/n"; mappings are indicated 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. In the case of UDP and TCP BIBs, + each BIB entry specifies a mapping between an IPv6 transport address + and an IPv4 transport address: + + (X',x) <--> (T,t) + + where 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 then two columns: the BIB IPv6 transport address + and the BIB IPv4 transport address. A given IPv6 or IPv4 transport + address can appear in at most one entry in a BIB: for example, + + + +Bagnulo, et al. Standards Track [Page 14] + +RFC 6146 Stateful NAT64 April 2011 + + + (2001:db8::17, 49832) can appear in at most one TCP and at most one + UDP BIB entry. TCP and UDP have separate BIBs because the port + number space for TCP and UDP are distinct. If the BIBs are + implemented as specified in this document, it results in + Endpoint-Independent Mappings in the NAT64. The information in the + BIBs is also used to implement Endpoint-Independent Filtering. + (Address-Dependent Filtering is implemented using the session tables + described below.) + + In the case of the ICMP Query BIB, each ICMP Query BIB entry + specifies a mapping between an (IPv6 address, ICMPv6 Identifier) pair + and an (IPv4 address, ICMPv4 Identifier) pair. + + (X',i1) <--> (T,i2) + + where 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 appear in at most one + entry in the ICMP Query BIB. + + Entries in any of the three BIBs can be created dynamically as the + result of the flow of packets as described in Section 3.5, but they + can also be created manually by an administrator. NAT64 + implementations SHOULD support manually configured BIB entries for + any of the three BIBs. Dynamically created entries are deleted from + the corresponding BIB when the last session associated with the BIB + entry is removed from the session table. Manually configured BIB + entries are not deleted when there is no corresponding Session Table + Entry and can only be deleted by the administrator. + +3.2. Session Tables + + A NAT64 also has three session tables: one for TCP sessions, one for + UDP sessions, and one for ICMP Query sessions. Each entry keeps + information on the state of the corresponding session. In the TCP + and UDP session tables, each entry specifies a mapping between a pair + of IPv6 transport addresses and 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 applied + by the NAT64 to create IPv6 representations of IPv4 addresses. y will + always be equal to z. + + + + +Bagnulo, et al. Standards Track [Page 15] + +RFC 6146 Stateful NAT64 April 2011 + + + For each TCP or UDP Session Table Entry (STE), there are then five + columns. The terminology used for the STE columns is from the + perspective 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 specifies a mapping + between a 3-tuple of IPv6 source address, IPv6 destination address, + and ICMPv6 Identifier and 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 applied by the NAT64 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; i1 in the example above. + + The STE source IPv4 address; T in the example above. + + The STE destination IPv4 address; Z in the example above. + + The STE ICMPv4 Identifier; i2 in the example above. + + The STE lifetime. + + + +Bagnulo, et al. Standards Track [Page 16] + +RFC 6146 Stateful NAT64 April 2011 + + +3.3. Packet Processing Overview + + The NAT64 uses the session state information to determine when the + session is completed, and also uses session information 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 is a corresponding 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 is a corresponding 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). However, 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 is deleted. + + The NAT64 will receive packets through its interfaces. These packets + can be either IPv6 packets or IPv4 packets, and they may carry TCP + traffic, UDP traffic, or ICMP traffic. The processing of the packets + will be described next. In the case that the processing is common to + all the aforementioned types of packets, we will refer to the packet + as the incoming IP packet in general. In the case that the + processing is specific to IPv6 packets, we will explicitly refer to + the incoming packet as an incoming IPv6 packet; analogous terminology + will apply in the case of processing that is specific to IPv4 + packets. + + The processing of an incoming IP packet takes the following steps: + + 1. Determining the incoming tuple + + 2. Filtering and updating binding and session information + + 3. Computing the outgoing tuple + + 4. Translating the packet + + 5. Handling hairpinning + + The details of these steps are specified in the following + subsections. + + + + + + + +Bagnulo, et al. Standards Track [Page 17] + +RFC 6146 Stateful NAT64 April 2011 + + + This breakdown of the NAT64 behavior into processing steps is done + for ease of presentation. 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 associates an incoming tuple with every incoming IP packet + for use in subsequent steps. In the case of TCP, UDP, and ICMP error + packets, the tuple is a 5-tuple consisting of the source IP address, + source port, destination IP address, destination port, and transport + protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting + 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, then the 5-tuple is computed by extracting the + appropriate fields from 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 containing a UDP or a TCP packet, then the incoming + 5-tuple is computed by extracting the appropriate fields from the IP + packet embedded inside the ICMP error message. However, the role of + source and destination is swapped when doing this: 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, etc. If it is not possible to determine the + incoming 5-tuple (perhaps because not enough of the embedded packet + is reproduced inside 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 containing an ICMP error message, then the packet is + silently discarded. + + If the incoming IP packet contains a complete (un-fragmented) ICMP + error message containing an ICMP Query message, then the incoming + 3-tuple is computed by extracting the appropriate fields from the IP + packet embedded inside the ICMP error message. However, the role of + source and destination is swapped when doing this: the embedded + source IP address becomes the destination IP address in the incoming + 3-tuple, the embedded destination IP address becomes the source + + + +Bagnulo, et al. Standards Track [Page 18] + +RFC 6146 Stateful NAT64 April 2011 + + + address in the incoming 3-tuple, and the embedded ICMP Identifier is + used as the ICMP Identifier of the incoming 3-tuple. If it is not + possible to determine the incoming 3-tuple (perhaps because not + enough of the embedded packet is reproduced inside the ICMP message), + then the incoming IP packet MUST be silently discarded. + + If the incoming IP packet contains a fragment, then more processing + may be needed. This specification leaves open the exact details of + how a NAT64 handles incoming IP packets containing fragments, and + simply requires that the external behavior of the NAT64 be compliant + with the following conditions: + + The NAT64 MUST handle fragments. In particular, NAT64 MUST handle + fragments arriving out of order, conditional on the following: + + * The NAT64 MUST limit the amount of resources devoted to the + storage of fragmented packets in order to protect from 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 contains fragment + offset equal to zero. + + For incoming packets carrying TCP or UDP fragments with a non-zero + checksum, NAT64 MAY elect to queue the fragments as they arrive + and translate all fragments at the same time. In this case, the + incoming tuple is determined as documented above to the un- + fragmented packets. Alternatively, a NAT64 MAY translate the + fragments as they arrive, by storing information that allows it to + compute the 5-tuple for fragments other than the first. In the + latter case, subsequent fragments may arrive before the first, 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 does not 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 + that specified in [RFC6145]. + + + + + +Bagnulo, et al. Standards Track [Page 19] + +RFC 6146 Stateful NAT64 April 2011 + + + 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 + + This step updates binding and session information stored in the + appropriate tables. This step may also filter incoming packets, if + desired. + + The details of this step depend on the protocol, i.e., UDP, TCP, or + ICMP. The behaviors for UDP, TCP, and ICMP Queries are described in + Section 3.5.1, Section 3.5.2, and Section 3.5.3, respectively. For + the case of ICMP error messages, they do not affect in any way either + the BIBs or the session tables, so there is no processing resulting + from these messages in this section. ICMP error message processing + continues in Section 3.6. + + Irrespective of the transport protocol used, the NAT64 MUST silently + discard all incoming IPv6 packets containing a source address that + contains the Pref64::/n. This is required in order to prevent + hairpinning loops as described in Section 5. In addition, 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. + + + + + + + +Bagnulo, et al. Standards Track [Page 20] + +RFC 6146 Stateful NAT64 April 2011 + + +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 + as follows: + + 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 such an entry does not exist, the NAT64 tries to + create a new entry (if resources and policy permit). The source + IPv6 transport address of the packet (X',x) is used as the BIB + IPv6 transport address, and the BIB IPv4 transport address is set + to (T,t), which is allocated using the rules defined in + Section 3.5.1.1. The result is a BIB entry as follows: (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 entry (if resources and policy permit). The + information included 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), 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). + + + + + +Bagnulo, et al. Standards Track [Page 21] + +RFC 6146 Stateful NAT64 April 2011 + + + The result is a Session Table Entry as follows: + (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 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 as follows: + + 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 such an entry + does not exist, 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 to see if 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 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, then 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), then 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 entry (if + resources and policy permit). In case 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. + + + + +Bagnulo, et al. Standards Track [Page 22] + +RFC 6146 Stateful NAT64 April 2011 + + + * The STE destination IPv6 transport address is set to (Y'(W),w), + 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 addresses contained in the + received IPv4 packet. + + * The STE destination IPv4 transport is set to (W,w), i.e., the + source IPv4 transport addresses 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 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 as follows: + + 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, use any IPv4 address + of the IPv4 pool assigned to the NAT64 to be used 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]). + + + + +Bagnulo, et al. Standards Track [Page 23] + +RFC 6146 Stateful NAT64 April 2011 + + + In all cases, the allocated IPv4 transport address (T,t) MUST NOT + be in use in another entry in the same BIB, but 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 + + The following state information is stored for a TCP session: + + Binding:(X',x),(Y',y) <--> (T,t),(Z,z) + + Lifetime: a timer that tracks the remaining lifetime of the TCP + session. When the timer expires, the TCP session is deleted. If + all the TCP sessions corresponding to a TCP BIB entry are deleted, + then the dynamically created TCP BIB entry is also deleted. + + Because the TCP session inactivity lifetime is set to at least 2 + hours and 4 minutes (as per [RFC5382]), it is important that each TCP + Session Table Entry corresponds to an existing TCP session. In order + to do that, for each TCP session established, the TCP connection + state is tracked using the following state machine. + + The states are as follows: + + CLOSED: Analogous to [RFC0793], CLOSED is a fictional state + because it represents the state when there is no state for this + particular 5-tuple, and therefore no connection. + + V4 INIT: An IPv4 packet containing a TCP SYN was received by the + NAT64, implying that a TCP connection is being initiated from the + IPv4 side. The NAT64 is now waiting for a matching IPv6 packet + containing the TCP SYN in the opposite direction. + + + + + + + +Bagnulo, et al. Standards Track [Page 24] + +RFC 6146 Stateful NAT64 April 2011 + + + V6 INIT: An IPv6 packet containing a TCP SYN was received, + translated, and forwarded by the NAT64, implying that a TCP + connection is being initiated from the IPv6 side. The NAT64 is + now waiting for a matching IPv4 packet containing the TCP SYN in + the opposite direction. + + ESTABLISHED: Represents an open connection, with data able to flow + in both directions. + + V4 FIN RCV: An IPv4 packet containing a TCP FIN was received by + the NAT64, data can still flow in the connection, and the NAT64 is + waiting for a matching TCP FIN in the opposite direction. + + V6 FIN RCV: An IPv6 packet containing a TCP FIN was received by + the NAT64, data can still flow in the connection, and the NAT64 is + waiting for a matching TCP FIN in the opposite direction. + + V6 FIN + V4 FIN RCV: Both an IPv4 packet containing a TCP FIN and + an IPv6 packet containing an TCP FIN for this connection were + received by the NAT64. The NAT64 keeps the connection state alive + and forwards packets in both directions for a short period of time + to allow remaining packets (in particular, the ACKs) to be + delivered. + + TRANS: The lifetime of the state for the connection is set to + TCP_TRANS minutes either because a packet containing a TCP RST was + received by the NAT64 for this connection or simply because the + lifetime of the connection has decreased and there are only + TCP_TRANS minutes left. The NAT64 will keep the state for the + connection for TCP_TRANS minutes, and if no other data packets for + that connection are received, the state for this connection is + then terminated. + +3.5.2.2. State Machine for TCP Processing in the NAT64 + + The state machine used by the NAT64 for the TCP session processing is + depicted next. The described state machine handles all TCP segments + received through the IPv6 and IPv4 interface. There is one state + machine per TCP connection that is potentially established through + the NAT64. After bootstrapping of the NAT64 device, all TCP sessions + are in CLOSED state. As we mention above, the CLOSED state is a + fictional state when there is no state for that particular connection + in the NAT64. It should be noted that there is one state machine per + connection, so only packets belonging to a given connection are + inputs to the state machine associated to that connection. In other + words, when in the state machine below we state that a packet is + received, it is implicit that the incoming 5-tuple of the data packet + matches to the one of the state machine. + + + +Bagnulo, et al. Standards Track [Page 25] + +RFC 6146 Stateful NAT64 April 2011 + + + A TCP segment with the SYN flag set that is received through the IPv6 + interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 + FIN + V4 FIN, V6 RST, and V4 RST. + + The figure presents a simplified version of the state machine; refer + to the text for the full specification of the state machine. + + +-----------------------------+ + | | + 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 |--------------------+ + +---------------------+ + + We next describe the state information and the transitions. + + + + + + + +Bagnulo, et al. Standards Track [Page 26] + +RFC 6146 Stateful NAT64 April 2011 + + + *** CLOSED *** + + If a V6 SYN is received with an incoming tuple with source transport + address (X',x) and destination transport address (Y',y) (this is the + case of a TCP connection initiated from the IPv6 side), the + processing is as follows: + + 1. The NAT64 searches for a TCP BIB entry that matches the IPv6 + source transport address (X',x). + + If such an entry does not exist, the NAT64 tries to create a + new BIB entry (if resources and policy permit). The BIB IPv6 + transport address is set to (X',x), i.e., the source IPv6 + transport address of the packet. The BIB IPv4 transport + address is set to an IPv4 transport address allocated using + the rules defined in Section 3.5.2.3. The processing of the + packet continues as described in bullet 2. + + If the entry already exists, then the processing continues as + described in bullet 2. + + 2. Then the NAT64 tries to create a new TCP session entry in the TCP + session table (if resources and policy permit). The information + included in the session table is as follows: + + The STE source IPv6 transport address is set to (X',x), i.e., + the source transport address contained in the received V6 SYN + packet. + + The STE destination IPv6 transport address is set to (Y',y), + i.e., the destination transport address contained in the + received V6 SYN packet. + + The STE source IPv4 transport address is set to the BIB IPv4 + transport address of the corresponding TCP BIB entry. + + The STE destination IPv4 transport address contains the port y + (i.e., the same port as the IPv6 destination transport + address) and the IPv4 address that is algorithmically + generated from the IPv6 destination address (i.e., Y') using + the reverse algorithm as specified 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 as defined + in [RFC5382]). + + 3. The state of the session is moved to V6 INIT. + + + + +Bagnulo, et al. Standards Track [Page 27] + +RFC 6146 Stateful NAT64 April 2011 + + + 4. The NAT64 translates and forwards the packet as described in the + following sections. + + If a V4 SYN packet is received with an incoming tuple with source + IPv4 transport address (Y,y) and destination IPv4 transport address + (X,x) (this is the case of a TCP connection initiated from the IPv4 + side), the processing is as follows: + + If the security policy requires silently dropping externally + initiated TCP connections, then the packet is silently discarded. + + Else, if the destination transport address contained in the + incoming V4 SYN (i.e., 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 permit), containing the + following information: + + + The STE source IPv4 transport address is set to (X,x), i.e., + the destination transport address contained in the V4 SYN. + + + The STE destination IPv4 transport address is set to (Y,y), + i.e., the source transport address contained in the V4 SYN. + + + The STE transport IPv6 source address is left unspecified + and may be populated by other protocols that are out of the + scope of this specification. + + + The STE destination IPv6 transport address contains the port + y (i.e., the same port as the STE destination IPv4 transport + address) and the IPv6 representation of Y (i.e., the IPv4 + address of the STE destination IPv4 transport address), + generated using the algorithm described in Section 3.5.4. + + The state is moved to V4 INIT. + + The lifetime of the STE entry is set to TCP_INCOMING_SYN as per + [RFC5382], and the packet is stored. The result is that the + NAT64 will not drop the packet based on the filtering, nor + create a BIB entry. Instead, the NAT64 will only create the + Session Table Entry and store the packet. The motivation for + this is to support simultaneous open of TCP connections. + + If the destination transport address contained in the incoming V4 + SYN (i.e., X,x) is in use in the TCP BIB, then: + + + + + + +Bagnulo, et al. Standards Track [Page 28] + +RFC 6146 Stateful NAT64 April 2011 + + + The NAT64 tries to create a new Session Table Entry in the TCP + session table (if resources and policy permit), containing the + following information: + + + The STE source IPv4 transport address is set to (X,x), i.e., + the destination transport address contained in the V4 SYN. + + + The STE destination IPv4 transport address is set to (Y,y), + i.e., the source transport address contained 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 STE destination IPv6 transport address contains the port + y (i.e., the same port as the STE destination IPv4 transport + address) and the IPv6 representation of Y (i.e., the IPv4 + address of the STE destination IPv4 transport address), + generated using the algorithm described in Section 3.5.4. + + The state is moved to V4 INIT. + + If the NAT64 is performing Address-Dependent Filtering, the + lifetime of the STE entry is set to TCP_INCOMING_SYN as per + [RFC5382], and the packet is stored. The motivation for + creating the Session Table Entry and storing the packet + (instead of simply dropping the packet based on the filtering) + is to support simultaneous open of TCP connections. + + If the NAT64 is not performing Address-Dependent Filtering, the + lifetime of the STE 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 belonging to this connection: + + If there is a corresponding entry in the TCP BIB, the packet + SHOULD be translated and forwarded if the security policy allows + doing so. The state remains unchanged. + + If there is no corresponding entry in the TCP BIB, the packet is + silently discarded. + + + + + + + + +Bagnulo, et al. Standards Track [Page 29] + +RFC 6146 Stateful NAT64 April 2011 + + + *** V4 INIT *** + + If a V6 SYN is received with incoming tuple with source transport + address (X',x) and destination transport address (Y',y), then the + lifetime of the TCP Session Table Entry is set to at least the + maximum session lifetime. The value for 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 value for the maximum session lifetime SHOULD be set to + TCP_EST. The packet is translated and forwarded. The state is moved + to ESTABLISHED. + + If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code + 3) containing the IPv4 SYN packet stored is sent back to the source + of the v4 SYN, the Session Table Entry is deleted, and the state is + moved to CLOSED. + + For any other packet, the packet SHOULD be translated and forwarded + if the security policy allows doing so. The state remains unchanged. + + *** V6 INIT *** + + If a V4 SYN is received (with or without the ACK flag set), with an + incoming tuple with source IPv4 transport address (Y,y) and + destination IPv4 transport address (X,x), then the state is moved to + ESTABLISHED. The lifetime of the TCP Session Table Entry is set to + at least the maximum session lifetime. The value for 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 value for the maximum session lifetime + SHOULD be set to TCP_EST. The packet is translated and forwarded. + + If the lifetime expires, the Session Table Entry is deleted, and the + state is moved to CLOSED. + + If a V6 SYN packet is received, the packet is translated and + forwarded. The lifetime of the TCP Session Table Entry is set to at + least TCP_TRANS. The state remains unchanged. + + For any other packet, the packet SHOULD be translated and forwarded + if the security policy allows doing so. The state remains unchanged. + + *** ESTABLISHED *** + + If a V4 FIN packet is received, the packet is translated and + forwarded. The state is moved to V4 FIN RCV. + + + + + +Bagnulo, et al. Standards Track [Page 30] + +RFC 6146 Stateful NAT64 April 2011 + + + If a V6 FIN packet is received, the packet is translated and + forwarded. The state is moved to V6 FIN RCV. + + If a V4 RST or a V6 RST packet is received, the packet is translated + and forwarded. The lifetime is set to TCP_TRANS and the state is + moved to TRANS. (Since the NAT64 is uncertain whether the peer will + accept the RST packet, instead of moving the state to CLOSED, it + moves to TRANS, which has a shorter lifetime. If no other packets + are received for this connection during the short timer, the NAT64 + assumes that the peer has accepted the RST packet and moves to + CLOSED. If packets keep flowing, the NAT64 assumes that the peer has + not accepted the RST packet and moves back to the ESTABLISHED state. + This is described below in the TRANS state processing description.) + + If any other packet is received, the packet is translated and + forwarded. The lifetime of the TCP Session Table Entry is set to at + least the maximum session lifetime. The value for 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 value for the maximum session lifetime + SHOULD be set to TCP_EST. The state remains unchanged as + ESTABLISHED. + + If the lifetime expires, then the NAT64 SHOULD send a probe packet + (as 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 + set to zero. All flags but the ACK flag are set to zero. The state + is moved to TRANS. + + Upon the reception of this probe packet, the endpoint will reply + with an ACK containing the expected sequence number for that + connection. It should be noted that, for an active connection, + each of these probe packets will generate one packet from each end + involved in the connection, since the reply of the first point to + the probe packet will generate a reply from the other endpoint. + + *** V4 FIN RCV *** + + If a V6 FIN packet is received, the packet is translated and + forwarded. The lifetime is set to TCP_TRANS. The state is moved to + V6 FIN + V4 FIN RCV. + + If any packet other than the V6 FIN is received, the packet is + translated and forwarded. The lifetime of the TCP Session Table + Entry is set to at least the maximum session lifetime. The value for + the maximum session lifetime MAY be configurable, but it MUST NOT be + + + + +Bagnulo, et al. Standards Track [Page 31] + +RFC 6146 Stateful NAT64 April 2011 + + + less than TCP_EST (the established connection idle timeout as defined + in [RFC5382]). The default value for the maximum session lifetime + SHOULD be set to TCP_EST. The state remains unchanged as V4 FIN RCV. + + If the lifetime expires, the Session Table Entry is deleted, and the + state is moved to CLOSED. + + *** V6 FIN RCV *** + + If a V4 FIN packet is received, the packet is translated and + forwarded. The lifetime is set to TCP_TRANS. The state is moved to + V6 FIN + V4 FIN RCV. + + If any packet other than the V4 FIN is received, the packet is + translated and forwarded. The lifetime of the TCP Session Table + Entry is set to at least the maximum session lifetime. The value for + 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 value for the maximum session lifetime + SHOULD be set to TCP_EST. The state remains unchanged as V6 FIN RCV. + + If the lifetime expires, the Session Table Entry is deleted and the + state is moved to CLOSED. + + *** V6 FIN + V4 FIN RCV *** + + All packets are translated and forwarded. + + If the lifetime expires, the Session Table Entry is deleted and the + state is moved 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. The value for 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 value + for the maximum session lifetime SHOULD be set to TCP_EST. The state + is moved to ESTABLISHED. + + If the lifetime expires, the Session Table Entry is deleted and the + state is moved to CLOSED. + + + + + + + + +Bagnulo, et al. Standards Track [Page 32] + +RFC 6146 Stateful NAT64 April 2011 + + +3.5.2.3. Rules for Allocation of IPv4 Transport Addresses for TCP + + When a new TCP BIB entry is created for a source transport address of + (S',s), the NAT64 allocates an IPv4 transport address for this BIB + entry as follows: + + If there exists some other BIB entry in any of the BIBs that + contains S' as the IPv6 address and maps it to some IPv4 address + T, then T SHOULD be used as the IPv4 address. Otherwise, use any + IPv4 address of the IPv4 pool assigned to the NAT64 to be used 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. + + 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. + + In all cases, the allocated IPv4 transport address (T,t) MUST NOT + be in use in another entry in the same BIB, but 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.3. ICMP Query Session Handling + + The following state information is stored for an ICMP Query session + in the ICMP Query session table: + + Binding:(X',Y',i1) <--> (T,Z,i2) + + Lifetime: a timer that tracks the remaining lifetime of the ICMP + Query session. When the timer expires, the session is deleted. + If all the ICMP Query sessions corresponding to a dynamically + created ICMP Query BIB entry are deleted, then the ICMP Query BIB + entry is also deleted. + + + + + + +Bagnulo, et al. Standards Track [Page 33] + +RFC 6146 Stateful NAT64 April 2011 + + + An incoming ICMPv6 Informational packet with IPv6 source address X', + IPv6 destination address Y', and ICMPv6 Identifier i1 is processed as + follows: + + If the local security policy determines that ICMPv6 Informational + packets are to be filtered, the packet is silently discarded. + Else, the NAT64 searches for an ICMP Query BIB entry that matches + the (X',i1) pair. If such an entry does not exist, the NAT64 + tries to create a new entry (if resources and policy permit) with + the following data: + + * The BIB IPv6 address is set to X' (i.e., the source IPv6 + address of the IPv6 packet). + + * The BIB ICMPv6 Identifier is set to i1 (i.e., the ICMPv6 + Identifier). + + * If there exists another BIB entry in any of the BIBs that + contains the same IPv6 address X' and maps it to an IPv4 + address T, then use T as the BIB IPv4 address for this new + entry. Otherwise, use any IPv4 address assigned to the IPv4 + interface. + + * Any available value is used as the BIB ICMPv4 Identifier, i.e., + any identifier value for which no other entry exists with the + same (IPv4 address, ICMPv4 Identifier) pair. + + The NAT64 searches for an ICMP Query Session Table Entry + corresponding to the incoming 3-tuple (X',Y',i1). If no such + entry is found, the NAT64 tries to create a new entry (if + resources and policy permit). The information included in the new + Session Table Entry is as follows: + + * The STE IPv6 source address is set to X' (i.e., the address + contained in the received IPv6 packet). + + * The STE IPv6 destination address is set to Y' (i.e., the + address contained in the received IPv6 packet). + + * The STE ICMPv6 Identifier is set to i1 (i.e., the identifier + contained in the received IPv6 packet). + + * The STE IPv4 source address is set to the IPv4 address + contained in the corresponding BIB entry. + + * The STE ICMPv4 Identifier is set to the IPv4 identifier + contained in the corresponding BIB entry. + + + + +Bagnulo, et al. Standards Track [Page 34] + +RFC 6146 Stateful NAT64 April 2011 + + + * The STE IPv4 destination address is algorithmically generated + from Y' using the reverse algorithm as specified in + Section 3.5.4. + + The NAT64 sets (or resets) the timer in the session table entry to + the maximum session lifetime. By default, the maximum session + lifetime is ICMP_DEFAULT. The maximum lifetime value SHOULD be + configurable. The packet is translated and forwarded as described + in the following sections. + + An incoming ICMPv4 Query packet with source IPv4 address Y, + destination IPv4 address X, and ICMPv4 Identifier i2 is processed as + follows: + + The NAT64 searches for an ICMP Query BIB entry that contains X as + the IPv4 address and i2 as the ICMPv4 Identifier. If such an + entry does not exist, the packet is dropped. An ICMP error + message MAY be sent to the original sender of the packet. The + ICMP error message, if sent, has Type 3, Code 1 (Host + Unreachable). + + If the NAT64 filters on its IPv4 interface, then the NAT64 checks + to see if 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 address equal to X, an STE + ICMPv4 Identifier equal to i2, and a STE destination IPv4 address + equal to Y. 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, then 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 + steps (either because the NAT64 is not filtering or because the + packet is compliant with the Address-Dependent Filtering rule), + then the NAT64 searches for a Session Table Entry with an STE + source IPv4 address equal to X, an STE ICMPv4 Identifier equal to + i2, and a STE destination IPv4 address equal to Y. If no such + entry is found, the NAT64 tries to create a new entry (if + resources and policy permit) with the following information: + + * The STE source IPv4 address is set to X. + + * The STE ICMPv4 Identifier is set to i2. + + * The STE destination IPv4 address is set to Y. + + + + +Bagnulo, et al. Standards Track [Page 35] + +RFC 6146 Stateful NAT64 April 2011 + + + * The STE source IPv6 address is set to the IPv6 address of the + corresponding BIB entry. + + * The STE ICMPv6 Identifier is set to the ICMPv6 Identifier of + the corresponding BIB entry. + + * The STE destination IPv6 address is set to the IPv6 + representation of the IPv4 address of Y, generated using the + algorithm described in Section 3.5.4. + + * The NAT64 sets (or resets) the timer in the session table entry + to the maximum session lifetime. By default, the maximum + session lifetime is ICMP_DEFAULT. The maximum lifetime value + SHOULD be configurable. The packet is translated and forwarded + as described in the following sections. + +3.5.4. Generation of the IPv6 Representations of IPv4 Addresses + + NAT64 supports multiple algorithms for the generation of the IPv6 + representation of an IPv4 address and vice versa. The constraints + imposed on the generation algorithms are the following: + + The algorithm MUST be reversible, i.e., it MUST be possible to + derive the original IPv4 address from the IPv6 representation. + + The input for the algorithm MUST be limited to the IPv4 address, + the IPv6 prefix (denoted Pref64::/n) used in the IPv6 + representations, and optionally a set of stable parameters that + are configured in the NAT64 (such as a fixed string to be used as + a suffix). + + If we note n the length of the prefix Pref64::/n, then n MUST + be less than or equal to 96. If a Pref64::/n is configured + through any means in the NAT64 (such as manually configured, or + other automatic means not specified in this document), the + default algorithm MUST use this 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]. The + aforementioned algorithm SHOULD be used as default algorithm. + +3.6. Computing the Outgoing Tuple + + This step computes the outgoing tuple by translating the IP addresses + and port numbers or ICMP Identifier in the incoming tuple. + + + + +Bagnulo, et al. Standards Track [Page 36] + +RFC 6146 Stateful NAT64 April 2011 + + + In the text below, a reference to a BIB means the TCP BIB, the UDP + BIB, or the ICMP Query BIB, as appropriate. + + NOTE: Not all addresses are translated using the BIB. BIB entries + are 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, nor to translate IPv4 source + transport addresses to IPv6 source transport addresses. The + latter cases are handled by applying the algorithmic + transformation described in Section 3.5.4. This distinction is + important; 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 + that in the incoming 5-tuple. When translating from IPv4 ICMP to + IPv6 ICMP, the protocol number in the last next header field in 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 as follows: 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 described 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 described 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). + + + + + + + +Bagnulo, et al. Standards Track [Page 37] + +RFC 6146 Stateful NAT64 April 2011 + + +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: 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 described 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 is i2. The outgoing source + address is generated from S using the address transformation + algorithm described 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 + + This step translates the packet from IPv6 to IPv4 or vice versa. + + The translation of the packet is as specified in Sections 4 and 5 of + the IP/ICMP Translation Algorithm [RFC6145], with the following + modifications: + + o When translating an IP header (Sections 4.1 and 5.1 of [RFC6145]), + the source and destination IP address fields are set to the source + and destination IP addresses from the outgoing tuple as determined + in Section 3.6. + + o When the protocol following the IP header is TCP or UDP, then the + source and destination ports are modified to the source and + destination ports from the outgoing 5-tuple. In addition, the TCP + or UDP checksum must also be updated to reflect the translated + addresses and ports; note that the TCP and UDP checksum covers the + pseudo-header that contains the source and destination IP + addresses. An algorithm for efficiently updating these checksums + is described in [RFC3022]. + + o When the protocol following the IP header is ICMP and it is an + ICMP Query message, the ICMP Identifier is set to the one from the + outgoing 3-tuple as determined in Section 3.6.2. + + + + + +Bagnulo, et al. Standards Track [Page 38] + +RFC 6146 Stateful NAT64 April 2011 + + + o When the protocol following the IP header is ICMP and it is an + ICMP error message, the source and destination transport addresses + in the embedded packet are set to the destination and source + transport addresses from the outgoing 5-tuple (note the swap of + source and destination). + + The size of outgoing packets as well and the potential need for + fragmentation is done according to the behavior defined in the IP/ + ICMP Translation Algorithm [RFC6145]. + +3.8. Handling Hairpinning + + 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 are processed as follows: + + o The outgoing 5-tuple becomes the incoming 5-tuple. + + o The packet is treated as if it was received on the outgoing + interface. + + o Processing of the packet continues at step 2 -- "Filtering and + Updating Binding and Session Information" (Section 3.5). + +4. Protocol Constants + + 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 the + TCP_TRANS timer.) + + TCP_INCOMING_SYN: 6 seconds (as defined in [RFC5382]) + + FRAGMENT_MIN: 2 seconds + + ICMP_DEFAULT: 60 seconds (as defined in [RFC5508]) + + + + + + + + + +Bagnulo, et al. Standards Track [Page 39] + +RFC 6146 Stateful NAT64 April 2011 + + +5. Security Considerations + +5.1. Implications on End-to-End Security + + Any protocols that protect IP header information are essentially + incompatible with NAT64. This implies that end-to-end IPsec + verification will fail when the Authentication Header (AH) is used + (both transport and tunnel mode) and when ESP is used in transport + mode. This is inherent in any network-layer translation mechanism. + End-to-end IPsec protection can be restored, using UDP encapsulation + as described in [RFC3948]. The actual extensions to support IPsec + are out of the scope of this document. + +5.2. Filtering + + NAT64 creates binding state using packets flowing from the IPv6 side + to the IPv4 side. In accordance with the procedures defined in this + document following the guidelines defined in [RFC4787], a NAT64 MUST + offer "Endpoint-Independent Mapping". This 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,d2 + + Implementations MAY also provide support for "Address-Dependent + Mapping" as also defined in this document and following the + guidelines defined in [RFC4787]. + + The security properties, however, are determined by which packets the + NAT64 filter allows in and which it does not. The security + properties are determined by the filtering behavior and filtering + configuration in the filtering portions of the NAT64, not by the + address mapping behavior. 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 + + + +Bagnulo, et al. Standards Track [Page 40] + +RFC 6146 Stateful NAT64 April 2011 + + + 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 (e.g., statically configured + mappings), this may make it easy for an attacker to guess. An + attacker need not be able to guess other fields, e.g., the TCP + sequence number, to get a packet through the NAT64. While such + traffic might be dropped by the final destination, it does not + provide additional mitigations against bandwidth/CPU attacks + targeting the internal network. To avoid this type of abuse, a NAT64 + MAY keep track of the sequence number of TCP packets in order to + verify the proper sequencing of exchanged segments, in particular, + those of the SYNs and the FINs. + +5.3. Attacks on NAT64 + + The NAT64 device itself is a potential victim of different types of + attacks. In particular, the NAT64 can be a victim of DoS attacks. + The NAT64 device has a limited number of resources that can be + consumed by attackers creating a DoS attack. The NAT64 has a limited + number of IPv4 addresses that it uses to create the bindings. Even + though the NAT64 performs address and port translation, it is + possible for an attacker to 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 are not used to create binding state. DoS attacks + can also affect other limited resources available in the NAT64 such + as memory or link capacity. For instance, it is possible for an + attacker to launch a DoS attack on the memory of the NAT64 device by + sending fragments that the NAT64 will store for a given period. If + the number of fragments is high enough, the memory of the NAT64 could + be exhausted. Similarly, a DoS attack against the NAT64 can be + crafted by sending either V4 or V6 SYN packets that consume memory in + the form of session and/or binding table entries. In the case of + IPv4 SYNs the situation is aggravated by the requirement to also + store the data packets for a given amount of time, requiring more + + + +Bagnulo, et al. Standards Track [Page 41] + +RFC 6146 Stateful NAT64 April 2011 + + + memory from the NAT64 device. NAT64 devices MUST implement proper + protection against such attacks, for instance, allocating a limited + amount of memory for fragmented packet storage as specified in + Section 3.4. + + Another consideration related to NAT64 resource depletion refers to + the preservation of binding state. Attackers may try to keep a + binding state alive forever by sending periodic packets that refresh + the state. In order to allow the NAT64 to defend against such + attacks, the NAT64 MAY choose not to extend the session entry + lifetime for a specific entry upon the reception of 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 which the Internet side is the IPv6 one, and in others of + which the Internet side is the IPv4 one. It is then important to + properly set which is the Internet side of the NAT64 in each specific + 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 for creating this binding. Then, any packet sent to + the binding's IPv4 address could loop in the NAT64. This is + prevented in the current specification by filtering incoming packets + containing Pref64::/n in the source address, as described below. + + Consider the following 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: any + + The NAT64 allocates 192.0.2.1:500 as the IPv4 binding address. Now + anything sent to 192.0.2.1:500, be it a hairpinned IPv6 packet or an + IPv4 packet, could loop. + + It is 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, it uses a source port in the range 1-1023. This will + increase the chances to 1/512 (since range and parity are preserved + by NAT64 in UDP). + + + +Bagnulo, et al. Standards Track [Page 42] + +RFC 6146 Stateful NAT64 April 2011 + + + In order to address this vulnerability, the NAT64 MUST drop IPv6 + packets whose source address is in Pref64::/n, as defined in + Section 3.5. + +6. Contributors + + 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 provided useful comments to improve it. + + The content of the document was 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 + + [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. + + + +Bagnulo, et al. Standards Track [Page 43] + +RFC 6146 Stateful NAT64 April 2011 + + + [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 + + [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. + + + + + +Bagnulo, et al. Standards Track [Page 44] + +RFC 6146 Stateful NAT64 April 2011 + + + [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 + + 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.com + + + + + + + + + + + + + +Bagnulo, et al. Standards Track [Page 45] + |