idnits 2.17.1 draft-ietf-behave-v6v4-xlate-stateful-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2010) is 5039 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-20 == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-09 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-10 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-09 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE WG M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Standards Track P. Matthews 5 Expires: January 11, 2011 Alcatel-Lucent 6 I. van Beijnum 7 IMDEA Networks 8 July 10, 2010 10 Stateful NAT64: Network Address and Protocol Translation from IPv6 11 Clients to IPv4 Servers 12 draft-ietf-behave-v6v4-xlate-stateful-12 14 Abstract 16 This document describes stateful NAT64 translation, which allows 17 IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or 18 ICMP. The public IPv4 address can be shared among several IPv6-only 19 clients. When the stateful NAT64 is used in conjunction with DNS64 20 no changes are usually required in the IPv6 client or the IPv4 21 server. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 11, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Features of stateful NAT64 . . . . . . . . . . . . . . . . 5 59 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.2.1. Stateful NAT64 solution elements . . . . . . . . . . . 6 61 1.2.2. Stateful NAT64 Behaviour Walkthrough . . . . . . . . . 8 62 1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 10 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 3. Stateful NAT64 Normative Specification . . . . . . . . . . . . 13 65 3.1. Binding Information Bases . . . . . . . . . . . . . . . . 14 66 3.2. Session Tables . . . . . . . . . . . . . . . . . . . . . . 15 67 3.3. Packet Processing Overview . . . . . . . . . . . . . . . . 17 68 3.4. Determining the Incoming tuple . . . . . . . . . . . . . . 18 69 3.5. Filtering and Updating Binding and Session Information . . 20 70 3.5.1. UDP Session Handling . . . . . . . . . . . . . . . . . 20 71 3.5.1.1. Rules for Allocation of IPv4 Transport 72 Addresses for UDP . . . . . . . . . . . . . . . . 23 73 3.5.2. TCP Session Handling . . . . . . . . . . . . . . . . . 23 74 3.5.2.1. State definition . . . . . . . . . . . . . . . . . 24 75 3.5.2.2. State machine for TCP processing in the NAT64 . . 25 76 3.5.2.3. Rules for allocation of IPv4 transport 77 addresses for TCP . . . . . . . . . . . . . . . . 32 78 3.5.3. ICMP Query Session Handling . . . . . . . . . . . . . 33 79 3.5.4. Generation of the IPv6 Representations of IPv4 80 Addresses . . . . . . . . . . . . . . . . . . . . . . 35 81 3.6. Computing the Outgoing Tuple . . . . . . . . . . . . . . . 36 82 3.6.1. Computing the Outgoing 5-tuple for TCP, UDP and 83 for ICMP Error messages containing a TCP or UDP 84 packets. . . . . . . . . . . . . . . . . . . . . . . . 36 85 3.6.2. Computing the Outgoing 3-tuple for ICMP Query 86 Messages and for ICMP Error messages containing an 87 ICMP Query. . . . . . . . . . . . . . . . . . . . . . 37 88 3.7. Translating the Packet . . . . . . . . . . . . . . . . . . 37 89 3.8. Handling Hairpinning . . . . . . . . . . . . . . . . . . . 38 90 4. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 38 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 39 92 5.1. Implications on end-to-end security . . . . . . . . . . . 39 93 5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 39 94 5.3. Attacks on NAT64 . . . . . . . . . . . . . . . . . . . . . 40 95 5.4. Avoiding hairpinning loops . . . . . . . . . . . . . . . . 41 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 98 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 42 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 101 9.1. Normative References . . . . . . . . . . . . . . . . . . . 43 102 9.2. Informative References . . . . . . . . . . . . . . . . . . 44 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 105 1. Introduction 107 This document specifies stateful NAT64, a mechanism for IPv4-IPv6 108 transition and co-existence. Together with DNS64 109 [I-D.ietf-behave-dns64], these two mechanisms allow an IPv6-only 110 client to initiate communications to an IPv4-only server. They also 111 enable peer-to-peer communication between an IPv4 and an IPv6 node, 112 where the communication can be initiated by either end using 113 existing, NAT-traversal, peer-to-peer communication techniques, such 114 as ICE [RFC5245]. Stateful NAT64 also supports IPv4-initiated 115 communications to a subset of the IPv6 hosts through statically 116 configured bindings in the stateful NAT64. 118 Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 119 packets and vice-versa. The translation is done by translating the 120 packet headers according to the IP/ICMP Translation Algorithm defined 121 in [I-D.ietf-behave-v6v4-xlate]. The IPv4 addresses of IPv4 hosts 122 are algorithmically translated to and from IPv6 addresses by using 123 the algorithm defined in [I-D.ietf-behave-address-format] and a 124 prefix assigned to the stateful NAT64 for this specific purpose. The 125 IPv6 addresses of IPv6 hosts are translated to and from IPv4 126 addresses by installing mappings in the normal NAPT manner [RFC3022]. 127 The current specification only defines how stateful NAT64 translates 128 unicast packets carrying TCP, UDP and ICMP traffic. Multicast 129 packets and other protocols, including SCTP, DCCP and IPsec are out 130 of the scope of this specification. 132 DNS64 is a mechanism for synthesizing AAAA resource records (RR) from 133 A RR. The IPv6 address contained in the synthetic AAAA RR is 134 algorithmically generated from the IPv4 address and the IPv6 prefix 135 assigned to a NAT64 device by using the same algorithm defined in 136 [I-D.ietf-behave-address-format]. 138 Together, these two mechanisms allow an IPv6-only client (i.e. either 139 a host with only IPv6 stack, or a host with both IPv4 and IPv6 stack, 140 but only with IPv6 connectivity or a host running an IPv6 only 141 application) to initiate communications to an IPv4-only server 142 (analogous meaning to the IPv6-only host above). 144 These mechanisms are expected to play a critical role in the IPv4- 145 IPv6 transition and co-existence. Due to IPv4 address depletion, it 146 is likely that in the future, the new clients will be IPv6-only and 147 they will want to connect to the existent IPv4-only servers. The 148 stateful NAT64 and DNS64 mechanisms are easily deployable, since they 149 require no changes to either the IPv6 client nor the IPv4 server. 150 For basic functionality, the approach only requires the deployment of 151 the stateful NAT64 function in the devices connecting an IPv6-only 152 network to the IPv4-only network, along with the deployment of a few 153 DNS64-enabled name servers accessible to the IPv6-only hosts. An 154 analysis of the application scenarios can be found in 155 [I-D.ietf-behave-v6v4-framework]. 157 For brevity, in the rest of the document, we will refer to the 158 stateful NAT64 either as stateful NAT64 or simply as NAT64. 160 1.1. Features of stateful NAT64 162 The features of NAT64 are: 164 o NAT64 is compliant with the recommendations for how NATs should 165 handle UDP [RFC4787], TCP [RFC5382], and ICMP [RFC5508]. As such, 166 NAT64 only supports Endpoint-Independent mappings and supports 167 both Endpoint-Independent and Address-Dependent Filtering. 168 Because of the compliance with the aforementioned requirements, 169 NAT64 is compatible with current NAT traversal techniques, such as 170 ICE [RFC5245] and compatible with other non-IETF-standard NAT 171 traversal techniques. 173 o In the absence of any state in NAT64, only IPv6 nodes can initiate 174 sessions to IPv4 nodes. This works for roughly the same class of 175 applications that work through IPv4-to-IPv4 NATs. 177 o Depending on the filtering policy used (Endpoint-Independent, or 178 Address-Dependent), IPv4-nodes might be able to initiate sessions 179 to a given IPv6 node, if the NAT64 somehow has an appropriate 180 mapping (i.e.,state) for an IPv6 node, via one of the following 181 mechanisms: 183 * The IPv6 node has recently initiated a session to the same or 184 another IPv4 node. This is also the case if the IPv6 node has 185 used a NAT-traversal technique (such as ICE) . 187 * If a statically configured mapping exists for the IPv6 node. 189 o IPv4 address sharing: NAT64 allows multiple IPv6-only nodes to 190 share an IPv4 address to access the IPv4 Internet. This helps 191 with IPv4 forthcoming exhaustion. 193 o As currently defined in this NAT64 specification, only TCP/UDP/ 194 ICMP are supported. Support for other protocols such as other 195 transport protocols and IPsec are to be defined in separate 196 documents. 198 1.2. Overview 200 This section provides a non-normative introduction to NAT64. This is 201 achieved by describing the NAT64 behavior involving a simple setup, 202 that involves a single NAT64 device, a single DNS64 and a simple 203 network topology. The goal of this description is to provide the 204 reader with a general view of NAT64. It is not the goal of this 205 section to describe all possible configurations nor to provide a 206 normative specification of the NAT64 behavior. So, for the sake of 207 clarity, only TCP and UDP are described in this overview; the details 208 of ICMP, fragmentation, and other aspects of translation are 209 purposefully avoided in this overview. The normative specification 210 of NAT64 is provided in Section 3. 212 The NAT64 mechanism is implemented in a device which has (at least) 213 two interfaces, an IPv4 interface connected to the IPv4 network, and 214 an IPv6 interface connected to the IPv6 network. Packets generated 215 in the IPv6 network for a receiver located in the IPv4 network will 216 be routed within the IPv6 network towards the NAT64 device. The 217 NAT64 will translate them and forward them as IPv4 packets through 218 the IPv4 network to the IPv4 receiver. The reverse takes place for 219 packets generated by hosts connected to the IPv4 network for an IPv6 220 receiver. NAT64, however, is not symmetric. In order to be able to 221 perform IPv6-IPv4 translation, NAT64 requires state, binding an IPv6 222 address and TCP/UDP port (hereafter called an IPv6 transport address) 223 to an IPv4 address and TCP/UDP port (hereafter called an IPv4 224 transport address). 226 Such binding state is either statically configured in the NAT64 or it 227 is created when the first packet flowing from the IPv6 network to the 228 IPv4 network is translated. After the binding state has been 229 created, packets flowing in both directions on that particular flow 230 are translated. The result is that, in the general case, NAT64 only 231 supports communications initiated by the IPv6-only node towards an 232 IPv4-only node. Some additional mechanisms (like ICE) or static 233 binding configuration, can be used to provide support for 234 communications initiated by an IPv4-only node to an IPv6-only node. 236 1.2.1. Stateful NAT64 solution elements 238 In this section we describe the different elements involved in the 239 NAT64 approach. 241 The main component of the proposed solution is the translator itself. 242 The translator has essentially two main parts, the address 243 translation mechanism and the protocol translation mechanism. 245 Protocol translation from IPv4 packet header to IPv6 packet header 246 and vice-versa is performed according to the IP/ICMP Translation 247 Algorithm [I-D.ietf-behave-v6v4-xlate]. 249 Address translation maps IPv6 transport addresses to IPv4 transport 250 addresses and vice-versa. In order to create these mappings the 251 NAT64 has two pools of addresses: an IPv6 address pool (to represent 252 IPv4 addresses in the IPv6 network) and an IPv4 address pool (to 253 represent IPv6 addresses in the IPv4 network). 255 The IPv6 address pool is one or more IPv6 prefixes assigned to the 256 translator itself. Hereafter we will call the IPv6 address pool as 257 Pref64::/n; in the case there are more than one prefix assigned to 258 the NAT64, the comments made about Pref64::/n apply to each of them. 259 Pref64::/n will be used by the NAT64 to construct IPv4-Converted IPv6 260 addresses as defined in [I-D.ietf-behave-address-format]. Due to the 261 abundance of IPv6 address space, it is possible to assign one or more 262 Pref64::/n, each of them being equal to or even bigger than the size 263 of the whole IPv4 address space. This allows each IPv4 address to be 264 mapped into a different IPv6 address by simply concatenating a 265 Pref64::/n with the IPv4 address being mapped and a suffix. The 266 provisioning of the Pref64::/n as well as the address format are 267 defined in [I-D.ietf-behave-address-format]. 269 The IPv4 address pool is a set of IPv4 addresses, normally a prefix 270 assigned by the local administrator. Since IPv4 address space is a 271 scarce resource, the IPv4 address pool is small and typically not 272 sufficient to establish permanent one-to-one mappings with IPv6 273 addresses. So, except for the static/manually created ones, mappings 274 using the IPv4 address pool will be created and released dynamically. 275 Moreover, because of the IPv4 address scarcity, the usual practice 276 for NAT64 is likely to be the binding of IPv6 transport addresses 277 into IPv4 transport addresses, instead of IPv6 addresses into IPv4 278 addresses directly, enabling a higher utilization of the limited IPv4 279 address pool. This implies that NAT64 performs both address and port 280 translation. 282 Because of the dynamic nature of the IPv6 to IPv4 address mapping and 283 the static nature of the IPv4 to IPv6 address mapping, it is far 284 simpler to allow communications initiated from the IPv6 side toward 285 an IPv4 node, whose address is algorithmically mapped into an IPv6 286 address, than communications initiated from IPv4-only nodes to an 287 IPv6 node in which case an IPv4 address needs to be associated with 288 the IPv6 node's address dynamically. 290 Using a mechanisms such as DNS64, an IPv6 client obtains an IPv6 291 address that embeds the IPv4 address of the IPv4 server, and sends a 292 packet to that IPv6 address. The packets are intercepted by the 293 NAT64 device, which associates an IPv4 transport address of its IPv4 294 pool to the IPv6 transport address of the initiator, creating binding 295 state, so that reply packets can be translated and forwarded back to 296 the initiator. The binding state is kept while packets are flowing. 297 Once the flow stops, and based on a timer, the IPv4 transport address 298 is returned to the IPv4 address pool so that it can be reused for 299 other communications. 301 To allow an IPv6 initiator to do a DNS lookup to learn the address of 302 the responder, DNS64 [I-D.ietf-behave-dns64] is used to synthesize 303 AAAA RRs from the A RRs. The IPv6 addresses contained in the 304 synthetic AAAA RRs contain a Pref64::/n assigned to the NAT64 and the 305 IPv4 address of the responder. The synthetic AAAA RRs are passed 306 back to the IPv6 initiator, which will initiate an IPv6 communication 307 with an IPv6 address associated to the IPv4 receiver. The packet 308 will be routed to the NAT64 device, which will create the IPv6 to 309 IPv4 address mapping as described before. 311 1.2.2. Stateful NAT64 Behaviour Walkthrough 313 In this section we provide a simple example of the NAT64 behaviour. 314 We consider an IPv6 node located in an IPv6-only site that initiates 315 a TCP connection to an IPv4-only node located in the IPv4 network. 317 The scenario for this case is depicted in the following figure: 319 +---------------------+ +---------------+ 320 |IPv6 network | | IPv4 | 321 | | +-------------+ | Network | 322 | |--| Name server |--| | 323 | | | with DNS64 | | +----+ | 324 | +----+ | +-------------+ | | H2 | | 325 | | H1 |---| | | +----+ | 326 | +----+ | +-------+ | 192.0.2.1 | 327 |2001:DB8::1|------| NAT64 |----| | 328 | | +-------+ | | 329 | | | | | 330 +---------------------+ +---------------+ 332 The figure above shows an IPv6 node H1 with an IPv6 address 2001: 333 DB8::1 and an IPv4 node H2 with IPv4 address 192.0.2.1 H2 has 334 h2.example.com as FQDN. 336 A NAT64 connects the IPv6 network to the IPv4 network. This NAT64 337 uses the Well-Known Prefix 64:FF9B::/96 defined in 338 [I-D.ietf-behave-address-format] to represent IPv4 addresses in the 339 IPv6 address space and a single IPv4 address 203.0.113.1 assigned to 340 its IPv4 interface. The routing is configured in such a way that the 341 IPv6 packets addressed to a destination address in 64:FF9B::/96 are 342 routed to the IPv6 interface of the NAT64 device. 344 Also shown is a local name server with DNS64 functionality. The 345 local name server uses the Well-Known prefix 64:FF9B::/96 to create 346 the IPv6 addresses in the synthetic RRs. 348 For this example, assume the typical DNS situation where IPv6 hosts 349 have only stub resolvers and the local name server does the recursive 350 lookups. 352 The steps by which H1 establishes communication with H2 are: 354 1. H1 performs a DNS query for h2.example.com and receives the 355 synthetic AAAA RR from the local name server that implements the 356 DNS64 functionality. The AAAA record contains an IPv6 address 357 formed by the Well-Known Prefix and the IPv4 address of H2 (i.e. 358 64:FF9B::192.0.2.1). 360 2. H1 sends a TCP SYN packet to H2. The packet is sent from a 361 source transport address of (2001:DB8::1,1500) to a destination 362 transport address of (64:FF9B::192.0.2.1,80), where the ports are 363 set by H1. 365 3. The packet is routed to the IPv6 interface of the NAT64 (since 366 IPv6 routing is configured that way). 368 4. The NAT64 receives the packet and performs the following actions: 370 * The NAT64 selects an unused port (e.g. 2000) on its IPv4 371 address 203.0.113.1 and creates the mapping entry (2001:DB8:: 372 1,1500) <--> (203.0.113.1,2000) 374 * The NAT64 translates the IPv6 header into an IPv4 header using 375 the IP/ICMP Translation Algorithm 376 [I-D.ietf-behave-v6v4-xlate]. 378 * The NAT64 includes (203.0.113.1,2000) as source transport 379 address in the packet and (192.0.2.1,80) as destination 380 transport address in the packet. Note that 192.0.2.1 is 381 extracted directly from the destination IPv6 address of the 382 received IPv6 packet that is being translated. The 383 destination port 80 of the translated packet is the same as 384 the destination port of the received IPv6 packet. 386 5. The NAT64 sends the translated packet out its IPv4 interface and 387 the packet arrives at H2. 389 6. H2 node responds by sending a TCP SYN+ACK packet with destination 390 transport address (203.0.113.1,2000) and source transport address 391 (192.0.2.1,80). 393 7. Since the IPv4 address 203.0.113.1 is assigned to the IPv4 394 interface of the NAT64 device, the packet is routed to the NAT64 395 device, which will look for an existing mapping containing 396 (203.0.113.1,2000). Since the mapping (2001:DB8::1,1500) <--> 397 (203.0.113.1,2000) exists, the NAT64 performs the following 398 operations: 400 * The NAT64 translates the IPv4 header into an IPv6 header using 401 the IP/ICMP Translation Algorithm 402 [I-D.ietf-behave-v6v4-xlate]. 404 * The NAT64 includes (2001:DB8::1,1500) as destination transport 405 address in the packet and (64:FF9B::192.0.2.1,80) as source 406 transport address in the packet. Note that 192.0.2.1 is 407 extracted directly from the source IPv4 address of the 408 received IPv4 packet that is being translated. The source 409 port 80 of the translated packet is the same as the source 410 port of the received IPv4 packet. 412 8. The translated packet is sent out the IPv6 interface to H1. 414 The packet exchange between H1 and H2 continues and packets are 415 translated in the different directions as previously described. 417 It is important to note that the translation still works if the IPv6 418 initiator H1 learns the IPv6 representation of H2's IPv4 address 419 (i.e., 64:FF9B::192.0.2.1) through some scheme other than a DNS 420 look-up. This is because the DNS64 processing does NOT result in any 421 state installed in the NAT64 and because the mapping of the IPv4 422 address into an IPv6 address is the result of concatenating the Well- 423 Known Prefix to the original IPv4 address. 425 1.2.3. Filtering 427 NAT64 may do filtering, which means that it only allows a packet in 428 through an interface under certain circumstances. The NAT64 can 429 filter IPv6 packets based on the administrative rules to create 430 entries in the binding and session tables. The filtering can be 431 flexible and general but the idea of the filtering is to provide the 432 administrators necessary control to avoid DoS attacks that would 433 result in exhaustion of the NAT64's IPv4 address, port, memory and 434 CPU resources. Filtering techniques of incoming IPv6 packets are not 435 specific to the NAT64 and therefore are not described in this 436 specification. 438 Filtering of IPv4 packets on the other hand is tightly coupled to the 439 NAT64 state and therefore is described in this specification. In 440 this document, we consider that the NAT64 may do no filtering, or it 441 may filter incoming IPv4 packets. 443 NAT64 filtering of incoming IPv4 packets is consistent with the 444 recommendations of [RFC4787], and the ones of [RFC5382]. Because of 445 that, the NAT64 as specified in this document, supports both 446 Endpoint-Independent Filtering and Address-Dependent Filtering, both 447 for TCP and UDP as well as filtering of ICMP packets. 449 If a NAT64 performs Endpoint-Independent Filtering of incoming IPv4 450 packets, then an incoming IPv4 packet is dropped unless the NAT64 has 451 state for the destination transport address of the incoming IPv4 452 packet. 454 If a NAT64 performs Address-Dependent Filtering of incoming IPv4 455 packets, then an incoming IPv4 packet is dropped unless the NAT64 has 456 state involving the destination transport address of the IPv4 457 incoming packet and the particular source IP address of the incoming 458 IPv4 packet. 460 2. Terminology 462 This section provides a definitive reference for all the terms used 463 in this document. 465 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 466 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 467 document are to be interpreted as described in RFC 2119 [RFC2119]. 469 The following additional terms are used in this document: 471 3-Tuple: The tuple (source IP address, destination IP address, ICMP 472 Identifier). A 3-tuple uniquely identifies an ICMP Query session. 473 When an ICMP Query session flows through a NAT64, each session has 474 two different 3-tuples: one with IPv4 addresses and one with IPv6 475 addresses. 477 5-Tuple: The tuple (source IP address, source port, destination IP 478 address, destination port, transport protocol). A 5-tuple 479 uniquely identifies a UDP/TCP session. When a UDP/TCP session 480 flows through a NAT64, each session has two different 5-tuples: 481 one with IPv4 addresses and one with IPv6 addresses. 483 BIB: Binding Information Base. A table of bindings kept by a NAT64. 484 Each NAT64 has a BIB for each translated protocol. An 485 implementation compliant to this document would have a BIB for 486 TCP, one for UDP and one for ICMP Queries. Additional BIBs would 487 be added to support other protocols, such as SCTP. 489 Endpoint-Independent Mapping: In NAT64, using the same mapping for 490 all the sessions involving a given IPv6 transport address of an 491 IPv6 host (irrespectively of the transport address of the IPv4 492 host involved in the communication). Endpoint-independent Mapping 493 is important for peer-to-peer communication. See [RFC4787] for 494 the definition of the different types of mappings in IPv4-to-IPv4 495 NATs. 497 Filtering, Endpoint-Independent: The NAT64 only filters incoming 498 IPv4 packets destined to a transport address for which there is no 499 state in the NAT64, regardless of the source IPv4 transport 500 address. The NAT forwards any packets destined to any transport 501 address for which it has state. In other words, having state for 502 a given transport address is sufficient to allow any packets back 503 to the internal endpoint. See [RFC4787] for the definition of the 504 different types of filtering in IPv4-to-IPv4 NATs. 506 Filtering, Address-Dependent: The NAT64 filters incoming IPv4 507 packets destined to a transport address for which there is no 508 state (similar to the Endpoint-Independent Filtering). 509 Additionally, the NAT64 will filter out incoming IPv4 packets 510 coming from a given IPv4 address X and destined for a transport 511 address that it has state for if the NAT64 has not sent packets to 512 X previously (independently of the port used by X). In other 513 words, for receiving packets from a specific IPv4 endpoint, it is 514 necessary for the IPv6 endpoint to send packets first to that 515 specific IPv4 endpoint's IP address. 517 Hairpinning: Having a packet do a "U-turn" inside a NAT and come 518 back out the same side as it arrived on. If the destination IPv6 519 address and its embedded IPv4 address are both assigned to the 520 NAT64 itself, then the packet is being sent to another IPv6 host 521 connected to the same NAT64. Such a packet is called a 'hairpin 522 packet'. A NAT64 that forwards hairpin packets, back to the IPv6 523 host are defined as supporting "hairpinning". Hairpinning support 524 is important for peer-to-peer applications, as there are cases 525 when two different hosts on the same side of a NAT can only 526 communicate using sessions that hairpin through the NAT. Hairpin 527 packets can be either TCP or UDP. More detailed explanation of 528 hairpinning and examples for the UDP case can be found in 529 [RFC4787]. 531 ICMP Query packet: ICMP packets that are not ICMP error messages. 532 For ICMPv6, ICMPv6 Query Messages are the ICMPv6 Informational 533 messages as defined in [RFC4443]. For ICMPv4, ICMPv4 Query 534 messages are all ICMPv4 messages that are not ICMPv4 error 535 messages. 537 Mapping or Binding: A mapping between an IPv6 transport address and 538 a IPv4 transport address or a mapping between an (IPv6 address, 539 ICMPv6 Identifier) pair and an (IPv4 address, ICMPv4 Identifier) 540 pair. Used to translate the addresses and ports/ICMP Identifiers 541 of packets flowing between the IPv6 host and the IPv4 host. In 542 NAT64, the IPv4 address and port/ICMPv4 Identifier is always one 543 assigned to the NAT64 itself, while the IPv6 address and port/ 544 ICMPv6 Identifier belongs to some IPv6 host. 546 Session: The flow of packets between two different hosts. This may 547 be TCP, UDP or ICMP Queries. In NAT64, typically one host is an 548 IPv4 host, and the other one is an IPv6 host. However, due to 549 hairpinning, both hosts might be IPv6 hosts. 551 Session table: A table of sessions kept by a NAT64. Each NAT64 has 552 three session tables, one for TCP, one for UDP and one for ICMP 553 Queries. 555 Stateful NAT64: A function that has per-flow state which translates 556 IPv6 packets to IPv4 packets and vice-versa, for TCP, UDP, and 557 ICMP. The NAT64 uses binding state to perform the translation 558 between IPv6 and IPv4 addresses. In this document we also refer 559 to stateful NAT64 simply as NAT64. 561 Stateful NAT64 device: The device where the NAT64 function is 562 executed. In this document we also refer to stateful NAT64 device 563 simply as NAT64 device. 565 Transport Address: The combination of an IPv6 or IPv4 address and a 566 port. Typically written as (IP address, port)- e.g. (192.0.2.15, 567 8001). 569 Tuple: Refers to either a 3-Tuple or a 5-tuple as defined above. 571 For a detailed understanding of this document, the reader should also 572 be familiar with NAT terminology [RFC4787]. 574 3. Stateful NAT64 Normative Specification 576 A NAT64 is a device with at least one IPv6 interface and at least one 577 IPv4 interface. Each NAT64 device MUST have at least one unicast /n 578 IPv6 prefix assigned to it, denoted Pref64::/n. Additional 579 considerations about the Pref64::/n are presented in Section 3.5.4. 580 A NAT64 MUST have one or more unicast IPv4 addresses assigned to it. 582 A NAT64 uses the following conceptual dynamic data structures: 584 o UDP Binding Information Base 586 o UDP Session Table 588 o TCP Binding Information Base 590 o TCP Session Table 592 o ICMP Query Binding Information Base 594 o ICMP Query Session Table 596 These tables contain information needed for the NAT64 processing. 597 The actual division of the information into six tables is done in 598 order to ease the description of the NAT64 behaviour. NAT64 599 implementations are free to use different data structures but they 600 MUST store all the required information and the externally visible 601 outcome MUST be the same as the one described in this document. 603 The notation used is the following: upper case letters are IPv4 604 addresses; upper case letters with a prime(') are IPv6 addresses; 605 lower case letters are ports; IPv6 prefixes of length n are indicated 606 by "P::/n", mappings are indicated as "(X,x) <--> (Y',y)". 608 3.1. Binding Information Bases 610 A NAT64 has three Binding Information Bases (BIBs): one for TCP, one 611 for UDP and one for ICMP Queries. In the case of UDP and TCP BIBs, 612 each BIB entry specifies a mapping between an IPv6 transport address 613 and an IPv4 transport address: 615 (X',x) <--> (T,t) 617 where X' is some IPv6 address, T is an IPv4 address, and x and t are 618 ports. T will always be one of the IPv4 addresses assigned to the 619 NAT64. The BIB has then two columns: the BIB IPv6 transport address 620 and the BIB IPv4 transport address. A given IPv6 or IPv4 transport 621 address can appear in at most one entry in a BIB: for example, (2001: 622 db8::17, 49832) can appear in at most one TCP and at most one UDP BIB 623 entry. TCP and UDP have separate BIBs because the port number space 624 for TCP and UDP are distinct. If the BIBs are implemented as 625 specified in this document, it results in Endpoint-Independent 626 Mappings in the NAT64. The information in the BIBs is also used to 627 implement Endpoint-Independent Filtering. (Address-Dependent 628 Filtering is implemented using the session tables described below.) 630 In the case of the ICMP Query BIB, each ICMP Query BIB entry 631 specifies a mapping between an (IPv6 address, ICMPv6 Identifier) pair 632 and an (IPv4 address, ICMPv4 Identifier) pair. 634 (X',i1) <--> (T,i2) 636 where X' is some IPv6 address, T is an IPv4 address, i1 is an ICMPv6 637 Identifier and i2 is an ICMPv4 Identifier. T will always be one of 638 the IPv4 addresses assigned to the NAT64. A given (IPv6 or IPv4 639 address, ICMPv6 or ICMPv4 Identifier) pair can appear in at most one 640 entry in the ICMP Query BIB. 642 Entries in any of the three BIBs can be created dynamically as the 643 result of the flow of packets as described in Section 3.5 but they 644 can also be created manually by an administrator. NAT64 645 implementations SHOULD support manually configured BIB entries for 646 any of the three BIBs. Dynamically-created entries are deleted from 647 the corresponding BIB when the last session associated with the BIB 648 entry is removed from the session table. Manually-configured BIB 649 entries are not deleted when there is no corresponding session table 650 entry and can only be deleted by the administrator. 652 3.2. Session Tables 654 A NAT64 also has three session tables: one for TCP sessions, one for 655 UDP sessions, and one for ICMP Query sessions. Each entry keeps 656 information on the state of the corresponding session. In the TCP 657 and UDP session tables, each entry specifies a mapping between a pair 658 of IPv6 transport addresses and a pair of IPv4 transport addresses: 660 (X',x),(Y',y) <--> (T,t),(Z,z) 662 where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and 663 x, y, z and t are ports. T will always be one of the IPv4 addresses 664 assigned to the NAT64. Y' is always the IPv6 representation of the 665 IPv4 address Z, so Y' is obtained from Z using the algorithm applied 666 by the NAT64 to create IPv6 representations of IPv4 addresses. y will 667 always be equal to z. 669 For each TCP or UDP Session Table Entry (STE), there are then five 670 columns. The terminology used for the session table entry columns is 671 from the perspective of an incoming IPv6 packet being translated into 672 an outgoing IPv4 packet. The columns are:: 674 The STE source IPv6 transport address, (X',x) in the example 675 above, 677 The STE destination IPv6 transport address, (Y',y) in the example 678 above, 680 The STE source IPv4 transport address, (T,t) in the example above, 681 and, 683 The STE destination IPv4 transport address, (Z,z) in the example 684 above. 686 The STE lifetime. 688 In the ICMP query session table, each entry specifies a mapping 689 between a 3-tuple of IPv6 source address, IPv6 destination address 690 and ICMPv6 Identifier and a 3-tuple of IPv4 source address, IPv4 691 destination address and ICMPv4 Identifier: 693 (X',Y',i1) <--> (T,Z,i2) 695 where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, i1 is 696 an ICMPv6 Identifier and i2 is an ICMPv4 Identifier. T will always 697 be one of the IPv4 addresses assigned to the NAT64. Y' is always the 698 IPv6 representation of the IPv4 address Z, so Y' is obtained from Z 699 using the algorithm applied by the NAT64 to create IPv6 700 representations of IPv4 addresses. 702 For each ICMP Query Session Table Entry (STE), there are then seven 703 columns: 705 The STE source IPv6 address, X' in the example above, 707 The STE destination IPv6 address, Y' in the example above, 709 The STE ICMPv6 Identifier, i1 in the example above, 711 The STE source IPv4 address, T in the example above, 713 The STE destination IPv4 address, Z in the example above, and, 715 The STE ICMPv4 Identifier, i2 in the example above. 717 The STE lifetime. 719 3.3. Packet Processing Overview 721 The NAT64 uses the session state information to determine when the 722 session is completed, and also uses session information for Address- 723 Dependent Filtering. A session can be uniquely identified by either 724 an incoming tuple or an outgoing tuple. 726 For each TCP or UDP session, there is a corresponding BIB entry, 727 uniquely specified by either the source IPv6 transport address (in 728 the IPv6 --> IPv4 direction) or the destination IPv4 transport 729 address (in the IPv4 --> IPv6 direction). For each ICMP Query 730 session, there is a corresponding BIB entry, uniquely specified by 731 either the source IPv6 address and ICMPv6 Identifier (in the IPv6 --> 732 IPv4 direction) or the destination IPv4 address and the ICMPv4 733 Identifier (in the IPv4 --> IPv6 direction). However, for all the 734 BIBs, a single BIB entry can have multiple corresponding sessions. 735 When the last corresponding session is deleted, if the BIB entry was 736 dynamically created, the BIB entry is deleted. 738 The NAT64 will receive packets through its interfaces. These packets 739 can be either IPv6 packets or IPv4 packets and they may carry TCP 740 traffic, UDP traffic or ICMP traffic. The processing of the packets 741 will be described next. In the case that the processing is common to 742 all the aforementioned types of packets, we will refer to the packet 743 as the incoming IP packet in general. In case that the processing is 744 specific to IPv6 packets, we will refer to the incoming IPv6 packet 745 and similarly to the IPv4 packets. 747 The processing of an incoming IP packet takes the following steps: 749 1. Determining the incoming tuple 751 2. Filtering and updating binding and session information 753 3. Computing the outgoing tuple 755 4. Translating the packet 757 5. Handling hairpinning 759 The details of these steps are specified in the following 760 subsections. 762 This breakdown of the NAT64 behavior into processing steps is done 763 for ease of presentation. A NAT64 MAY perform the steps in a 764 different order, or MAY perform different steps, but the externally 765 visible outcome MUST be the same as the one described in this 766 document. 768 3.4. Determining the Incoming tuple 770 This step associates an incoming tuple with every incoming IP packet 771 for use in subsequent steps. In the case of TCP, UDP and ICMP error 772 packets, the tuple is a 5-tuple consisting of source IP address, 773 source port, destination IP address, destination port, transport 774 protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting 775 of the source IP address, destination IP address and ICMP Identifier. 777 If the incoming IP packet contains a complete (un-fragmented) UDP or 778 TCP protocol packet, then the 5-tuple is computed by extracting the 779 appropriate fields from the received packet. 781 If the incoming packet is a complete (un-fragmented) ICMP query 782 message (i.e., an ICMPv4 Query message or an ICMPv6 Informational 783 message), the 3-tuple is the source IP address, the destination IP 784 address and the ICMP Identifier. 786 If the incoming IP packet contains a complete (un-fragmented) ICMP 787 error message containing a UDP or a TCP packet, then the incoming 788 5-tuple is computed by extracting the appropriate fields from the IP 789 packet embedded inside the ICMP error message. However, the role of 790 source and destination is swapped when doing this: the embedded 791 source IP address becomes the destination IP address in the incoming 792 5-tuple, the embedded source port becomes the destination port in the 793 incoming 5-tuple, etc. If it is not possible to determine the 794 incoming 5-tuple (perhaps because not enough of the embedded packet 795 is reproduced inside the ICMP message), then the incoming IP packet 796 MUST be silently discarded. 798 If the incoming IP packet contains a complete (un-fragmented) ICMP 799 error message containing a ICMP error message, then the packet is 800 silently discarded. 802 If the incoming IP packet contains a complete (un-fragmented) ICMP 803 error message containing an ICMP Query message, then the incoming 804 3-tuple is computed by extracting the appropriate fields from the IP 805 packet embedded inside the ICMP error message. However, the role of 806 source and destination is swapped when doing this: the embedded 807 source IP address becomes the destination IP address in the incoming 808 3-tuple, the embedded destination IP address becomes the source 809 address in the incoming 3-tuple and the embedded ICMP Identifier is 810 used as the ICMP Identifier of the incoming 3-tuple. If it is not 811 possible to determine the incoming 3-tuple (perhaps because not 812 enough of the embedded packet is reproduced inside the ICMP message), 813 then the incoming IP packet MUST be silently discarded. 815 If the incoming IP packet contains a fragment, then more processing 816 may be needed. This specification leaves open the exact details of 817 how a NAT64 handles incoming IP packets containing fragments, and 818 simply requires that the external behavior of the NAT64 is compliant 819 with the following conditions: 821 The NAT64 MUST handle fragments. In particular, NAT64 MUST handle 822 fragments arriving out-of-order , conditioned on the following: 824 * The NAT64 MUST limit the amount of resources devoted to the 825 storage of fragmented packets in order to protect from DoS 826 attacks. 828 * As long as the NAT64 has available resources, the NAT64 MUST 829 allow the fragments to arrive over a time interval. The time 830 interval SHOULD be configurable and the default value MUST be 831 of at least FRAGMENT_MIN. 833 * The NAT64 MAY require that the UDP, TCP, or ICMP header be 834 completely contained within the fragment that contains fragment 835 offset equal to zero. 837 For incoming packets carrying TCP or UDP fragments with non-null 838 checksum, NAT64 MAY elect to queue the fragments as they arrive 839 and translate all fragments at the same time. In this case, the 840 incoming tuple is determined as documented above to the un- 841 fragmented packets. Alternatively, a NAT64 MAY translate the 842 fragments as they arrive, by storing information that allows it to 843 compute the 5-tuple for fragments other than the first. In the 844 latter case, subsequent fragments may arrive before the first and 845 the rules about how the NAT64 handles (out-of-order) fragments 846 described in the bulleted list above apply. 848 For incoming IPv4 packets carrying UDP packets with null checksum, 849 if the NAT64 has enough resources, the NAT64 MUST reassemble the 850 packets and MUST calculate the checksum. If the NAT64 does not 851 have enough resources, then it MUST silently discard the packets. 853 Implementers of NAT64 should be aware that there are a number of 854 well-known attacks against IP fragmentation; see [RFC1858] and 855 [RFC3128]. Implementers should also be aware of additional issues 856 with reassembling packets at high rates, described in [RFC4963]. 858 If the incoming packet is an IPv6 packet that contains a protocol 859 other than TCP, UDP or ICMPv6 in the last Next Header, then the 860 packet SHOULD be discarded and, if the security policy permits, the 861 NAT64 SHOULD send an ICMPv6 Destination Unreachable error message 862 with Code 3 (Destination Unreachable) to the source address of the 863 received packet. NOTE: This behaviour may be updated by future 864 documents that define how other protocols such as SCTP or DCCP are 865 processed by NAT64. 867 If the incoming packet is an IPv4 packet that contains a protocol 868 other than TCP, UDP or ICMPv4, then the packet SHOULD discarded and, 869 if the security policy permits, the NAT64 SHOULD send an ICMPv4 870 Destination Unreachable error message with Code 2 (Protocol 871 Unreachable) to the source address of the received packet. NOTE: 872 This behaviour may be updated by future documents that define how 873 other protocols such as SCTP or DCCP are processed by NAT64. 875 3.5. Filtering and Updating Binding and Session Information 877 This step updates binding and session information stored in the 878 appropriate tables. This step may also filter incoming packets, if 879 desired. 881 The details of this step depend on the protocol i.e. UDP, TCP or 882 ICMP. The behaviour for UDP is described in Section 3.5.1, for TCP 883 is described in Section 3.5.2 and for ICMP Queries is described in 884 Section 3.5.3. For the case of ICMP error messages, they do not 885 affect in any way neither the BIBs nor the session tables, so, there 886 is no processing resulting from these messages in this section. ICMP 887 error message processing continues in Section 3.6. 889 Irrespective of the transport protocol used, the NAT64 MUST silently 890 discard all incoming IPv6 packets containing a source address that 891 contains the Pref64::/n. This is required in order to prevent 892 hairpinning loops as described in Section 5. In addition, the NAT64 893 MUST only process incoming IPv6 packets that contain a destination 894 address that contains Pref64::/n. Likewise, the NAT64 MUST only 895 process incoming IPv4 packets that contain a destination address that 896 belong to the IPv4 pool assigned to the NAT64. 898 3.5.1. UDP Session Handling 900 The following state information is stored for a UDP session: 902 Binding:(X',x),(Y',y) <--> (T,t),(Z,z) 904 Lifetime: a timer that tracks the remaining lifetime of the UDP 905 session. When the timer expires, the UDP session is deleted. If 906 all the UDP sessions corresponding to a dynamically created UDP 907 BIB entry are deleted, then the UDP BIB entry is also deleted. 909 An IPv6 incoming packet with an incoming tuple with source transport 910 address (X',x) and destination transport address (Y',y) is processed 911 as follows: 913 The NAT64 searches for a UDP BIB entry that contains the BIB IPv6 914 transport address that matches the IPv6 source transport address 915 (X',x). If such an entry does not exist, the NAT64 tries to 916 create a new entry (if resources and policy permit). The source 917 IPv6 transport address of the packet (X',x) is used as BIB IPv6 918 transport address, and the BIB IPv4 transport address is set to 919 (T,t) which is allocated using the rules defined in 920 Section 3.5.1.1. The result is a BIB entry as follows: (X',x) 921 <--> (T,t). 923 The NAT64 searches for the session table entry corresponding to 924 the incoming 5-tuple. If no such entry is found, the NAT64 tries 925 to create a new entry (if resources and policy permit). The 926 information included in the session table is as follows: 928 * The STE source IPv6 transport address is set to (X',x), the 929 source IPv6 transport addresses contained in the received IPv6 930 packet, 932 * The STE destination IPv6 transport address is set to (Y',y), 933 the destination IPv6 transport addresses contained in the 934 received IPv6 packet, 936 * The STE source IPv4 transport address is extracted from the 937 corresponding UDP BIB entry i.e. it is set to (T,t), 939 * The STE destination IPv4 transport is set to (Z(Y'),y), y being 940 the same port as the STE destination IPv6 transport address and 941 Z(Y') being algorithmically generated from the IPv6 destination 942 address (i.e. Y') using the reverse algorithm (see 943 Section 3.5.4). 945 The result is a Session table entry as follows: (X',x),(Y',y) <--> 946 (T,t),(Z(Y'),y) 948 The NAT64 sets (or resets) the timer in the Session Table Entry to 949 the maximum session lifetime. The maximum session lifetime MAY be 950 configurable and the default SHOULD be at least UDP_DEFAULT. The 951 maximum session lifetime MUST NOT be less than UDP_MIN. The 952 packet is translated and forwarded as described in the following 953 sections. 955 An IPv4 incoming packet, with an incoming tuple with source IPv4 956 transport address (W,w) and destination IPv4 transport address (T,t) 957 is processed as follows: 959 The NAT64 searches for a UDP BIB entry that contains the BIB IPv4 960 transport address matching (T,t), (i.e., the IPv4 destination 961 transport address in the incoming IPv4 packet). If such an entry 962 does not exist, the packet MUST be dropped. An ICMP error message 963 with type of 3 (Destination Unreachable) MAY be sent to the 964 original sender of the packet. 966 If the NAT64 applies Address-Dependent Filters on its IPv4 967 interface, then the NAT64 checks to see if the incoming packet is 968 allowed according to the Address-Dependent Filtering rule. To do 969 this, it searches for a session table entry with an STE source 970 IPv4 transport address equal to (T,t), (i.e., the destination IPv4 971 transport address in the incoming packet) and STE destination IPv4 972 address equal to W, (i.e., the source IPv4 address in the incoming 973 packet). If such an entry is found (there may be more than one), 974 packet processing continues. Otherwise, the packet is discarded. 975 If the packet is discarded, then an ICMP error message MAY be sent 976 to the original sender of the packet. The ICMP error message, if 977 sent, has a type of 3 (Destination Unreachable) and a code of 13 978 (Communication Administratively Prohibited). 980 In case the packet is not discarded in the previous processing 981 (either because the NAT64 is not filtering or because the packet 982 is compliant with the Address-Dependent Filtering rule), then the 983 NAT64 searches for the session table entry containing the STE 984 source IPv4 transport address equal to (T,t) and the STE 985 destination IPv4 transport address equal to (W,w). If no such 986 entry is found, the NAT64 tries to create a new entry (if 987 resources and policy permit). In case a new UDP session table 988 entry is created, it contains the following information: 990 * The STE source IPv6 transport address is extracted from the 991 corresponding UDP BIB entry. 993 * The STE destination IPv6 transport address is set to (Y'(W),w), 994 w being the same port w than the source IPv4 transport address 995 and Y'(W) being the IPv6 representation of W, generated using 996 the algorithm described in Section 3.5.4. 998 * The STE source IPv4 transport address is set to (T,t) the 999 destination IPv4 transport addresses contained in the received 1000 IPv4 packet. 1002 * The STE destination IPv4 transport is set to (W,w), the source 1003 IPv4 transport addresses contained in the received IPv4 packet. 1005 The NAT64 sets (or resets) the timer in the Session Table Entry to 1006 the maximum session lifetime. The maximum session lifetime MAY be 1007 configurable and the default SHOULD be at least UDP_DEFAULT. The 1008 maximum session lifetime MUST NOT be less than UDP_MIN. The 1009 packet is translated and forwarded as described in the following 1010 sections. 1012 3.5.1.1. Rules for Allocation of IPv4 Transport Addresses for UDP 1014 When a new UDP BIB entry is created for a source transport address of 1015 (S',s), then the NAT64 allocates an IPv4 transport address for this 1016 BIB entry as follows: 1018 If there exists some other BIB entry containing S' as the IPv6 1019 address and mapping it to some IPv4 address T, then the NAT64 1020 SHOULD use T as the IPv4 address. Otherwise, use any IPv4 address 1021 of the IPv4 pool assigned to the NAT64 to be used for translation. 1023 If the port s is in the Well-Known port range 0-1023, and the 1024 NAT64 has an available port t in the same port range, then the 1025 NAT64 SHOULD allocate the port t. If the NAT64 does not have a 1026 port available in the same range, the NAT64 MAY assign a port t 1027 from other range where it has an available port. (This behavior 1028 is recommended in REQ 3-a of [RFC4787].) 1030 If the port s is in the range 1024-65535, and the NAT64 has an 1031 available port t in the same port range, then the NAT64 SHOULD 1032 allocate the port t. If the NAT64 does not have a port available 1033 in the same range, the NAT64 MAY assign a port t from other range 1034 where it has an available port. (this behavior is recommended in 1035 REQ 3-a of [RFC4787]) 1037 The NAT64 SHOULD preserve the port parity (odd/even), as per 1038 Section 4.2.2 of [RFC4787]). 1040 In all cases, the allocated IPv4 transport address (T,t) MUST NOT 1041 be in use in another entry in the same BIB, but MAY be in use in 1042 the other BIB (referring to the UDP and TCP BIBs). 1044 If it is not possible to allocate an appropriate IPv4 transport 1045 address or create a BIB entry, then the packet is discarded. The 1046 NAT64 SHOULD send an ICMPv6 Destination Unreachable/Address 1047 unreachable (Code 3) message. 1049 3.5.2. TCP Session Handling 1051 In this section we describe how the TCP BIB and Session table are 1052 populated. We do so by defining the state machine of the NAT64 uses 1053 for TCP. We first describe the states and the information contained 1054 in them and then we describe the actual state machine and state 1055 transitions. 1057 3.5.2.1. State definition 1059 The following state information is stored for a TCP session: 1061 Binding:(X',x),(Y',y) <--> (T,t),(Z,z) 1063 Lifetime: a timer that tracks the remaining lifetime of the TCP 1064 session. When the timer expires, the TCP session is deleted. If 1065 all the TCP sessions corresponding to a TCP BIB entry are deleted, 1066 then the dynamically created TCP BIB entry is also deleted. 1068 Because the TCP session inactivity lifetime is set to at least 2 1069 hours and 4 min (as per [RFC5382]), it is important that each TCP 1070 session table entry corresponds to an existent TCP session. In order 1071 to do that, for each TCP session established through it, it tracks 1072 the corresponding state machine as follows. 1074 The states are the following ones: 1076 CLOSED: Analogous to [RFC0793], CLOSED is a fictional state 1077 because it represents the state when there is no state for this 1078 particular 5-tuple, and therefore, no connection. 1080 V4 INIT: An IPv4 packet containing a TCP SYN was received by the 1081 NAT64, implying that a TCP connection is being initiated from the 1082 IPv4 side. The NAT64 is now waiting for a matching IPv6 packet 1083 containing the TCP SYN in the opposite direction. 1085 V6 INIT: An IPv6 packet containing a TCP SYN was received, 1086 translated and forwarded by the NAT64, implying that a TCP 1087 connection is being initiated from the IPv6 side. The NAT64 is 1088 now waiting for a matching IPv4 packet containing the TCP SYN in 1089 the opposite direction. 1091 ESTABLISHED: Represents an open connection, with data able to flow 1092 in both directions. 1094 V4 FIN RCV: An IPv4 packet containing a TCP FIN was received by 1095 the NAT64, data can still flow in the connection, and the NAT64 is 1096 waiting for a matching TCP FIN in the opposite direction. 1098 V6 FIN RCV: An IPv6 packet containing a TCP FIN was received by 1099 the NAT64, data can still flow in the connection, and the NAT64 is 1100 waiting for a matching TCP FIN in the opposite direction. 1102 V6 FIN + V4 FIN RCV: Both an IPv4 packet containing a TCP FIN and 1103 an IPv6 packet containing an TCP FIN for this connection were 1104 received by the NAT64. The NAT64 keeps the connection state alive 1105 and forwards packets in both directions for a short period of time 1106 to allow remaining packets (in particular the ACKs) to be 1107 delivered. 1109 TRANS: The lifetime of the state for the connection is set to 1110 TCP_TRANS minutes either because a packet containing a TCP RST was 1111 received by the NAT64 for this connection or simply because the 1112 lifetime of the connection has decreased and there are only 1113 TCP_TRANS minutes left. The NAT64 will keep the state for the 1114 connection for TCP_TRANS min. and if no other data packets for 1115 that connection are received, the state for this connection is 1116 then terminated. 1118 3.5.2.2. State machine for TCP processing in the NAT64 1120 The state machine used by the NAT64 for the TCP session processing is 1121 depicted next. The described state machine handles all TCP segments 1122 received through the IPv6 and IPv4 interface. There is one state 1123 machine per TCP connection that is potentially established through 1124 the NAT64. After bootstrapping of the NAT64 device, all TCP sessions 1125 are in CLOSED state. As we mention above, the CLOSED state is a 1126 fictional state when is no state for that particular connection in 1127 the NAT64. It should be noted that there is one state machine per 1128 connection, so only packets belonging to a given connection are 1129 inputs to the state machine associated to that connection. In other 1130 words, when in the state machine below we state that a packet is 1131 received, it is implicit that the incoming 5-tuple of the data packet 1132 matches to the one of the state machine. 1134 A TCP segment with the SYN flag set that is received through the IPv6 1135 interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 1136 FIN + V4 FIN, V6 RST and V4 RST. 1138 +-----------------------------+ 1139 | | 1140 V | 1141 V6 +------+ V4 | 1142 +----SYN------|CLOSED|-----SYN------+ | 1143 | +------+ | | 1144 | ^ | | 1145 | |TCP_TRANS T.O. | | 1146 V | V | 1147 +-------+ +-------+ +-------+ | 1148 |V6 INIT| | TRANS | |V4 INIT| | 1149 +-------+ +-------+ +-------+ | 1150 | | ^ | | 1151 | data pkt | | | 1152 | | V4 or V6 RST | | 1153 | | TCP_EST T.O. | | 1154 V4 SYN V | V6 SYN | 1155 | +--------------+ | | 1156 +--------->| ESTABLISHED |<---------+ | 1157 +--------------+ | 1158 | | | 1159 V4 FIN V6 FIN | 1160 | | | 1161 V V | 1162 +---------+ +----------+ | 1163 | V4 FIN | | V6 FIN | | 1164 | RCV | | RCV | | 1165 +---------+ +----------+ | 1166 | | | 1167 V6 FIN V4 FIN TCP_TRANS 1168 | | T.O. 1169 V V | 1170 +---------------------+ | 1171 | V4 FIN + V6 FIN RCV |--------------------+ 1172 +---------------------+ 1174 We next describe the state information and the transitions. 1176 *** CLOSED *** 1178 If a V6 SYN is received with an incoming tuple with source transport 1179 address (X',x) and destination transport address (Y',y) (this is the 1180 case of a TCP connection initiated from the IPv6 side), the 1181 processing is as follows: 1183 1. The NAT64 searches for a TCP BIB entry that matches the IPv6 1184 source transport address (X',x). 1186 If such an entry does not exist, the NAT64 tries to create a 1187 new BIB entry (if resources and policy permit). The BIB IPv6 1188 transport address is set to (X',x) (i.e., the source IPv6 1189 transport address of the packet). The BIB IPv4 transport 1190 address is set to an IPv4 transport address allocated using 1191 the rules defined in Section 3.5.2.3. The processing of the 1192 packet continues as described in bullet 2. 1194 If the entry already exists, then the processing continues as 1195 described in bullet 2. 1197 2. Then the NAT64 tries to create a new TCP session entry in the TCP 1198 session table (if resources and policy permit). The information 1199 included in the session table is as follows: 1201 The STE source IPv6 transport address is set to (X',x) (i.e. 1202 the source transport address contained in the received V6 SYN 1203 packet, 1205 The STE destination IPv6 transport address is set to (Y',y) 1206 (i.e. the destination transport address contained in the 1207 received V6 SYN packet. 1209 The STE source IPv4 transport address is set to the BIB IPv4 1210 transport address of the corresponding TCP BIB entry. 1212 The STE destination IPv4 transport address contains the port y 1213 (i.e., the same port as the IPv6 destination transport 1214 address) and the IPv4 address that is algorithmically 1215 generated from the IPv6 destination address (i.e. Y') using 1216 the reverse algorithm as specified in Section 3.5.4. 1218 The lifetime of the TCP session table entry is set to at least 1219 to TCP_TRANS (the transitory connection idle timeout as 1220 defined in [RFC5382]). 1222 3. The state of the session is moved to V6 INIT. 1224 4. The NAT64 translates and forwards the packet as described in the 1225 following sections. 1227 If a V4 SYN packet is received with an incoming tuple with source 1228 IPv4 transport address (Y,y) and destination IPv4 transport address 1229 (X,x) (this is the case of a TCP connection initiated from the IPv4 1230 side), the processing is as follows: 1232 If the security policy requires silently dropping externally 1233 initiated TCP connections, then the packet is silently discarded, 1234 else, 1236 If the destination transport address contained in the incoming V4 1237 SYN (i.e., X,x) is not in use in the TCP BIB, then: 1239 The NAT64 tries to create a new session table entry in the TCP 1240 session table (if resources and policy permit), containing the 1241 following information: 1243 + The STE source IPv4 transport address is set to (X,x) (i.e. 1244 the destination transport address contained in the V4 SYN) 1246 + The STE destination IPv4 transport address is set to (Y,y) 1247 (i.e. the source transport address contained in the V4 SYN) 1249 + The STE transport IPv6 source address is left unspecified 1250 and may be populated by other protocols out of the scope of 1251 this specification. 1253 + The STE destination IPv6 transport address contains the port 1254 y (i.e. the same port as the STE destination IPv4 transport 1255 address) and the IPv6 representation of Y (i.e. the IPv4 1256 address of the STE destination IPv4 transport address), 1257 generated using the algorithm described in Section 3.5.4. 1259 The state is moved to V4 INIT. 1261 The lifetime of the STE entry is set to TCP_INCOMING_SYN as per 1262 [RFC5382] and the packet is stored. The result is that the 1263 NAT64 will not drop the packet based on the filtering, nor 1264 create a BIB entry. Instead, the NAT64 will only create the 1265 session table entry and store the packet. The motivation for 1266 this is to support simultaneous open of TCP connections. 1268 If the destination transport address contained in the incoming V4 1269 SYN (i.e., X,x) is in use in the TCP BIB, then: 1271 The NAT64 tries to create a new session table entry in the TCP 1272 session table (if resources and policy permit), containing the 1273 following information: 1275 + The STE source IPv4 transport address is set to (X,x) (i.e. 1276 the destination transport address contained in the V4 SYN) 1278 + The STE destination IPv4 transport address is set to (Y,y) 1279 (i.e. the source transport address contained in the V4 SYN) 1281 + The STE transport IPv6 source address is set to the IPv6 1282 transport address contained in the corresponding TCP BIB 1283 entry. 1285 + The STE destination IPv6 transport address contains the port 1286 y (i.e. the same port as the STE destination IPv4 transport 1287 address) and the IPv6 representation of Y (i.e. the IPv4 1288 address of the STE destination IPv4 transport address), 1289 generated using the algorithm described in Section 3.5.4. 1291 The state is moved to V4 INIT. 1293 If the NAT64 is performing Address-Dependent Filtering, the 1294 lifetime of the STE entry is set to TCP_INCOMING_SYN as per 1295 [RFC5382] and the packet is stored. The motivation for 1296 creating the session table entry and storing the packet 1297 (instead of simply dropping the packet based on the filtering) 1298 is to support simultaneous open of TCP connections. 1300 If the NAT64 is not performing Address-Dependent Filtering, the 1301 lifetime of the STE is set to at least to TCP_TRANS (the 1302 transitory connection idle timeout as defined in [RFC5382]) and 1303 it translates and forwards the packet as described in the 1304 following sections. 1306 For any other packet belonging to this connection: 1308 If there is a corresponding entry in the TCP BIB other packets 1309 SHOULD be translated and forwarded if the security policy allows 1310 to do so. The state remains unchanged. 1312 If there is no corresponding entry in the TCP BIB the packet is 1313 silently discarded. 1315 *** V4 INIT *** 1317 If a V6 SYN is received with incoming tuple with source transport 1318 address (X',x) and destination transport address (Y',y). The 1319 lifetime of the TCP session table entry is set to at least to the 1320 maximum session lifetime. The value for the maximum session lifetime 1321 MAY be configurable but it MUST NOT be less than TCP_EST (the 1322 established connection idle timeout as defined in [RFC5382]). The 1323 default value for the maximum session lifetime SHOULD be set to 1324 TCP_EST. The packet is translated and forwarded. The state is moved 1325 to ESTABLISHED. 1327 If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code 1328 3) containing the IPv4 SYN packet stored is sent back to the source 1329 of the v4 SYN, the session table entry is deleted and, the state is 1330 moved to CLOSED. 1332 For any other packet, other packets SHOULD be translated and 1333 forwarded if the security policy allows to do so. The state remains 1334 unchanged. 1336 *** V6 INIT *** 1338 If a V4 SYN is received (with or without the ACK flag set), with an 1339 incoming tuple with source IPv4 transport address (Y,y) and 1340 destination IPv4 transport address (X,x), then the state is moved to 1341 ESTABLISHED. The lifetime of the TCP session table entry is set to 1342 at least to the maximum session lifetime. The value for the maximum 1343 session lifetime MAY be configurable but it MUST NOT be less than 1344 TCP_EST (the established connection idle timeout as defined in 1345 [RFC5382]). The default value for the maximum session lifetime 1346 SHOULD be set to TCP_EST. The packet is translated and forwarded. 1348 If the lifetime expires, the session table entry is deleted and the 1349 state is moved to CLOSED. 1351 If a V6 SYN packet is received, the packet is translated and 1352 forwarded. The lifetime of the TCP session table entry is set to at 1353 least to TCP_TRANS. The state remains unchanged. 1355 For any other packet, other packets SHOULD be translated and 1356 forwarded if the security policy allows to do so. The state remains 1357 unchanged. 1359 *** ESTABLISHED *** 1361 If a V4 FIN packet is received, the packet is translated and 1362 forwarded. The state is moved to V4 FIN RCV. 1364 If a V6 FIN packet is received, the packet is translated and 1365 forwarded. The state is moved to V6 FIN RCV. 1367 If a V4 RST or a V6 RST packet is received, the packet is translated 1368 and forwarded. The lifetime is set to TCP_TRANS and the state is 1369 moved to TRANS. (Since the NAT64 is uncertain whether the peer will 1370 accept the RST packet, instead of moving the state to CLOSED, it 1371 moves to TRANS, which has a shorter lifetime. If no other packets 1372 are received for this connection during the short timer, the NAT64 1373 assumes that the peer has accepted the RST packet and moves to 1374 CLOSED. If packets keep flowing, the NAT64 assumes that the peer has 1375 not accepted the RST packet and moves back to the ESTABLISHED state. 1376 This is described below in the TRANS state processing description.) 1377 If any other packet is received, the packet is translated and 1378 forwarded. The lifetime of the TCP session table entry is set to at 1379 least to the maximum session lifetime. The value for the maximum 1380 session lifetime MAY be configurable but it MUST NOT be less than 1381 TCP_EST (the established connection idle timeout as defined in 1382 [RFC5382]). The default value for the maximum session lifetime 1383 SHOULD be set to TCP_EST. The state remains unchanged as 1384 ESTABLISHED. 1386 If the lifetime expires then the NAT64 SHOULD send a probe packet (as 1387 defined next) to at least one of the endpoints of the TCP connection. 1388 The probe packet is a TCP segment for the connection with no data. 1389 The sequence number and the acknowledgment number are set to zero. 1390 All flags but the ACK flag are reset. The state is moved to TRANS. 1392 Upon the reception of this probe packet, the endpoint will reply 1393 with an ACK containing the expected sequence number for that 1394 connection. It should be noted that, for an active connection, 1395 each of these probe packets will generate one packet from each end 1396 involved in the connection, since the reply of the first point to 1397 the probe packet will generate a reply from the other endpoint. 1399 *** V4 FIN RCV *** 1401 If a V6 FIN packet is received, the packet is translated and 1402 forwarded. The lifetime is set to TCP_TRANS. The state is moved to 1403 V6 FIN + V4 FIN RCV. 1405 If any packet other than the V6 FIN is received, the packet is 1406 translated and forwarded. The lifetime of the TCP session table 1407 entry is set to at least to the maximum session lifetime. The value 1408 for the maximum session lifetime MAY be configurable but it MUST NOT 1409 be less than TCP_EST (the established connection idle timeout as 1410 defined in [RFC5382]). The default value for the maximum session 1411 lifetime SHOULD be set to TCP_EST. The state remains unchanged as V4 1412 FIN RCV. 1414 If the lifetime expires, the session table entry is deleted and the 1415 state is moved to CLOSED. 1417 *** V6 FIN RCV *** 1419 If a V4 FIN packet is received, the packet is translated and 1420 forwarded. The lifetime is set to TCT_TRANS. The state is moved to 1421 V6 FIN + V4 FIN RCV. 1423 If any packet other than the V4 FIN is received, the packet is 1424 translated and forwarded. The lifetime of the TCP session table 1425 entry is set to at least to the maximum session lifetime. The value 1426 for the maximum session lifetime MAY be configurable but it MUST NOT 1427 be less than TCP_EST (the established connection idle timeout as 1428 defined in [RFC5382]). The default value for the maximum session 1429 lifetime SHOULD be set to TCP_EST. The state remains unchanged as V6 1430 FIN RCV. 1432 If the lifetime expires, the session table entry is deleted and the 1433 state is moved to CLOSED. 1435 *** V6 FIN + V4 FIN RCV *** 1437 All packets are translated and forwarded. 1439 If the lifetime expires, the session table entry is deleted and the 1440 state is moved to CLOSED. 1442 *** TRANS *** 1444 If a packet other than a RST packet is received, the lifetime of the 1445 TCP session table entry is set to at least to the maximum session 1446 lifetime. The value for the maximum session lifetime MAY be 1447 configurable but it MUST NOT be less than TCP_EST (the established 1448 connection idle timeout as defined in [RFC5382]). The default value 1449 for the maximum session lifetime SHOULD be set to TCP_EST. The state 1450 is moved to ESTABLISHED. 1452 If the lifetime expires, the session table entry is deleted and the 1453 state is moved to CLOSED. 1455 3.5.2.3. Rules for allocation of IPv4 transport addresses for TCP 1457 When a new TCP BIB entry is created for a source transport address of 1458 (S',s), then the NAT64 allocates an IPv4 transport address for this 1459 BIB entry as follows: 1461 If there exists some other BIB entry containing S' as the IPv6 1462 address and mapping it to some IPv4 address T, then T SHOULD be 1463 used as the IPv4 address. Otherwise, use any IPv4 address of the 1464 IPv4 pool assigned to the NAT64 to be used for translation. 1466 If the port s is in the Well-Known port range 0-1023, and the 1467 NAT64 has an available port t in the same port range, then the 1468 NAT64 SHOULD allocate the port t. If the NAT64 does not have a 1469 port available in the same range, the NAT64 MAY assign a port t 1470 from another range where it has an available port. 1472 If the port s is in the range 1024-65535, and the NAT64 has an 1473 available port t in the same port range, then the NAT64 SHOULD 1474 allocate the port t. If the NAT64 does not have a port available 1475 in the same range, the NAT64 MAY assign a port t from another 1476 range where it has an available port. 1478 In all cases, the allocated IPv4 transport address (T,t) MUST NOT 1479 be in use in another entry in the same BIB, but MAY be in use in 1480 the other BIB (referring to the UDP and TCP BIBs). 1482 If it is not possible to allocate an appropriate IPv4 transport 1483 address or create a BIB entry, then the packet is discarded. The 1484 NAT64 SHOULD send an ICMPv6 Destination Unreachable/Address 1485 unreachable (Code 3) message. 1487 3.5.3. ICMP Query Session Handling 1489 The following state information is stored for an ICMP Query session 1490 in the ICMP Query session table: 1492 Binding:(X',Y',i1) <--> (T,Z,i2) 1494 Lifetime: a timer that tracks the remaining lifetime of the ICMP 1495 Query session. When the timer expires, the session is deleted. 1496 If all the ICMP Query sessions corresponding to a dynamically 1497 created ICMP Query BIB entry are deleted, then the ICMP Query BIB 1498 entry is also deleted. 1500 An incoming ICMPv6 Informational packet with IPv6 source address X', 1501 IPv6 destination address Y' and ICMPv6 Identifier i1, is processed as 1502 follows: 1504 If the local security policy determines that ICMPv6 Informational 1505 packets are to be filtered, the packet is silently discarded. 1506 Else, the NAT64 searches for an ICMP Query BIB entry that matches 1507 the (X',i1) pair. If such entry does not exist, the NAT64 tries 1508 to create a new entry (if resources and policy permit) with the 1509 following data: 1511 * The BIB IPv6 address is set to X' (i.e. the source IPv6 address 1512 of the IPv6 packet). 1514 * The BIB ICMPv6 Identifier is set to i1 (i.e. the ICMPv6 1515 Identifier). 1517 * If there exists another BIB entry containing the same IPv6 1518 address X' and mapping it to an IPv4 address T, then use T as 1519 the BIB IPv4 address for this new entry. Otherwise, use any 1520 IPv4 address assigned to the IPv4 interface. 1522 * As the BIB ICMPv4 Identifier use any available value i.e. any 1523 identifier value for which no other entry exists with the same 1524 (IPv4 address, ICMPv4 Identifier) pair. 1526 The NAT64 searches for an ICMP query session table entry 1527 corresponding to the incoming 3-tuple (X',Y',i1). If no such 1528 entry is found, the NAT64 tries to create a new entry (if 1529 resources and policy permit). The information included in the new 1530 session table entry is as follows: 1532 * The STE IPv6 source address is set to X' (i.e. the address 1533 contained in the received IPv6 packet), 1535 * The STE IPv6 destination address is set to Y' (i.e. the address 1536 contained in the received IPv6 packet), 1538 * The STE ICMPv6 Identifier is set to i1 (i.e. the identifier 1539 contained in the received IPv6 packet), 1541 * The STE IPv4 source address is set to the IPv4 address 1542 contained in the corresponding BIB entry, 1544 * The STE ICMPv4 Identifier is set to the IPv4 identifier 1545 contained in the corresponding BIB entry, 1547 * The STE IPv4 destination address is algorithmically generated 1548 from Y' using the reverse algorithm as specified in 1549 Section 3.5.4. 1551 The NAT64 sets (or resets) the timer in the session table entry to 1552 the maximum session lifetime. By default, the maximum session 1553 lifetime is ICMP_DEFAULT. The maximum lifetime value SHOULD be 1554 configurable. The packet is translated and forwarded as described 1555 in the following sections. 1557 An incoming ICMPv4 Query packet with source IPv4 address Y, 1558 destination IPv4 address X and ICMPv4 Identifier i2 is processed as 1559 follows: 1561 The NAT64 searches for an ICMP Query BIB entry that contains X as 1562 IPv4 address and i2 as the ICMPv4 Identifier. If such an entry 1563 does not exist, the packet is dropped. An ICMP error message MAY 1564 be sent to the original sender of the packet. The ICMP error 1565 message, if sent, has a type of 3 (Destination Unreachable). 1567 If the NAT64 filters on its IPv4 interface, then the NAT64 checks 1568 to see if the incoming packet is allowed according to the Address- 1569 Dependent Filtering rule. To do this, it searches for a session 1570 table entry with an STE source IPv4 address equal to X, an STE 1571 ICMPv4 Identifier equal to i2 and a STE destination IPv4 address 1572 equal to Y. If such an entry is found (there may be more than 1573 one), packet processing continues. Otherwise, the packet is 1574 discarded. If the packet is discarded, then an ICMP error message 1575 MAY be sent to the original sender of the packet. The ICMP error 1576 message, if sent, has a type of 3 (Destination Unreachable) and a 1577 code of 13 (Communication Administratively Prohibited). 1579 In case the packet is not discarded in the previous processing 1580 steps (either because the NAT64 is not filtering or because the 1581 packet is compliant with the Address-dependent Filtering rule), 1582 then the NAT64 searches for a session table entry with an STE 1583 source IPv4 address equal to X, an STE ICMPv4 Identifier equal to 1584 i2 and a STE destination IPv4 address equal to Y. If no such entry 1585 is found, the NAT64 tries to create a new entry (if resources and 1586 policy permit) with the following information: 1588 * The STE source IPv4 address is set to X, 1590 * The STE ICMPv4 Identifier is set to i2, 1592 * The STE destination IPv4 address is set to Y, 1594 * The STE source IPv6 address is set to the IPv6 address of the 1595 corresponding BIB entry, 1597 * The STE ICMPv6 Identifier is set to the ICMPv6 Identifier of 1598 the corresponding BIB entry, and, 1600 * The STE destination IPv6 address is set to the IPv6 1601 representation of the IPv4 address of Y, generated using the 1602 algorithm described in Section 3.5.4. 1604 * The NAT64 sets (or resets) the timer in the session table entry 1605 to the maximum session lifetime. By default, the maximum 1606 session lifetime is ICMP_DEFAULT. The maximum lifetime value 1607 SHOULD be configurable. The packet is translated and forwarded 1608 as described in the following sections. 1610 3.5.4. Generation of the IPv6 Representations of IPv4 Addresses 1612 NAT64 supports multiple algorithms for the generation of the IPv6 1613 representation of an IPv4 address and vice-versa. The constraints 1614 imposed on the generation algorithms are the following: 1616 The algorithm MUST be reversible, i.e. it MUST be possible to 1617 derive the original IPv4 address from the IPv6 representation. 1619 The input for the algorithm MUST be limited to the IPv4 address, 1620 the IPv6 prefix (denoted Pref64::/n) used in the IPv6 1621 representations and optionally a set of stable parameters that are 1622 configured in the NAT64 (such as fixed string to be used as a 1623 suffix). 1625 If we note n the length of the prefix Pref64::/n, then n MUST 1626 be less or equal than 96. If a Pref64::/n is configured 1627 through any means in the NAT64 (such as manually configured, or 1628 other automatic means not specified in this document), the 1629 default algorithm MUST use this prefix. If no prefix is 1630 available, the algorithm SHOULD use the Well-Known Prefix (64: 1631 FF9B::/96) defined in [I-D.ietf-behave-address-format] 1633 NAT64 MUST support the algorithm for generating IPv6 representations 1634 of IPv4 addresses defined in Section 2.1 of 1635 [I-D.ietf-behave-address-format]. The aforementioned algorithm 1636 SHOULD be used as default algorithm. 1638 3.6. Computing the Outgoing Tuple 1640 This step computes the outgoing tuple by translating the IP addresses 1641 and port numbers or ICMP Identifier in the incoming tuple. 1643 In the text below, a reference to a BIB means either the TCP BIB, the 1644 UDP BIB or the ICMP Query BIB as appropriate. 1646 NOTE: Not all addresses are translated using the BIB. BIB entries 1647 are used to translate IPv6 source transport addresses to IPv4 1648 source transport addresses, and IPv4 destination transport 1649 addresses to IPv6 destination transport addresses. They are NOT 1650 used to translate IPv6 destination transport addresses to IPv4 1651 destination transport addresses, nor to translate IPv4 source 1652 transport addresses to IPv6 source transport addresses. The 1653 latter cases are handled applying the algorithmic transformation 1654 described in Section 3.5.4. This distinction is important; 1655 without it, hairpinning doesn't work correctly. 1657 3.6.1. Computing the Outgoing 5-tuple for TCP, UDP and for ICMP Error 1658 messages containing a TCP or UDP packets. 1660 The transport protocol in the outgoing 5-tuple is always the same as 1661 that in the incoming 5-tuple. 1663 When translating in the IPv6 --> IPv4 direction, let the source and 1664 destination transport addresses in the incoming 5-tuple be (S',s) and 1665 (D',d) respectively. The outgoing source transport address is 1666 computed as follows: if the BIB contains a entry (S',s) <--> (T,t), 1667 then the outgoing source transport address is (T,t). 1669 The outgoing destination address is computed algorithmically from D' 1670 using the address transformation described in Section 3.5.4. 1672 When translating in the IPv4 --> IPv6 direction, let the source and 1673 destination transport addresses in the incoming 5-tuple be (S,s) and 1674 (D,d) respectively. The outgoing source transport address is 1675 computed as follows: 1677 The outgoing source transport address is generated from S using 1678 the address transformation algorithm described in Section 3.5.4. 1680 The BIB table is searched for an entry (X',x) <--> (D,d), and if 1681 one is found, the outgoing destination transport address is set to 1682 (X',x). 1684 3.6.2. Computing the Outgoing 3-tuple for ICMP Query Messages and for 1685 ICMP Error messages containing an ICMP Query. 1687 When translating in the IPv6 --> IPv4 direction, let the source and 1688 destination addresses in the incoming 3-tuple be S' and D' 1689 respectively and the ICMPv6 Identifier be i1. The outgoing source 1690 address is computed as follows: the BIB contains an entry (S',i1) 1691 <--> (T,i2), then the outgoing source address is T and the ICMPv4 1692 Identifier is i2. 1694 The outgoing IPv4 destination address is computed algorithmically 1695 from D' using the address transformation described in Section 3.5.4. 1697 When translating in the IPv4 --> IPv6 direction, let the source and 1698 destination addresses in the incoming 3-tuple be S and D respectively 1699 and the ICMPv4 Identifier is i2. The outgoing source address is 1700 generated from S using the address transformation algorithm described 1701 in Section 3.5.4. The BIB is searched for an entry containing 1702 (X',i1) <--> (D,i2) and if found the outgoing destination address is 1703 X' and the outgoing ICMPv6 Identifier is i1. 1705 3.7. Translating the Packet 1707 This step translates the packet from IPv6 to IPv4 or vice-versa. 1709 The translation of the packet is as specified in Section 3 and 1710 Section 4 of the IP/ICMP Translation Algorithm 1711 [I-D.ietf-behave-v6v4-xlate], with the following modifications: 1713 o When translating an IP header (Sections 3.1 and 4.1), the source 1714 and destination IP address fields are set to the source and 1715 destination IP addresses from the outgoing tuple as determined in 1716 Section 3.6. 1718 o When the protocol following the IP header is TCP or UDP, then the 1719 source and destination ports are modified to the source and 1720 destination ports from the outgoing 5-tuple. In addition, the TCP 1721 or UDP checksum must also be updated to reflect the translated 1722 addresses and ports; note that the TCP and UDP checksum covers the 1723 pseudo-header which contains the source and destination IP 1724 addresses. An algorithm for efficiently updating these checksums 1725 is described in [RFC3022]. 1727 o When the protocol following the IP header is ICMP and it is an 1728 ICMP Query message, the ICMP Identifier is set to the one from the 1729 outgoing 3-tuple as determined in Section 3.6.2. 1731 o When the protocol following the IP header is ICMP and it is an 1732 ICMP error message, the source and destination transport addresses 1733 in the embedded packet are set to the destination and source 1734 transport addresses from the outgoing 5-tuple (note the swap of 1735 source and destination). 1737 The size of outgoing packets as well and the potential need for 1738 fragmentation is done according to the behavior defined in the IP/ 1739 ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate] 1741 3.8. Handling Hairpinning 1743 If the destination IP address of the translated packet is an IPv4 1744 address assigned to the NAT64 itself then the packet is a hairpin 1745 packet. Hairpin packets are processed as follows: 1747 o The outgoing 5-tuple becomes the incoming 5-tuple, and, 1749 o the packet is treated as if it was received on the outgoing 1750 interface. 1752 o Processing of the packet continues at step 2 - Filtering and 1753 updating binding and session information described in Section 3.5. 1755 4. Protocol Constants 1757 UDP_MIN 2 minutes (as defined in [RFC4787]) 1759 UDP_DEFAULT 5 minutes (as defined in [RFC4787]) 1760 TCP_TRANS 4 minutes (as defined in [RFC5382]) 1762 TCP_EST 2 hours (the minimum lifetime for an established TCP session 1763 defined in [RFC5382] is 2 hrs and 4 minutes, which is achieved adding 1764 the 2 hours with this timer and the 4 minutes with the TCP_TRANS 1765 timer) 1767 TCP_INCOMING_SYN 6 seconds (as defined in [RFC5382]) 1769 FRAGMENT_MIN 2 seconds 1771 ICMP_DEFAULT 60 seconds (as defined in [RFC5508]) 1773 5. Security Considerations 1775 5.1. Implications on end-to-end security 1777 Any protocols that protect IP header information are essentially 1778 incompatible with NAT64. This implies that end-to-end IPsec 1779 verification will fail when AH is used (both transport and tunnel 1780 mode) and when ESP is used in transport mode. This is inherent in 1781 any network-layer translation mechanism. End-to-end IPsec protection 1782 can be restored, using UDP encapsulation as described in [RFC3948]. 1783 The actual extensions to support IPsec are out of the scope of this 1784 document. 1786 5.2. Filtering 1788 NAT64 creates binding state using packets flowing from the IPv6 side 1789 to the IPv4 side. In accordance with the procedures defined in this 1790 document following the guidelines defined in [RFC4787] a NAT64 MUST 1791 offer "Endpoint-Independent Mapping". This means: 1793 for any IPv6 packet with source (S'1,s1) and destination (Pref64:: 1794 D1,d1) that creates an external mapping to (S1,s1v4), (D1,d1), for 1795 any subsequent packet from (S'1,s1) to (Pref64::D2,d2) that 1796 creates an external mapping to (S2,s2v4), (D2,d2), within a given 1797 binding timer window, 1799 (S1,s1v4) = (S2,s2v4) for all values of D2,d2 1801 Implementations MAY also provide support for "Address-Dependent 1802 Mapping" as also defined in this document and following the 1803 guidelines defined in [RFC4787]. 1805 The security properties however are determined by which packets the 1806 NAT64 filter allows in and which it does not. The security 1807 properties are determined by the filtering behavior and filtering 1808 configuration in the filtering portions of the NAT64, not by the 1809 address mapping behavior. For example, 1811 Without filtering - When "Endpoint-Independent Mapping" is used in 1812 NAT64, once a binding is created in the IPv6 ---> IPv4 direction, 1813 packets from any node on the IPv4 side destined to the IPv6 1814 transport address will traverse the NAT64 gateway and be forwarded 1815 to the IPv6 transport address that created the binding. However, 1817 With filtering - When "Endpoint-Independent Mapping" is used in 1818 NAT64, once a binding is created in the IPv6 ---> IPv4 direction, 1819 packets from any node on the IPv4 side destined to the IPv6 1820 transport address will first be processed against the filtering 1821 rules. If the source IPv4 address is permitted, the packets will 1822 be forwarded to the IPv6 transport address. If the source IPv4 1823 address is explicitly denied -- or the default policy is to deny 1824 all addresses not explicitly permitted -- then the packet will be 1825 discarded. A dynamic filter may be employed where by the filter 1826 will only allow packets from the IPv4 address to which the 1827 original packet that created the binding was sent. This means 1828 that only the IPv4 addresses to which the IPv6 host has initiated 1829 connections will be able to reach the IPv6 transport address, and 1830 no others. This essentially narrows the effective operation of 1831 the NAT64 device to an "Address-Dependent Mapping" behavior, 1832 though not by its mapping behavior, but instead by its filtering 1833 behavior. 1835 As currently specified, the NAT64 only requires filtering traffic 1836 based on the 5-tuple. In some cases (e.g., statically configured 1837 mappings), this may make it easy for an attacker to guess. An 1838 attacker need not be able to guess other fields, e.g. the TCP 1839 sequence number, to get a packet through the NAT64. While such 1840 traffic might be dropped by the final destination, it does not 1841 provide additional mitigations against bandwidth/CPU attacks 1842 targeting the internal network. To avoid this type of abuse, a NAT64 1843 MAY keep track of the sequence number of TCP packets in order to 1844 verify that proper sequencing of exchanged segments, in particular, 1845 those of the SYNs and the FINs. 1847 5.3. Attacks on NAT64 1849 The NAT64 device itself is a potential victim of different types of 1850 attacks. In particular, the NAT64 can be a victim of DoS attacks. 1851 The NAT64 device has a limited number of resources that can be 1852 consumed by attackers creating a DoS attack. The NAT64 has a limited 1853 number of IPv4 addresses that it uses to create the bindings. Even 1854 though the NAT64 performs address and port translation, it is 1855 possible for an attacker to consume all the IPv4 transport addresses 1856 by sending IPv6 packets with different source IPv6 transport 1857 addresses. This attack can only be launched from the IPv6 side, 1858 since IPv4 packets are not used to create binding state. DoS attacks 1859 can also affect other limited resources available in the NAT64 such 1860 as memory or link capacity. For instance, it is possible for an 1861 attacker to launch a DoS attack on the memory of the NAT64 device by 1862 sending fragments that the NAT64 will store for a given period. If 1863 the number of fragments is high enough, the memory of the NAT64 could 1864 be exhausted. Similarly, A DoS attack against the NAT64 can be 1865 crafted by sending either V4 or V6 SYN packets that consume memory in 1866 the form of session and/or binding table entries. In the case of 1867 IPv4 SYNs the situation is aggravated by thee requirement to also 1868 store the data packets for a given amount of time, requiring more 1869 memory from the NAT64 device. NAT64 devices MUST implement proper 1870 protection against such attacks, for instance allocating a limited 1871 amount of memory for fragmented packet storage as specified in 1872 Section 3.4. 1874 Another consideration related to NAT64 resource depletion refers to 1875 the preservation of binding state. Attackers may try to keep a 1876 binding state alive forever by sending periodic packets that refresh 1877 the state. In order to allow the NAT64 to defend against such 1878 attacks, the NAT64 MAY choose not to extend the session entry 1879 lifetime for a specific entry upon the reception of packets for that 1880 entry through the external interface. As described in the Framework 1881 document [I-D.ietf-behave-v6v4-framework], the NAT64 can be deployed 1882 in multiple scenarios, some of which the Internet side is the IPv6 1883 one and some of which the Internet side is the IPv4 one. It is then 1884 important to properly set which is the Internet side of the NAT64 in 1885 each specific configuration. 1887 5.4. Avoiding hairpinning loops 1889 If an IPv6-only client can guess the IPv4 binding address that will 1890 be created, it can use the IPv6 representation of it as source 1891 address for creating this binding. Then any packet sent to the 1892 binding's IPv4 address could loop in the NAT64. This is prevented in 1893 the current specification by filtering incoming packets containing 1894 Pref64::/n in the source address as described next. 1896 Consider the following example: 1898 Suppose that the IPv4 pool is 192.0.2.0/24 1900 Then the IPv6-only client sends this to NAT64: 1902 Source: [Pref64::192.0.2.1]:500 1904 Destination: whatever 1906 The NAT64 allocates 192.0.2.1:500 as IPv4 binding address. Now 1907 anything sent to 192.0.2.1:500, be it a hairpinned IPv6 packet or an 1908 IPv4 packet, could loop. 1910 It is not hard to guess the IPv4 address that will be allocated. 1911 First the attacker creates a binding and use (for example) STUN to 1912 learn its external IPv4 address. New bindings will always have this 1913 address. Then it uses a source port in the range 1-1023. This will 1914 increase the chances to 1/512 (since range and parity are preserved 1915 by NAT64 in UDP). 1917 In order to address this vulnerability, the NAT64 MUST drop IPv6 1918 packets whose source address is in Pref64::/n as defined in 1919 Section 3.5. 1921 6. IANA Considerations 1923 This document contains no actions for IANA. 1925 7. Contributors 1927 George Tsirtsis 1929 Qualcomm 1931 tsirtsis@googlemail.com 1933 Greg Lebovitz 1935 Juniper 1937 gregory.ietf@gmail.com 1939 Simon Parreault 1941 Viagenie 1943 simon.perreault@viagenie.ca 1945 8. Acknowledgements 1947 Dave Thaler, Dan Wing, Alberto Garcia-Martinez, Reinaldo Penno, 1948 Ranjana Rao, Lars Eggert, Senthil Sivakumar, Zhen Cao, Xiangsong Cui, 1949 Mohamed Boucadair, Dong Zhang, Bryan Ford, Kentaro Ebisawa, Charles 1950 Perkins, Magnus Westerlund, Ed Jankiewicz, David Harrington, Peter 1951 McCann, Julien Laganier, Pekka Savola and Joao Damas reviewed the 1952 document and provided useful comments to improve it. 1954 The content of the draft was improved thanks to discussions with 1955 Christian Huitema, Fred Baker and Jari Arkko. 1957 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 1958 Trilogy, a research project supported by the European Commission 1959 under its Seventh Framework Program. 1961 9. References 1963 9.1. Normative References 1965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1966 Requirement Levels", BCP 14, RFC 2119, March 1997. 1968 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1969 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1970 RFC 4787, January 2007. 1972 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1973 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1974 RFC 5382, October 2008. 1976 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1977 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 1978 April 2009. 1980 [I-D.ietf-behave-v6v4-xlate] 1981 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1982 Algorithm", draft-ietf-behave-v6v4-xlate-20 (work in 1983 progress), May 2010. 1985 [I-D.ietf-behave-address-format] 1986 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1987 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1988 draft-ietf-behave-address-format-09 (work in progress), 1989 July 2010. 1991 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1992 Message Protocol (ICMPv6) for the Internet Protocol 1993 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1995 9.2. Informative References 1997 [I-D.ietf-behave-dns64] 1998 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 1999 "DNS64: DNS extensions for Network Address Translation 2000 from IPv6 Clients to IPv4 Servers", 2001 draft-ietf-behave-dns64-10 (work in progress), July 2010. 2003 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2004 RFC 793, September 1981. 2006 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 2007 Considerations for IP Fragment Filtering", RFC 1858, 2008 October 1995. 2010 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 2011 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 2013 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2014 Address Translator (Traditional NAT)", RFC 3022, 2015 January 2001. 2017 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2018 (ICE): A Protocol for Network Address Translator (NAT) 2019 Traversal for Offer/Answer Protocols", RFC 5245, 2020 April 2010. 2022 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2023 Errors at High Data Rates", RFC 4963, July 2007. 2025 [I-D.ietf-behave-v6v4-framework] 2026 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 2027 IPv4/IPv6 Translation", 2028 draft-ietf-behave-v6v4-framework-09 (work in progress), 2029 May 2010. 2031 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 2032 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 2033 RFC 3948, January 2005. 2035 Authors' Addresses 2037 Marcelo Bagnulo 2038 UC3M 2039 Av. Universidad 30 2040 Leganes, Madrid 28911 2041 Spain 2043 Phone: +34-91-6249500 2044 Fax: 2045 Email: marcelo@it.uc3m.es 2046 URI: http://www.it.uc3m.es/marcelo 2048 Philip Matthews 2049 Alcatel-Lucent 2050 600 March Road 2051 Ottawa, Ontario 2052 Canada 2054 Phone: +1 613-592-4343 x224 2055 Fax: 2056 Email: philip_matthews@magma.ca 2057 URI: 2059 Iljitsch van Beijnum 2060 IMDEA Networks 2061 Avda. del Mar Mediterraneo, 22 2062 Leganes, Madrid 28918 2063 Spain 2065 Email: iljitsch@muada.com