idnits 2.17.1 draft-ietf-behave-v6v4-xlate-stateful-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (October 10, 2009) is 5311 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: 'RFC2671' is defined on line 1703, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 1710, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-ice' is defined on line 1775, but no explicit reference was found in the text == Unused Reference: 'RFC3498' is defined on line 1781, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-00 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-01 == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-00 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- 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-01 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 5 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: April 13, 2010 Alcatel-Lucent 6 I. van Beijnum 7 IMDEA Networks 8 October 10, 2009 10 NAT64: Network Address and Protocol Translation from IPv6 Clients to 11 IPv4 Servers 12 draft-ietf-behave-v6v4-xlate-stateful-02 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on April 13, 2010. 47 Copyright Notice 48 Copyright (c) 2009 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 in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and 60 vice-versa. DNS64 is a mechanism for synthesizing AAAA records from 61 A records. These two mechanisms together enable client-server 62 communication between an IPv6-only client and an IPv4-only server, 63 without requiring any changes to either the IPv6 or the IPv4 node, 64 for the class of applications that work through NATs. They also 65 enable peer-to-peer communication between an IPv4 and an IPv6 node, 66 where the communication can be initiated by either end using 67 existing, NAT-traversing, peer-to-peer communication techniques. 68 This document specifies NAT64, and gives suggestions on how they 69 should be deployed. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Features of NAT64 . . . . . . . . . . . . . . . . . . . . 5 75 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.2.1. NAT64 solution elements . . . . . . . . . . . . . . . 6 77 1.2.2. Walkthrough . . . . . . . . . . . . . . . . . . . . . 7 78 1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 10 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3. NAT64 Normative Specification . . . . . . . . . . . . . . . . 12 81 3.1. Determining the Incoming tuple . . . . . . . . . . . . . . 14 82 3.2. Filtering and Updating Binding and Session Information . . 15 83 3.2.1. UDP Session Handling . . . . . . . . . . . . . . . . . 16 84 3.2.2. TCP Session Handling . . . . . . . . . . . . . . . . . 17 85 3.2.3. Rules for allocation of IPv4 transport addresses . . . 22 86 3.2.4. ICMP Query Session Handling . . . . . . . . . . . . . 22 87 3.2.5. Generation of the IPv6 representations of IPv4 88 addresses . . . . . . . . . . . . . . . . . . . . . . 24 89 4. Computing the Outgoing Tuple . . . . . . . . . . . . . . . . . 25 90 4.1. Computing the outgoing 5-tuple for TCP, UDP and ICMP 91 error messages . . . . . . . . . . . . . . . . . . . . . . 26 92 4.2. Computing the outgoing 3-tuple for ICMP Query messages . . 27 93 5. Translating the Packet . . . . . . . . . . . . . . . . . . . . 27 94 6. Handling Hairpinning . . . . . . . . . . . . . . . . . . . . . 28 95 7. Path MTU discovery and fragmentation . . . . . . . . . . . . . 28 96 7.1. Translating whole packets and PMTUD . . . . . . . . . . . 29 97 7.1.1. IPv6-to-IPv4 translation . . . . . . . . . . . . . . . 29 98 7.1.2. IPv4-to-IPv6 . . . . . . . . . . . . . . . . . . . . . 30 99 7.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 31 100 7.2.1. IPv4-to-IPv6 . . . . . . . . . . . . . . . . . . . . . 31 101 7.2.2. IPv6-to-IPv4 . . . . . . . . . . . . . . . . . . . . . 32 102 7.3. TCP MSS option . . . . . . . . . . . . . . . . . . . . . . 33 103 8. Application scenarios . . . . . . . . . . . . . . . . . . . . 33 104 8.1. Scenario 1: an IPv6 network to the IPv4 Internet . . . . . 33 105 8.2. Scenario 3: the IPv6 Internet to an IPv4 network . . . . . 34 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 108 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 109 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 110 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 111 13.1. Normative References . . . . . . . . . . . . . . . . . . . 37 112 13.2. Informative References . . . . . . . . . . . . . . . . . . 38 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 115 1. Introduction 117 This document specifies NAT64, a mechanism for IPv6-IPv4 transition 118 and co-existence. Together with DNS64 [I-D.ietf-behave-dns64], these 119 two mechanisms allow a IPv6-only client to initiate communications to 120 an IPv4-only server, and also allow peer-to-peer communication 121 between IPv6-only and IPv4-only hosts. 123 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and 124 vice-versa. The translation is done by translating the packet 125 headers according to IP/ICMP Translation Algorithm 126 [I-D.ietf-behave-v6v4-xlate], translating the IPv4 server address by 127 adding or removing an IPv6 prefix, and translating the IPv6 client 128 address by installing mappings in the normal NAT manner. 130 DNS64 is a mechanism for synthesizing AAAA resource records (RR) from 131 A RR. The synthesis is done by adding a IPv6 prefix to the IPv4 132 address to create an IPv6 address, where the IPv6 prefix is assigned 133 to a NAT64 device. 135 Together, these two mechanisms allow a IPv6-only client to initiate 136 communications to an IPv4-only server. 138 These mechanisms are expected to play a critical role in the IPv4- 139 IPv6 transition and co-existence. Due to IPv4 address depletion, 140 it's likely that in the future, a lot of IPv6-only clients will want 141 to connect to IPv4-only servers. The NAT64 and DNS64 mechanisms are 142 easily deployable, since they require no changes to either the IPv6 143 client nor the IPv4 server. For basic functionality, the approach 144 only requires the deployment of NAT64 function in the devices 145 connecting an IPv6-only network to the IPv4-only network, along with 146 the deployment of a few DNS64-enabled name servers in the IPv6-only 147 network. However, some advanced features such as support for DNSSEC 148 validating stub resolvers or support for some IPsec modes, require 149 software updates to the IPv6-only hosts. 151 The NAT64 and DNS64 mechanisms are related to the NAT-PT mechanism 152 defined in [RFC2766], but significant differences exist. First, 153 NAT64 does not define the NATPT mechanisms used to support IPv6 only 154 servers to be contacted by IPv4 only clients, but only defines the 155 mechanisms for IPv6 clients to contact IPv4 servers and its potential 156 reuse to support peer to peer communications through standard NAT 157 traversal techniques. Second, NAT64 includes a set of features that 158 overcomes many of the reasons the original NAT-PT specification was 159 moved to historic status [RFC4966]. 161 1.1. Features of NAT64 163 The features of NAT64 and DNS64 are: 165 o It enables IPv6-only nodes to initiate a client-server connection 166 with an IPv4-only server, without needing any changes on either 167 IPv4 or IPv6 nodes. This works for roughly the same class of 168 applications that work through IPv4-to-IPv4 NATs. 170 o It supports peer-to-peer communication between IPv4 and IPv6 171 nodes, including the ability for IPv4 nodes to initiate 172 communication with IPv6 nodes using peer-to-peer techniques (i.e., 173 using a rendezvous server and ICE). To this end, NAT64 is 174 compliant with the recommendations for how NATs should handle UDP 175 [RFC4787], TCP [RFC4787], and ICMP [RFC5508]. 177 o Compatible with ICE. 179 o Supports additional features with some changes on nodes. These 180 features include: 182 * Support for DNSSEC 184 * Some forms of IPsec support 186 1.2. Overview 188 This section provides a non-normative introduction to the mechanisms 189 of NAT64. 191 NAT64 mechanism is implemented in an NAT64 box which has two 192 interfaces, an IPv4 interface connected to the the IPv4 network, and 193 an IPv6 interface connected to the IPv6 network. Packets generated 194 in the IPv6 network for a receiver located in the IPv4 network will 195 be routed within the IPv6 network towards the NAT64 box. The NAT64 196 box will translate them and forward them as IPv4 packets through the 197 IPv4 network to the IPv4 receiver. The reverse takes place for 198 packets generated in the IPv4 network for an IPv6 receiver. NAT64, 199 however, is not symmetric. In order to be able to perform IPv6 - 200 IPv4 translation NAT64 requires state, binding an IPv6 address and 201 port (hereafter called an IPv6 transport address) to an IPv4 address 202 and port (hereafter called an IPv4 transport address). 204 Such binding state is created when the first packet flowing from the 205 IPv6 network to the IPv4 network is translated. After the binding 206 state has been created, packets flowing in either direction on that 207 particular flow are translated. The result is that NAT64 only 208 supports communications initiated by the IPv6-only node towards an 209 IPv4-only node. Some additional mechanisms, like ICE, can be used in 210 combination with NAT64 to provide support for communications 211 initiated by the IPv4-only node to the IPv6-only node. The 212 specification of such mechanisms, however, is out of the scope of 213 this document. 215 1.2.1. NAT64 solution elements 217 In this section we describe the different elements involved in the 218 NAT64 approach. 220 The main component of the proposed solution is the translator itself. 221 The translator has essentially two main parts, the address 222 translation mechanism and the protocol translation mechanism. 224 Protocol translation from IPv4 packet header to IPv6 packet header 225 and vice-versa is performed according to IP/ICMP Translation 226 Algorithm [I-D.ietf-behave-v6v4-xlate]. 228 Address translation maps IPv6 transport addresses to IPv4 transport 229 addresses and vice-versa. In order to create these mappings the 230 NAT64 box has two pools of addresses i.e. an IPv6 address pool (to 231 represent IPv4 addresses in the IPv6 network) and an IPv4 address 232 pool (to represent IPv6 addresses in the IPv4 network). Since there 233 is enough IPv6 address space, it is possible to map every IPv4 234 address into a different IPv6 address. 236 NAT64 creates the required mappings by using as the IPv6 address pool 237 an IPv6 IPv6 prefix (hereafter called Pref64::/n). This allows each 238 IPv4 address to be mapped into a different IPv6 address by simply 239 concatenating the Pref64::/n prefix assigned as the IPv6 address pool 240 of the NAT64, with the IPv4 address being mapped and a suffix (i.e. 241 an IPv4 address X is mapped into the IPv6 address Pref64:X:SUFFIX). 242 The NAT64 prefix Pref64::/n is assigned by the administrator of the 243 NAT64 box from the global unicast IPv6 address block assigned to the 244 site. 246 The IPv4 address pool is a set of IPv4 addresses, normally a small 247 prefix assigned by the local administrator. Since IPv4 address space 248 is a scarce resource, the IPv4 address pool is small and typically 249 not sufficient to establish permanent one-to-one mappings with IPv6 250 addresses. So, mappings using the IPv4 address pool will be created 251 and released dynamically. Moreover, because of the IPv4 address 252 scarcity, the usual practice for NAT64 is likely to be the mapping of 253 IPv6 transport addresses into IPv4 transport addresses, instead of 254 IPv6 addresses into IPv4 addresses directly, which enable a higher 255 utilization of the limited IPv4 address pool. 257 Because of the dynamic nature of the IPv6 to IPv4 address mapping and 258 the static nature of the IPv4 to IPv6 address mapping, it is easy to 259 understand that it is far simpler to allow communication initiated 260 from the IPv6 side toward an IPv4 node, which address is permanently 261 mapped into an IPv6 address, than communications initiated from IPv4- 262 only nodes to an IPv6 node in which case IPv4 address needs to be 263 associated with it dynamically. For this reason NAT64 supports only 264 communications initiated from the IPv6 side. 266 An IPv6 initiator can know or derive in advance the IPv6 address 267 representing the IPv4 target and send packets to that address. The 268 packets are intercepted by the NAT64 device, which associates an IPv4 269 transport address of its IPv4 pool to the IPv6 transport address of 270 the initiator, creating binding state, so that reply packets can be 271 translated and forwarded back to the initiator. The binding state is 272 kept while packets are flowing. Once the flow stops, and based on a 273 timer, the IPv4 transport address is returned to the IPv4 address 274 pool so that it can be reused for other communications. 276 To allow an IPv6 initiator to do the standard DNS lookup to learn the 277 address of the responder, DNS64 [I-D.ietf-behave-dns64] is used to 278 synthesize an AAAA RR from the A RR (containing the real IPv4 address 279 of the responder). DNS64 receives the DNS queries generated by the 280 IPv6 initiator. If there is no AAAA record available for the target 281 node (which is the normal case when the target node is an IPv4-only 282 node), DNS64 performs a query for the A record. If an A record is 283 discovered, DNS64 creates a synthetic AAAA RR that includes the IPv6 284 representations of the IPv4 address created by concatenating the 285 Pref64::/n of a NAT64 to the responder's IPv4 address and a suffix 286 (i.e. if the IPv4 node has IPv4 address X, then the synthetic AAAA RR 287 will contain the IPv6 address formed as Pref64:X:SUFFIX). The 288 synthetic AAAA RR is passed back to the IPv6 initiator, which will 289 initiate an IPv6 communication with the IPv6 address associated to 290 the IPv4 receiver. The packet will be routed to the NAT64 device, 291 which will create the IPv6 to IPv4 address mapping as described 292 before. 294 1.2.2. Walkthrough 296 In this example, we consider an IPv6 node located in a IPv6-only site 297 that initiates a communication to a IPv4 node located in the IPv4 298 network. 300 The notation used is the following: upper case letters are IPv4 301 addresses; upper case letters with a prime(') are IPv6 addresses; 302 lower case letters are ports; prefixes are indicated by "P::X", which 303 is a IPv6 address built from an IPv4 address X by adding the prefix 304 P, mappings are indicated as "(X,x) <--> (Y',y)". 306 The scenario for this case is depicted in the following figure: 308 +---------------------------------------+ +---------------+ 309 |IPv6 network +-------------+ | | | 310 | +----+ | Name server | +-------+ | IPv4 | 311 | | H1 | | with DNS64 | | NAT64 |----| Network | 312 | +----+ +-------------+ +-------+ | | 313 | |IP addr: Y' | | | | IP addr: X | 314 | --------------------------------- | | +----+ | 315 +---------------------------------------+ | | H2 | | 316 | +----+ | 317 +---------------+ 319 The figure shows a IPv6 node H1 which has an IPv6 address Y' and an 320 IPv4 node H2 with IPv4 address X. 322 A NAT64 connects the IPv6 network to the IPv4 network. This NAT64 323 has a /n prefix (called Pref64::/n) that it uses to represent IPv4 324 addresses in the IPv6 address space and an IPv4 address T assigned to 325 its IPv4 interface. the routing is configured in such a way, that the 326 IPv6 packets addressed to a destination address containing Pref64::/n 327 are routed to the IPv6 interface of the NAT64 box. 329 Also shown is a local name server with DNS64 functionality. The 330 local name server needs to know the /n prefix assigned to the local 331 NAT64 (Pref64::/n). For the purpose of this example, we assume it 332 learns this through manual configuration. 334 For this example, assume the typical DNS situation where IPv6 hosts 335 have only stub resolvers and the local name server does the recursive 336 lookups. 338 The steps by which H1 establishes communication with H2 are: 340 1. H1 performs a DNS query for FQDN(H2) and receives the synthetic 341 AAAA RR from the local name server that implements the DNS64 342 functionality. The AAAA record contains an IPv6 address formed 343 by the Pref64::/n associated to the NAT64 box and the IPv4 344 address of H2 and a suffix. 346 2. H1 sends a packet to H2. The packet is sent from a source 347 transport address of (Y',y) to a destination transport address of 348 (Pref64:X:SUFFIX,x), where y and x are ports set by H1. 350 3. The packet is routed to the IPv6 interface of the NAT64 (since 351 the IPv6 routing is configured that way). 353 4. The NAT64 receives the packet and performs the following actions: 355 * The NAT64 selects an unused port t on its IPv4 address T and 356 creates the mapping entry (Y',y) <--> (T,t) 358 * The NAT64 translates the IPv6 header into an IPv4 header using 359 IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]. 361 * The NAT64 includes (T,t) as source transport address in the 362 packet and (X,x) as destination transport address in the 363 packet. Note that X is extracted directly from the 364 destination IPv6 address of the received IPv6 packet that is 365 being translated. 367 5. The NAT64 sends the translated packet out its IPv4 interface and 368 the packet arrives at H2. 370 6. H2 node responds by sending a packet with destination transport 371 address (T,t) and source transport address (X,x). 373 7. The packet is routed to the NAT64 box, which will look for an 374 existing mapping containing (T,t). Since the mapping (Y',y) <--> 375 (T,t) exists, the NAT64 performs the following operations: 377 * The NAT64 translates the IPv4 header into an IPv6 header using 378 IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]. 380 * The NAT64 includes (Y',y) as destination transport address in 381 the packet and (Pref64:X:SUFFIX,x) as source transport address 382 in the packet. Note that X is extracted directly from the 383 source IPv4 address of the received IPv4 packet that is being 384 translated. 386 8. The translated packet is sent out the IPv6 interface to H1. 388 The packet exchange between H1 and H2 continues and packets are 389 translated in the different directions as previously described. 391 It is important to note that the translation still works if the IPv6 392 initiator H1 learns the IPv6 representation of H2's IPv4 address 393 (i.e. Pref64:X:SUFFIX) through some scheme other than a DNS look-up. 394 This is because the DNS64 processing does NOT result in any state 395 installed in the NAT64 box and because the mapping of the IPv4 396 address into an IPv6 address is the result of concatenating the 397 prefix defined within the site for this purpose (called Pref64::/n in 398 this document) to the original IPv4 address and a suffix. 400 1.2.3. Filtering 402 A NAT64 box may do filtering, which means that it only allows a 403 packet in through an interface if the appropriate permission exists. 404 A NAT64 may do no filtering, or it may filter on its IPv4 interface. 405 Filtering on the IPv6 interface is not supported, as mappings are 406 only created by packets traveling in the IPv6 --> IPv4 direction. 408 If a NAT64 performs address-dependent filtering according to RFC4787 409 [RFC4787] on its IPv4 interface, then an incoming packet is dropped 410 unless a packet has been recently sent out the interface with a 411 source transport address equal to the destination transport address 412 of the incoming packet and destination IP address equal to the source 413 IP address of the incoming packet. 415 NAT64 filtering is consistent with the recommendations of RFC 4787 416 [RFC4787], and the ones of RFC 5382 [RFC5382] 418 2. Terminology 420 This section provides a definitive reference for all the terms used 421 in document. 423 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 424 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 425 document are to be interpreted as described in RFC 2119 [RFC2119]. 427 The following terms are used in this document: 429 3-Tuple: The tuple (source IP address, destination IP address, Query 430 Identifier). A 3-tuple uniquely identifies an ICMP Query session. 431 When an ICMP Query session flows through a NAT64, each session has 432 two different 3-tuples: one with IPv4 addresses and one with IPv6 433 addresses. 435 5-Tuple: The tuple (source IP address, source port, destination IP 436 address, destination port, transport protocol). A 5-tuple 437 uniquely identifies a UDP/TCP session. When a UDP/TCP session 438 flows through a NAT64, each session has two different 5-tuples: 439 one with IPv4 addresses and one with IPv6 addresses. 441 BIB: Binding Information Base. A table of mappings kept by a NAT64. 442 Each NAT64 has three BIBs, one for TCP, one for UDP and one for 443 ICMP Queries. 445 DNS64: A logical function that synthesizes AAAA Resource Records 446 (containing IPv6 addresses) from A Resource Records (containing 447 IPv4 addresses). 449 Endpoint-Independent Mapping: In NAT64, using the same mapping for 450 all the sessions involving a given IPv6 transport address of an 451 IPv6 host (irrespectively of the transport address of the IPv4 452 host involved in the communication). Endpoint-independent mapping 453 is important for peer-to-peer communication. See [RFC4787] for 454 the definition of the different types of mappings in IPv4-to-IPv4 455 NATs. 457 Hairpinning: Having a packet do a "U-turn" inside a NAT and come 458 back out the same interface as it arrived on. Hairpinning support 459 is important for peer-to-peer applications, as there are cases 460 when two different hosts on the same side of a NAT can only 461 communicate using sessions that hairpin though the NAT. 463 Mapping: A mapping between an IPv6 transport address and a IPv4 464 transport address. Used to translate the addresses and ports of 465 packets flowing between the IPv6 host and the IPv4 host. In 466 NAT64, the IPv4 transport address is always a transport address 467 assigned to the NAT64 itself, while the IPv6 transport address 468 belongs to some IPv6 host. 470 NAT64: A device that translates IPv6 packets to IPv4 packets and 471 vice-versa, with the provision that the communication must be 472 initiated from the IPv6 side. The translation involves not only 473 the IP header, but also the transport header (TCP or UDP). 475 Session: A TCP, UDP or ICMP Query session. In other words, the bi- 476 directional flow of packets between two ports on two different 477 hosts. In NAT64, typically one host is an IPv4 host, and the 478 other one is an IPv6 host. 480 Session table: A table of sessions kept by a NAT64. Each NAT64 has 481 three session tables, one for TCP, one for UDP and one for ICMP 482 Queries. 484 Synthetic RR: A DNS Resource Record (RR) that is not contained in 485 any zone data file, but has been synthesized from other RRs. An 486 example is a synthetic AAAA record created from an A record. 488 Transport Address: The combination of an IPv6 or IPv4 address and a 489 port. Typically written as (IP address, port); e.g. (192.0.2.15, 490 8001). 492 Tuple: Refers to either a 3-Tuple or a 5-tuple as defined above. 494 For a detailed understanding of this document, the reader should also 495 be familiar with DNS terminology [RFC1035] and current NAT 496 terminology [RFC4787]. 498 3. NAT64 Normative Specification 500 A NAT64 is a device with at least one IPv6 interface and at least one 501 IPv4 interface. Each NAT64 device MUST have one unicast /n IPv6 502 prefix assigned to it, denoted Pref64::/n. Additional consideration 503 about the Pref64::/n are presented in Section 3.2.5. Each NAT64 box 504 MUST have one or more unicast IPv4 addresses assigned to it. 506 A NAT64 uses the following dynamic data structures: 508 o UDP Binding Information Base 510 o UDP Session Table 512 o TCP Binding Information Base 514 o TCP Session Table 516 o ICMP Query Binding Information Base 518 o ICMP Query Session Table 520 A NAT64 has three Binding Information Bases (BIBs): one for TCP, one 521 for UDP and one for ICMP Queries. In the case of UDP and TCP BIBs, 522 each BIB entry specifies a mapping between an IPv6 transport address 523 and an IPv4 transport address: 525 (X',x) <--> (T,t) 527 where X' is some IPv6 address, T is an IPv4 address, and x and t are 528 ports. T will always be one of the IPv4 addresses assigned to the 529 NAT64. A given IPv6 or IPv4 transport address can appear in at most 530 one entry in a BIB: for example, (2001:db8::17, 4) can appear in at 531 most one TCP and at most one UDP BIB entry. TCP and UDP have 532 separate BIBs because the port number space for TCP and UDP are 533 distinct. 535 In the case of the ICMP Query BIB, each ICMP Query BIB entry specify 536 a mapping between an (IPv6 address, Query Identifier) pair and an 537 (IPv4 address, Query Identifier pair). 539 (X',I1) <--> (T,I2) 541 where X' is some IPv6 address, T is an IPv4 address, and I1 and I2 542 are Query Identifiers. T will always be one of the IPv4 addresses 543 assigned to the NAT64. A given (IPv6 or IPv4 address, Query Id) pair 544 can appear in at most one entry in the ICMP Query BIB. 546 Entries in any of the three BIBs can be created dynamically as the 547 result of the flow of packets as described in the section Section 3.2 548 but the can also can be created manually by the system administrator. 549 NAT64 implementations SHOULD support manually configured BIB entries 550 for any of the three BIBs. Dynamically-created entries are deleted 551 from the corresponding BIB when the last session associated to the 552 BIB entry is removed from the session table. Manually-configured BIB 553 entries are not deleted when there is no corresponding session table 554 entry and can only be deleted by the administrator. 556 A NAT64 also has three session tables: one for TCP sessions, one for 557 UDP sessions and one for ICMP Query sessions. Each entry keeps 558 information on the state of the corresponding session. In the TCP 559 and UDP session tables, each entry specifies a mapping between a pair 560 of IPv6 transport address and a pair of IPv4 transport address: 562 (X',x),(Y',y) <--> (T,t),(Z,z) 564 where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and 565 x, y, z and t are ports. T will always be one of the IPv4 addresses 566 assigned to the NAT64. Y' is always the IPv6 representation of the 567 IPv4 address Z, so Y' is obtained from Z using the algorithm applied 568 by the NAT64 to create IPv6 representations of IPv4 addresses. y is 569 always equal to z. In addition, each session table entry has a 570 lifetime. 572 In the ICMP query session table, each entry specifies a mapping 573 between a 3-tuple of IPv6 source address, IPv6 destination address 574 and ICMPv6 Query Id and a 3-tuple of IPv4 source address, IPv4 575 destination address and ICMPv4 Query Id: 577 (X',Y',I1) <--> (T,Z,I2) 579 where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and 580 I1 and I2 are ICMP query Ids. T will always be one of the IPv4 581 addresses assigned to the NAT64. Y' is always the IPv6 582 representation of the IPv4 address Z, so Y' is obtained from Z using 583 the algorithm applied by the NAT64 to create IPv6 representations of 584 IPv4 addresses. In addition, each session table entry has a 585 lifetime. 587 The NAT64 uses the session state information to determine when the 588 session is completed, and also uses session information for ingress 589 filtering. A session can be uniquely identified by either an 590 incoming tuple or an outgoing tuple. 592 For each session, there is a corresponding BIB entry, uniquely 593 specified by either the source IPv6 transport address or the source 594 IPv6 address and ICMPv6 Query Id (in the IPv6 --> IPv4 direction) or 595 the destination IPv4 transport address or the destination IPv4 596 address and the ICMPv4 Query Id (in the IPv4 --> IPv6 direction). 597 However, a single BIB entry can have multiple corresponding sessions. 598 When the last corresponding session is deleted, if the BIB entry was 599 dynamically created, the BIB entry is deleted. 601 The processing of an incoming IP packet takes the following steps: 603 1. Determining the incoming tuple 605 2. Filtering and updating binding and session information 607 3. Computing the outgoing tuple 609 4. Translating the packet 611 5. Handling hairpinning 613 The details of these steps are specified in the following 614 subsections. 616 This breakdown of the NAT64 behavior into processing steps is done 617 for ease of presentation. A NAT64 MAY perform the steps in a 618 different order, or MAY perform different steps, as long as the 619 externally visible outcome is the same. 621 3.1. Determining the Incoming tuple 623 This step associates a incoming tuple with every incoming IP packet 624 for use in subsequent steps. In the case of TCP, UDP and ICMP error 625 packets, the tuple is a 5-tuple consisting of source IP address, 626 source port, destination IP address, destination port, transport 627 protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting 628 of the source IP address, destination IP address and Query 629 Identifier. 631 If the incoming IP packet contains a complete (un-fragmented) UDP or 632 TCP protocol packet, then the 5-tuple is computed by extracting the 633 appropriate fields from the packet. 635 If the incoming packet is an ICMP query message (i.e. an ICMPv4 Query 636 message or an ICMPv6 Informational message), the 3-tuple is the 637 source IP address. the destination IP address and the ICMP Query 638 Identifier. 640 If the incoming IP packet contains a complete (un-fragmented) ICMP 641 error message, then the 5-tuple is computed by extracting the 642 appropriate fields from the IP packet embedded inside the ICMP error 643 message. However, the role of source and destination is swapped when 644 doing this: the embedded source IP address becomes the destination IP 645 address in the 5-tuple, the embedded source port becomes the 646 destination port in the 5-tuple, etc. If it is not possible to 647 determine the 5-tuple (perhaps because not enough of the embedded 648 packet is reproduced inside the ICMP message), then the incoming IP 649 packet is silently discarded. 651 NOTE: The transport protocol is always one of TCP or UDP, even if 652 the IP packet contains an ICMP Error message. 654 If the incoming IP packet contains a fragment, then more processing 655 may be needed. This specification leaves open the exact details of 656 how a NAT64 handles incoming IP packets containing fragments, and 657 simply requires that a NAT64 handle fragments arriving out-of-order. 658 A NAT64 MAY elect to queue the fragments as they arrive and translate 659 all fragments at the same time. Alternatively, a NAT64 MAY translate 660 the fragments as they arrive, by storing information that allows it 661 to compute the 5-tuple for fragments other than the first. In the 662 latter case, the NAT64 will still need to handle the situation where 663 subsequent fragments arrive before the first. 665 Implementors of NAT64 should be aware that there are a number of 666 well-known attacks against IP fragmentation; see [RFC1858] and 667 [RFC3128]. 669 Assuming it otherwise has sufficient resources, a NAT64 MUST allow 670 the fragments to arrive over a time interval of at least 10 seconds. 671 A NAT64 MAY require that the UDP, TCP, or ICMP header be completely 672 contained within the first fragment. 674 3.2. Filtering and Updating Binding and Session Information 676 This step updates binding and session information stored in the 677 appropriate tables. This step may also filter incoming packets, if 678 desired. 680 The details of this step depend on the protocol (UDP TCP or ICMP 681 Query). 683 3.2.1. UDP Session Handling 685 The state information stored for a UDP session in the UDP session 686 table includes a timer that tracks the remaining lifetime of the UDP 687 session. The NAT64 decrements this timer at regular intervals. When 688 the timer expires, the UDP session is deleted. If all the UDP 689 sessions corresponding to a UDP BIB entry are deleted, then the UDP 690 BIB entry is also deleted (only applies to the case of dynamically 691 created entries). 693 An IPv6 incoming packet is processed as follows: 695 The NAT64 searches for a UDP BIB entry that matches the IPv6 696 source transport address. If such entry does not exists, a new 697 entry is created. As IPv6 address, the source IPv6 transport 698 address of the packet is included and an IPv4 transport address 699 allocated using the rules defined in Section 3.2.3 is included as 700 IPv4 address. 702 The NAT64 searches for the session table entry corresponding to 703 the incoming 5-tuple. If no such entry is found, a new entry is 704 created. The information included in the session table is as 705 follows: the IPv6 transport source and destination addresses 706 contained in the received IPv6 packet, the IPv4 transport source 707 address is extracted from the corresponding UDP BIB entry and the 708 IPv4 transport destination address contains the same port as the 709 IPv6 destination transport address and the IPv4 address that is 710 algorithmically generated from the IPv6 destination address using 711 the reverse algorithm as specified in Section 3.2.5. 713 The NAT64 sets or resets the timer in the session table entry to 714 maximum session lifetime. By default, the maximum session 715 lifetime is 5 minutes, but for specific destination ports in the 716 Well-Known port range (0..1023), the NAT64 MAY use a smaller 717 maximum lifetime. The packet is translated and forwarded as 718 described in the following sections. 720 An IPv4 incoming packet is processed as follows: 722 The NAT64 searches for a UDP BIB entry that matches the IPv4 723 destination transport address. If such entry does not exists, the 724 packet is dropped. An ICMP message MAY be sent to the original 725 sender of the packet, unless the discarded packet is itself an 726 ICMP message. The ICMP message, if sent, has a type of 3 727 (Destination Unreachable). 729 If the NAT64 filters on its IPv4 interface, then the NAT64 checks 730 to see if the incoming packet is allowed according to the address- 731 dependent filtering rule. To do this, it searches for a session 732 table entry with a source IPv4 transport address equal to the 733 destination IPv4 transport address in the incoming 5-tuple and 734 destination IPv4 address (in the session table entry) equal to the 735 source IPv4 address in the incoming 5-tuple. If such an entry is 736 found (there may be more than one), packet processing continues. 737 Otherwise, the packet is discarded. If the packet is discarded, 738 then an ICMP message MAY be sent to the original sender of the 739 packet, unless the discarded packet is itself an ICMP message. 740 The ICMP message, if sent, has a type of 3 (Destination 741 Unreachable) and a code of 13 (Communication Administratively 742 Prohibited). 744 The NAT64 searches for the session table entry corresponding to 745 the incoming 5-tuple. If no such entry is found, a new entry is 746 created. The UDP session table entry contains the transport 747 source and destination address contained in the IPv4 packet and 748 the source IPv6 transport address (in the IPv6 --> IPv4 direction) 749 contained in the existing UDP BIB entry. The destination IPv6 750 transport address contains the same port than the destination IPv4 751 transport address and the IPv6 representation of the IPv4 address 752 of the destination IPv4 transport address, generated using the 753 algorithm described in Section 3.2.5. 755 The NAT64 sets or resets the timer in the session table entry to 756 maximum session lifetime. By default, the maximum session 757 lifetime is 5 minutes, but for specific destination ports in the 758 Well-Known port range (0..1023), the NAT64 MAY use a smaller 759 maximum lifetime. 761 3.2.2. TCP Session Handling 763 The state information stored for a TCP session: 765 Binding:(X',x),(Y',y) <--> (T,t),(Z,z) 767 Lifetime: is a timer that tracks the remaining lifetime of the UDP 768 session. The NAT64 decrements this timer at regular intervals. 769 When the timer expires, the TCP session is deleted. If all the 770 TCP sessions corresponding to a TCP BIB entry are deleted, then 771 the TCP BIB entry is also deleted (only applies to the case of 772 dynamically created entries). 774 TCP sessions are expensive, because their inactivity lifetime is set 775 to 2 hours and 4 min (as per [RFC5382]), so it is important that each 776 TCP session table entry corresponds to an existent TCP session. In 777 order to do that, the NAT64 tracks the TCP connection procedure. In 778 this section we describe how the NAT64 does that tracking by 779 describing the state machine. 781 Temporarily the NAT64 TCP tracking state machine is depicted in 782 http:/www.it.uc3m.es/~marcelo/nat64_state_machine.pdf. Once it is 783 stable, we will include in the draft in ASCII art format. 785 The states are the following ones: 787 CLOSED 789 V4 SYN RCV 791 V6 SYN RCV 793 ESTABLISHED 795 V4 FIN RCV 797 V6 FIN RCV 799 V6 FIN + V4 FIN RCV 801 RST RCV 803 After bootstrapping of the NAT64 device, all TCP session are in 804 CLOSED state. We next describe the state information and the 805 transitions. 807 A TCP segment with the SYN flag set that is received through the IPv6 808 interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 809 FIN + V4 FIN, V6 RST and V4 RST. 811 *** CLOSED *** 813 If a V6 SYN is received, the processing is as follows: 815 The state of the session is moved to V6 SYN RCV. 817 The NAT64 searches for a TCP BIB entry that matches the IPv6 818 source transport address. 820 If such entry does not exists, a new entry is created. As IPv6 821 address, the source IPv6 transport address of the packet is 822 included and an IPv4 transport address allocated using the 823 rules defined in Section 3.2.3 is included as the IPv4 824 transport address. 826 Then a new TCP session entry is created in the TCP session table. 827 The information included in the session table is as follows: 829 The IPv6 transport source and destination addresses contained 830 in the received V6 SYN packet, 832 The IPv4 transport source address is extracted from the 833 corresponding TCP BIB entry and, 835 the IPv4 transport destination address contains the same port 836 as the IPv6 destination transport address and the IPv4 address 837 that is algorithmically generated from the IPv6 destination 838 address using the reverse algorithm as specified in 839 Section 3.2.5. 841 The lifetime of the TCP session table entry is set to 4 min 842 (the transitory connection idle timeout as defined in 843 [RFC5382]). 845 The packet is translated and forwarded. 847 If a V4 SYN packet is received, the processing is as follows: 849 If the security policy requires silently dropping externally 850 initiated TCP connections, then the packet is silently discarded, 851 else, 853 If the destination transport address contained in the incoming V4 854 SYN is not in use in the TCP BIB, then the packet is discarded and 855 an ICMP Port Unreachable error (Type 3, Code 3) is sent back to 856 the source of the v4 SYN. The state remains unchanged in CLOSED 858 If the destination transport address contained in the incoming V4 859 SYN is in use in the TCP BIB, then 861 The state is moved to V4 SYN RCV. 863 A new session table entry is created in the TCP session table, 864 containing the following information: 866 The transport source and destination address contained in 867 the V4 SYN and, 869 The source IPv6 transport address (in the IPv6 --> IPv4 870 direction) contained in the existing TCP BIB entry. 872 The destination IPv6 transport address contains the same 873 port than the destination IPv4 transport address and the 874 IPv6 representation of the IPv4 address of the destination 875 IPv4 transport address, generated using the algorithm 876 described in Section 3.2.5. 878 The lifetime of the entry is set to 6 seconds as per 879 [RFC5382]. 881 The packet is discarded. 883 For any other IPv6 packet, depending on the security policy other 884 packets MAY be forwarded or MAY be silently discarded. In any case, 885 the state remains unchanged. 887 For any other IPv4 packet, 889 If the destination transport address contained in the incoming 890 IPv4 packet is in use in the TCP BIB depending on the security 891 policy other packets MAY be forwarded or MAY be silently 892 discarded. In any case, the state remains unchanged. 894 If the destination transport address contained in the incoming 895 IPv4 packet is not in use in the TCP BIB the packet is silently 896 discarded. 898 *** V4 SYN RCV *** 900 If a V6 SYN is received, then the state is moved to ESTABLISHED. The 901 lifetime of the corresponding TCP session table entry is updated to 2 902 hours 4 min (the established connection idle timeout as defined in 903 [RFC5382]). The packet is translated and forwarded. 905 If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code 906 3) is sent back to the source of the v4 SYN, the session table entry 907 is deleted and, the state is moved to CLOSED. 909 For any other packet, depending on the security policy other packets 910 MAY be forwarded or MAY be silently discarded. In any case, the 911 state remains unchanged. 913 *** V6 SYN RCV *** 915 If a V4 SYN is received (with or without the ACK flag set), then the 916 state is moved to ESTABLISHED. The timer is updated to 2 hours 4 min 917 (the established connection idle timeout as defined in [RFC5382]). 918 The packet is translated and forwarded. 920 If the lifetime expires, the session table entry is deleted and the 921 state is moved to CLOSED. 923 For any other packet, depending on the security policy other packets 924 MAY be forwarded or MAY be silently discarded. In any case, the 925 state remains unchanged. 927 *** ESTABLISHED *** 929 If the lifetime expires, the session table entry is deleted and the 930 state is moved to CLOSED. 932 If a V4 FIN packet is received, the packet is translated and 933 forwarded. The state is moved to V4 FIN RCV. 935 If a V6 FIN packet is received, the packet is translated and 936 forwarded. The state is moved to V6 FIN RCV. 938 If a packet is received, the packet is translated and forwarded. The 939 lifetime is set to 2 hours and 4 min. The state remains unchanged as 940 ESTABLISHED. 942 If the lifetime expires, the session table entry is deleted and the 943 state is moved to CLOSED. 945 If a V4 RST or a V6 RST packet is received, the packet is translated 946 and forwarded. The lifetime is set to 4 min and state is moved to 947 RST RCV. 949 *** V4 FIN RCV *** 951 If a packet is received, the packet is translated and forwarded. The 952 lifetime is set to 2 hours and 4 min. The state remains unchanged as 953 V4 FIN RCV. 955 If a V6 FIN packet is received, the packet is translated and 956 forwarded. The lifetime is set to 4 min. The state is moved to V6 957 FIN + V4 FIN RCV. 959 If the lifetime expires, the session table entry is deleted and the 960 state is moved to CLOSED. 962 *** V6 FIN RCV *** 964 If a packet is received, the packet is translated and forwarded. The 965 lifetime is set to 2 hours and 4 min. The state remains unchanged as 966 V6 FIN RCV. 968 If a V4 FIN packet is received, the packet is translated and 969 forwarded. The lifetime is set to 4 min. The state is moved to V6 970 FIN + V4 FIN RCV. 972 If the lifetime expires, the session table entry is deleted and the 973 state is moved to CLOSED. 975 *** V6 FIN + V4 FIN RCV *** 977 All packets are translated and forwarded. 979 If the lifetime expires, the session table entry is deleted and the 980 state is moved to CLOSED. 982 *** RST RCV *** 984 If a packet is received, the lifetime is set to 2 hours and 4 min and 985 the state is moved to ESTABLISHED. 987 If the lifetime expires, the session table entry is deleted and the 988 state is moved to CLOSED. 990 3.2.3. Rules for allocation of IPv4 transport addresses 992 If the rules specify that a new BIB entry is created for a source 993 transport address of (S',s), then the NAT64 allocates an IPv4 994 transport address for this BIB entry as follows: 996 If there exists some other BIB entry containing S' as the IPv6 997 address and mapping it to some IPv4 address T, then use T as the 998 IPv4 address. Otherwise, use any IPv4 address assigned to the 999 IPv4 interface. 1001 If the port s is in the Well-Known port range 0..1023, then 1002 allocate a port t from this same range. Otherwise, if the port s 1003 is in the range 1024..65535, then allocate a port t from this 1004 range. Furthermore, if port s is even, then t must be even, and 1005 if port s is odd, then t must be odd. 1007 In all cases, the allocated IPv4 transport address (T,t) MUST NOT 1008 be in use in another entry in the same BIB, but MAY be in use in 1009 the other BIB. 1011 If it is not possible to allocate an appropriate IPv4 transport 1012 address or create a BIB entry for some reason, then the packet is 1013 discarded. 1015 3.2.4. ICMP Query Session Handling 1017 The state information stored for an ICMP Query session in the ICMP 1018 Query session table includes a timer that tracks the remaining 1019 lifetime of the session. The NAT64 decrements this timer at regular 1020 intervals. When the timer expires, the session is deleted. If all 1021 the sessions corresponding to a ICMP Query BIB entry are deleted, 1022 then the ICMP Query BIB entry is also deleted in the case of 1023 dynamically created entries. 1025 An incoming ICMPv6 Informational packet is processed as follows: 1027 If the local security policy determines that ICMPv6 Informative 1028 packets are to be filtered, the packet is silently discarded. 1029 Else, the NAT64 searches for a ICMP Query BIB entry that matches 1030 the (IPv6 source address, ICMPv6 Query Id) pair. If such entry 1031 does not exist, a new entry is created. As (IPv6 address, ICMPv6 1032 Query Id) pair, the source IPv6 address of the packet and the 1033 ICMPv6 Query Identifier are included. The IPv4 address and ICMPv4 1034 Query Identifier values are allocated as follows: 1036 If there exists some other BIB entry containing the same IPv6 1037 address and mapping it to some IPv4 address T, then use T as 1038 the IPv4 address. Otherwise, use any IPv4 address assigned to 1039 the IPv4 interface. 1041 As ICMPv4 Identifier use any available value i.e. any 1042 identifier value for which no other entry exists with the same 1043 (IPv4 address, ICMPv4 Query Id) pair. 1045 The NAT64 searches for the session table entry corresponding to 1046 the incoming 3-tuple. If no such entry is found, a new entry is 1047 created. The information included in the session table is as 1048 follows: the IPv6 source and destination addresses contained in 1049 the received IPv6 packet, the IPv4 source address, the ICMPv4 1050 Query Id and the ICMPv6 Query Id are extracted from the 1051 corresponding ICMP Query BIB entry and the IPv4 destination 1052 address is algorithmically generated from the IPv6 destination 1053 address using the reverse algorithm as specified in Section 3.2.5. 1055 The NAT64 sets or resets the timer in the session table entry to 1056 maximum session lifetime. By default, the maximum session 1057 lifetime is 60 seconds. The maximum lifetime value SHOULD be 1058 configurable. The packet is translated and forwarded as described 1059 in the following sections. 1061 An incoming ICMPv4 Query packet is processed as follows: 1063 The NAT64 searches for a ICMP Query BIB entry that matches the 1064 IPv4 destination address and ICMPv4 query Id pair. If such entry 1065 does not exists, the packet is dropped. An ICMP message MAY be 1066 sent to the original sender of the packet, unless the discarded 1067 packet is itself an ICMP message. The ICMP message, if sent, has 1068 a type of 3 (Destination Unreachable). 1070 If the NAT64 filters on its IPv4 interface, then the NAT64 checks 1071 to see if the incoming packet is allowed according to the address- 1072 dependent filtering rule. To do this, it searches for a session 1073 table entry with a source IPv4 address and ICMP Query Id pair 1074 equal to the destination IPv4 address and ICMP Query Id in the 1075 incoming 3-tuple and destination IPv4 address (in the session 1076 table entry) equal to the source IPv4 address in the incoming 1077 3-tuple. If such an entry is found (there may be more than one), 1078 packet processing continues. Otherwise, the packet is discarded. 1079 If the packet is discarded, then an ICMP message MAY be sent to 1080 the original sender of the packet, unless the discarded packet is 1081 itself an ICMP message. The ICMP message, if sent, has a type of 1082 3 (Destination Unreachable) and a code of 13 (Communication 1083 Administratively Prohibited). 1085 The NAT64 searches for the session table entry corresponding to 1086 the incoming 3-tuple. If no such entry is found, a new entry is 1087 created. The ICMP Query session table entry contains the ICMPv4 1088 Query Identifier, source and destination address contained in the 1089 IPv4 packet and the source IPv6 address and the ICMPv6 Query Id 1090 (in the IPv6 --> IPv4 direction) contained in the existing ICMP 1091 Query BIB entry. The destination IPv6 address contains is the 1092 IPv6 representation of the IPv4 address of the destination IPv4 1093 address, generated using the algorithm described in Section 3.2.5. 1095 The NAT64 sets or resets the timer in the session table entry to 1096 maximum session lifetime. By default, the maximum session 1097 lifetime is 60 seconds. The maximum lifetime value SHOULD be 1098 configurable. The packet is translated and forwarded as described 1099 in the following sections. 1101 3.2.5. Generation of the IPv6 representations of IPv4 addresses 1103 NAT64 support multiple algorithms for the generation of the IPv6 1104 representation of an IPv4 address. The constraints imposed to the 1105 generation algorithms are the following: 1107 The same algorithm to create an IPv6 address from an IPv4 address 1108 MUST be used by: 1110 The DNS64 to create the IPv6 address to be returned in the 1111 synthetic AAAA RR from the IPv4 address contained in original A 1112 RR, and, 1114 The NAT64 to create the IPv6 address to be included in the 1115 destination address field of the outgoing IPv6 packets from the 1116 IPv4 address included in the destination address field of the 1117 incoming IPv4 packet. 1119 The algorithm MUST be reversible, i.e. it MUST be possible to 1120 extract the original IPv4 address from the IPv6 representation. 1122 The input for the algorithm MUST be limited to the IPv4 address, 1123 the IPv6 prefix (denoted Pref64::/n) used in the IPv6 1124 representations and optionally a set of stable parameters that are 1125 configured in the NAT64 (such as fixed string to be used as a 1126 suffix). 1128 If we note n the length of the prefix Pref64::/n, then n MUST 1129 the less or equal than 96. If a Pref64::/n is configured 1130 through any means in the DNS64 (such as manually configured, or 1131 other automatic mean not specified in this document), the 1132 default algorithm MUST use this prefix. If no prefix is 1133 available, the algorithm MUST use the Well-Known prefix 1134 (include here the prefix to be assigned by IANA) defined in 1135 [I-D.ietf-behave-address-format] 1137 NAT64 MUST support the following algorithms for generating IPv6 1138 representations of IPv4 addresses defined in 1139 [I-D.ietf-behave-address-format]: 1141 Zero-Pad And Embed, defined in section 3.2.3 of 1142 [I-D.ietf-behave-address-format] 1144 Compensation-Pad And Embed, defined in section of 3.2.4 of 1145 [I-D.ietf-behave-address-format] 1147 Embed And Zero-Pad, defined in section of 3.2.5 of 1148 [I-D.ietf-behave-address-format] 1150 Preconfigured Mapping Table, defined in section of 3.2.6 of 1151 [I-D.ietf-behave-address-format] 1153 The default algorithm used by NAT64 must be Embed and Zero-Pad. 1154 While the normative description of the algorithms is provided in 1155 [I-D.ietf-behave-address-format]. 1157 4. Computing the Outgoing Tuple 1159 This step computes the outgoing tuple by translating the addresses 1160 and ports or ICMP Query Id in the incoming tuple. 1162 In the text below, a reference to the the "BIB" means either the TCP 1163 BIB the UDP BIB or the ICMP Query BIB as appropriate. 1165 NOTE: Not all addresses are translated using the BIB. BIB entries 1166 are used to translate IPv6 source transport addresses to IPv4 1167 source transport addresses, and IPv4 destination transport 1168 addresses to IPv6 destination transport addresses. They are NOT 1169 used to translate IPv6 destination transport addresses to IPv4 1170 destination transport addresses, nor to translate IPv4 source 1171 transport addresses to IPv6 source transport addresses. The 1172 latter cases are handled applying the algorithmic transformation 1173 described in Section 3.2.5. This distinction is important; 1174 without it, hairpinning doesn't work correctly. 1176 4.1. Computing the outgoing 5-tuple for TCP, UDP and ICMP error 1177 messages 1179 The transport protocol in the outgoing 5-tuple is always the same as 1180 that in the incoming 5-tuple. 1182 When translating in the IPv6 --> IPv4 direction, let the incoming 1183 source and destination transport addresses in the 5-tuple be (S',s) 1184 and (D',d) respectively. The outgoing source transport address is 1185 computed as follows: the BIB contains a entry (S',s) <--> (T,t), then 1186 the outgoing source transport address is (T,t). 1188 The outgoing destination address is computed algorithmically from D' 1189 using the address transformation described in Section 3.2.5. 1191 When translating in the IPv4 --> IPv6 direction, let the incoming 1192 source and destination transport addresses in the 5-tuple be (S,s) 1193 and (D,d) respectively. The outgoing source transport address is 1194 computed as follows: 1196 The outgoing source transport address is generated from S using 1197 the address transformation algorithm described in Section 3.2.5. 1199 The outgoing destination transport address is computed as follows: 1201 If the BIB contains an entry (X',x) <--> (D,d), then the outgoing 1202 destination transport address is (X',x). 1204 Otherwise, discard the packet. 1206 If the rules specify that the packet is discarded, then the NAT64 MAY 1207 send an ICMP reply to the original sender, unless the packet being 1208 translated contains an ICMP message. The type should be 3 1209 (Destination Unreachable) and the code should be 0 (Network 1210 Unreachable in IPv4, and No Route to Destination in IPv6). 1212 4.2. Computing the outgoing 3-tuple for ICMP Query messages 1214 When translating in the IPv6 --> IPv4 direction, let the incoming 1215 source and destination addresses in the 3-tuple be S' and D' 1216 respectively and the ICMPv6 Query Identifier be I1. The outgoing 1217 source address is computed as follows: the BIB contains a entry 1218 (S',I1) <--> (T,I2), then the outgoing source address is T and the 1219 ICMPv4 Query Id is I2. 1221 The outgoing IPv4 destination address is computed algorithmically 1222 from D' using the address transformation described in Section 3.2.5. 1224 When translating in the IPv4 --> IPv6 direction, let the incoming 1225 source and destination addresses in the 3-tuple be S and D 1226 respectively and the ICMPv4 query Id is I2. The outgoing source 1227 address is generated from S using the address transformation 1228 algorithm described in Section 3.2.5. The outgoing destination 1229 address and ICMPv6 Query Id are computed as follows: 1231 If the BIB contains an entry (X',I1) <--> (D,I2), then the 1232 outgoing destination address is X' and the outgoing ICMPv6 Query 1233 Id is I1. 1235 Otherwise, discard the packet. 1237 NOTE: Not sure if this applies to ICMP query messages....If the rules 1238 specify that the packet is discarded, then the NAT64 MAY send an ICMP 1239 reply to the original sender, unless the packet being translated 1240 contains an ICMP message. The type should be 3 (Destination 1241 Unreachable) and the code should be 0 (Network Unreachable in IPv4, 1242 and No Route to Destination in IPv6). 1244 5. Translating the Packet 1246 This step translates the packet from IPv6 to IPv4 or vice-versa. 1248 The translation of the packet is as specified in section 3 and 1249 section 4 of IP/ICMP Translation Algorithm 1250 [I-D.ietf-behave-v6v4-xlate], with the following modifications: 1252 o When translating an IP header (sections 3.1 and 4.1), the source 1253 and destination IP address fields are set to the source and 1254 destination IP addresses from the outgoing 5-tuple. 1256 o When the protocol following the IP header is TCP or UDP, then the 1257 source and destination ports are modified to the source and 1258 destination ports from the outgoing 5-tuple. In addition, the TCP 1259 or UDP checksum must also be updated to reflect the translated 1260 addresses and ports; note that the TCP and UDP checksum covers the 1261 pseudo-header which contains the source and destination IP 1262 addresses. An algorithm for efficiently updating these checksums 1263 is described in [RFC3022]. 1265 o When the protocol following the IP header is ICMP and it is an 1266 ICMP Query message, the ICMP query Identifier is set to the one of 1267 the outgoing 3-tuple. 1269 o When the protocol following the IP header is ICMP (sections 3.4 1270 and 4.4) and it is an ICMP error message, the source and 1271 destination transport addresses in the embedded packet are set to 1272 the destination and source transport addresses from the outgoing 1273 5-tuple (note the swap of source and destination). 1275 6. Handling Hairpinning 1277 This step handles hairpinning if necessary. 1279 If the destination IP address is an address assigned to the NAT64 1280 itself (i.e., is one of the IPv4 addresses assigned to the IPv4 1281 interface, or is covered by the /96 prefix assigned to the IPv6 1282 interface), then the packet is a hairpin packet. The outgoing 1283 5-tuple becomes the incoming 5-tuple, and the packet is treated as if 1284 it was received on the outgoing interface. Processing of the packet 1285 continues at step 2. 1287 [R/T] The reference to step 2 here was a little confusing to us. Are 1288 you referring to Filtering and Updating Session Information (Section 1289 3.2)? MB> I am not sure about this anymore. I mean what if the 1290 packet that is being hairpinned is an ICMP error msge, I mean don't 1291 we still need step 1? 1293 TBD: Is there such a thing as a hairpin loop (likely not naturally, 1294 but perhaps through a special-crafted attack packet with a spoofed 1295 source address)? If so, need to drop packets that hairpin more than 1296 once. 1298 7. Path MTU discovery and fragmentation 1300 It's the job of the network layer to adapt to different maximum 1301 packet sizes as packets move through the network. There are three 1302 mechanisms that handle this: transport layer negotiations such as the 1303 TCP MSS option, path MTU discovery and fragmentation. The difference 1304 between the IPv4 and IPv6 header sizes requires some handling in a 1305 NAT64 translator, and there are complications because of the 1306 differences between how IPv4 and IPv6 handle fragmentation, as well 1307 as the issue of how to demultiplex fragmented IPv4 packets. 1309 The vast majority of both IPv4 and IPv6 hosts use path MTU discovery 1310 [RFC1191] [RFC1981]. With IPv4, PMTUD can be enabled on a per-packet 1311 basis by setting the DF bit to 1. With IPv6, there is no need for 1312 PMTUD for packets up to 1280 bytes because all IPv6 hosts are 1313 required to be able to receive 1280-byte packets without 1314 fragmentation. When sending larger packets, IPv6 hosts implicitly 1315 use PMTUD. 1317 The fragmentation behavior specified in [RFC2765] is that upon the 1318 reception of an ICMPv6 "packet too big" message with an indicated 1319 packet size of less than 1280 octets, IPv6 hosts will transmit 1280- 1320 octet packets, but include a fragment header in those packets. In a 1321 stateful translator, the identification value in this fragment header 1322 can't be used, so the fragment header itself serves no purpose. 1323 Additionally, the presence or absense of the fragment header isn't 1324 enough to determine whether to set the DF bit in packets translated 1325 to IPv4 to 0 (fragment header present) or 1 (no fragment header 1326 present). The reason for this is that operators may decide to forego 1327 path MTU discovery by configuring an MTU of 1280 and filtering 1328 incoming "too big" messages. The behavior specified below is meant 1329 to avoid PMTUD black holes in this situation 1331 7.1. Translating whole packets and PMTUD 1333 This section specifies the values in the fragmentation-related fields 1334 in the IPv4 header when no fragmentation occurs, and how path MTU 1335 discovery is handled. 1337 7.1.1. IPv6-to-IPv4 translation 1339 If the NAT64 has the same MTUs on its IPv6 and IPv4 interfaces, it 1340 will never have to generate "packet too big" messages for incoming 1341 IPv6 packets because the translation from IPv6 to IPv4 reduces the 1342 packet size by 20 bytes, more if the IPv6 packet has extension 1343 headers that are removed during the translation, such as the fragment 1344 header. If the MTU on the IPv6 side is larger than 1280 bytes and 1345 more than 20 bytes smaller than the MTU on the IPv4 side, the NAT64 1346 MUST generate the appropriate "packet too big" messages on the IPv6 1347 side. 1349 To support PMTUD, for translated packets that are larger than 1260 1350 bytes on the IPv4 side (1280 bytes IPv6 packets with 20 byte size 1351 reduction through the translation), the DF bit is set to 1 in the 1352 resulting IPv4 packet. 1354 IPv4 routers may generate "packet too big" messages indicating a 1355 supported MTU size smaller than 1280 bytes. In those cases, the IPv6 1356 hosts will continue to send packets larger than what the IPv4 path 1357 MTU can support. To allow packets to be delivered successfully in 1358 this case, the DF bit is set to 0 in all translated packets smaller 1359 than or equal to 1260 bytes, to allow these packets to be fragmented 1360 in the IPv4 network. 1362 Note: it is highly recommended for IPv4 hosts running services that 1363 may be used by IPv6 clients through a NAT64 translator to use an MTU 1364 size of at least 1260 bytes and to properly generate "packet too big" 1365 messages. 1367 When a NAT64 translates "packet too big" messages from IPv6 to IPv4, 1368 it adjusts the advertised MTU to the minimum of the original 1369 advertised MTU + 20, the NAT64's MTU on the IPv6 side + 20 and the 1370 NAT64's MTU on the IPv4 side. 1372 The identification field in the IPv4 header MUST be filled with a 1373 value generated by the NAT64 translator, similar to the way that 1374 identification values are created for locally generated packets. It 1375 is RECOMMENDED that a NAT64 translator keep an identification counter 1376 for every combination of remote IPv4 destination and protocol. 1378 In theory, IPv4 packets with DF set to 1 don't need a unique 1379 identification value. However, it is not unheard of for operators to 1380 configure equipment to clear the DF bit, at which time an 1381 identification value with good uniqueness becomes necessary. As 1382 such, it is recommended that translators include a unique 1383 identification value in all packets, including those with DF set to 1384 1. However, since more packets will be sent with DF set to 1, this 1385 will use up identification values faster. Implementations may choose 1386 to segment the identification space and assign values from non- 1387 overlapping pools to packets with DF set to 0 and DF set to 1 to 1388 provide a longer period of uniqueness to fragmentable packets. 1390 7.1.2. IPv4-to-IPv6 1392 Because it may be necessary to include a fragmentation header or 1393 other extension header, the NAT64 MUST be prepared to generate 1394 "packet too big" messages for packets with the DF bit set to 1 1395 received from the IPv4 side, regardless of the MTU sizes on the IPv4 1396 and IPv6 interfaces. If the packet with DF = 1 is larger than can be 1397 transmitted on the IPv6 side after translation, the NAT64 returns a 1398 "packet too big" message indicating the maximum IPv4 packet size that 1399 would be supported using the same translation as the current packet. 1400 This can be calculated as IPv4-packet-size - 20. 1402 When a NAT64 translates "packet too big" messages from IPv4 to IPv6, 1403 it adjusts the advertised MTU to the minimum of the original 1404 advertised MTU - 20, the NAT64's MTU on the IPv6 side and the NAT64's 1405 MTU on the IPv4 side - 20. However, if the advertised MTU in "packet 1406 too big" messages is smaller than 1260 bytes, the value put into the 1407 translated "packet too big" message is 1280. This makes sure that 1408 the IPv6 host will limit its packet sizes to 1280 bytes, so its 1409 packets are subsequently translated into IPv4 packets with DF set to 1410 0. (This deviates from [RFC2765].) 1412 7.2. Fragmentation 1414 Because NAT deviates from normal router behavior, the limitation that 1415 IPv6 packets or IPv4 packets with DF set to 1 are not fragmented by 1416 routers doesn't apply to a NAT64 translator. Where appropriate, 1417 these packets are fragmented after translation as described below. 1419 7.2.1. IPv4-to-IPv6 1421 Because packets coming in on the IPv4 side may be larger than 1280 1422 bytes after translation, a NAT64 MUST implement PMTUD on the IPv6 1423 side. In other words, it must react to "packet too big" messages for 1424 any IPv6 destination that it communicates with by limiting the size 1425 of the packets that it sends to the advertised maximum. 1427 In the case where, after translation from IPv4 to IPv6, a packet is 1428 larger than a destination's PMTU, the NAT64 returns a "packet too 1429 big" as outlined earlier in the case that the DF bit was set to 1 in 1430 the IPv4 packet. If the DF bit was set to 0, the translator first 1431 translates the IPv4 packet, and then fragments the resulting IPv6 1432 packets using normal IPv6 fragmentation rules. The lower 16 bits of 1433 the IPv6 identification field are copied from the IPv4 identification 1434 field. The upper 16 bits of the IPv6 identification field are set to 1435 0. 1437 Because NAT64 provides a stateful many-to-one (perhaps even many-to- 1438 many) translation, it is necessary to recognize which session a given 1439 packet belongs to. In the IPv4-to-IPv6 direction, the TCP or UDP 1440 port numbers must be known to accomplish this, but the port numbers 1441 only occur in the first fragment of a fragmented packet. There are 1442 two possible ways to deal with this: 1444 1. Reassemble the packet before translating it. 1446 2. Create translation state for the fragments belonging to the same 1447 packet so each packet can be translated. 1449 Strategy 2 is attractive in large installations because it requires 1450 less storage and processing. However, it may still be necessary to 1451 buffer fragments for some time, as the fragment containing the first 1452 part of the packet (and with that, the port numbers) may not be the 1453 first one to arrive. 1455 Note: based on the assumptions that hosts generate fragments in-order 1456 and that reordering must happen through parallel network links and 1457 that the path between these parallel links and a NAT64 supports 1458 speeds of at least 10 Mbps, there is a very high probability that two 1459 out-of-order fragments making up a packet will arrive at the NAT64 1460 within 50 to 100 milliseconds. Further assuming that fragmented 1461 traffic makes up less than 10% of all traffic, this only requires a 1462 buffer of 6 to 12,500 fragments (50 ms at 10 Mbps to 100 ms at 10 1463 Gbps). 1465 In some cases, there may only be a single session matching the 1466 fragment's source and destination addresses and protocol number. In 1467 these cases, it would be possible to translate the fragments out-of- 1468 order. A NAT64 translator MAY do this for TCP, however, it MUST NOT 1469 translate UDP packets before the first fragment is available. The 1470 reason for this is that the fragment could be part of a packet 1471 setting up a new session. However, with TCP session establishment 1472 packets don't carry data, so it's extremely unlikely that they are 1473 fragmented. This is not the case with UDP, and in the IPv4-to-IPv6 1474 direction, a UDP packet may have a zero checksum, which must be 1475 recalculated when translating to IPv6, for which the entire packet 1476 must be available. 1478 7.2.2. IPv6-to-IPv4 1480 For all IPv4 packets that the NAT64 creates through translation, the 1481 translator generates an ID value. This applies to all packets, 1482 regardless of their size or the value of the DF field. A NAT64 1483 translator MAY employ strategies to avoid reusing an ID value for a 1484 certain source, destination, protocol tuple as long as possible. If 1485 the IPv4 packets are fragments of an IPv6 packet, then state is 1486 created that makes it possible for all the fragments to have the same 1487 ID value on the IPv4 side. 1489 [RFC2765] specifies copying the lower bits from the IPv6 ID field in 1490 a fragment header (if present) to the IPv4 ID field, but this runs 1491 the risk of two IPv6 hosts talking to the same IPv4 destination 1492 through the NAT64 using the same ID value. 1494 Otherwise, when translating IPv6 packets with a fragmentation header, 1495 the fragments are translated as per [RFC2765]. 1497 In the IPv6-to-IPv4 direction, there is no need to map a fragment to 1498 the session it belongs to in order to translate the fragment. 1499 However, it is necessary that all the fragments have the same 1500 identification value, so fragments may be translated individually, 1501 but state must be kept to be able to translate subsequent fragments 1502 of the same packet using the same identification value on the IPv4 1503 side. 1505 7.3. TCP MSS option 1507 It is not recommended that NAT64 translators rewrite the TCP MSS 1508 option [RFC0793]. As such, assuming the common case of all 1500- 1509 octet MTUs, an IPv6 host will advertise a 1440-octet MSS, triggering 1510 the IPv4 host to generate 1480-octet packets that are translated to 1511 1500-octet IPv6 packets. IPv4 hosts will advertise a 1460-octet MSS, 1512 which would be 1520-octet IPv6 packets. However, ethernet-connected 1513 IPv6 hosts can only send 1500-octet packets, so in the all-ethernet 1514 case, there is no dependency on path MTU discovery. 1516 8. Application scenarios 1518 In this section, we describe how to apply NAT64/DNS64 to the suitable 1519 scenarios described in [I-D.ietf-behave-v6v4-framework] . 1521 8.1. Scenario 1: an IPv6 network to the IPv4 Internet 1523 An IPv6 only network basically has IPv6 hosts (those that are 1524 currently available) and because of different reasons including 1525 operational simplicity, wants to run those hosts in IPv6 only mode, 1526 while still providing access to the IPv4 Internet. The scenario is 1527 depicted in the picture below. 1529 +----+ +-------------+ 1530 | +------------------+IPv6 Internet+ 1531 | | +-------------+ 1532 IPv6 host-----------------+ GW | 1533 | | +-------------+ 1534 | +------------------+IPv4 Internet+ 1535 +----+ +-------------+ 1537 |-------------------------public v6-----------------------------| 1538 |-------public v6---------|NAT|----------public v4--------------| 1540 The proposed NAT64/DNS64 is perfectly suitable for this particular 1541 scenario. The deployment of the NAT64/DNS64 would be as follows: The 1542 NAT64 function should be located in the GW device that connects the 1543 IPv6 site to the IPv4 Internet. The DNS64 functionality can be 1544 placed either in the local recursive DNS server or in the local 1545 resolver in the hosts. 1547 The proposed NAT64/DNS64 approach satisfies the requirements of this 1548 scenario, in particular because it doesn't require any changes to 1549 current IPv6 hosts in the site to obtain basic functionality. 1551 8.2. Scenario 3: the IPv6 Internet to an IPv4 network 1553 The scenario of servers using private addresses and being reached 1554 from the IPv6 Internet basically includes the cases that for whatever 1555 reason the servers cannot be upgraded to IPv6 and they even may not 1556 have public IPv4 addresses and it would be useful to allow IPv6 nodes 1557 in the IPv6 Internet to reach those servers. This scenario is 1558 depicted in the figure below. 1560 +----+ 1561 IPv6 Host(s)-------(Internet)-----+ GW +------Private IPv4 Servers 1562 +----+ 1564 |---------public v6---------------|NAT|------private v4----------| 1566 This scenario can again be perfectly served by the NAT64 approach. 1567 In this case the NAT64 functionality is placed in the GW device 1568 connecting the IPv6 Internet to the server's site. In this case, the 1569 DNS64 functionality is not required in general since real (i.e. non 1570 synthetic) AAAA RRs for the IPv4 servers containing the IPv6 1571 representation of the IPv4 address of the servers can be created. 1572 See more discussion about this in [I-D.ietf-behave-dns64] 1574 Again, this scenario is satisfied by the NAT64 since it supports the 1575 required functionality without requiring changes in the IPv4 servers 1576 nor in the IPv6 clients. 1578 9. Security Considerations 1580 Implications on end-to-end security. 1582 Any protocol that protect IP header information are essentially 1583 incompatible with NAT64. So, this implies that end to end IPSec 1584 verification will fail when AH is used (both transport and tunnel 1585 mode) and when ESP is used in transport mode. This is inherent to 1586 any network layer translation mechanism. End-to-end IPsec protection 1587 can be restored, using UDP encapsulation as described in [RFC3948]. 1589 Filtering. 1591 NAT64 creates binding state using packets flowing from the IPv6 side 1592 to the IPv4 side. In accordance with the procedures defined in this 1593 document following the guidelines defined in RFC 4787 [RFC4787] a 1594 NAT64 must offer "enpoint independent filtering". This means: 1596 for any IPv6 side packet with source (S'1,s1) and destination 1597 (Pref64::D1,d1) that creates an external mapping to (S1,s1), 1598 (D1,d1), 1600 for any subsequent external connection to from S'1 to (D2,d2) 1601 within a given binding timer window, 1603 (S1,s1) = (S2,s2) for all values of D2,d2 1605 Implementations may also provide support for "Address-Dependent 1606 Mapping" and "Address and Port-Dependent Mapping", as also defined in 1607 this document and following the guidelines defined in RFC 4787 1608 [RFC4787]. 1610 The security properties however are determined by which packets the 1611 NAT64 filter allows in and which it does not. The security 1612 properties are determined by the filtering behavior and filtering 1613 configuration in the filtering portions of the NAT64, not by the 1614 address mapping behavior. For example, 1616 Without filtering - When "endpoint independent filtering" is used 1617 in NAT64, once a binding is created in the IPv6 ---> IPv4 1618 direction, packets from any node on the IPv4 side destined to the 1619 IPv6 transport address will traverse the NAT64 gateway and be 1620 forwarded to the IPv6 transport address that created the binding. 1621 However, 1623 With filtering - When "endpoint independent filtering" is used in 1624 NAT64, once a binding is created in the IPv6 ---> IPv4 direction, 1625 packets from any node on the IPv4 side destined to the IPv6 1626 transport address will first be processed against the filtering 1627 rules. If the source IPv4 address is permitted, the packets will 1628 be forwarded to the IPv6 transport address. If the source IPv4 1629 address is explicitly denied -- or the default policy is to deny 1630 all addresses not explicitly permitted -- then the packet will 1631 discarded. A dynamic filter may be employed where by the filter 1632 will only allow packets from the IPv4 address to which the 1633 original packet that created the binding was sent. This means 1634 that only the D IPv4 addresses to which the IPv6 host has 1635 initiated connections will be able to reach the IPv6 transport 1636 address, and no others. This essentially narrows the effective 1637 operation of the NAT64 device to a "Address Dependent" behavior, 1638 though not by its mapping behavior, but instead by its filtering 1639 behavior. 1641 Attacks to NAT64. 1643 The NAT64 device itself is a potential victim of different type of 1644 attacks. In particular, the NAT64 can be a victim of DoS attacks. 1645 The NAT64 box has a limited number of resources that can be consumed 1646 by attackers creating a DoS attack. The NAT64 has a limited number 1647 of IPv4 addresses that it uses to create the bindings. Even though 1648 the NAT64 performs address and port translation, it is possible for 1649 an attacker to consume all the IPv4 transport addresses by sending 1650 IPv6 packets with different source IPv6 transport addresses. It 1651 should be noted that this attack can only be launched from the IPv6 1652 side, since IPv4 packets are not used to create binding state. DoS 1653 attacks can also affect other limited resources available in the 1654 NAT64 such as memory or link capacity. For instance, it is possible 1655 for an attacker to launch a DoS attack to the memory of the NAT64 1656 device by sending fragments that the NAT64 will store for a given 1657 period. If the number of fragments is high enough, the memory of the 1658 NAT64 could be exhausted. NAT64 devices should implement proper 1659 protection against such attacks, for instance allocating a limited 1660 amount of memory for fragmented packet storage. 1662 10. IANA Considerations 1664 This document contains no IANA considerations. 1666 11. Contributors 1668 George Tsirtsis 1670 Qualcomm 1672 tsirtsis@googlemail.com 1674 Greg Lebovitz 1676 Juniper 1678 gregory.ietf@gmail.com 1680 12. Acknowledgements 1682 Dave Thaler, Dan Wing, Alberto Garcia-Martinez, Reinaldo Penno and 1683 Joao Damas reviewed the document and provided useful comments to 1684 improve it. 1686 The content of the draft was improved thanks to discussions with Fred 1687 Baker and Jari Arkko. 1689 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 1690 Trilogy, a research project supported by the European Commission 1691 under its Seventh Framework Program. 1693 13. References 1695 13.1. Normative References 1697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1698 Requirement Levels", BCP 14, RFC 2119, March 1997. 1700 [RFC1035] Mockapetris, P., "Domain names - implementation and 1701 specification", STD 13, RFC 1035, November 1987. 1703 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1704 RFC 2671, August 1999. 1706 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1707 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1708 RFC 4787, January 2007. 1710 [RFC3484] Draves, R., "Default Address Selection for Internet 1711 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1713 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1714 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1715 RFC 3948, January 2005. 1717 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1718 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1719 RFC 5382, October 2008. 1721 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1722 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 1723 April 2009. 1725 [I-D.ietf-behave-dns64] 1726 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 1727 "DNS64: DNS extensions for Network Address Translation 1728 from IPv6 Clients to IPv4 Servers", 1729 draft-ietf-behave-dns64-00 (work in progress), July 2009. 1731 [I-D.ietf-behave-v6v4-xlate] 1732 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1733 Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in 1734 progress), September 2009. 1736 [I-D.ietf-behave-address-format] 1737 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 1738 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1739 draft-ietf-behave-address-format-00 (work in progress), 1740 August 2009. 1742 13.2. Informative References 1744 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1745 (SIIT)", RFC 2765, February 2000. 1747 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1748 November 1990. 1750 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1751 for IP version 6", RFC 1981, August 1996. 1753 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1754 RFC 793, September 1981. 1756 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1757 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1758 February 2000. 1760 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1761 Considerations for IP Fragment Filtering", RFC 1858, 1762 October 1995. 1764 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1765 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1767 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1768 Address Translator (Traditional NAT)", RFC 3022, 1769 January 2001. 1771 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 1772 Address Translator - Protocol Translator (NAT-PT) to 1773 Historic Status", RFC 4966, July 2007. 1775 [I-D.ietf-mmusic-ice] 1776 Rosenberg, J., "Interactive Connectivity Establishment 1777 (ICE): A Protocol for Network Address Translator (NAT) 1778 Traversal for Offer/Answer Protocols", 1779 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1781 [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of 1782 Managed Objects for Synchronous Optical Network (SONET) 1783 Linear Automatic Protection Switching (APS) 1784 Architectures", RFC 3498, March 2003. 1786 [I-D.ietf-behave-v6v4-framework] 1787 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1788 IPv4/IPv6 Translation", 1789 draft-ietf-behave-v6v4-framework-01 (work in progress), 1790 September 2009. 1792 Authors' Addresses 1794 Marcelo Bagnulo 1795 UC3M 1796 Av. Universidad 30 1797 Leganes, Madrid 28911 1798 Spain 1800 Phone: +34-91-6249500 1801 Fax: 1802 Email: marcelo@it.uc3m.es 1803 URI: http://www.it.uc3m.es/marcelo 1805 Philip Matthews 1806 Alcatel-Lucent 1807 600 March Road 1808 Ottawa, Ontario 1809 Canada 1811 Phone: +1 613-592-4343 x224 1812 Fax: 1813 Email: philip_matthews@magma.ca 1814 URI: 1816 Iljitsch van Beijnum 1817 IMDEA Networks 1818 Avda. del Mar Mediterraneo, 22 1819 Leganes, Madrid 28918 1820 Spain 1822 Email: iljitsch@muada.com