idnits 2.17.1 draft-bagnulo-behave-nat64-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1220. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 10, 2008) is 5798 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: 'I-D.ietf-mmusic-ice' is defined on line 1143, but no explicit reference was found in the text == Unused Reference: 'RFC3498' is defined on line 1149, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 == Outdated reference: A later version (-12) exists of draft-ietf-behave-nat-icmp-08 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: December 12, 2008 Unaffiliated 6 I. van Beijnum 7 IMDEA Networks 8 June 10, 2008 10 NAT64/DNS64: Network Address and Protocol Translation from IPv6 Clients 11 to IPv4 Servers 12 draft-bagnulo-behave-nat64-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 12, 2008. 39 Abstract 41 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and 42 vice-versa. DNS64 is a mechanism for synthesizing AAAA records from 43 A records. These two mechanisms together enable client-server 44 communication between an IPv6-only client and an IPv4-only server, 45 without requiring any changes to either the IPv6 or the IPv4 node, 46 for the class of applications that work through NATs. They also 47 enable peer-to-peer communication between an IPv4 and an IPv6 node, 48 where the communication can be initiated by either end using 49 existing, NAT-traversing, peer-to-peer communication techniques. 50 This document specifies NAT64 and DNS64, and gives suggestions on how 51 they should be deployed. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Features of NAT64 . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2.1. NAT64 solution elements . . . . . . . . . . . . . . . 5 59 1.2.2. Walkthough . . . . . . . . . . . . . . . . . . . . . . 7 60 1.2.3. Dual stack nodes . . . . . . . . . . . . . . . . . . . 9 61 1.2.4. IPv6 nodes implementing DNSSEC . . . . . . . . . . . . 10 62 1.2.5. Filtering . . . . . . . . . . . . . . . . . . . . . . 10 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 3. Normative Specification . . . . . . . . . . . . . . . . . . . 12 65 3.1. Synthentic AAAA RRs . . . . . . . . . . . . . . . . . . . 12 66 3.2. The EDNS SAS option . . . . . . . . . . . . . . . . . . . 13 67 3.3. DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 3.4. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 3.4.1. Determining the Incoming 5-tuple . . . . . . . . . . . 17 70 3.4.2. Filtering and Updating Session Information . . . . . . 17 71 3.4.2.1. UDP Session Handling . . . . . . . . . . . . . . . 18 72 3.4.2.2. TCP Session Handling . . . . . . . . . . . . . . . 18 73 3.4.3. Computing the Outgoing 5-Tuple . . . . . . . . . . . . 18 74 3.4.4. Translating the Packet . . . . . . . . . . . . . . . . 20 75 3.4.5. Handling Hairpinning . . . . . . . . . . . . . . . . . 21 76 3.5. FTP ALG . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 79 6. Changes from Previous Draft Versions . . . . . . . . . . . . . 23 80 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 86 Intellectual Property and Copyright Statements . . . . . . . . . . 27 88 1. Introduction 90 This document specifies NAT64 and DNS64, two mechanisms for IPv6-IPv4 91 transition and co-existence. Together, these two mechanisms allow a 92 IPv6-only client to initiate communications to an IPv4-only server, 93 and also allow peer-to-peer communication between IPv6-only and IPv4- 94 only hosts. 96 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets. 97 The translation is done by translating the packet headers according 98 to SIIT [RFC2765], translating the IPv4 server address by adding or 99 removing a /96 prefix, and translating the IPv6 client address by 100 installing mappings in the normal NAT manner. 102 DNS64 is a mechanism for synthesizing AAAA resource records (RR) from 103 A RR. The synthesis is done by adding a /96 prefix to the IPv4 104 address to create an IPv6 address, where the /96 prefix is assigned 105 to a NAT64 device. 107 Together, these two mechanisms allow a IPv6-only client to initiate 108 communications to an IPv4-only server. 110 These mechanisms are expected to play a critical role in the IPv4- 111 IPv6 transition and co-existence. Due to IPv4 address depletion, 112 it's likely that in the future, a lot of IPv6-only clients will want 113 to connect to IPv4-only servers. The NAT64 and DNS64 mechanisms are 114 easily deployable, since they require no changes to either the IPv6 115 client nor the IPv6 server. For basic functionality, the approach 116 only requires the deployment of NAT64-enabled devices connecting an 117 IPv6-only network to the IPv4-only Internet, along with the 118 deployment of a few DNS64-enabled name servers in the IPv6-only 119 network. However, some advanced features require software updates to 120 the IPv6-only hosts. 122 The NAT64 and DNS64 mechanisms are related to the NAT-PT mechanism 123 defined in [RFC2766], but significant differences exist. First, 124 NAT64 does not define the NATPT mechanisms used to support IPv6 only 125 servers to be contacted by IPv4 only clients, but only defines the 126 mechanisms for IPv6 clients to contact IPv4 servers and its potential 127 reuse to support peer to peer communications through standard NAT 128 traversal techniques. Second, NAT64 includes a set of features that 129 overcomes many of the reasons the original NAT-PT specification was 130 moved to historic status [RFC4966]. 132 1.1. Features of NAT64 134 The features of NAT64 and DNS64 are: 136 o It enables IPv6-only nodes to initiate a client-server connection 137 with an IPv4-only server, without needing any changes on either 138 IPv4 or IPv6 nodes. This works for the same class of applications 139 that work through IPv4-to-IPv4 NATs. 141 o It supports peer-to-peer communication between IPv4 and IPv6 142 nodes, including the ability for IPv4 nodes to initiate 143 communcation with IPv6 nodes using peer-to-peer techniques (i.e., 144 using a rendezvous server and ICE). To this end, NAT64 is 145 compliant with the recommendations for how NATs should handle UDP 146 [RFC4787], TCP [I-D.ietf-behave-tcp], and ICMP 147 [I-D.ietf-behave-nat-icmp]. 149 o Compatible with ICE. 151 o Supports additional features with some changes on nodes. These 152 features include: 154 * Support for DNSSec 156 * Some forms of IPSec support 158 * Increased ability to detect when there is a communication path 159 that does not involve translating between IPv6 and IPv4. This 160 is achieved by marking synthetic DNS AAAA resource records 161 which usage would result in translated connectivity, so that 162 the sender can prefer using non-synthetic records when it is 163 possible. 165 1.2. Overview 167 This section provides a non-normative introduction to the mechanisms 168 of NAT64 and DNS64. 170 NAT64 mechanism is implemented in an NAT64 box which has two 171 interfaces, an IPv4 interface connected to the the IPv4 network, and 172 an IPv6 interface connected to the IPv6 network. Packets generated 173 in the IPv6 network for a receiver located in the IPv4 network will 174 be routed within the IPv6 network towards the NAT64 box. The NAT64 175 box will translate them and forward them as IPv4 packets through the 176 IPv4 network to the IPv4 receiver. The reverse takes place for 177 packets generated in the IPv4 network for an IPv6 receiver. NAT64, 178 however, is not symmetric. In order to be able to perform IPv6 - 179 IPv4 translation NAT64 requires state, binding an IPv6 address and 180 port (hereafter called an IPv6 transport address) to an IPv4 address 181 and port (hereafter called an IPv4 transport address). 183 Such binding state is created when the first packet flowing from the 184 IPv6 network to the IPv4 network is translated. After the binding 185 state has been created, packets flowing in either direction on that 186 particular flow are translated. The result is that NAT64 only 187 supports communications initiated by the IPv6-only node towards an 188 IPv4-only node. Some additional mechanisms, like ICE, can be used in 189 combination with NAT64 to provide support for communications 190 initiated by the IPv4-only node to the IPv6-only node. The 191 specification of such mechanisms, however, is out of the scope of 192 this document. 194 1.2.1. NAT64 solution elements 196 In this section we describe the different elements involved in the 197 NAT64 approach. 199 The main component of the proposed solution is the translator itself. 200 The translator has essentially two main parts, the address 201 translation mechanism and the protocol translation mechanism. 203 Protocol translation from IPv4 packet header to IPv6 packet header 204 and vice-versa is performed according to SIIT [RFC2765]. 206 Address translation maps IPv6 transport addresses to IPv4 transport 207 addresses and vice-versa. In order to create these mappings the 208 NAT64 box has two pools of addresses i.e. an IPv6 address pool (to 209 represent IPv4 addresses in the IPv6 network) and an IPv4 address 210 pool (to represent IPv6 addresses in the IPv4 network). Since there 211 is enough IPv6 address space, it is possible to map every IPv4 212 address into a different IPv6 address. 214 NAT64 creates the required mappings by using as the IPv6 address pool 215 a /96 IPv6 prefix (hereafter called Pref64::/96). This allows each 216 IPv4 address to be mapped into a different IPv6 address by simply 217 concatenating the /96 prefix assigned as the IPv6 address pool of the 218 NAT64, with the IPv4 address being mapped (i.e. an IPv4 address X is 219 mapped into the IPv6 address Pref64:X). The NAT64 prefix Pref64::/96 220 is assigned by the administrator of the NAT64 box from the global 221 unicast IPv6 address block assigned to the site. It should be noted 222 that the the prefix used as the IPv6 address pool is assigned to a 223 specific NAT64 box and if there are multiple NAT64 boxes, each box is 224 allocated a different prefix. Assigning the same prefix to multiple 225 boxes may lead to communication failures due to internal routing 226 fluctuations. 228 The IPv4 address pool, however, is a set of IPv4 addresses, normally 229 a small prefix assigned by the local administrator to the NAT64's 230 external (IPv4) interface. Since IPv4 address space is a scarce 231 resource, the IPv4 address pool is small and typicaly not sufficient 232 to establish permanent one-to-one mappings with IPv6 addresses. So, 233 mappings using the IPv4 address pool will be created and released 234 dynamically. Moreover, because of the IPv4 address scarcity, the 235 usual practice for NAT64 is likely to be the mapping of IPv6 236 transport addresses into IPv4 transport addresses, instead of IPv6 237 addresses into IPv4 addresses directly, which enable a higher 238 utilization of the limited IPv4 address pool. 240 Because of the dynamic nature of the IPv6 to IPv4 address mapping and 241 the static nature of the IPv4 to IPv6 address mapping, it is easy to 242 understand that it is far simpler to allow communication initiated 243 from the IPv6 side toward an IPv4 node, which address is permanently 244 mapped into an IPv6 address, than communications initiated from IPv4- 245 only nodes to an IPv6 node in which case IPv4 address needs to be 246 associated with it dynamically. For this reason NAT64 supports only 247 communications initiated from the IPv6 side. 249 An IPv6 initiator can know or derive in advance the IPv6 address 250 representing the IPv4 target and send packets to that address. The 251 packets are intercepted by the NAT64 device, which associates an IPv4 252 transport address of its IPv4 pool to the IPv6 transport address of 253 the initiator, creating binding state, so that reply packets can be 254 translated and forwarded back to the initiator. The binding state is 255 kept while packets are flowing. Once the flow stops, and based on a 256 timer, the IPv4 transport address is returned to the IPv4 address 257 pool so that it can be reused for other communications. 259 To allow an IPv6 initiator to do the standard DNS lookup to learn the 260 address of the responder, DNS64 is used to synthesize an AAAA record 261 (pronounced "quad-A" and containing an IPv6 address) from the A 262 record (containing the real IPv4 address of the responder). DNS64 263 receives the DNS queries generated by the IPv6 initiator. If there 264 is no AAAA record available for the target node (which is the normal 265 case when the target node is an IPv4-only node), DNS64 performs a 266 query for the A record. If an A record is discovered, DNS64 creates 267 a synthetic AAAA RR by adding the Pref64::/96 of a NAT64 to the 268 responder's IPv4 address (i.e. if the IPv4 node has IPv4 address X, 269 then the synthetic AAAA RR will contain the IPv6 address formed as 270 Pref64:X). The synthetic AAAA RR is passed back to the IPv6 271 initiator, which will initiate an IPv6 communication with the IPv6 272 address associated to the IPv4 receiver. The packet will be routed 273 to the NAT64 device, which will create the IPv6 to IPv4 address 274 mapping as described before. 276 Having DNS synthesize AAAA records creates a number of problems, as 277 described in [RFC4966]: 279 o The synthesized AAAA records may leak outside their intended 280 scope; 282 o Dual-stack hosts may communicate with IPv4-only servers using IPv6 283 which is then translated to IPv4, rather than using their IPv4 284 connectivity; 286 o The IPv6-only hosts will be unable to use DNSSEC to verify the 287 legitimacy of the synthetic AAAA records. 289 In order to avoid these issues, responses containing synthesized 290 addresses are tagged with an Extended DNS [RFC2671] option defined in 291 this document, called the SAS option, so the AAAA records can be 292 recognized as synthetic. This allows caching nameservers, dual stack 293 nodes and nodes implementing DNSSEC to ignore synthetic addresses and 294 perform an additional request for the original address records. 296 1.2.2. Walkthough 298 In this example, we consider an IPv6 node located in a IPv6-only site 299 that initiates a communication to a IPv4 node located in the IPv6 300 Internet. 302 The notation used is the following: upper case letters are IPv4 303 addresses; upper case letters with a prime(') are IPv6 addresses; 304 lower case letters are ports; prefixes are indicated by "P::X", which 305 is a IPv6 address built from an IPv4 address X by adding the prefix 306 P, mappings are indicated as "(X,x) <--> (Y',y)". 308 The scenario for this case is depicted in the following figure: 310 +---------------------------------------+ +-----------+ 311 |IPv6 site +-------------+ | | | 312 | +----+ | Name server | +-------+ | IPv4 | 313 | | H1 | | with DNS64 | | NAT64 |----| Internet | 314 | +----+ +-------------+ +-------+ +-----------+ 315 | |IP addr: Y' | | | |IP addr: X 316 | --------------------------------- | +----+ 317 +---------------------------------------+ | H2 | 318 +----+ 320 The figure shows a IPv6 node H1 which has an IPv6 address Y' and an 321 IPv4 node H2 with IPv4 address X. 323 A NAT64 connects the IPv6 network to the IPv4 Internet. This NAT64 324 has a /96 prefix (called Pref64::/96) associated to its IPv6 325 interface and an IPv4 address T assigned to its IPv4 interface. 327 Also shown is a local name server with DNS64 functionality. For the 328 purpose of this example, we assume that the name server is a dual- 329 stack node, so that H1 can contact it via IPv6, while it can contact 330 IPv4-only name servers via IPv4. 332 The local name server needs to know the /96 prefix assigned to the 333 local NAT64 (Pref64::/96). For the purpose of this example, we 334 assume it learns this through manual configuration. 336 For this example, assume the typical DNS situation where IPv6 hosts 337 have only stub resolvers and the local name server does the recursive 338 lookups. 340 The steps by which H1 establishes communication with H2 are: 342 1. H1 does a DNS lookup for the IPv6 address of H2. H1 does this by 343 sending a DNS query for an AAAA record for H2 to the local name 344 server. Assume the local name server is implementing DNS64 345 functionality. 347 2. The local DNS server resolves the query, and discovers that there 348 are no AAAA records for H2. 350 3. The name server queries for a A record for H2 and gets back an A 351 record containing the IPv4 address X. The name server then 352 synthesizes an AAAA record. The IPv6 address in the AAAA record 353 contains the prefix assigned to the NAT64 in the first 96 bits 354 and the IPv4 address X in the lower 32 bits. 356 4. The name server sends a response back to H1. If H1 has 357 indicated, in its query, that it supports the EDNS0, then the 358 name server will use the SAS option to indicate that the AAAA 359 record is synthetic. 361 5. H1 receives the synthetic AAAA record and sends a packet towards 362 H2. The packet is sent from a source transport address of (Y',y) 363 to a destination transport address of (Pref64:X,x), where y and x 364 are ports chosen by H2. 366 6. The packet is routed to the IPv6 interface of the NAT64 (since 367 Pref64::/96 has been associated to this interface). 369 7. The NAT64 receives the packet and performs the following actions: 371 * The NAT64 selects an unused port t on its IPv4 address T and 372 creates the mapping entry (Y',y) <--> (T,t) 374 * The NAT64 translates the IPv6 header into an IPv4 header using 375 SIIT. 377 * The NAT64 includes (T,t) as source transport address in the 378 packet and (X,x) as destination transport address in the 379 packet. Note that X is extracted directly from the lower 32 380 bits of the destination IPv6 address of the received IPv6 381 packet that is being translated. 383 The NAT64 sends the translated packet out its IPv4 interface and 384 the packet arrives at H2. 386 8. H2 node responds by sending a packet with destination transport 387 address (T,t) and source transport address (X,x). 389 9. The packet is routed to the NAT64 box, which will look for an 390 existing mapping containing (T,t). Since the mapping (Y',y) <--> 391 (T,t) exists, the NAT64 performs the following operations: 393 * The NAT64 translates the IPv4 header into an IPv6 header using 394 SIIT. 396 * The NAT64 includes (Y',y) as source transport address in the 397 packet and (Pref64:X,x) as destination transport address in 398 the packet. Note that X is extracted directly from the source 399 IPv4 address of the received IPv4 packet that is being 400 translated. 402 The translated packet is sent out the IPv6 interface to H2. 404 The packet exchange between H1 and H2 continues and packets are 405 translated in the different directions as previously described. 407 It is important to note that the translation still works if the IPv6 408 initiator H1 learns the IPv4 address through some scheme other than a 409 DNS look-up. This is because the DNS64 processing does NOT result in 410 any state installed in the NAT64 box and because the mapping of the 411 IPv4 address into an IPv6 address is the result of concatenating the 412 prefix defined within the site for this purpose (called Pref64::/96 413 in this document) to the original IPv4 address. 415 1.2.3. Dual stack nodes 417 Nodes that have both IPv6 and IPv4 connectivity and are configured 418 with an address for a DNS64 as their resolving nameserver may receive 419 responses containing synthetic AAAA resource records. If the node 420 prefers IPv6 over IPv4, using the addresses in the synthetic AAAA RRs 421 means that the node will attempt to communicate through the NAT64 422 mechanism first, and only fall back to native IPv4 connectivity if 423 connecting through NAT64 fails (if the application tries the full set 424 of destination addresses). To avoid this, dual stack nodes can 425 ignore all replies to DNS requests that contain the EDNS SAS option, 426 and use the destination addresses found in the responses for A 427 resource record requests instead. 429 1.2.4. IPv6 nodes implementing DNSSEC 431 Synthesizing resource records is incompatible with DNSSEC. So like 432 dual stack nodes, IPv6 nodes implementing DNSSec must not use 433 synthetic address records as indicated by the EDNS SAS option. In 434 this case, the node should perform the DNSSec validation on the 435 original A RR and then locally synthesize the AAAA RR. This 436 basically means that the DNS64 functionality should be implemented in 437 the local host for those hosts that want to be able to perform DNSSec 438 validation. In order to do that, hosts implementing DNS64 439 functionality should be able to discover Pref64::/96 prefix that is 440 needed to synthesize AAAA RR. The means used to discover the prefix 441 are out of the scope of this document. So for the purposes of 442 DNSSEC, the synthetic response doesn't exist, an IPv6 node 443 implementing DNSSEC has to request the original A resource records 444 and perform the normal DNSSEC validation steps. When this is done, 445 an IPv6 address is synthesized from the validated IPv4 address and 446 the translator /96 prefix locally. 448 1.2.5. Filtering 450 A NAT64 box may do filtering, which means that it only allows a 451 packet in through an interface if the appropriate permission exists. 452 A NAT64 may do no filtering, or it may filter on its IPv4 interface. 453 Filtering on the IPv6 interface is not supported, as mappings are 454 only created by packets traveling in the IPv6 --> IPv4 direction. 456 If a NAT64 filters on its IPv4 interface, then an incoming packet is 457 dropped unless a packet has been recently sent out the interface with 458 a destination IP address equal to the source IP address of the 459 incoming packet. 461 NAT64 filtering is consistent with the recommendations of RFC 4787. 463 2. Terminology 465 This section provides a definitive reference for all the terms used 466 in document. 468 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 469 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 470 document are to be interpreted as described in RFC 2119 [RFC2119]. 472 The following terms are used in this document: 474 DNS64: A logical function that synthesizes AAAA records (containing 475 IPv6 addresses) from A records (containing IPv4 addresses). 477 Synthetic RR: A DNS resource record (RR) that is not contained in 478 any zone data file, but has been synthesized from other RRs. An 479 example is a synthetic AAAA record created from an A record. 481 SAS Option: An Extended DNS (EDNS) option used in DNS responses. 482 Its primary purpose is to indicate that the set of AAAA RR 483 contained in a DNS response are synthetic. 485 NAT64: A device that translates IPv6 packets to IPv4 packets and 486 vice-versa, with the provision that the communication must be 487 initiated from the IPv6 side. The translation involves not only 488 the IP header, but also the transport header (TCP or UDP). 490 Session: A TCP or UDP session. In other words, the bi-directional 491 flow of packets between two ports on two different hosts. In 492 NAT64, typically one host is an IPv4 host, and the other one is an 493 IPv6 host. 495 5-Tuple: The tuple (source IP address, source port, destination IP 496 address, destination port, transport protocol). A 5-tuple 497 uniquely identifies a session. When a session flows through a 498 NAT64, each session has two different 5-tuples: one with IPv4 499 addresses and one with IPv6 addresses. 501 Session table: A table of sessions kept by a NAT64. Each NAT64 has 502 two session tables, one for TCP and one for UDP. 504 Transport Address: The combination of an IPv6 or IPv4 address and a 505 port. Typically written as (IP address, port); e.g. (192.0.2.15, 506 8001). 508 Mapping: A mapping between an IPv6 transport address and a IPv4 509 transport address. Used to translate the addresses and ports of 510 packets flowing between the IPv6 host and the IPv4 host. In 511 NAT64, the IPv4 transport address is always a transport address 512 assigned to the NAT64 itself, while the IPv6 transport address 513 belongs to some IPv6 host. 515 BIB: Binding Information Base. A table of mappings kept by a NAT64. 516 Each NAT64 has two BIBs, one for TCP and one for UDP. 518 Endpoint-Independent Mapping: In NAT64, using the same mapping for 519 all sessions between an IPv6 that have the same IPv6 transport 520 address endpoint. Endpoint-independent mapping is important for 521 peer-to-peer communication. See [RFC4787] for the definition of 522 the different types of mappings in IPv4-to-IPv4 NATs. 524 Hairpinning: Having a packet do a "U-turn" inside a NAT and come 525 back out the same interface as it arrived on. Hairpinning support 526 is important for peer-to-peer applications, as there are cases 527 when two different hosts on the same side of a NAT can only 528 communicate using sessions that hairpin though the NAT. 530 For a detailed understand of this document, the reader should also be 531 familiar with DNS terminology [RFC1035] and current NAT terminology 532 [RFC4787]. 534 3. Normative Specification 536 3.1. Synthentic AAAA RRs 538 A synthentic RR is an RR that does not appear in the master zone 539 file. 541 The rules on the usage of synthetic AAAA RRs are: 543 Synthetic AAAA RRs MAY be included in the answer section of a 544 response. 546 Synthetic AAAA RRs MUST NOT be included in sections other than the 547 answer section. 549 A synthetic AAAA RR MUST NOT be included if the responder knows of 550 at least one non-synthetic RR of the same type and class. 552 If a synthetic AAAA RR is included in the answer section, then all 553 RRs included in the answer section MUST be synthetic. 555 If a synthetic AAAA RR is _not_ explicitly marked as synthetic 556 (using the SAS option), then its TTL MUST be 0. 558 If a synthetic AAAA RR is explicitly marked as synthetic (using 559 the SAS option), then its TTL SHOULD be 0. 561 TBD: Can/should the AA bit be set in a response containing synthetic 562 RRs? 564 TBD: Do we always want synthetic RRs to have a TTL of 0? Is it ever 565 reasonable or desirable to cache them? 567 3.2. The EDNS SAS option 569 EDNS [RFC2671] defines a mechanism to add options to the DNS 570 [RFC1035] protocol. This section defines the SAS (Status of Answer 571 Section) option that indicates the status (real or synethetic) of RRs 572 in the answer section. 574 The format of the SAS option is: 575 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 576 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 577 | OPTION-CODE | 578 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 579 | OPTION-LENGTH | 580 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 581 | | 582 / OPTION-DATA / 583 | | 584 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 586 The fields are defined as follows: 588 o OPTION-CODE: (to be allocated by IANA) 590 o OPTION-LENGTH: the size (in octets) of the OPTION-DATA part of the 591 option 593 o OPTION-DATA: variable length field. No values for this field are 594 defined by this document. 596 For any OPTION-DATA defined in the future, the maximum length of the 597 OPTION-DATA field in the SAS option is 12 bytes, and any SAS option 598 with a OPTION-LENGTH of more than 8 SHOULD be silently ignored. 600 The rules on the usage of the SAS option are: 602 A requestor that understands the SAS option SHOULD include the OPT 603 RR in all queries. 605 A responder can include the SAS option in a response only if the 606 OPT RR appeared in the corresponding query. 608 Any options not understood or not meaningful in the current 609 context MUST be ignored. 611 A responder MUST include the SAS option in the response if it 612 knows that all the RRs in the answer section are synthetic. 614 The presence of the OPT RR in a query indicates that the requestor 615 understands the OPT extension. 617 3.3. DNS64 619 A DNS64 is a logical function that synthesizes AAAA records from A 620 records. The DNS64 function may be implemented in a resolver, in a 621 local recursive name server, or in some other device such as a NAT64. 623 The only configuration parameter required by the DNS64 is the /96 624 IPv6 prefix assigned to a NAT64. This prefix is used to map IPv4 625 addresses into IPv6 addresses, and is denoted Pref64::/96. The DNS64 626 learns this prefix through some means not specified here. 628 When the DNS64 receives a query for RRs of type AAAA and class IN, it 629 firsts attempts to retrieve non-synthetic RRs of this type and class 630 (where "non-synthetic RRs" means RRs not explicitly marked as 631 synthetic). If this query results in one or more AAAA records or in 632 an error condition, this result is returned to the client as per 633 normal DNS semantics. If the query is successful, but doesn't return 634 any answers, the DNS64 resolver executes a recursive A RR lookup for 635 the name in question. If this query results in an empty result or in 636 an error, this result is returned to the client. If the query 637 results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on 638 the A RRs and the /96 prefix of the translator. The synthetic AAAA 639 RRs get a TTL of 0 second. The DNS64 resolver then returns the 640 synthesized AAAA records to the client. If the client included the 641 EDNS0 OPT RR in the query, the DNS64 resolver MUST include an EDNS0 642 OPT RR that contains the SAS option. When synthesizing the answer to 643 a query for ANY, the DNS64 MUST include the A records from which the 644 AAAA records were synthesized. 646 To ensure endpoint-independent mapping behavior, a given IPv6 host 647 must always use the same NAT64. This, in turn, means that any 648 synthetic AAAA records used by the host must always use the same 649 prefix. To ensure this, if a DNS64 has multiple Pref64::/96 prefixes 650 configured, it SHOULD ensure that the same prefix is used for all 651 AAAA records returned to a given host across all queries. A 652 reasonable exception would be when the DNS64 knows, through some 653 unspecified means, that the NAT64 associated with a Pref64::/96 654 prefix is no longer functional. 656 Furthermore, it is highly desirable to synthesize the AAAA records as 657 close as possible to the host that will use them. This helps ensure 658 that a given host always uses the same NAT64. 660 The DNS64 MUST obey the rules for synthetic RRs (Section 3.1) and the 661 SAS option (Section 3.2). 663 A synthetic AAAA record is created from an A record as follows: 665 o The NAME field is set to the NAME field from the A record 667 o The TYPE field is set to 28 (AAAA) 669 o The CLASS field is set to 1 (IN) 671 o The TTL field is set as described in Section 3.1 673 o The RDLENGTH field is set to 16 675 o The RDATA field is set to the IPv6 address whose upper 96 bits are 676 Pref64::/96 and whose lower 32 bits are the IPv4 address from the 677 RDATA field of the A record. 679 TBD: What does a DNS64 do when a query for an A record returns a 680 CNAME record and an A record? The SAS option, as currently defined, 681 flags ALL records in the answer section as synthetic. Does the DNS64 682 return just a CNAME record? Does it return just an AAAA record? Or 683 does it return a real CNAME record and a synthetic AAAA record in the 684 answer section -- something that the current rules do not allow. 686 3.4. NAT64 688 A NAT64 is a device with one IPv6 interface and one IPv4 interface. 689 The IPv6 interface MUST have a unicast /96 IPv6 prefix assigned to 690 it, denoted Pref64::/96. The IPv4 interface MUST have one or more 691 unicast IPv4 addresses assigned to it. 693 A NAT64 uses the following dynamic data structures: 695 o UDP BIB 697 o UDP Session Table 699 o TCP BIB 701 o TCP Session Table 703 A NAT64 has two Binding Information Bases: one for TCP and one for 704 UDP. Each BIB entry specifies a mapping between an IPv6 transport 705 address and an IPv4 transport address: 707 (X',x) <--> (T,t) 709 where X' is some IPv6 address, T is an IPv4 address, and x and t are 710 ports. T will always be one of the IPv4 addresses assigned to the 711 IPv4 interface of the NAT64. A given IPv6 or IPv4 transport address 712 can appear in at most one entry in a BIB: for example, (2001:db8::17, 713 4) can appear in at most one TCP and at most one UDP BIB entry. TCP 714 and UDP have separate BIBs because the port number space for TCP and 715 UDP are distinct. 717 A NAT64 also has two session tables: one for TCP sessions and one for 718 UDP sessions. Each entry keeps information on the state of the 719 corresponding session: see Section 3.4.2. The NAT64 uses the session 720 state information to determine when the session is completed, and 721 also uses session information for ingress filtering. A session can 722 be uniquely identified by either an incoming 5-tuple or an outgoing 723 5-tuple. 725 For each session, there is a corresponding BIB entry, uniquely 726 specified by either the source IPv6 transport address (in the IPv6 727 --> IPv4 direction) or the destination IPv4 transport address (in the 728 IPv4 --> IPv6 direction). However, a single BIB entry can have 729 multiple corresponding sessions. When the last corresponding session 730 is deleted, the BIB entry is deleted. 732 The processing of an incoming IP packet takes the following steps: 734 1. Determining the incoming 5-tuple 736 2. Filtering and updating session information 738 3. Computing the outgoing 5-tuple 740 4. Translating the packet 742 5. Handling hairpinning 744 The details of these steps are specified in the following 745 subsections. 747 This breakdown of the NAT64 behavior into processing steps is done 748 for ease of presentation. A NAT64 MAY perform the steps in a 749 different order, or MAY perform different steps, as long as the 750 externally visible outcome in the same. 752 TBD: Add support for ICMP Query packets. (ICMP Error packets are 753 handled). 755 3.4.1. Determining the Incoming 5-tuple 757 This step associates a incoming 5-tuple (source IP address, source 758 port, destination IP address, destination port, transport protocol) 759 with every incoming IP packet for use in subsequent steps. 761 If the incoming IP packet contains a complete (un-fragmented) UDP or 762 TCP protocol packet, then the 5-tuple is computed by extracting the 763 appropriate fields from the packet. 765 If the incoming IP packet contains a complete (un-fragmented) ICMP 766 message, then the 5-tuple is computed by extracting the appropriate 767 fields from the IP packet embedded inside the ICMP message. However, 768 the role of source and destination is swapped when doing this: the 769 embedded source IP address becomes the destination IP address in the 770 5-tuple, the embedded source port becomes the destination port in the 771 5-tuple, etc. If it is not possible to determine the 5-tuple 772 (perhaps because not enough of the embedded packet is reproduced 773 inside the ICMP message), then the incoming IP packet is silently 774 discarded. 776 NOTE: The transport protocol is always one of TCP or UDP, even if 777 the IP packet contains an ICMP message. 779 If the incoming IP packet contains a fragment, then more processing 780 may be needed. This specification leaves open the exact details of 781 how a NAT64 handles incoming IP packets containing fragments, and 782 simply requires that a NAT64 handle fragments arriving out-of-order. 783 A NAT64 MAY elect to queue the fragments as they arrive and translate 784 all fragments at the same time. Alternatively, a NAT64 MAY translate 785 the fragments as they arrive, by storing information that allows it 786 to compute the 5-tuple for fragments other than the first. In the 787 latter case, the NAT64 will still need to handle the situation where 788 subsequent fragments arrive before the first. 790 Implementors of NAT64 should be aware that there are a number of 791 well-known attacks against IP fragmentation; see [RFC1858] and 792 [RFC3128]. 794 Assuming it otherwise has sufficient resources, a NAT64 MUST allow 795 the fragments to arrive over a time interval of at least 10 seconds. 796 A NAT64 MAY require that the UDP, TCP, or ICMP header be completely 797 contained within the first fragment. 799 3.4.2. Filtering and Updating Session Information 801 This step updates the per-session information stored in the 802 appropriate session table. This affects the lifetime of the session, 803 which in turn affects the lifetime of the corresponding BIB entry. 804 This step may also filter incoming packets, if desired. 806 The details of this step depend on the transport protocol (UDP or 807 TCP). 809 3.4.2.1. UDP Session Handling 811 The state information stored for a UDP session is a timer that tracks 812 the remaining lifetime of the UDP session. The NAT64 decrements this 813 timer at regular intervals. When the timer expires, the UDP session 814 is deleted. 816 The incoming packet is processed as follows: 818 1. If the packet arrived on the IPv4 interface and the NAT64 filters 819 on its IPv4 interface, then the NAT64 checks to see if the 820 incoming packet is allowed according to the address-dependent 821 filtering rule. To do this, it searches for a session table 822 entry with a source IPv4 address equal to the source IPv4 address 823 in the incoming 5-tuple. If such an entry is found (there may be 824 more than one), packet processing continues. Otherwise, the 825 packet is discarded. If the packet is discarded, then an ICMP 826 message SHOULD be sent to the original sender of the packet, 827 unless the discarded packet is itself an ICMP message. The ICMP 828 message, if sent, has a type of 3 (Destination Unreachable) and a 829 code of 13 (Communication Administratively Prohibited). 831 2. The NAT64 searches for the session table entry corresponding to 832 the incoming 5-tuple. If no such entry if found, a new entry is 833 created. 835 3. The NAT64 sets or resets the timer in the session table entry to 836 maximum session lifetime. By default, the maximum session 837 lifetime is 5 minutes, but for specific destination ports in the 838 Well-Known port range (0..1023), the NAT64 MAY use a smaller 839 maximum lifetime. 841 3.4.2.2. TCP Session Handling 843 TBD: Describe the state machine required to track the state of the 844 TCP session. This is a simplified version of the state machine used 845 by the endpoints. 847 3.4.3. Computing the Outgoing 5-Tuple 849 This step computes the outgoing 5-tuple by translating the addresses 850 and ports in the incoming 5-tuple. The transport protocol in the 851 outgoing 5-tuple is always the same as that in the incoming 5-tuple. 853 In the text below, a reference to the "the BIB" means either the TCP 854 BIB or the UDP BIB as appropriate, as determined by the transport 855 protocol in the 5-tuple. 857 NOTE: Not all addresses are translated using the BIB. BIB entries 858 are used to translate IPv6 source transport addresses to IPv4 859 source transport addresses, and IPv4 destination transport 860 addresses to IPv6 destination transport addresses. They are NOT 861 used to translate IPv6 destination transport addresses to IPv4 862 destination transport addresses, nor to translate IPv4 source 863 transport addresses to IPv6 source transport addresses. The 864 latter cases are handled by adding or removing the /96 prefix. 865 This distinction is important; without it, hairpinning doesn't 866 work correctly. 868 When translating in the IPv6 --> IPv4 direction, let the incoming 869 source and destination transport addresses in the 5-tuple be (S',s) 870 and (D',d) respectively. The outgoing source transport address is 871 computed as follows: 873 If the BIB contains a entry (S',s) <--> (T,t), then the outgoing 874 source transport address is (T,t). 876 Otherwise, create a new BIB entry (S',s) <--> (T,t) as described 877 below. The outgoing source transport address is (T,t). 879 The outgoing destination address is computed as follows: 881 If D' is composed of the NAT64's prefix followed by an IPv4 882 address D, then the outgoing destination transport address is 883 (D,d). 885 Otherwise, discard the packet. 887 When translating in the IPv4 --> IPv6 direction, let the incoming 888 source and destination transport addresses in the 5-tuple be (S,s) 889 and (D,d) respectively. The outgoing source transport address is 890 computed as follows: 892 The outgoing source transport address is (Pref64::S,s). 894 The outgoing destination transport address is computed as follows: 896 If the BIB contains an entry (X',x) <--> (D,d), then the outgoing 897 destination transport address is (X',x). 899 Otherwise, discard the packet. 901 If the rules specify that a new BIB entry is created for a source 902 transport address of (S',s), then the NAT64 allocates an IPv4 903 transport address for this BIB entry as follows: 905 If there exists some other BIB entry containing S' as the IPv6 906 address and mapping it to some IPv4 address T, then use T as the 907 IPv4 address. Otherwise, use any IPv4 address assigned to the 908 IPv4 interface. 910 If the port s is in the Well-Known port range 0..1023, then 911 allocate a port t from this same range. Otherwise, if the port s 912 is in the range 1024..65535, then allocate a port t from this 913 range. Furthermore, if port s is even, then t must be even, and 914 if port s is odd, then t must be odd. 916 In all cases, the allocated IPv4 transport address (T,t) MUST NOT 917 be in use in another entry in the same BIB, but MAY be in use in 918 the other BIB. 920 If it is not possible to allocate an appropriate IPv4 transport 921 address or create a BIB entry for some reason, then the packet is 922 discarded. 924 TBD: Do we delete the session entry if we cannot create a BIB entry? 926 If the rules specify that the packet is discarded, then the NAT64 927 SHOULD send an ICMP reply to the original sender, unless the packet 928 being translated contains an ICMP message. The type should be 3 929 (Destination Unreachable) and the code should be 0 (Network 930 Unreachable in IPv4, and No Route to Destination in IPv6). 932 3.4.4. Translating the Packet 934 This step translates the packet from IPv6 to IPv4 or vica-versa. 936 The translation of the packet is as specified in section 3 and 937 section 4 of SIIT [RFC2765], with the following modifications: 939 o When translating an IP header (sections 3.1 and 4.1), the source 940 and destination IP address fields are set to the source and 941 destination IP addresses from the outgoing 5-tuple. 943 o When the protocol following the IP header is TCP or UDP, then the 944 source and destination ports are modified to the source and 945 destination ports from the 5-tuple. In addition, the TCP or UDP 946 checksum must also be updated to reflect the translated addresses 947 and ports; note that the TCP and UDP checksum covers the pseudo- 948 header which contains the source and destination IP addresses. An 949 algorithm for efficently updating these checksums is described in 950 [RFC3022]. 952 o When the protocol following the IP header is ICMP (sections 3.4 953 and 4.4) the source and destination transport addresses in the 954 embedded packet are set to the destination and source transport 955 addresses from the outgoing 5-tuple (note the swap of source and 956 destination). 958 3.4.5. Handling Hairpinning 960 This step handles hairpinning if necessary. 962 If the destination IP address is an address assigned to the NAT64 963 itself (i.e., is one of the IPv4 addresses assigned to the IPv4 964 interface, or is covered by the /96 prefix assigned to the IPv6 965 interface), then the packet is a hairpin packet. The outgoing 966 5-tuple becomes the incoming 5-tuple, and the packet is treated as if 967 it was received on the outgoing interface. Processing of the packet 968 continues at step 2. 970 TBD: Is there such a thing as a hairpin loop (likely not naturally, 971 but perhaps through a special-crafted attack packet with a spoofed 972 source address)? If so, need to drop packets that hairpin more than 973 once. 975 3.5. FTP ALG 977 TBD: Describe the FTP ALG, a mechanism for translating the embedded 978 IP addresses inside FTP commands, that enables FTP sessions to pass 979 through NAT64. 981 4. Security Considerations 983 Implications on end-to-end security, IPSec and TLS. 985 Any protocol that protect IP header information are essentially 986 incompatible with NAT64. So, this implies that end to end IPSec 987 verification will fail when AH is used (both transport and tunnel 988 mode) and when ESP is used in transport mode. This is inherent to 989 any network layer translation mechanism. End-to-end IPsec protection 990 can be restored, using UDP encapsulation as described in [RFC2765]. 992 TBD: TLS implications 993 Implications on DNS security and DNSSec. 995 NAT64 uses synthetic DNS RR to enable IPv6 clients to initiate 996 communications with IPv4 servers using the DNS. This essentially 997 means that the DNS64 component generates synthetic AAAA RR that are 998 not contained in the master zone file. From a DNSSec perspective, 999 this means that the straight DNSSec verification of such RR would 1000 fail. However, it is possible to restore DNSSec functionality if the 1001 verification is performed right before the DNS64 processing directly 1002 using the original A RR of the IPv4 server. So, in order to jointly 1003 use the NAT64 appraoch described in thei specification and DNSSec 1004 validation, the DNS64 functionality should be performed in the 1005 resolver of the IPv6 client. In this case, the IPv6 client would 1006 receive the original A RR with DNSSec information and it would first 1007 perform the DNSSec validation. If it is succcessful, it would then 1008 proceed the synthetize the AAAA RR according to the mechanism 1009 described in this document. It should be noted that the synthetic 1010 AAAA RR would stay within the IPv6 client and it would not leak 1011 outside, making further DNSSec validations unnecesary. 1013 Filtering. 1015 NAT64 creates binding state using packets flowing from the IPv6 side 1016 to the IPv4 side. So, NAT64 implements by definition, at least, 1017 endpoint independent filtering, meaning that in order to enable any 1018 packet to flow from the IPv4 side to the IPv6 side, there must have 1019 been a packet flowing from the IPv6 side to the IPv4 side the created 1020 the binding information to be used for packets in the other 1021 direction. Endpoint independent filtering allows that once a binding 1022 is created, it can be used by any node on the IPv4 side to send 1023 packets to the IPv6 transport address that created the binding. This 1024 basically means that as long a the IPv6 node does not open a hole in 1025 the NAT64, incoming communications are blocked and that once that the 1026 IPv6 node has sent the first packet, this packet opens the door for 1027 any node on the IPv4 side to send packets to that IPv6 transport 1028 address. It is possible to configure the NAT64 to implement more 1029 stringent security policy, if endpoint independent mapping is 1030 considered not secure enough. In particular, if the security policy 1031 of the NAT64 requires it, is it possible to configure the NAT64 to 1032 perform address dependent filtering. This basically means that the 1033 binding state created can only be used by to send packets from the 1034 IPv4 address to which the original packet that created the binding 1035 was sent to. This basically means that the door is open only for 1036 that IPv4 address to send packet to the IPv6 transport address. 1038 Attacks to NAT64. 1040 The NAT64 device itself is a potential victim of different type of 1041 attacks. In particular, the NAT64 can be a victim of DoS attacks. 1042 The NAT64 box has a limited number of resources that can be consumed 1043 by attackers creating a DoS attack. The NAT64 has a limited number 1044 of IPv4 address that is uses to create the bindings. Even though the 1045 NAT64 performs address and port translation, it is possible for an 1046 attacker to consume all the IPv4 transport addresses by sending IPv6 1047 packets with different source IPv6 transport address. It should be 1048 noted that this attack can only be launched from the IPv6 side, since 1049 IPv4 packets are not used to create binding state. DoS attacks can 1050 also affect other limited resource available in the NAT64 such as 1051 memory or link capacity. For instance, if the NAT64 implements 1052 reassembly of fragmented packets, it is possible for an attacker to 1053 launch a DoS attack to the memory of the NAT64 device by sending 1054 fragments that the NAT64 will store for a given period. If the 1055 number of fragments if high enough, the memory of the NAT64 could be 1056 exhausted. NAT64 devices should implement proper protection against 1057 such attacks, for instance allocating a limited amount of memory for 1058 fragmented packet storage. 1060 5. IANA Considerations 1062 The IANA is requested to assign an EDNS Option Code value for the SAS 1063 option. 1065 TBD: Set up an IANA registry for SAS flags?? 1067 6. Changes from Previous Draft Versions 1069 Note to RFC Editor: Please remove this section prior to publication 1070 of this document as an RFC. 1072 [[This section lists the changes between the various versions of this 1073 draft.]] 1075 7. Contributors 1077 George Tsirtsis 1079 Qualcomm 1081 tsirtsis@googlemail.com 1083 8. Acknowledgements 1085 Alberto Garcia-Martinez and Joao Damas reviewed the document and 1086 provided useful comments to improve it. 1088 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 1089 Trilogy, a research project supported by the European Commission 1090 under its Seventh Framework Program. 1092 9. References 1094 9.1. Normative References 1096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1097 Requirement Levels", BCP 14, RFC 2119, March 1997. 1099 [RFC1035] Mockapetris, P., "Domain names - implementation and 1100 specification", STD 13, RFC 1035, November 1987. 1102 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1103 RFC 2671, August 1999. 1105 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1106 (SIIT)", RFC 2765, February 2000. 1108 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1109 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1110 RFC 4787, January 2007. 1112 [I-D.ietf-behave-tcp] 1113 Guha, S., "NAT Behavioral Requirements for TCP", 1114 draft-ietf-behave-tcp-07 (work in progress), April 2007. 1116 [I-D.ietf-behave-nat-icmp] 1117 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1118 Behavioral Requirements for ICMP protocol", 1119 draft-ietf-behave-nat-icmp-08 (work in progress), 1120 June 2008. 1122 9.2. Informative References 1124 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1125 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1126 February 2000. 1128 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1129 Considerations for IP Fragment Filtering", RFC 1858, 1130 October 1995. 1132 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1133 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1135 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1136 Address Translator (Traditional NAT)", RFC 3022, 1137 January 2001. 1139 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 1140 Address Translator - Protocol Translator (NAT-PT) to 1141 Historic Status", RFC 4966, July 2007. 1143 [I-D.ietf-mmusic-ice] 1144 Rosenberg, J., "Interactive Connectivity Establishment 1145 (ICE): A Protocol for Network Address Translator (NAT) 1146 Traversal for Offer/Answer Protocols", 1147 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1149 [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of 1150 Managed Objects for Synchronous Optical Network (SONET) 1151 Linear Automatic Protection Switching (APS) 1152 Architectures", RFC 3498, March 2003. 1154 Authors' Addresses 1156 Marcelo Bagnulo 1157 UC3M 1158 Av. Universidad 30 1159 Leganes, Madrid 28911 1160 Spain 1162 Phone: +34-91-6249500 1163 Fax: 1164 Email: marcelo@it.uc3m.es 1165 URI: http://www.it.uc3m.es/marcelo 1167 Philip Matthews 1168 Unaffiliated 1170 Email: philip_matthews@magma.ca 1171 URI: 1173 Iljitsch van Beijnum 1174 IMDEA Networks 1175 Av. Universidad 30 1176 Leganes, Madrid 28911 1177 Spain 1179 Phone: +34-91-6246245 1180 Email: iljitsch@muada.com 1182 Full Copyright Statement 1184 Copyright (C) The IETF Trust (2008). 1186 This document is subject to the rights, licenses and restrictions 1187 contained in BCP 78, and except as set forth therein, the authors 1188 retain all their rights. 1190 This document and the information contained herein are provided on an 1191 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1192 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1193 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1194 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1195 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1196 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1198 Intellectual Property 1200 The IETF takes no position regarding the validity or scope of any 1201 Intellectual Property Rights or other rights that might be claimed to 1202 pertain to the implementation or use of the technology described in 1203 this document or the extent to which any license under such rights 1204 might or might not be available; nor does it represent that it has 1205 made any independent effort to identify any such rights. Information 1206 on the procedures with respect to rights in RFC documents can be 1207 found in BCP 78 and BCP 79. 1209 Copies of IPR disclosures made to the IETF Secretariat and any 1210 assurances of licenses to be made available, or the result of an 1211 attempt made to obtain a general license or permission for the use of 1212 such proprietary rights by implementers or users of this 1213 specification can be obtained from the IETF on-line IPR repository at 1214 http://www.ietf.org/ipr. 1216 The IETF invites any interested party to bring to its attention any 1217 copyrights, patents or patent applications, or other proprietary 1218 rights that may cover technology that may be required to implement 1219 this standard. Please address the information to the IETF at 1220 ietf-ipr@ietf.org.