idnits 2.17.1 draft-ietf-behave-v6v4-xlate-stateful-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a V6 SYN is received with incoming tuple with source transport address (X',x) and destination transport address (Y',y). The lifetime of the TCP session table entry is set to at least to the maximum session lifetime. The value for the maximum session lifetime MAY be configurable but it MUST not be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The packet is translated and forwarded. The state is moved to ESTABLISHED. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a V4 SYN is received (with or without the ACK flag set), with an incoming tuple with source IPv4 transport address (Y,y) and destination IPv4 transport address (X,x), then the state is moved to ESTABLISHED. The lifetime of the TCP session table entry is set to at least to the maximum session lifetime. The value for the maximum session lifetime MAY be configurable but it MUST not be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The packet is translated and forwarded. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If any other packet is received, the packet is translated and forwarded. The lifetime of the TCP session table entry is set to at least to the maximum session lifetime. The value for the maximum session lifetime MAY be configurable but it MUST not be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state remains unchanged as ESTABLISHED. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If any packet other than the V6 FIN is received, the packet is translated and forwarded. The lifetime of the TCP session table entry is set to at least to the maximum session lifetime. The value for the maximum session lifetime MAY be configurable but it MUST not be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state remains unchanged as V4 FIN RCV. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If any packet other than the V4 FIN is received, the packet is translated and forwarded. The lifetime of the TCP session table entry is set to at least to the maximum session lifetime. The value for the maximum session lifetime MAY be configurable but it MUST not be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state remains unchanged as V6 FIN RCV. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a packet other than a RST packet is received, the lifetime of the TCP session table entry is set to at least to the maximum session lifetime. The value for the maximum session lifetime MAY be configurable but it MUST not be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state is moved to ESTABLISHED. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2010) is 5157 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) == Unused Reference: 'RFC1035' is defined on line 1940, but no explicit reference was found in the text == Unused Reference: 'RFC2766' is defined on line 1978, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 1993, but no explicit reference was found in the text == Unused Reference: 'I-D.penno-behave-64-analysis' is defined on line 2012, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-10 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-07 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-07 == Outdated reference: A later version (-06) exists of draft-penno-behave-64-analysis-03 Summary: 1 error (**), 0 flaws (~~), 17 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: September 7, 2010 Alcatel-Lucent 6 I. van Beijnum 7 IMDEA Networks 8 March 6, 2010 10 Stateful NAT64: Network Address and Protocol Translation from IPv6 11 Clients to IPv4 Servers 12 draft-ietf-behave-v6v4-xlate-stateful-09 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 to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 7, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Features of stateful NAT64 . . . . . . . . . . . . . . . . 5 77 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 1.2.1. Stateful NAT64 solution elements . . . . . . . . . . . 6 79 1.2.2. Stateful NAT64 Behaviour Walkthrough . . . . . . . . . 8 80 1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 10 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 3. Stateful NAT64 Normative Specification . . . . . . . . . . . . 13 83 3.1. Binding Information Bases . . . . . . . . . . . . . . . . 14 84 3.2. Session Tables . . . . . . . . . . . . . . . . . . . . . . 15 85 3.3. Packet Processing Overview . . . . . . . . . . . . . . . . 16 86 3.4. Determining the Incoming tuple . . . . . . . . . . . . . . 17 87 3.5. Filtering and Updating Binding and Session Information . . 19 88 3.5.1. UDP Session Handling . . . . . . . . . . . . . . . . . 20 89 3.5.1.1. Rules for Allocation of IPv4 Transport 90 Addresses for UDP . . . . . . . . . . . . . . . . 22 91 3.5.2. TCP Session Handling . . . . . . . . . . . . . . . . . 23 92 3.5.2.1. State definition . . . . . . . . . . . . . . . . . 23 93 3.5.2.2. State machine for TCP processing in the NAT64 . . 24 94 3.5.2.3. Rules for allocation of IPv4 transport 95 addresses for TCP . . . . . . . . . . . . . . . . 31 96 3.5.3. ICMP Query Session Handling . . . . . . . . . . . . . 32 97 3.5.4. Generation of the IPv6 Representations of IPv4 98 Addresses . . . . . . . . . . . . . . . . . . . . . . 35 99 3.6. Computing the Outgoing Tuple . . . . . . . . . . . . . . . 35 100 3.6.1. Computing the Outgoing 5-tuple for TCP and UDP . . . . 36 101 3.6.2. Computing the Outgoing 3-tuple for ICMP Query 102 Messages . . . . . . . . . . . . . . . . . . . . . . . 36 103 3.7. Translating the Packet . . . . . . . . . . . . . . . . . . 37 104 3.8. Handling Hairpinning . . . . . . . . . . . . . . . . . . . 37 105 4. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 38 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 107 5.1. Implications on end-to-end security . . . . . . . . . . . 38 108 5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 38 109 5.3. Attacks on NAT64 . . . . . . . . . . . . . . . . . . . . . 40 110 5.4. Avoiding hairpinning loops . . . . . . . . . . . . . . . . 40 111 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 112 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41 113 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 114 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 115 9.1. Normative References . . . . . . . . . . . . . . . . . . . 42 116 9.2. Informative References . . . . . . . . . . . . . . . . . . 43 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 119 1. Introduction 121 This document specifies stateful NAT64, a mechanism for IPv4-IPv6 122 transition and co-existence. Together with DNS64 123 [I-D.ietf-behave-dns64], these two mechanisms allow a IPv6-only 124 client to initiate communications to an IPv4-only server. They also 125 enable peer-to-peer communication between an IPv4 and an IPv6 node, 126 where the communication can be initiated by either end using 127 existing, NAT-traversal, peer-to-peer communication techniques, such 128 as ICE [I-D.ietf-mmusic-ice]. Stateful NAT64 also supports IPv4- 129 initiated communications to a subset of the IPv6 hosts through 130 statically configured bindings in the stateful NAT64. 132 Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 133 packets and vice-versa. The translation is done by translating the 134 packet headers according to the IP/ICMP Translation Algorithm defined 135 in [I-D.ietf-behave-v6v4-xlate]. The IPv4 addresses of IPv4 hosts 136 are algorithmically translated to and from IPv6 addresses by using 137 the algorithm defined in [I-D.ietf-behave-address-format] and a 138 prefix assigned to the stateful NAT64 for this specific purpose. The 139 IPv6 addresses of IPv6 hosts are translated to and from IPv4 140 addresses by installing mappings in the normal NAT manner. The 141 current specification only defines how stateful NAT64 translates 142 packets carrying TCP and UDP traffic. Other protocols, including 143 SCTP, DCCP and IPsec are out of the scope of this specification. 145 DNS64 is a mechanism for synthesizing AAAA resource records (RR) from 146 A RR. The IPv6 address contained in the synthetic AAAA RR is 147 algorithmically generated from the IPv4 address and the IPv6 prefix 148 assigned to a NAT64 device by using the same algorithm defined in 149 [I-D.ietf-behave-address-format]. 151 Together, these two mechanisms allow an IPv6-only client (i.e. either 152 a host with only IPv6 stack, or a host with both IPv4 and IPv6 stack, 153 but only with IPv6 connectivity or a host running an IPv6 only 154 application) to initiate communications to an IPv4-only server 155 (analogous meaning to the IPv6-only host above). 157 These mechanisms are expected to play a critical role in the IPv4- 158 IPv6 transition and co-existence. Due to IPv4 address depletion, it 159 is likely that in the future, many IPv6-only clients will want to 160 connect to IPv4-only servers. The stateful NAT64 and DNS64 161 mechanisms are easily deployable, since they require no changes to 162 either the IPv6 client nor the IPv4 server. For basic functionality, 163 the approach only requires the deployment of the stateful NAT64 164 function in the devices connecting an IPv6-only network to the IPv4- 165 only network, along with the deployment of a few DNS64-enabled name 166 servers accessible to the IPv6-only hosts. An analysis of the 167 application scenarios can be found in 168 [I-D.ietf-behave-v6v4-framework]. 170 For brevity, in the rest of the document, we will refer to the 171 stateful NAT64 either as stateful NAT64 or simply as NAT64. 173 1.1. Features of stateful NAT64 175 The features of NAT64 are: 177 o NAT64 is compliant with the recommendations for how NATs should 178 handle UDP [RFC4787], TCP [RFC5382], and ICMP [RFC5508]. As such, 179 NAT64 only supports Endpoint-Independent mappings and supports 180 both Endpoint-Independent and Address-Dependent Filtering. 181 Because of the compliance with the aforementioned requirements, 182 NAT64 is compatible with current NAT traversal techniques, such as 183 ICE [I-D.ietf-mmusic-ice] and compatible with other non-IETF- 184 standard NAT traversal techniques. 186 o In the absence of any state in NAT64, only IPv6 nodes can initiate 187 sessions to IPv4 nodes. This works for roughly the same class of 188 applications that work through IPv4-to-IPv4 NATs. 190 o Depending on the filtering policy used (Endpoint-Independent, or 191 Address-Dependent), IPv4-nodes might be able to initiate sessions 192 to a given IPv6 node, if the NAT64 somehow has an appropriate 193 mapping (i.e.,state) for an IPv6 node, via one of the following 194 mechanisms: 196 * The IPv6 node has recently initiated a session to the same or 197 another IPv4 node. this is also the case if the IPv6 node has 198 used a NAT-traversal technique (such as ICE) . 200 * If a statically configured mapping exists for the IPv6 node. 202 o IPv4 address sharing: NAT64 allows multiple IPv6-only nodes to 203 share an IPv4 address to access the IPv4 Internet. This helps 204 with IPv4 forthcoming exhaustion. 206 o As currently defined in this NAT64 specification, only TCP/UDP/ 207 ICMP are supported. Support for other protocols such as other 208 transport protocols and IPsec are to be defined in separate 209 documents. 211 1.2. Overview 213 This section provides a non-normative introduction to NAT64. This is 214 achieved by describing the NAT64 behavior involving a simple setup, 215 that involves a single NAT64 device, a single DNS64 and a simple 216 network topology. The goal of this description is to provide the 217 reader with a general view of NAT64. It is not the goal of this 218 section to describe all possible configurations nor to provide a 219 normative specification of the NAT64 behavior. So, for the sake of 220 clarity, only TCP and UDP are described in this overview; the details 221 of ICMP, fragmentation, and other aspects of translation are 222 purposefully avoided in this overview. The normative specification 223 of NAT64 is provided in Section 3. 225 The NAT64 mechanism is implemented in a device which has (at least) 226 two interfaces, an IPv4 interface connected to the IPv4 network, and 227 an IPv6 interface connected to the IPv6 network. Packets generated 228 in the IPv6 network for a receiver located in the IPv4 network will 229 be routed within the IPv6 network towards the NAT64 device. The 230 NAT64 will translate them and forward them as IPv4 packets through 231 the IPv4 network to the IPv4 receiver. The reverse takes place for 232 packets generated by hosts connected to the IPv4 network for an IPv6 233 receiver. NAT64, however, is not symmetric. In order to be able to 234 perform IPv6-IPv4 translation, NAT64 requires state, binding an IPv6 235 address and TCP/UDP port (hereafter called an IPv6 transport address) 236 to an IPv4 address and TCP/UDP port (hereafter called an IPv4 237 transport address). 239 Such binding state is either statically configured in the NAT64 or it 240 is created when the first packet flowing from the IPv6 network to the 241 IPv4 network is translated. After the binding state has been 242 created, packets flowing in both directions on that particular flow 243 are translated. The result is that, in the general case, NAT64 only 244 supports communications initiated by the IPv6-only node towards an 245 IPv4-only node. Some additional mechanisms (like ICE) or static 246 binding configuration, can be used to provide support for 247 communications initiated by an IPv4-only node to an IPv6-only node. 249 1.2.1. Stateful NAT64 solution elements 251 In this section we describe the different elements involved in the 252 NAT64 approach. 254 The main component of the proposed solution is the translator itself. 255 The translator has essentially two main parts, the address 256 translation mechanism and the protocol translation mechanism. 258 Protocol translation from IPv4 packet header to IPv6 packet header 259 and vice-versa is performed according to the IP/ICMP Translation 260 Algorithm [I-D.ietf-behave-v6v4-xlate]. 262 Address translation maps IPv6 transport addresses to IPv4 transport 263 addresses and vice-versa. In order to create these mappings the 264 NAT64 has two pools of addresses: an IPv6 address pool (to represent 265 IPv4 addresses in the IPv6 network) and an IPv4 address pool (to 266 represent IPv6 addresses in the IPv4 network). 268 The IPv6 address pool is one or more IPv6 prefixes assigned to the 269 translator itself. Hereafter we will call the IPv6 address pool as 270 Pref64::/n, in the case there are more than one prefix assigned to 271 the NAT64, the comments made about Pref64::/n apply to each of them. 272 Pref64::/n will be used by the NAT64 to construct IPv4-Converted IPv6 273 addresses as defined in [I-D.ietf-behave-address-format]. Due to the 274 abundance of IPv6 address space, it is possible to assign one or more 275 Pref64::/n, each of them being equal to or even bigger than the size 276 of the whole IPv4 address space. This allows each IPv4 address to be 277 mapped into a different IPv6 address by simply concatenating a 278 Pref64::/n with the IPv4 address being mapped and a suffix. The 279 provisioning of the Pref64::/n as well as the address format are 280 defined in [I-D.ietf-behave-address-format]. 282 The IPv4 address pool is a set of IPv4 addresses, normally a small 283 prefix assigned by the local administrator. Since IPv4 address space 284 is a scarce resource, the IPv4 address pool is small and typically 285 not sufficient to establish permanent one-to-one mappings with IPv6 286 addresses. So, except for the static/manually created ones, mappings 287 using the IPv4 address pool will be created and released dynamically. 288 Moreover, because of the IPv4 address scarcity, the usual practice 289 for NAT64 is likely to be the binding of IPv6 transport addresses 290 into IPv4 transport addresses, instead of IPv6 addresses into IPv4 291 addresses directly, enabling a higher utilization of the limited IPv4 292 address pool. 294 Because of the dynamic nature of the IPv6 to IPv4 address mapping and 295 the static nature of the IPv4 to IPv6 address mapping, it is far 296 simpler to allow communications initiated from the IPv6 side toward 297 an IPv4 node, whose address is algorithmically mapped into an IPv6 298 address, than communications initiated from IPv4-only nodes to an 299 IPv6 node in which case an IPv4 address needs to be associated with 300 the IPv6 node's address dynamically. 302 Using a mechanisms such as DNS64, an IPv6 client obtains an IPv6 303 address that embeds the IPv4 address of the IPv4 server, and sends a 304 packet to that IPv6 address. The packets are intercepted by the 305 NAT64 device, which associates an IPv4 transport address of its IPv4 306 pool to the IPv6 transport address of the initiator, creating binding 307 state, so that reply packets can be translated and forwarded back to 308 the initiator. The binding state is kept while packets are flowing. 309 Once the flow stops, and based on a timer, the IPv4 transport address 310 is returned to the IPv4 address pool so that it can be reused for 311 other communications. 313 To allow an IPv6 initiator to do a DNS lookup to learn the address of 314 the responder, DNS64 [I-D.ietf-behave-dns64] is used to synthesize 315 AAAA RRs from the A RRs. The IPv6 addresses contained in the 316 synthetic AAAA RRs contain a Pref64::/n assigned to the NAT64 and the 317 IPv4 address of the responder. The synthetic AAAA RRs are passed 318 back to the IPv6 initiator, which will initiate an IPv6 communication 319 with an IPv6 address associated to the IPv4 receiver. The packet 320 will be routed to the NAT64 device, which will create the IPv6 to 321 IPv4 address mapping as described before. 323 1.2.2. Stateful NAT64 Behaviour Walkthrough 325 In this section we provide a simple example of the NAT64 behaviour. 326 We consider an IPv6 node located in an IPv6-only site that initiates 327 a TCP connection to an IPv4-only node located in the IPv4 network. 329 The scenario for this case is depicted in the following figure: 331 +---------------------+ +---------------+ 332 |IPv6 network | | IPv4 | 333 | | +-------------+ | Network | 334 | |--| Name server |--| | 335 | | | with DNS64 | | +----+ | 336 | +----+ | +-------------+ | | H2 | | 337 | | H1 |---| | | +----+ | 338 | +----+ | +-------+ | 192.0.2.1 | 339 |2001:DB8::1|------| NAT64 |----| | 340 | | +-------+ | | 341 | | | | | 342 +---------------------+ +---------------+ 344 The figure above shows an IPv6 node H1 with an IPv6 address 2001: 345 DB8::1 and an IPv4 node H2 with IPv4 address 192.0.2.1 H2 has 346 h2.example.com as FQDN. 348 A NAT64 connects the IPv6 network to the IPv4 network. This NAT64 349 uses the Well-Known Prefix 64:FF9B::/96 defined in 350 [I-D.ietf-behave-address-format] to represent IPv4 addresses in the 351 IPv6 address space and a single IPv4 address 203.0.113.1 assigned to 352 its IPv4 interface. The routing is configured in such a way that the 353 IPv6 packets addressed to a destination address in 64:FF9B::/96 are 354 routed to the IPv6 interface of the NAT64 device. 356 Also shown is a local name server with DNS64 functionality. The 357 local name server uses the Well-Known prefix 64:FF9B::/96 to create 358 the IPv6 addresses in the synthetic RRs. 360 For this example, assume the typical DNS situation where IPv6 hosts 361 have only stub resolvers and the local name server does the recursive 362 lookups. 364 The steps by which H1 establishes communication with H2 are: 366 1. H1 performs a DNS query for h2.example.com and receives the 367 synthetic AAAA RR from the local name server that implements the 368 DNS64 functionality. The AAAA record contains an IPv6 address 369 formed by the Well-Known Prefix and the IPv4 address of H2 (i.e. 370 64:FF9B::192.0.2.1). 372 2. H1 sends a TCP SYN packet to H2. The packet is sent from a 373 source transport address of (2001:DB8::1,1500) to a destination 374 transport address of (64:FF9B::192.0.2.1,80), where the ports are 375 set by H1. 377 3. The packet is routed to the IPv6 interface of the NAT64 (since 378 IPv6 routing is configured that way). 380 4. The NAT64 receives the packet and performs the following actions: 382 * The NAT64 selects an unused port (e.g. 2000) on its IPv4 383 address 203.0.113.1 and creates the mapping entry (2001:DB8:: 384 1,1500) <--> (203.0.113.1,2000) 386 * The NAT64 translates the IPv6 header into an IPv4 header using 387 the IP/ICMP Translation Algorithm 388 [I-D.ietf-behave-v6v4-xlate]. 390 * The NAT64 includes (203.0.113.1,2000) as source transport 391 address in the packet and (192.0.2.1,80) as destination 392 transport address in the packet. Note that 192.0.2.1 is 393 extracted directly from the destination IPv6 address of the 394 received IPv6 packet that is being translated. The 395 destination port 80 of the translated packet is the same as 396 the destination port of the received IPv6 packet. 398 5. The NAT64 sends the translated packet out its IPv4 interface and 399 the packet arrives at H2. 401 6. H2 node responds by sending a TCP SYN+ACK packet with destination 402 transport address (203.0.113.1,2000) and source transport address 403 (192.0.2.1,80). 405 7. Since the IPv4 address 203.0.113.1 is assigned to the IPv4 406 interface of the NAT64 device, the packet is routed to the NAT64 407 device, which will look for an existing mapping containing 408 (203.0.113.1,2000). Since the mapping (2001:DB8::1,1500) <--> 409 (203.0.113.1,2000) exists, the NAT64 performs the following 410 operations: 412 * The NAT64 translates the IPv4 header into an IPv6 header using 413 the IP/ICMP Translation Algorithm 414 [I-D.ietf-behave-v6v4-xlate]. 416 * The NAT64 includes (2001:DB8::1,1500) as destination transport 417 address in the packet and (64:FF9B::192.0.2.1,80) as source 418 transport address in the packet. Note that 192.0.2.1 is 419 extracted directly from the source IPv4 address of the 420 received IPv4 packet that is being translated. The source 421 port 80 of the translated packet is the same as the source 422 port of the received IPv4 packet. 424 8. The translated packet is sent out the IPv6 interface to H1. 426 The packet exchange between H1 and H2 continues and packets are 427 translated in the different directions as previously described. 429 It is important to note that the translation still works if the IPv6 430 initiator H1 learns the IPv6 representation of H2's IPv4 address 431 (i.e., 64:FF9B::192.0.2.1) through some scheme other than a DNS 432 look-up. This is because the DNS64 processing does NOT result in any 433 state installed in the NAT64 and because the mapping of the IPv4 434 address into an IPv6 address is the result of concatenating the Well- 435 Known Prefix to the original IPv4 address. 437 1.2.3. Filtering 439 NAT64 may do filtering, which means that it only allows a packet in 440 through an interface under certain circumstances. The NAT64 can 441 filter IPv6 packets based on the administrative rules to create 442 entries in the binding and session tables. The filtering can be 443 flexible and general but the idea of the filtering is to provide the 444 administrators necessary control to avoid DoS attacks that would 445 result in exhaustion of the NAT64's IPv4 address, port, memory and 446 CPU resources. Filtering techniques of incoming IPv6 packets are not 447 specific to the NAT64 and therefore are not described in this 448 specification. 450 Filtering of IPv4 packets on the other hand is tightly coupled to the 451 NAT64 state and therefore is described in this specification. In 452 this document, we consider that the NAT64 may do no filtering, or it 453 may filter incoming IPv4 packets. 455 NAT64 filtering of incoming IPv4 packets is consistent with the 456 recommendations of [RFC4787], and the ones of [RFC5382]. Because of 457 that, the NAT64 as specified in this document, supports both 458 Endpoint-Independent Filtering and Address-Dependent Filtering, both 459 for TCP and UDP as well as filtering of ICMP packets. 461 If a NAT64 performs Endpoint-Independent Filtering of incoming IPv4 462 packets, then an incoming IPv4 packet is dropped unless the NAT64 has 463 state for the destination transport address of the incoming IPv4 464 packet. 466 If a NAT64 performs Address-Dependent Filtering of incoming IPv4 467 packets, then an incoming IPv4 packet is dropped unless the NAT64 has 468 state involving the destination transport address of the IPv4 469 incoming packet and the particular source IP address of the incoming 470 IPv4 packet. 472 2. Terminology 474 This section provides a definitive reference for all the terms used 475 in this document. 477 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 478 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 479 document are to be interpreted as described in RFC 2119 [RFC2119]. 481 The following additional terms are used in this document: 483 3-Tuple: The tuple (source IP address, destination IP address, ICMP 484 Identifier). A 3-tuple uniquely identifies an ICMP Query session. 485 When an ICMP Query session flows through a NAT64, each session has 486 two different 3-tuples: one with IPv4 addresses and one with IPv6 487 addresses. 489 5-Tuple: The tuple (source IP address, source port, destination IP 490 address, destination port, transport protocol). A 5-tuple 491 uniquely identifies a UDP/TCP session. When a UDP/TCP session 492 flows through a NAT64, each session has two different 5-tuples: 493 one with IPv4 addresses and one with IPv6 addresses. 495 BIB: Binding Information Base. A table of mappings kept by a NAT64. 496 Each NAT64 has three BIBs, one for TCP, one for UDP and one for 497 ICMP Queries. 499 Endpoint-Independent Mapping: In NAT64, using the same mapping for 500 all the sessions involving a given IPv6 transport address of an 501 IPv6 host (irrespectively of the transport address of the IPv4 502 host involved in the communication). Endpoint-independent Mapping 503 is important for peer-to-peer communication. See [RFC4787] for 504 the definition of the different types of mappings in IPv4-to-IPv4 505 NATs. 507 Filtering, Endpoint-Independent: The NAT64 filters out only incoming 508 IPv4 packets not destined to a transport address for which there 509 is no state in the NAT64, regardless of the source IPv4 transport 510 address. The NAT forwards any packets destined to any transport 511 address for which it has state. In other words, having state for 512 a given transport address is sufficient to allow any packets back 513 to the internal endpoint. See [RFC4787] for the definition of the 514 different types of filtering in IPv4-to-IPv4 NATs. 516 Filtering, Address-Dependent: The NAT64 filters out incoming IPv4 517 packets not destined to a transport address for which there is no 518 state (similar to the Endpoint-Independent Filtering). 519 Additionally, the NAT64 will filter out incoming IPv4 packets 520 coming from a given IPv4 address X and destined for a transport 521 address that it has state for if the NAT64 has not sent packets to 522 X previously (independently of the port used by X). In other 523 words, for receiving packets from a specific IPv4 endpoint, it is 524 necessary for the IPv6 endpoint to send packets first to that 525 specific IPv4 endpoint's IP address. 527 Hairpinning: Having a packet do a "U-turn" inside a NAT and come 528 back out the same side as it arrived on. If the destination IPv6 529 address and its embedded IPv4 address are both assigned to the 530 NAT64 itself, then the packet is being sent to another IPv6 host 531 connected to the same NAT64. Such a packet is called a 'hairpin 532 packet'. A NAT64 that forwards hairpin packets, back to the IPv6 533 host are defined as supporting "hairpinning". Hairpinning support 534 is important for peer-to-peer applications, as there are cases 535 when two different hosts on the same side of a NAT can only 536 communicate using sessions that hairpin through the NAT. Hairpin 537 packets can be either TCP or UDP. More detailed explanation of 538 hairpinning and examples for the UDP case can be found in 539 [RFC4787]. 541 Mapping or Binding: A mapping between an IPv6 transport address and 542 a IPv4 transport address or a mapping between an (IPv6 address, 543 ICMPv6 Identifier) pair and an (IPv4 address, ICMPv4 Identifier) 544 pair. Used to translate the addresses and ports/ICMP Identifiers 545 of packets flowing between the IPv6 host and the IPv4 host. In 546 NAT64, the IPv4 address and port/ICMPv4 Identifier is always one 547 assigned to the NAT64 itself, while the IPv6 address and port/ 548 ICMPv6 Identifier belongs to some IPv6 host. 550 Session: A TCP, UDP or ICMP Query session. In other words, the bi- 551 directional flow of packets between two different hosts. In 552 NAT64, typically one host is an IPv4 host, and the other one is an 553 IPv6 host. However, due to hairpinning, both hosts might be IPv6 554 hosts. 556 Session table: A table of sessions kept by a NAT64. Each NAT64 has 557 three session tables, one for TCP, one for UDP and one for ICMP 558 Queries. 560 Stateful NAT64: A function that has per-flow state which translates 561 IPv6 packets to IPv4 packets and vice-versa, for TCP, UDP, and 562 ICMP. The NAT64 uses binding state to perform the translation 563 between IPv6 and IPv4 addresses. In this document we also refer 564 to stateful NAT64 simply as NAT64. 566 Stateful NAT64 device: The device where the NAT64 function is 567 executed. In this document we also refer to stateful NAT64 device 568 simply as NAT64 device. 570 Transport Address: The combination of an IPv6 or IPv4 address and a 571 port. Typically written as (IP address, port)- e.g. (192.0.2.15, 572 8001). 574 Tuple: Refers to either a 3-Tuple or a 5-tuple as defined above. 576 For a detailed understanding of this document, the reader should also 577 be familiar with NAT terminology [RFC4787]. 579 3. Stateful NAT64 Normative Specification 581 A NAT64 is a device with at least one IPv6 interface and at least one 582 IPv4 interface. Each NAT64 device MUST have at least one unicast /n 583 IPv6 prefix assigned to it, denoted Pref64::/n. Additional 584 considerations about the Pref64::/n are presented in Section 3.5.4. 585 A NAT64 MUST have one or more unicast IPv4 addresses assigned to it. 587 A NAT64 uses the following conceptual dynamic data structures: 589 o UDP Binding Information Base 591 o UDP Session Table 593 o TCP Binding Information Base 595 o TCP Session Table 597 o ICMP Query Binding Information Base 599 o ICMP Query Session Table 601 These tables contain information needed for the NAT64 processing. 602 The actual division of the information into six tables is done in 603 order to ease the description of the NAT64 behaviour. NAT64 604 implementations are free to use different data structures but they 605 MUST store all the required information and the externally visible 606 outcome MUST be the same as the one described in this document. 608 The notation used is the following: upper case letters are IPv4 609 addresses; upper case letters with a prime(') are IPv6 addresses; 610 lower case letters are ports; prefixes of length n are indicated by 611 "P::/n", mappings are indicated as "(X,x) <--> (Y',y)". 613 3.1. Binding Information Bases 615 A NAT64 has three Binding Information Bases (BIBs): one for TCP, one 616 for UDP and one for ICMP Queries. In the case of UDP and TCP BIBs, 617 each BIB entry specifies a mapping between an IPv6 transport address 618 and an IPv4 transport address: 620 (X',x) <--> (T,t) 622 where X' is some IPv6 address, T is an IPv4 address, and x and t are 623 ports. T will always be one of the IPv4 addresses assigned to the 624 NAT64. The BIB has then two columns: the BIB IPv6 transport address 625 and the BIB IPv4 transport address. A given IPv6 or IPv4 transport 626 address can appear in at most one entry in a BIB: for example, (2001: 627 db8::17, 4) can appear in at most one TCP and at most one UDP BIB 628 entry. TCP and UDP have separate BIBs because the port number space 629 for TCP and UDP are distinct. This implementation of the BIBs 630 ensures Endpoint-Independent Mappings in the NAT64. The information 631 in the BIBs is also used to implement Endpoint-Independent Filtering. 632 (Address-Dependent Filtering is implemented using the session tables 633 described below.) 635 In the case of the ICMP Query BIB, each ICMP Query BIB entry 636 specifies a mapping between an (IPv6 address, ICMPv6 Identifier) pair 637 and an (IPv4 address, ICMPv4 Identifier) pair. 639 (X',I1) <--> (T,I2) 641 where X' is some IPv6 address, T is an IPv4 address, I1 is an ICMPv6 642 Identifier and I2 is an ICMPv4 Identifier. T will always be one of 643 the IPv4 addresses assigned to the NAT64. A given (IPv6 or IPv4 644 address, ICMPv6 or ICMPv4 Identifier) pair can appear in at most one 645 entry in the ICMP Query BIB. 647 Entries in any of the three BIBs can be created dynamically as the 648 result of the flow of packets as described in Section 3.5 but they 649 can also be created manually by an administrator. NAT64 650 implementations SHOULD support manually configured BIB entries for 651 any of the three BIBs. Dynamically-created entries are deleted from 652 the corresponding BIB when the last session associated with the BIB 653 entry is removed from the session table. Manually-configured BIB 654 entries are not deleted when there is no corresponding session table 655 entry and can only be deleted by the administrator. 657 3.2. Session Tables 659 A NAT64 also has three session tables: one for TCP sessions, one for 660 UDP sessions, and one for ICMP Query sessions. Each entry keeps 661 information on the state of the corresponding session. In the TCP 662 and UDP session tables, each entry specifies a mapping between a pair 663 of IPv6 transport addresses and a pair of IPv4 transport addresses: 665 (X',x),(Y',y) <--> (T,t),(Z,z) 667 where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and 668 x, y, z and t are ports. T will always be one of the IPv4 addresses 669 assigned to the NAT64. Y' is always the IPv6 representation of the 670 IPv4 address Z, so Y' is obtained from Z using the algorithm applied 671 by the NAT64 to create IPv6 representations of IPv4 addresses. y will 672 always be equal to z. 674 For each TCP or UDP Session Table Entry (STE), there are then five 675 columns: 677 The STE source IPv6 transport address, (X',x) in the example 678 above, 680 The STE destination IPv6 transport address, (Y',y) in the example 681 above, 683 The STE source IPv4 transport address, (T,t) in the example above, 684 and, 685 The STE destination IPv4 transport address, (Z,z) in the example 686 above. 688 The STE lifetime. 690 The terminology used for the session table entry columns is from the 691 perspective of an incoming IPv6 packet being translated into an 692 outgoing IPv4 packet. 694 In the ICMP query session table, each entry specifies a mapping 695 between a 3-tuple of IPv6 source address, IPv6 destination address 696 and ICMPv6 Identifier and a 3-tuple of IPv4 source address, IPv4 697 destination address and ICMPv4 Identifier: 699 (X',Y',I1) <--> (T,Z,I2) 701 where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, I1 is 702 an ICMPv6 Identifier and I2 is an ICMPv4 Identifier. T will always 703 be one of the IPv4 addresses assigned to the NAT64. Y' is always the 704 IPv6 representation of the IPv4 address Z, so Y' is obtained from Z 705 using the algorithm applied by the NAT64 to create IPv6 706 representations of IPv4 addresses. 708 For each ICMP Query Session Table Entry (STE), there are then seven 709 columns: 711 The STE source IPv6 address, X' in the example above, 713 The STE destination IPv6 address, Y' in the example above, 715 The STE ICMPv6 Identifier, I1 in the example above, 717 The STE source IPv4 address, T in the example above, 719 The STE destination IPv4 address, Z in the example above, and, 721 The STE ICMPv4 Identifier, I2 in the example above. 723 The STE lifetime. 725 3.3. Packet Processing Overview 727 The NAT64 uses the session state information to determine when the 728 session is completed, and also uses session information for Address- 729 Dependent Filtering. A session can be uniquely identified by either 730 an incoming tuple or an outgoing tuple. 732 For each TCP or UDP session, there is a corresponding BIB entry, 733 uniquely specified by either the source IPv6 transport address (in 734 the IPv6 --> IPv4 direction) or the destination IPv4 transport 735 address (in the IPv4 --> IPv6 direction). For each ICMP Query 736 session, there is a corresponding BIB entry, uniquely specified by 737 either the source IPv6 address and ICMPv6 Identifier (in the IPv6 --> 738 IPv4 direction) or the destination IPv4 address and the ICMPv4 739 Identifier (in the IPv4 --> IPv6 direction). However, for all the 740 BIBs, a single BIB entry can have multiple corresponding sessions. 741 When the last corresponding session is deleted, if the BIB entry was 742 dynamically created, the BIB entry is deleted. 744 The NAT64 will receive packets through its interfaces. These packets 745 can be either IPv6 packets or IPv4 packets and they may carry TCP 746 traffic, UDP traffic or ICMP traffic. The processing of the packets 747 will be described next. In the case that the processing is common to 748 all the aforementioned types of packets, we will refer to the packet 749 as the incoming IP packet in general. In case that the processing is 750 specific to IPv6 packets, we will refer to the incoming IPv6 packet 751 and similarly to the IPv4 packets. 753 The processing of an incoming IP packet takes the following steps: 755 1. Determining the incoming tuple 757 2. Filtering and updating binding and session information 759 3. Computing the outgoing tuple 761 4. Translating the packet 763 5. Handling hairpinning 765 The details of these steps are specified in the following 766 subsections. 768 This breakdown of the NAT64 behavior into processing steps is done 769 for ease of presentation. A NAT64 MAY perform the steps in a 770 different order, or MAY perform different steps, but the externally 771 visible outcome MUST be the same as the one described in this 772 document. 774 3.4. Determining the Incoming tuple 776 This step associates an incoming tuple with every incoming IP packet 777 for use in subsequent steps. In the case of TCP, UDP and ICMP error 778 packets, the tuple is a 5-tuple consisting of source IP address, 779 source port, destination IP address, destination port, transport 780 protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting 781 of the source IP address, destination IP address and ICMP Identifier. 783 If the incoming IP packet contains a complete (un-fragmented) UDP or 784 TCP protocol packet, then the 5-tuple is computed by extracting the 785 appropriate fields from the received packet. 787 If the incoming packet is a complete (un-fragmented) ICMP query 788 message (i.e., an ICMPv4 Query message or an ICMPv6 Informational 789 message), the 3-tuple is the source IP address, the destination IP 790 address and the ICMP Identifier. 792 If the incoming IP packet contains a complete (un-fragmented) ICMP 793 error message containing a UDP or a TCP packet, then the 5-tuple is 794 computed by extracting the appropriate fields from the IP packet 795 embedded inside the ICMP error message. However, the role of source 796 and destination is swapped when doing this: the embedded source IP 797 address becomes the destination IP address in the 5-tuple, the 798 embedded source port becomes the destination port in the 5-tuple, 799 etc. If it is not possible to determine the 5-tuple (perhaps because 800 not enough of the embedded packet is reproduced inside the ICMP 801 message), then the incoming IP packet MUST be silently discarded. 803 If the incoming IP packet contains a complete (un-fragmented) ICMP 804 error message containing a ICMP error message, then the packet is 805 silently discarded. 807 If the incoming IP packet contains a complete (un-fragmented) ICMP 808 error message containing an ICMP Query message, then the 3-tuple is 809 computed by extracting the appropriate fields from the IP packet 810 embedded inside the ICMP error message. However, the role of source 811 and destination is swapped when doing this: the embedded source IP 812 address becomes the destination IP address in the 3-tuple, the 813 embedded destination IP address becomes the source address in the 814 3-tuple and the embedded ICMP Identifier is used as the ICMP 815 Identifier of the 3-tuple. If it is not possible to determine the 816 3-tuple (perhaps because not enough of the embedded packet is 817 reproduced inside the ICMP message), then the incoming IP packet MUST 818 be silently discarded. 820 If the incoming IP packet contains a fragment, then more processing 821 may be needed. This specification leaves open the exact details of 822 how a NAT64 handles incoming IP packets containing fragments, and 823 simply requires that the external behavior of the NAT64 is compliant 824 with the following conditions: 826 The NAT64 MUST handle fragments. In particular, NAT64 MUST handle 827 fragments arriving out-of-order , conditioned on the following: 829 * The NAT64 MUST limit the amount of resources devoted to the 830 storage of fragmented packets in order to protect from DoS 831 attacks. 833 * As long as the NAT64 has available resources, the NAT64 MUST 834 allow the fragments to arrive over a time interval. The time 835 interval SHOULD be configurable and the default value MUST be 836 of at least FRAGMENT_MIN. 838 * The NAT64 MAY require that the UDP, TCP, or ICMP header be 839 completely contained within the fragment that contains OFFSET 840 equal to zero. 842 For incoming packets carrying TCP or UDP fragments with non-null 843 checksum, NAT64 MAY elect to queue the fragments as they arrive 844 and translate all fragments at the same time. In this case, the 845 incoming tuple is determined as documented above to the un- 846 fragmented packets. Alternatively, a NAT64 MAY translate the 847 fragments as they arrive, by storing information that allows it to 848 compute the 5-tuple for fragments other than the first. In the 849 latter case, subsequent fragments may arrive before the first and 850 the rules about how the NAT64 handles (out-of-order) fragments 851 described in the bulleted list above apply. 853 For incoming IPv4 packets carrying UDP packets with null checksum, 854 if the NAT64 has enough resources, the NAT64 MUST reassemble the 855 packets and MUST calculate the checksum. If the NAT64 does not 856 have enough resources, then it MUST silently discard the packets. 858 Implementers of NAT64 should be aware that there are a number of 859 well-known attacks against IP fragmentation; see [RFC1858] and 860 [RFC3128]. Implementers should also be aware of additional issues 861 with reassembling packets at high rates, described in [RFC4963]. 863 3.5. Filtering and Updating Binding and Session Information 865 This step updates binding and session information stored in the 866 appropriate tables. This step may also filter incoming packets, if 867 desired. 869 Irrespective of the transport protocol used, the NAT64 MUST silently 870 discard all incoming IPv6 packets containing a source address that 871 contains the Pref64::/n. This is required in order to prevent 872 hairpinning loops as described in Section 5. In addition, the NAT64 873 MUST only process incoming IPv6 packets that contain a destination 874 address that contains Pref64::/n. Likewise, the NAT64 MUST only 875 process incoming IPv4 packets that contain a destination address that 876 belong to the IPv4 pool assigned to the NAT64. 878 The details of this step depend on the protocol (UDP, TCP or ICMP 879 Query). 881 3.5.1. UDP Session Handling 883 The following state information is stored for a UDP session: 885 Binding:(X',x),(Y',y) <--> (T,t),(Z,z) 887 Lifetime: a timer that tracks the remaining lifetime of the TCP 888 session. When the timer expires, the UDP session is deleted. If 889 all the UDP sessions corresponding to a dynamically created UDP 890 BIB entry are deleted, then the UDP BIB entry is also deleted. 892 An IPv6 incoming packet with an incoming tuple with source transport 893 address (X',x) and destination transport address (Y',y) is processed 894 as follows: 896 The NAT64 searches for a UDP BIB entry that contains the BIB IPv6 897 transport address that matches the IPv6 source transport address 898 (X',x). If such an entry does not exist, the NAT64 tries to 899 create a new entry (if resources and policy permit). The source 900 IPv6 transport address of the packet (X',x) is used as BIB IPv6 901 transport address, and the BIB IPv4 transport address is set to 902 (T,t) which is allocated using the rules defined in 903 Section 3.5.1.1. The result is a BIB entry as follows: (X',x) 904 <--> (T,t). 906 The NAT64 searches for the session table entry corresponding to 907 the incoming 5-tuple. If no such entry is found, the NAT64 tries 908 to create a new entry (if resources and policy permit). The 909 information included in the session table is as follows: 911 * The STE source IPv6 transport address is set to (X',x), the 912 source IPv6 transport addresses contained in the received IPv6 913 packet, 915 * The STE destination IPv6 transport address is set to (Y',y), 916 the destination IPv6 transport addresses contained in the 917 received IPv6 packet, 919 * The STE source IPv4 transport address is extracted from the 920 corresponding UDP BIB entry i.e. it is set to (T,t), 922 * The STE destination IPv4 transport is set to (Z(Y'),y), y being 923 the same port as the STE destination IPv6 transport address and 924 Z(Y') being algorithmically generated from the IPv6 destination 925 address (i.e. Y') using the reverse algorithm as specified in 926 Section 3.5.4. 928 The result is a Session table entry as follows: (X',x),(Y',y) <--> 929 (T,t),(Z(Y'),y) 931 The NAT64 sets (or resets) the timer in the Session Table Entry to 932 the maximum session lifetime. The maximum session lifetime MAY be 933 configurable and the default SHOULD be at least UDP_DEFAULT. The 934 maximum session lifetime MUST NOT be less than UDP_MIN. The 935 packet is translated and forwarded as described in the following 936 sections. 938 An IPv4 incoming packet, with an incoming tuple with source IPv4 939 transport address (Y,y) and destination IPv4 transport address (X,x) 940 is processed as follows: 942 The NAT64 searches for a UDP BIB entry that contains the BIB IPv4 943 transport address matching (Y,y), (i.e., the IPv4 destination 944 transport address in the incoming IPv4 packet). If such an entry 945 does not exist, the packet MUST be dropped. An ICMP error message 946 with type of 3 (Destination Unreachable) MAY be sent to the 947 original sender of the packet, unless the discarded packet is 948 itself an ICMP error message. 950 If the NAT64 applies Address-Dependent Filters on its IPv4 951 interface, then the NAT64 checks to see if the incoming packet is 952 allowed according to the Address-Dependent Filtering rule. To do 953 this, it searches for a session table entry with an STE source 954 IPv4 transport address equal to (X,x), (i.e., the destination IPv4 955 transport address in the incoming packet) and STE destination IPv4 956 address equal to Y, (i.e., the source IPv4 address in the incoming 957 packet). If such an entry is found (there may be more than one), 958 packet processing continues. Otherwise, the packet is discarded. 959 If the packet is discarded, then an ICMP error message MAY be sent 960 to the original sender of the packet, unless the discarded packet 961 is itself an ICMP message. The ICMP error message, if sent, has a 962 type of 3 (Destination Unreachable) and a code of 13 963 (Communication Administratively Prohibited). 965 In case the packet is not discarded in the previous processing 966 (either because the NAT64 is not filtering or because the packet 967 is compliant with the Address-Dependent Filtering rule), then the 968 NAT64 searches for the session table entry corresponding 969 containing the STE source IPv4 transport address equal to (X,x) 970 and the STE destination IPv4 transport address equal to (Y,y). If 971 no such entry is found, the NAT64 tries to create a new entry (if 972 resources and policy permit). In case a new UDP session table 973 entry is created, it contains the following information: 975 * The STE source IPv6 transport address is extracted from the 976 corresponding UDP BIB entry. 978 * The STE destination IPv6 transport address is set to (Z'(Y),y), 979 y being the same port y than the destination IPv4 transport 980 address and Z'(Y) being the IPv6 representation of Y, generated 981 using the algorithm described in Section 3.5.4. 983 * The STE source IPv4 transport address is set to (X,x) the 984 destination IPv4 transport addresses contained in the received 985 IPv4 packet. 987 * The STE destination IPv4 transport is set to (Y,y), the source 988 IPv4 transport addresses contained in the received IPv4 packet. 990 The NAT64 sets (or resets) the timer in the Session Table Entry to 991 the maximum session lifetime. The maximum session lifetime MAY be 992 configurable and the default SHOULD be at least UDP_DEFAULT. The 993 maximum session lifetime MUST NOT be less than UDP_MIN. The 994 packet is translated and forwarded as described in the following 995 sections. 997 3.5.1.1. Rules for Allocation of IPv4 Transport Addresses for UDP 999 When a new UDP BIB entry is created for a source transport address of 1000 (S',s), then the NAT64 allocates an IPv4 transport address for this 1001 BIB entry as follows: 1003 If there exists some other BIB entry containing S' as the IPv6 1004 address and mapping it to some IPv4 address T, then the NAT64 1005 SHOULD use T as the IPv4 address. Otherwise, use any IPv4 address 1006 of the IPv4 pool assigned to the NAT64 to be used for translation. 1008 If the port s is in the Well-Known port range 0-1023, and the 1009 NAT64 has an available port t in the same port range, then the 1010 NAT64 SHOULD allocate the port t. If the NAT64 does not have a 1011 port available in the same range, the NAT64 MAY assign a port t 1012 from other range where it has an available port. (This behavior 1013 is recommended in REQ 3-a of [RFC4787].) 1015 If the port s is in the range 1024-65535, and the NAT64 has an 1016 available port t in the same port range, then the NAT64 SHOULD 1017 allocate the port t. If the NAT64 does not have a port available 1018 in the same range, the NAT64 MAY assign a port t from other range 1019 where it has an available port. (this behavior is recommended in 1020 REQ 3-a of [RFC4787]) 1021 The NAT64 SHOULD preserve the port parity (odd/even), as per 1022 Section 4.2.2 of [RFC4787]). 1024 In all cases, the allocated IPv4 transport address (T,t) MUST NOT 1025 be in use in another entry in the same BIB, but MAY be in use in 1026 the other BIB (referring to the UDP and TCP BIBs). 1028 If it is not possible to allocate an appropriate IPv4 transport 1029 address or create a BIB entry, then the packet is discarded. The 1030 NAT64 SHOULD send an ICMPv6 Destination Unreachable/Address 1031 unreachable (Code 3) message. 1033 3.5.2. TCP Session Handling 1035 In this section we describe how the TCP BIB and Session table are 1036 populated. We do so by defining the state machine of the NAT64 uses 1037 for TCP. We first describe the states and the information contained 1038 in them and then we describe the actual state machine and state 1039 transitions. 1041 3.5.2.1. State definition 1043 The following state information is stored for a TCP session: 1045 Binding:(X',x),(Y',y) <--> (T,t),(Z,z) 1047 Lifetime: a timer that tracks the remaining lifetime of the TCP 1048 session. When the timer expires, the TCP session is deleted. If 1049 all the TCP sessions corresponding to a TCP BIB entry are deleted, 1050 then the dynamically created TCP BIB entry is also deleted. 1052 TCP sessions are expensive, because their inactivity lifetime is set 1053 to at least 2 hours and 4 min (as per [RFC5382]), so it is important 1054 that each TCP session table entry corresponds to an existent TCP 1055 session. In order to do that, for each TCP session established 1056 through it, it tracks the corresponding state machine as follows. 1058 The states are the following ones: 1060 CLOSED: Analogous to [RFC0793], CLOSED is a fictional state 1061 because it represents the state when there is no state for this 1062 particular 5-tuple, and therefore, no connection. 1064 V4 SYN RCV: An IPv4 packet containing a TCP SYN was received by 1065 the NAT64, implying that a TCP connection is being initiated from 1066 the IPv4 side. The NAT64 is now waiting for a matching IPv6 1067 packet containing the TCP SYN in the opposite direction. 1069 V6 SYN RCV: An IPv6 packet containing a TCP SYN was received by 1070 the NAT64, implying that a TCP connection is being initiated from 1071 the IPv6 side. The NAT64 is now waiting for a matching IPv4 1072 packet containing the TCP SYN in the opposite direction. 1074 ESTABLISHED: Represents an open connection, with data able to flow 1075 in both directions. 1077 V4 FIN RCV: An IPv4 packet containing a TCP FIN was received by 1078 the NAT64, data can still flow in the connection, and the NAT64 is 1079 waiting for a matching TCP FIN in the opposite direction. 1081 V6 FIN RCV: An IPv6 packet containing a TCP FIN was received by 1082 the NAT64, data can still flow in the connection, and the NAT64 is 1083 waiting for a matching TCP FIN in the opposite direction. 1085 V6 FIN + V4 FIN RCV: Both an IPv4 packet containing a TCP FIN and 1086 an IPv6 packet containing an TCP FIN for this connection were 1087 received by the NAT64. The NAT64 keeps the connection state alive 1088 and forwards packets in both directions for a short period of time 1089 to allow remaining packets (in particular the ACKs) to be 1090 delivered. 1092 4MIN: The lifetime of the state for the connection is set to 4 1093 minutes either because a packet containing a TCP RST was received 1094 by the NAT64 for this connection or simply because the lifetime of 1095 the connection has decreased and there are only 4 minutes left. 1096 The NAT64 will keep the state for the connection for a short time 1097 and if no other data packets for that connection are received, the 1098 state for this connection is then terminated. 1100 3.5.2.2. State machine for TCP processing in the NAT64 1102 The state machine used by the NAT64 for the TCP session processing is 1103 depicted next. The described state machine handles all TCP segments 1104 received through the IPv6 and IPv4 interface. There is one state 1105 machine per TCP connection that is potentially established through 1106 the NAT64. After bootstrapping of the NAT64 device, all TCP sessions 1107 are in CLOSED state. As we mention above, the CLOSED state is a 1108 fictional state when is no state for that particular connection in 1109 the NAT64. It should be noted that there is one state machine per 1110 connection, so only packets belonging to a given connection are 1111 inputs to the state machine associated to that connection. In other 1112 words, when in the state machine below we state that a packet is 1113 received, it is implicit that the incoming 5-tuple of the data packet 1114 matches to the one of the state machine. 1116 A TCP segment with the SYN flag set that is received through the IPv6 1117 interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 1118 FIN + V4 FIN, V6 RST and V4 RST. 1120 +-----------------------------+ 1121 | | 1122 V | 1123 V6 +------+ V4 | 1124 +----SYN------|CLOSED|-----SYN------+ | 1125 | +------+ | | 1126 | ^ | | 1127 | |4min T.O. | | 1128 V | V | 1129 +-------+ +-------+ +-------+ | 1130 |V6 SYN | | 4MIN | |V4 SYN | | 1131 | RCV | +-------+ | RCV | | 1132 +-------+ | ^ +-------+ | 1133 | data pkt | | | 1134 | | V4 or V6 RST | | 1135 | | 2 hr. T.O. | | 1136 V4 SYN V | V6 SYN | 1137 | +--------------+ | | 1138 +--------->| ESTABLISHED |<---------+ | 1139 +--------------+ | 1140 | | | 1141 V4 FIN V6 FIN | 1142 | | | 1143 V V | 1144 +---------+ +----------+ | 1145 | V4 FIN | | V6 FIN | | 1146 +---------+ +----------+ | 1147 | | | 1148 V6 FIN V4 FIN 4 min 1149 | | T.O. 1150 V V | 1151 +-------------------+ | 1152 | V4 FIN + V6 FIN |----------------------+ 1153 +-------------------+ 1155 We next describe the state information and the transitions. 1157 *** CLOSED *** 1159 If a V6 SYN is received with an incoming tuple with source transport 1160 address (X',x) and destination transport address (Y',y) (this is the 1161 case of a TCP connection initiated from the IPv6 side), the 1162 processing is as follows: 1164 1. The NAT64 searches for a TCP BIB entry that matches the IPv6 1165 source transport address (X',x). 1167 If such an entry does not exist, the NAT64 tries to create a 1168 new BIB entry (if resources and policy permit). The BIB IPv6 1169 transport address is set to (X',x) (i.e., the source IPv6 1170 transport address of the packet). The BIB IPv4 transport 1171 address is set to an IPv4 transport address allocated using 1172 the rules defined in Section 3.5.2.3 The processing of the 1173 packet continues as described in bullet 2. 1175 If the entry already exists, then the processing continues as 1176 described in bullet 2. 1178 2. Then the NAT64 tries to create a new TCP session entry in the TCP 1179 session table (if resources and policy permit). The information 1180 included in the session table is as follows: 1182 The STE source IPv6 transport address is set to (X',x) (i.e. 1183 the source transport address contained in the received V6 SYN 1184 packet, 1186 The STE destination IPv6 transport address is set to (Y',y) 1187 (i.e. the destination transport address contained in the 1188 received V6 SYN packet. 1190 The STE source IPv4 transport address is set to the BIB IPv4 1191 transport address of the corresponding TCP BIB entry. 1193 The STE destination IPv4 transport address contains the port y 1194 (i.e., the same port as the IPv6 destination transport 1195 address) and the IPv4 address that is algorithmically 1196 generated from the IPv6 destination address (i.e. Y') using 1197 the reverse algorithm as specified in Section 3.5.4. 1199 The lifetime of the TCP session table entry is set to at least 1200 to TCP_TRANS (the transitory connection idle timeout as 1201 defined in [RFC5382]). 1203 3. The state of the session is moved to V6 SYN RCV. 1205 4. The NAT64 translates and forwards the packet as described in the 1206 following sections 1208 If a V4 SYN packet is received with an incoming tuple with source 1209 IPv4 transport address (Y,y) and destination IPv4 transport address 1210 (X,x) (this is the case of a TCP connection initiated from the IPv4 1211 side), the processing is as follows: 1213 If the security policy requires silently dropping externally 1214 initiated TCP connections, then the packet is silently discarded, 1215 else, 1217 If the destination transport address contained in the incoming V4 1218 SYN (i.e., X,x) is not in use in the TCP BIB, then: 1220 The NAT64 tries to create a new session table entry in the TCP 1221 session table (if resources and policy permit), containing the 1222 following information: 1224 + The STE source IPv4 transport address is set to (X,x) (i.e. 1225 the destination transport address contained in the V4 SYN) 1227 + The STE destination IPv4 transport address is set to (Y,y) 1228 (i.e. the source transport address contained in the V4 SYN) 1230 + The STE transport IPv6 source address is left unspecified 1231 and may be populated by other protocols out of the scope of 1232 this specification. 1234 + The STE destination IPv6 transport address contains the port 1235 y (i.e. the same port than the destination IPv4 transport 1236 address) and the IPv6 representation of Y (i.e. the IPv4 1237 address of the destination IPv4 transport address), 1238 generated using the algorithm described in Section 3.5.4. 1240 The state is moved to V4 SYN RCV. 1242 The lifetime of the STE entry is set to TCP_INCOMING_SYN as per 1243 [RFC5382] and the packet is stored. The motivation for 1244 creating the session table entry and storing the packet 1245 (instead of simply dropping the packet based on the filtering) 1246 is to support simultaneous open of TCP connections. 1248 If the destination transport address contained in the incoming V4 1249 SYN (i.e., X,x) is in use in the TCP BIB, then: 1251 The NAT64 tries to create a new session table entry in the TCP 1252 session table (if resources and policy permit), containing the 1253 following information: 1255 + The STE source IPv4 transport address is set to (X,x) (i.e. 1256 the destination transport address contained in the V4 SYN) 1258 + The STE destination IPv4 transport address is set to (Y,y) 1259 (i.e. the source transport address contained in the V4 SYN) 1261 + The STE transport IPv6 source address is set to the IPv6 1262 transport address contained in the corresponding TCP BIB 1263 entry. 1265 + The STE destination IPv6 transport address contains the port 1266 y (i.e. the same port than the destination IPv4 transport 1267 address) and the IPv6 representation of Y (i.e. the IPv4 1268 address of the destination IPv4 transport address), 1269 generated using the algorithm described in Section 3.5.4. 1271 The state is moved to V4 SYN RCV. 1273 If the NAT64 is performing Address-Dependent Filtering, the 1274 lifetime of the STE entry is set to TCP_INCOMING_SYN as per 1275 [RFC5382] and the packet is stored. The motivation for 1276 creating the session table entry and storing the packet 1277 (instead of simply dropping the packet based on the filtering) 1278 is to support simultaneous open of TCP connections. 1280 If the NAT64 is not performing Address-Dependent Filtering, the 1281 lifetime of the STE is set to at least to TCP_TRANS (the 1282 transitory connection idle timeout as defined in [RFC5382]) and 1283 it translates and forwards the packet as described in the 1284 following sections. 1286 For any other packet belonging to this connection: 1288 If there is a corresponding entry in the TCP BIB other packets 1289 SHOULD be translated and forwarded if the security policy allows 1290 to do so. The state remains unchanged. 1292 If there is no corresponding entry in the TCP BIB the packet is 1293 silently discarded. 1295 *** V4 SYN RCV *** 1297 If a V6 SYN is received with incoming tuple with source transport 1298 address (X',x) and destination transport address (Y',y). The 1299 lifetime of the TCP session table entry is set to at least to the 1300 maximum session lifetime. The value for the maximum session lifetime 1301 MAY be configurable but it MUST not be less than TCP_EST (the 1302 established connection idle timeout as defined in [RFC5382]). The 1303 default value for the maximum session lifetime SHOULD be set to 1304 TCP_EST. The packet is translated and forwarded. The state is moved 1305 to ESTABLISHED. 1307 If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code 1308 3) containing the IPv4 SYN packet stored is sent back to the source 1309 of the v4 SYN, the session table entry is deleted and, the state is 1310 moved to CLOSED. 1312 For any other packet, other packets SHOULD be translated and 1313 forwarded if the security policy allows to do so. The state remains 1314 unchanged. 1316 *** V6 SYN RCV *** 1318 If a V4 SYN is received (with or without the ACK flag set), with an 1319 incoming tuple with source IPv4 transport address (Y,y) and 1320 destination IPv4 transport address (X,x), then the state is moved to 1321 ESTABLISHED. The lifetime of the TCP session table entry is set to 1322 at least to the maximum session lifetime. The value for the maximum 1323 session lifetime MAY be configurable but it MUST not be less than 1324 TCP_EST (the established connection idle timeout as defined in 1325 [RFC5382]). The default value for the maximum session lifetime 1326 SHOULD be set to TCP_EST. The packet is translated and forwarded. 1328 If the lifetime expires, the session table entry is deleted and the 1329 state is moved to CLOSED. 1331 For any other packet, other packets SHOULD be translated and 1332 forwarded if the security policy allows to do so. The state remains 1333 unchanged. 1335 *** ESTABLISHED *** 1337 If a V4 FIN packet is received, the packet is translated and 1338 forwarded. The state is moved to V4 FIN RCV. 1340 If a V6 FIN packet is received, the packet is translated and 1341 forwarded. The state is moved to V6 FIN RCV. 1343 If a V4 RST or a V6 RST packet is received, the packet is translated 1344 and forwarded. The lifetime is set to TCP_TRANS and the state is 1345 moved to 4MIN. (Since the NAT64 is uncertain whether the peer will 1346 accept the RST packet, instead of moving the state to CLOSED, it 1347 moves to 4MIN, which has a shorter lifetime. If no other packets are 1348 received for this connection during the short timer, the NAT64 1349 assumes that the peer has accepted the RST packet and moves to 1350 CLOSED. If packets keep flowing, the NAT64 assumes that the peer has 1351 not accepted the RST packet and moves back to the ESTABLISHED state. 1352 This is described below in the 4MIN state processing description.) 1354 If any other packet is received, the packet is translated and 1355 forwarded. The lifetime of the TCP session table entry is set to at 1356 least to the maximum session lifetime. The value for the maximum 1357 session lifetime MAY be configurable but it MUST not be less than 1358 TCP_EST (the established connection idle timeout as defined in 1359 [RFC5382]). The default value for the maximum session lifetime 1360 SHOULD be set to TCP_EST. The state remains unchanged as 1361 ESTABLISHED. 1363 If the lifetime expires then the NAT64 SHOULD send a probe packet (as 1364 defined next) to at least one of the endpoints of the TCP connection. 1365 The probe packet is a TCP segment for the connection with no data. 1366 The sequence number and the acknowledgment number are set to zero. 1367 All flags but the ACK flag are reset. 1369 Upon the reception of this probe packet, the endpoint will reply 1370 with an ACK containing the expected sequence number for that 1371 connection. It should be noted that, for an active connection, 1372 each of these probe packets will generate one packet from each end 1373 involved in the connection, since the reply of the first point to 1374 the probe packet will generate a reply from the other endpoint. 1376 The state is moved to 4MIN. 1378 *** V4 FIN RCV *** 1380 If a V6 FIN packet is received, the packet is translated and 1381 forwarded. The lifetime is set to TCP_TRANS. The state is moved to 1382 V6 FIN + V4 FIN RCV. 1384 If any packet other than the V6 FIN is received, the packet is 1385 translated and forwarded. The lifetime of the TCP session table 1386 entry is set to at least to the maximum session lifetime. The value 1387 for the maximum session lifetime MAY be configurable but it MUST not 1388 be less than TCP_EST (the established connection idle timeout as 1389 defined in [RFC5382]). The default value for the maximum session 1390 lifetime SHOULD be set to TCP_EST. The state remains unchanged as V4 1391 FIN RCV. 1393 If the lifetime expires, the session table entry is deleted and the 1394 state is moved to CLOSED. 1396 *** V6 FIN RCV *** 1398 If a V4 FIN packet is received, the packet is translated and 1399 forwarded. The lifetime is set to TCT_TRANS. The state is moved to 1400 V6 FIN + V4 FIN RCV. 1402 If any packet other than the V4 FIN is received, the packet is 1403 translated and forwarded. The lifetime of the TCP session table 1404 entry is set to at least to the maximum session lifetime. The value 1405 for the maximum session lifetime MAY be configurable but it MUST not 1406 be less than TCP_EST (the established connection idle timeout as 1407 defined in [RFC5382]). The default value for the maximum session 1408 lifetime SHOULD be set to TCP_EST. The state remains unchanged as V6 1409 FIN RCV. 1411 If the lifetime expires, the session table entry is deleted and the 1412 state is moved to CLOSED. 1414 *** V6 FIN + V4 FIN RCV *** 1416 All packets are translated and forwarded. 1418 If the lifetime expires, the session table entry is deleted and the 1419 state is moved to CLOSED. 1421 *** 4MIN *** 1423 If a packet other than a RST packet is received, the lifetime of the 1424 TCP session table entry is set to at least to the maximum session 1425 lifetime. The value for the maximum session lifetime MAY be 1426 configurable but it MUST not be less than TCP_EST (the established 1427 connection idle timeout as defined in [RFC5382]). The default value 1428 for the maximum session lifetime SHOULD be set to TCP_EST. The state 1429 is moved to ESTABLISHED. 1431 If the lifetime expires, the session table entry is deleted and the 1432 state is moved to CLOSED. 1434 3.5.2.3. Rules for allocation of IPv4 transport addresses for TCP 1436 When a new TCP BIB entry is created for a source transport address of 1437 (S',s), then the NAT64 allocates an IPv4 transport address for this 1438 BIB entry as follows: 1440 If there exists some other BIB entry containing S' as the IPv6 1441 address and mapping it to some IPv4 address T, then T SHOULD be 1442 used as the IPv4 address. Otherwise, use any IPv4 address of the 1443 IPv4 pool assigned to the NAT64 to be used for translation. 1445 If the port s is in the Well-Known port range 0-1023, and the 1446 NAT64 has an available port t in the same port range, then the 1447 NAT64 SHOULD allocate the port t. If the NAT64 does not have a 1448 port available in the same range, the NAT64 MAY assign a port t 1449 from another range where it has an available port. 1451 If the port s is in the range 1024-65535, and the NAT64 has an 1452 available port t in the same port range, then the NAT64 SHOULD 1453 allocate the port t. If the NAT64 does not have a port available 1454 in the same range, the NAT64 MAY assign a port t from another 1455 range where it has an available port. 1457 In all cases, the allocated IPv4 transport address (T,t) MUST NOT 1458 be in use in another entry in the same BIB, but MAY be in use in 1459 the other BIB (referring to the UDP and TCP BIBs). 1461 If it is not possible to allocate an appropriate IPv4 transport 1462 address or create a BIB entry, then the packet is discarded. The 1463 NAT64 SHOULD send an ICMPv6 Destination Unreachable/Address 1464 unreachable (Code 3) message. 1466 3.5.3. ICMP Query Session Handling 1468 The following state information is stored for an ICMP Query session 1469 in the ICMP Query session table: 1471 Binding:(X',Y',I1) <--> (T,Z,I2) 1473 Lifetime: a timer that tracks the remaining lifetime of the ICMP 1474 Query session. When the timer expires, the session is deleted. 1475 If all the ICMP Query sessions corresponding to a dynamically 1476 created ICMP Query BIB entry are deleted, then the ICMP Query BIB 1477 entry is also deleted. 1479 An incoming ICMPv6 Informational packet with IPv6 source address X', 1480 IPv6 destination address Y' and ICMPv6 Identifier I1, is processed as 1481 follows: 1483 If the local security policy determines that ICMPv6 Informative 1484 packets are to be filtered, the packet is silently discarded. 1485 Else, the NAT64 searches for an ICMP Query BIB entry that matches 1486 the (X',I1) pair. If such entry does not exist, the NAT64 tries 1487 to create a new entry (if resources and policy permit) with the 1488 following data: 1490 * The BIB IPv6 address is set to X' (i.e. the source IPv6 address 1491 of the IPv6 packet). 1493 * The BIB ICMPv6 Identifier is set to I1 (i.e. the ICMPv6 1494 Identifier). 1496 * If there exists another BIB entry containing the same IPv6 1497 address X' and mapping it to an IPv4 address T, then use T as 1498 the BIB IPv4 address for this new entry. Otherwise, use any 1499 IPv4 address assigned to the IPv4 interface. 1501 * As the BIB ICMPv4 Identifier use any available value i.e. any 1502 identifier value for which no other entry exists with the same 1503 (IPv4 address, ICMPv4 Identifier) pair. 1505 The NAT64 searches for an ICMP query session table entry 1506 corresponding to the incoming 3-tuple (X',Y',I1). If no such 1507 entry is found, the NAT64 tries to create a new entry (if 1508 resources and policy permit). The information included in the new 1509 session table entry is as follows: 1511 * The STE IPv6 source address is set to the X' (i.e. the address 1512 contained in the received IPv6 packet), 1514 * The STE IPv6 destination address is set to the Y' (i.e. the 1515 address contained in the received IPv6 packet), 1517 * The STE ICMPv6 Identifier is set to the I1 (i.e. the identifier 1518 contained in the received IPv6 packet), 1520 * The STE IPv4 source address is set to the IPv4 address 1521 contained in the corresponding BIB entry, 1523 * The STE ICMPv4 Identifier is set to the IPv4 identifier 1524 contained in the corresponding BIB entry, 1526 * The STE IPv4 destination address is algorithmically generated 1527 from Y' using the reverse algorithm as specified in 1528 Section 3.5.4. 1530 The NAT64 sets (or resets) the timer in the session table entry to 1531 the maximum session lifetime. By default, the maximum session 1532 lifetime is ICMP_DEFAULT. The maximum lifetime value SHOULD be 1533 configurable. The packet is translated and forwarded as described 1534 in the following sections. 1536 An incoming ICMPv4 Query packet with source IPv4 address Y, 1537 destination IPv4 address X and ICMPv4 Identifier I2 is processed as 1538 follows: 1540 The NAT64 searches for an ICMP Query BIB entry that contains X as 1541 IPv4 address and I2 as the ICMPv4 Identifier. If such an entry 1542 does not exist, the packet is dropped. An ICMP error message MAY 1543 be sent to the original sender of the packet, unless the discarded 1544 packet is itself an ICMP error message. The ICMP error message, 1545 if sent, has a type of 3 (Destination Unreachable). 1547 If the NAT64 filters on its IPv4 interface, then the NAT64 checks 1548 to see if the incoming packet is allowed according to the Address- 1549 Dependent Filtering rule. To do this, it searches for a session 1550 table entry with an STE source IPv4 address equal to X, an STE 1551 ICMPv4 Identifier equal to I2 and a STE destination IPv4 address 1552 equal to Y. If such an entry is found (there may be more than 1553 one), packet processing continues. Otherwise, the packet is 1554 discarded. If the packet is discarded, then an ICMP error message 1555 MAY be sent to the original sender of the packet, unless the 1556 discarded packet is itself an ICMP message. The ICMP error 1557 message, if sent, has a type of 3 (Destination Unreachable) and a 1558 code of 13 (Communication Administratively Prohibited). 1560 In case the packet is not discarded in the previous processing 1561 steps (either because the NAT64 is not filtering or because the 1562 packet is compliant with the Address-dependent Filtering rule), 1563 then the NAT64 searches for a session table entry with an STE 1564 source IPv4 address equal to X, an STE ICMPv4 Identifier equal to 1565 I2 and a STE destination IPv4 address equal to Y. If no such entry 1566 is found, the NAT64 tries to create a new entry (if resources and 1567 policy permit) with the following information: 1569 * The STE source IPv4 address is set to X, 1571 * The STE ICMPv4 Identifier is set to I2, 1573 * The STE destination IPv4 address is set to Y, 1575 * The STE source IPv6 address is set to the IPv6 address of the 1576 corresponding BIB entry, 1578 * The STE ICMPv6 Identifier is set to the ICMPv6 Identifier of 1579 the corresponding BIB entry, and, 1581 * The STE destination IPv6 address is set to the IPv6 1582 representation of the IPv4 address of Y, generated using the 1583 algorithm described in Section 3.5.4. 1585 * The NAT64 sets (or resets) the timer in the session table entry 1586 to the maximum session lifetime. By default, the maximum 1587 session lifetime is ICMP_DEFAULT. The maximum lifetime value 1588 SHOULD be configurable. The packet is translated and forwarded 1589 as described in the following sections. 1591 3.5.4. Generation of the IPv6 Representations of IPv4 Addresses 1593 NAT64 supports multiple algorithms for the generation of the IPv6 1594 representation of an IPv4 address. The constraints imposed on the 1595 generation algorithms are the following: 1597 The algorithm MUST be reversible, i.e. it MUST be possible to 1598 derive the original IPv4 address from the IPv6 representation. 1600 The input for the algorithm MUST be limited to the IPv4 address, 1601 the IPv6 prefix (denoted Pref64::/n) used in the IPv6 1602 representations and optionally a set of stable parameters that are 1603 configured in the NAT64 (such as fixed string to be used as a 1604 suffix). 1606 If we note n the length of the prefix Pref64::/n, then n MUST 1607 be less or equal than 96. If a Pref64::/n is configured 1608 through any means in the NAT64 (such as manually configured, or 1609 other automatic mean not specified in this document), the 1610 default algorithm MUST use this prefix. If no prefix is 1611 available, the algorithm SHOULD use the Well-Known Prefix (64: 1612 FF9B::/96) defined in [I-D.ietf-behave-address-format] 1614 NAT64 MUST support the algorithm for generating IPv6 representations 1615 of IPv4 addresses defined in Section 2.1 of 1616 [I-D.ietf-behave-address-format]. The aforementioned algorithm 1617 SHOULD be used as default algorithm. 1619 3.6. Computing the Outgoing Tuple 1621 This step computes the outgoing tuple by translating the IP addresses 1622 and port numbers or ICMP Identifier in the incoming tuple. 1624 In the text below, a reference to a BIB means either the TCP BIB the 1625 UDP BIB or the ICMP Query BIB as appropriate. 1627 NOTE: Not all addresses are translated using the BIB. BIB entries 1628 are used to translate IPv6 source transport addresses to IPv4 1629 source transport addresses, and IPv4 destination transport 1630 addresses to IPv6 destination transport addresses. They are NOT 1631 used to translate IPv6 destination transport addresses to IPv4 1632 destination transport addresses, nor to translate IPv4 source 1633 transport addresses to IPv6 source transport addresses. The 1634 latter cases are handled applying the algorithmic transformation 1635 described in Section 3.5.4. This distinction is important; 1636 without it, hairpinning doesn't work correctly. 1638 3.6.1. Computing the Outgoing 5-tuple for TCP and UDP 1640 The transport protocol in the outgoing 5-tuple is always the same as 1641 that in the incoming 5-tuple. 1643 When translating in the IPv6 --> IPv4 direction, let the incoming 1644 source and destination transport addresses in the 5-tuple be (S',s) 1645 and (D',d) respectively. The outgoing source transport address is 1646 computed as follows: if the BIB contains a entry (S',s) <--> (T,t), 1647 then the outgoing source transport address is (T,t). 1649 The outgoing destination address is computed algorithmically from D' 1650 using the address transformation described in Section 3.5.4. 1652 When translating in the IPv4 --> IPv6 direction, let the incoming 1653 source and destination transport addresses in the 5-tuple be (S,s) 1654 and (D,d) respectively. The outgoing source transport address is 1655 computed as follows: 1657 The outgoing source transport address is generated from S using 1658 the address transformation algorithm described in Section 3.5.4. 1660 The BIB table is searched for an entry (X',x) <--> (D,d), and if 1661 one is found, the outgoing destination transport address is set to 1662 (X',x). 1664 3.6.2. Computing the Outgoing 3-tuple for ICMP Query Messages 1666 When translating in the IPv6 --> IPv4 direction, let the incoming 1667 source and destination addresses in the 3-tuple be S' and D' 1668 respectively and the ICMPv6 Identifier be I1. The outgoing source 1669 address is computed as follows: the BIB contains an entry (S',I1) 1670 <--> (T,I2), then the outgoing source address is T and the ICMPv4 1671 Identifier is I2. 1673 The outgoing IPv4 destination address is computed algorithmically 1674 from D' using the address transformation described in Section 3.5.4. 1676 When translating in the IPv4 --> IPv6 direction, let the incoming 1677 source and destination addresses in the 3-tuple be S and D 1678 respectively and the ICMPv4 Identifier is I2. The outgoing source 1679 address is generated from S using the address transformation 1680 algorithm described in Section 3.5.4. The BIB is searched for an 1681 entry containing (X',I1) <--> (D,I2) and if found the outgoing 1682 destination address is X' and the outgoing ICMPv6 Identifier is I1. 1684 3.7. Translating the Packet 1686 This step translates the packet from IPv6 to IPv4 or vice-versa. 1688 The translation of the packet is as specified in Section 3 and 1689 Section 4 of the IP/ICMP Translation Algorithm 1690 [I-D.ietf-behave-v6v4-xlate], with the following modifications: 1692 o When translating an IP header (Sections 3.1 and 4.1), the source 1693 and destination IP address fields are set to the source and 1694 destination IP addresses from the outgoing tuple as determined in 1695 Section 3.6. 1697 o When the protocol following the IP header is TCP or UDP, then the 1698 source and destination ports are modified to the source and 1699 destination ports from the outgoing 5-tuple. In addition, the TCP 1700 or UDP checksum must also be updated to reflect the translated 1701 addresses and ports; note that the TCP and UDP checksum covers the 1702 pseudo-header which contains the source and destination IP 1703 addresses. An algorithm for efficiently updating these checksums 1704 is described in [RFC3022]. 1706 o When the protocol following the IP header is ICMP and it is an 1707 ICMP Query message, the ICMP Identifier is set to the one from the 1708 outgoing 3-tuple as determined in Section 3.6.2. 1710 o When the protocol following the IP header is ICMP (Sections 3.4 1711 and 4.4) and it is an ICMP error message, the source and 1712 destination transport addresses in the embedded packet are set to 1713 the destination and source transport addresses from the outgoing 1714 5-tuple (note the swap of source and destination). 1716 The size of outgoing packets as well and the potential need for 1717 fragmentation is done according to the behavior defined in the IP/ 1718 ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate] 1720 3.8. Handling Hairpinning 1722 If the destination IP address of the translated packet is an IPv4 1723 address assigned to the NAT64 itself then the packet is a hairpin 1724 packet. Hairpin packets are processed as follows: 1726 o The outgoing 5-tuple becomes the incoming 5-tuple, and, 1728 o the packet is treated as if it was received on the outgoing 1729 interface. 1731 o Processing of the packet continues at step 2 - Filtering and 1732 updating binding and session information described in Section 3.5. 1734 4. Protocol Constants 1736 UDP_MIN 2 minutes (as defined in [RFC4787]) 1738 UDP_DEFAULT 5 minutes (as defined in [RFC4787]) 1740 TCP_TRANS 4 minutes (as defined in [RFC5382]) 1742 TCP_EST 2 hours (the minimum lifetime for an established TCP session 1743 defined in [RFC5382] is 2 hrs and 4 minutes, which is achieved adding 1744 the 2 hours with this timer and the 4 minutes with the TCP_TRANS 1745 timer) 1747 TCP_INCOMING_SYN 6 seconds (as defined in [RFC5382]) 1749 FRAGMENT_MIN 2 seconds 1751 ICMP_DEFAULT 60 seconds (as defined in [RFC5508]) 1753 5. Security Considerations 1755 5.1. Implications on end-to-end security 1757 Any protocols that protect IP header information are essentially 1758 incompatible with NAT64. This implies that end-to-end IPsec 1759 verification will fail when AH is used (both transport and tunnel 1760 mode) and when ESP is used in transport mode. This is inherent in 1761 any network-layer translation mechanism. End-to-end IPsec protection 1762 can be restored, using UDP encapsulation as described in [RFC3948]. 1763 The actual extensions to support IPsec are out of the scope of this 1764 document. 1766 5.2. Filtering 1768 NAT64 creates binding state using packets flowing from the IPv6 side 1769 to the IPv4 side. In accordance with the procedures defined in this 1770 document following the guidelines defined in [RFC4787] a NAT64 must 1771 offer "Endpoint-Independent Filtering". This means: 1773 for any IPv6 packet with source (S'1,s1) and destination (Pref64:: 1774 D1,d1) that creates an external mapping to (S1,s1), (D1,d1), 1775 for any subsequent external connection from S'1 to (D2,d2) within 1776 a given binding timer window, 1778 (S1,s1) = (S2,s2) for all values of D2,d2 1780 Implementations may also provide support for "Address-Dependent 1781 Mapping" as also defined in this document and following the 1782 guidelines defined in [RFC4787]. 1784 The security properties however are determined by which packets the 1785 NAT64 filter allows in and which it does not. The security 1786 properties are determined by the filtering behavior and filtering 1787 configuration in the filtering portions of the NAT64, not by the 1788 address mapping behavior. For example, 1790 Without filtering - When "Endpoint-Independent Filtering" is used 1791 in NAT64, once a binding is created in the IPv6 ---> IPv4 1792 direction, packets from any node on the IPv4 side destined to the 1793 IPv6 transport address will traverse the NAT64 gateway and be 1794 forwarded to the IPv6 transport address that created the binding. 1795 However, 1797 With filtering - When "Endpoint-Independent Filtering" is used in 1798 NAT64, once a binding is created in the IPv6 ---> IPv4 direction, 1799 packets from any node on the IPv4 side destined to the IPv6 1800 transport address will first be processed against the filtering 1801 rules. If the source IPv4 address is permitted, the packets will 1802 be forwarded to the IPv6 transport address. If the source IPv4 1803 address is explicitly denied -- or the default policy is to deny 1804 all addresses not explicitly permitted -- then the packet will be 1805 discarded. A dynamic filter may be employed where by the filter 1806 will only allow packets from the IPv4 address to which the 1807 original packet that created the binding was sent. This means 1808 that only the IPv4 addresses to which the IPv6 host has initiated 1809 connections will be able to reach the IPv6 transport address, and 1810 no others. This essentially narrows the effective operation of 1811 the NAT64 device to an "Address-Dependent Filtering" behavior, 1812 though not by its mapping behavior, but instead by its filtering 1813 behavior. 1815 As currently specified, the NAT64 only requires filtering traffic 1816 based on the 5-tuple. In some cases (e.g., statically configured 1817 mappings), this may make it easy for an attacker to guess. An 1818 attacker need not be able to guess other fields, e.g. the TCP 1819 sequence number, to get a packet through the NAT64. While such 1820 traffic might be dropped by the final destination, it does not 1821 provide additional mitigations against bandwidth/CPU attacks 1822 targeting the internal network. To avoid this type of abuse, a NAT64 1823 MAY keep track of the sequence number of TCP packets in order to 1824 verify that proper sequencing of exchanged segments, in particular, 1825 the SYNs and the FINs. 1827 5.3. Attacks on NAT64 1829 The NAT64 device itself is a potential victim of different types of 1830 attacks. In particular, the NAT64 can be a victim of DoS attacks. 1831 The NAT64 device has a limited number of resources that can be 1832 consumed by attackers creating a DoS attack. The NAT64 has a limited 1833 number of IPv4 addresses that it uses to create the bindings. Even 1834 though the NAT64 performs address and port translation, it is 1835 possible for an attacker to consume all the IPv4 transport addresses 1836 by sending IPv6 packets with different source IPv6 transport 1837 addresses. This attack can only be launched from the IPv6 side, 1838 since IPv4 packets are not used to create binding state. DoS attacks 1839 can also affect other limited resources available in the NAT64 such 1840 as memory or link capacity. For instance, it is possible for an 1841 attacker to launch a DoS attack on the memory of the NAT64 device by 1842 sending fragments that the NAT64 will store for a given period. If 1843 the number of fragments is high enough, the memory of the NAT64 could 1844 be exhausted. NAT64 devices MUST implement proper protection against 1845 such attacks, for instance allocating a limited amount of memory for 1846 fragmented packet storage as specified in Section 3.4. 1848 Another consideration related to NAT64 resource depletion refers to 1849 the preservation of binding state. Attackers may try to keep a 1850 binding state alive forever by sending periodic packets that refresh 1851 the state. In order to allow the NAT64 to defend against such 1852 attacks, the NAT64 MAY choose not to extend the session entry 1853 lifetime for a specific entry upon the reception of packets for that 1854 entry through the external interface. As described in the Framework 1855 document [I-D.ietf-behave-v6v4-framework], the NAT64 can be deployed 1856 in multiple scenarios, some of which the external side is the IPv6 1857 one and some of which the external side is the IPv4 one. It is then 1858 important to properly set which is the external side of the NAT64 in 1859 each specific configuration. 1861 5.4. Avoiding hairpinning loops 1863 If an IPv6-only client can guess the IPv4 binding address that will 1864 be created, it can use the IPv6 representation of it as source 1865 address for creating this binding. Then any packet sent to the 1866 binding's IPv4 address could loop in the NAT64. This is prevented in 1867 the current specification by filtering incoming packets containing 1868 Pref64::/n in the source address as described next. 1870 Consider the following example: 1872 Suppose that the IPv4 pool is 192.0.2.0/24 1874 Then the IPv6-only client sends this to NAT64: 1876 Source: [Pref64::192.0.2.1]:500 1878 Destination: whatever 1880 The NAT64 allocates 192.0.2.1:500 as IPv4 binding address. Now 1881 anything sent to 192.0.2.1:500, be it a hairpinned IPv6 packet or an 1882 IPv4 packet, could loop. 1884 It is not hard to guess the IPv4 address that will be allocated. 1885 First the attacker creates a binding and use (for example) STUN to 1886 learn its external IPv4 address. New bindings will always have this 1887 address. Then it uses a source port in the range 1-1023. This will 1888 increase the chances to 1/512 (since range and parity are preserved 1889 by NAT64 in UDP). 1891 In order to address this vulnerability, the NAT64 MUST drop IPv6 1892 packets whose source address is in Pref64::/n as defined in 1893 Section 3.5. 1895 6. IANA Considerations 1897 This document contains no actions for IANA. 1899 7. Contributors 1901 George Tsirtsis 1903 Qualcomm 1905 tsirtsis@googlemail.com 1907 Greg Lebovitz 1909 Juniper 1911 gregory.ietf@gmail.com 1913 Simon Parreault 1915 Viagenie 1916 simon.perreault@viagenie.ca 1918 8. Acknowledgements 1920 Dave Thaler, Dan Wing, Alberto Garcia-Martinez, Reinaldo Penno, 1921 Ranjana Rao, Lars Eggert, Senthil Sivakumar, Zhen Cao, Xiangsong Cui, 1922 Mohamed Boucadair, Dong Zhang, Bryan Ford, Kentaro Ebisawa, Charles 1923 Perkins and Joao Damas reviewed the document and provided useful 1924 comments to improve it. 1926 The content of the draft was improved thanks to discussions with 1927 Christian Huitema, Fred Baker and Jari Arkko. 1929 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 1930 Trilogy, a research project supported by the European Commission 1931 under its Seventh Framework Program. 1933 9. References 1935 9.1. Normative References 1937 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1938 Requirement Levels", BCP 14, RFC 2119, March 1997. 1940 [RFC1035] Mockapetris, P., "Domain names - implementation and 1941 specification", STD 13, RFC 1035, November 1987. 1943 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1944 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1945 RFC 4787, January 2007. 1947 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1948 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1949 RFC 5382, October 2008. 1951 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1952 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 1953 April 2009. 1955 [I-D.ietf-behave-v6v4-xlate] 1956 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1957 Algorithm", draft-ietf-behave-v6v4-xlate-10 (work in 1958 progress), February 2010. 1960 [I-D.ietf-behave-address-format] 1961 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 1963 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1964 draft-ietf-behave-address-format-04 (work in progress), 1965 January 2010. 1967 9.2. Informative References 1969 [I-D.ietf-behave-dns64] 1970 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 1971 "DNS64: DNS extensions for Network Address Translation 1972 from IPv6 Clients to IPv4 Servers", 1973 draft-ietf-behave-dns64-07 (work in progress), March 2010. 1975 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1976 RFC 793, September 1981. 1978 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1979 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1980 February 2000. 1982 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1983 Considerations for IP Fragment Filtering", RFC 1858, 1984 October 1995. 1986 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1987 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1989 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1990 Address Translator (Traditional NAT)", RFC 3022, 1991 January 2001. 1993 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 1994 Address Translator - Protocol Translator (NAT-PT) to 1995 Historic Status", RFC 4966, July 2007. 1997 [I-D.ietf-mmusic-ice] 1998 Rosenberg, J., "Interactive Connectivity Establishment 1999 (ICE): A Protocol for Network Address Translator (NAT) 2000 Traversal for Offer/Answer Protocols", 2001 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 2003 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2004 Errors at High Data Rates", RFC 4963, July 2007. 2006 [I-D.ietf-behave-v6v4-framework] 2007 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 2008 IPv4/IPv6 Translation", 2009 draft-ietf-behave-v6v4-framework-07 (work in progress), 2010 February 2010. 2012 [I-D.penno-behave-64-analysis] 2013 Penno, R., Saxena, T., and D. Wing, "Analysis of 64 2014 Translation", draft-penno-behave-64-analysis-03 (work in 2015 progress), February 2010. 2017 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 2018 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 2019 RFC 3948, January 2005. 2021 Authors' Addresses 2023 Marcelo Bagnulo 2024 UC3M 2025 Av. Universidad 30 2026 Leganes, Madrid 28911 2027 Spain 2029 Phone: +34-91-6249500 2030 Fax: 2031 Email: marcelo@it.uc3m.es 2032 URI: http://www.it.uc3m.es/marcelo 2034 Philip Matthews 2035 Alcatel-Lucent 2036 600 March Road 2037 Ottawa, Ontario 2038 Canada 2040 Phone: +1 613-592-4343 x224 2041 Fax: 2042 Email: philip_matthews@magma.ca 2043 URI: 2045 Iljitsch van Beijnum 2046 IMDEA Networks 2047 Avda. del Mar Mediterraneo, 22 2048 Leganes, Madrid 28918 2049 Spain 2051 Email: iljitsch@muada.com