idnits 2.17.1 draft-bagnulo-behave-nat64-03.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.ii 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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2009) is 5529 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 1069, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-ice' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'RFC3498' is defined on line 1125, 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) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE WG M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Standards Track P. Matthews 5 Expires: September 8, 2009 Alcatel-Lucent 6 I. van Beijnum 7 IMDEA Networks 8 March 7, 2009 10 NAT64: Network Address and Protocol Translation from IPv6 Clients to 11 IPv4 Servers 12 draft-bagnulo-behave-nat64-03 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 September 8, 2009. 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 . . . . . . . . . . . . . . . . . . . . 4 75 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.2.1. NAT64 solution elements . . . . . . . . . . . . . . . 6 77 1.2.2. Walkthough . . . . . . . . . . . . . . . . . . . . . . 7 78 1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 9 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3. NAT64 Normative Specification . . . . . . . . . . . . . . . . 11 81 3.1. Determining the Incoming 5-tuple . . . . . . . . . . . . . 13 82 3.2. Filtering and Updating Session Information . . . . . . . . 14 83 3.2.1. UDP Session Handling . . . . . . . . . . . . . . . . . 14 84 3.2.2. TCP Session Handling . . . . . . . . . . . . . . . . . 15 85 3.2.3. Computing the Outgoing 5-Tuple . . . . . . . . . . . . 15 86 3.2.4. Translating the Packet . . . . . . . . . . . . . . . . 16 87 3.2.5. Handling Hairpinning . . . . . . . . . . . . . . . . . 17 88 3.3. FTP ALG . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 4. Application scenarios . . . . . . . . . . . . . . . . . . . . 17 90 4.1. Enterprise IPv6 only network . . . . . . . . . . . . . . . 18 91 4.2. Reaching servers in private IPv4 space . . . . . . . . . . 18 92 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 5.1. About the Prefix used to map the IPv4 address space 94 into IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 19 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 97 8. Changes from Previous Draft Versions . . . . . . . . . . . . . 23 98 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 105 1. Introduction 107 This document specifies NAT64, a mechanism for IPv6-IPv4 transition 108 and co-existence. Together with DNS64 [I-D.bagnulo-behave-dns64], 109 these two mechanisms allow a IPv6-only client to initiate 110 communications to an IPv4-only server, and also allow peer-to-peer 111 communication between IPv6-only and IPv4-only hosts. 113 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets. 114 The translation is done by translating the packet headers according 115 to SIIT [RFC2765], translating the IPv4 server address by adding or 116 removing a /96 prefix, and translating the IPv6 client address by 117 installing mappings in the normal NAT manner. 119 DNS64 is a mechanism for synthesizing AAAA resource records (RR) from 120 A RR. The synthesis is done by adding a /96 prefix to the IPv4 121 address to create an IPv6 address, where the /96 prefix is assigned 122 to a NAT64 device. 124 Together, these two mechanisms allow a IPv6-only client to initiate 125 communications to an IPv4-only server. 127 These mechanisms are expected to play a critical role in the IPv4- 128 IPv6 transition and co-existence. Due to IPv4 address depletion, 129 it's likely that in the future, a lot of IPv6-only clients will want 130 to connect to IPv4-only servers. The NAT64 and DNS64 mechanisms are 131 easily deployable, since they require no changes to either the IPv6 132 client nor the IPv4 server. For basic functionality, the approach 133 only requires the deployment of NAT64-enabled devices connecting an 134 IPv6-only network to the IPv4-only Internet, along with the 135 deployment of a few DNS64-enabled name servers in the IPv6-only 136 network. However, some advanced features require software updates to 137 the IPv6-only hosts. 139 The NAT64 and DNS64 mechanisms are related to the NAT-PT mechanism 140 defined in [RFC2766], but significant differences exist. First, 141 NAT64 does not define the NATPT mechanisms used to support IPv6 only 142 servers to be contacted by IPv4 only clients, but only defines the 143 mechanisms for IPv6 clients to contact IPv4 servers and its potential 144 reuse to support peer to peer communications through standard NAT 145 traversal techniques. Second, NAT64 includes a set of features that 146 overcomes many of the reasons the original NAT-PT specification was 147 moved to historic status [RFC4966]. 149 1.1. Features of NAT64 151 The features of NAT64 and DNS64 are: 153 o It enables IPv6-only nodes to initiate a client-server connection 154 with an IPv4-only server, without needing any changes on either 155 IPv4 or IPv6 nodes. This works for the same class of applications 156 that work through IPv4-to-IPv4 NATs. 158 o It supports peer-to-peer communication between IPv4 and IPv6 159 nodes, including the ability for IPv4 nodes to initiate 160 communcation with IPv6 nodes using peer-to-peer techniques (i.e., 161 using a rendezvous server and ICE). To this end, NAT64 is 162 compliant with the recommendations for how NATs should handle UDP 163 [RFC4787], TCP [I-D.ietf-behave-tcp], and ICMP 164 [I-D.ietf-behave-nat-icmp]. 166 o Compatible with ICE. 168 o Supports additional features with some changes on nodes. These 169 features include: 171 * Support for DNSSec 173 * Some forms of IPSec support 175 1.2. Overview 177 This section provides a non-normative introduction to the mechanisms 178 of NAT64. 180 NAT64 mechanism is implemented in an NAT64 box which has two 181 interfaces, an IPv4 interface connected to the the IPv4 network, and 182 an IPv6 interface connected to the IPv6 network. Packets generated 183 in the IPv6 network for a receiver located in the IPv4 network will 184 be routed within the IPv6 network towards the NAT64 box. The NAT64 185 box will translate them and forward them as IPv4 packets through the 186 IPv4 network to the IPv4 receiver. The reverse takes place for 187 packets generated in the IPv4 network for an IPv6 receiver. NAT64, 188 however, is not symmetric. In order to be able to perform IPv6 - 189 IPv4 translation NAT64 requires state, binding an IPv6 address and 190 port (hereafter called an IPv6 transport address) to an IPv4 address 191 and port (hereafter called an IPv4 transport address). 193 Such binding state is created when the first packet flowing from the 194 IPv6 network to the IPv4 network is translated. After the binding 195 state has been created, packets flowing in either direction on that 196 particular flow are translated. The result is that NAT64 only 197 supports communications initiated by the IPv6-only node towards an 198 IPv4-only node. Some additional mechanisms, like ICE, can be used in 199 combination with NAT64 to provide support for communications 200 initiated by the IPv4-only node to the IPv6-only node. The 201 specification of such mechanisms, however, is out of the scope of 202 this document. 204 1.2.1. NAT64 solution elements 206 In this section we describe the different elements involved in the 207 NAT64 approach. 209 The main component of the proposed solution is the translator itself. 210 The translator has essentially two main parts, the address 211 translation mechanism and the protocol translation mechanism. 213 Protocol translation from IPv4 packet header to IPv6 packet header 214 and vice-versa is performed according to SIIT [RFC2765]. 216 Address translation maps IPv6 transport addresses to IPv4 transport 217 addresses and vice-versa. In order to create these mappings the 218 NAT64 box has two pools of addresses i.e. an IPv6 address pool (to 219 represent IPv4 addresses in the IPv6 network) and an IPv4 address 220 pool (to represent IPv6 addresses in the IPv4 network). Since there 221 is enough IPv6 address space, it is possible to map every IPv4 222 address into a different IPv6 address. 224 NAT64 creates the required mappings by using as the IPv6 address pool 225 a /96 IPv6 prefix (hereafter called Pref64::/96). This allows each 226 IPv4 address to be mapped into a different IPv6 address by simply 227 concatenating the /96 prefix assigned as the IPv6 address pool of the 228 NAT64, with the IPv4 address being mapped (i.e. an IPv4 address X is 229 mapped into the IPv6 address Pref64:X). The NAT64 prefix Pref64::/96 230 is assigned by the administrator of the NAT64 box from the global 231 unicast IPv6 address block assigned to the site. It should be noted 232 that the the prefix used as the IPv6 address pool is assigned to a 233 specific NAT64 box and if there are multiple NAT64 boxes, each box is 234 allocated a different prefix. Assigning the same prefix to multiple 235 boxes may lead to communication failures due to internal routing 236 fluctuations. 238 The IPv4 address pool, however, is a set of IPv4 addresses, normally 239 a small prefix assigned by the local administrator to the NAT64's 240 external (IPv4) interface. Since IPv4 address space is a scarce 241 resource, the IPv4 address pool is small and typically not sufficient 242 to establish permanent one-to-one mappings with IPv6 addresses. So, 243 mappings using the IPv4 address pool will be created and released 244 dynamically. Moreover, because of the IPv4 address scarcity, the 245 usual practice for NAT64 is likely to be the mapping of IPv6 246 transport addresses into IPv4 transport addresses, instead of IPv6 247 addresses into IPv4 addresses directly, which enable a higher 248 utilization of the limited IPv4 address pool. 250 Because of the dynamic nature of the IPv6 to IPv4 address mapping and 251 the static nature of the IPv4 to IPv6 address mapping, it is easy to 252 understand that it is far simpler to allow communication initiated 253 from the IPv6 side toward an IPv4 node, which address is permanently 254 mapped into an IPv6 address, than communications initiated from IPv4- 255 only nodes to an IPv6 node in which case IPv4 address needs to be 256 associated with it dynamically. For this reason NAT64 supports only 257 communications initiated from the IPv6 side. 259 An IPv6 initiator can know or derive in advance the IPv6 address 260 representing the IPv4 target and send packets to that address. The 261 packets are intercepted by the NAT64 device, which associates an IPv4 262 transport address of its IPv4 pool to the IPv6 transport address of 263 the initiator, creating binding state, so that reply packets can be 264 translated and forwarded back to the initiator. The binding state is 265 kept while packets are flowing. Once the flow stops, and based on a 266 timer, the IPv4 transport address is returned to the IPv4 address 267 pool so that it can be reused for other communications. 269 To allow an IPv6 initiator to do the standard DNS lookup to learn the 270 address of the responder, DNS64 [I-D.bagnulo-behave-dns64] is used to 271 synthesize an AAAA record from the A record (containing the real IPv4 272 address of the responder). DNS64 receives the DNS queries generated 273 by the IPv6 initiator. If there is no AAAA record available for the 274 target node (which is the normal case when the target node is an 275 IPv4-only node), DNS64 performs a query for the A record. If an A 276 record is discovered, DNS64 creates a synthetic AAAA RR by adding the 277 Pref64::/96 of a NAT64 to the responder's IPv4 address (i.e. if the 278 IPv4 node has IPv4 address X, then the synthetic AAAA RR will contain 279 the IPv6 address formed as Pref64:X). The synthetic AAAA RR is 280 passed back to the IPv6 initiator, which will initiate an IPv6 281 communication with the IPv6 address associated to the IPv4 receiver. 282 The packet will be routed to the NAT64 device, which will create the 283 IPv6 to IPv4 address mapping as described before. 285 1.2.2. Walkthough 287 In this example, we consider an IPv6 node located in a IPv6-only site 288 that initiates a communication to a IPv4 node located in the IPv6 289 Internet. 291 The notation used is the following: upper case letters are IPv4 292 addresses; upper case letters with a prime(') are IPv6 addresses; 293 lower case letters are ports; prefixes are indicated by "P::X", which 294 is a IPv6 address built from an IPv4 address X by adding the prefix 295 P, mappings are indicated as "(X,x) <--> (Y',y)". 297 The scenario for this case is depicted in the following figure: 299 +---------------------------------------+ +-----------+ 300 |IPv6 site +-------------+ | | | 301 | +----+ | Name server | +-------+ | IPv4 | 302 | | H1 | | with DNS64 | | NAT64 |----| Internet | 303 | +----+ +-------------+ +-------+ +-----------+ 304 | |IP addr: Y' | | | |IP addr: X 305 | --------------------------------- | +----+ 306 +---------------------------------------+ | H2 | 307 +----+ 309 The figure shows a IPv6 node H1 which has an IPv6 address Y' and an 310 IPv4 node H2 with IPv4 address X. 312 A NAT64 connects the IPv6 network to the IPv4 Internet. This NAT64 313 has a /96 prefix (called Pref64::/96) associated to its IPv6 314 interface and an IPv4 address T assigned to its IPv4 interface. 316 Also shown is a local name server with DNS64 functionality. For the 317 purpose of this example, we assume that the name server is a dual- 318 stack node, so that H1 can contact it via IPv6, while it can contact 319 IPv4-only name servers via IPv4. 321 The local name server needs to know the /96 prefix assigned to the 322 local NAT64 (Pref64::/96). For the purpose of this example, we 323 assume it learns this through manual configuration. 325 For this example, assume the typical DNS situation where IPv6 hosts 326 have only stub resolvers and the local name server does the recursive 327 lookups. 329 The steps by which H1 establishes communication with H2 are: 331 1. H1 performs a DNS query for FQDN(H2) and receives the synthetic 332 AAAA RR from the local name server that implements the DNS64 333 functionality. The AAAA record contains an IPv6 address formed 334 by the PRefix64::/96 associated to the NAT64 box and the IPv4 335 address of H2 in the lower 32 bits. 337 2. H1 sends a packet to H2. The packet is sent from a source 338 transport address of (Y',y) to a destination transport address of 339 (Pref64:X,x), where y and x are ports chosen by H1. 341 3. The packet is routed to the IPv6 interface of the NAT64 (since 342 Pref64::/96 has been associated to this interface). 344 4. The NAT64 receives the packet and performs the following actions: 346 * The NAT64 selects an unused port t on its IPv4 address T and 347 creates the mapping entry (Y',y) <--> (T,t) 349 * The NAT64 translates the IPv6 header into an IPv4 header using 350 SIIT. 352 * The NAT64 includes (T,t) as source transport address in the 353 packet and (X,x) as destination transport address in the 354 packet. Note that X is extracted directly from the lower 32 355 bits of the destination IPv6 address of the received IPv6 356 packet that is being translated. 358 The NAT64 sends the translated packet out its IPv4 interface and 359 the packet arrives at H2. 361 5. H2 node responds by sending a packet with destination transport 362 address (T,t) and source transport address (X,x). 364 6. The packet is routed to the NAT64 box, which will look for an 365 existing mapping containing (T,t). Since the mapping (Y',y) <--> 366 (T,t) exists, the NAT64 performs the following operations: 368 * The NAT64 translates the IPv4 header into an IPv6 header using 369 SIIT. 371 * The NAT64 includes (Y',y) as destination transport address in 372 the packet and (Pref64:X,x) as source transport address in the 373 packet. Note that X is extracted directly from the source 374 IPv4 address of the received IPv4 packet that is being 375 translated. 377 The translated packet is sent out the IPv6 interface to H1. 379 The packet exchange between H1 and H2 continues and packets are 380 translated in the different directions as previously described. 382 It is important to note that the translation still works if the IPv6 383 initiator H1 learns the IPv4 address through some scheme other than a 384 DNS look-up. This is because the DNS64 processing does NOT result in 385 any state installed in the NAT64 box and because the mapping of the 386 IPv4 address into an IPv6 address is the result of concatenating the 387 prefix defined within the site for this purpose (called Pref64::/96 388 in this document) to the original IPv4 address. 390 1.2.3. Filtering 392 A NAT64 box may do filtering, which means that it only allows a 393 packet in through an interface if the appropriate permission exists. 395 A NAT64 may do no filtering, or it may filter on its IPv4 interface. 396 Filtering on the IPv6 interface is not supported, as mappings are 397 only created by packets traveling in the IPv6 --> IPv4 direction. 399 If a NAT64 performs address-dependent filtering according to RFC4787 400 [RFC4787] on its IPv4 interface, then an incoming packet is dropped 401 unless a packet has been recently sent out the interface with a 402 destination IP address equal to the source IP address of the incoming 403 packet. 405 NAT64 filtering is consistent with the recommendations of RFC 4787 406 [RFC4787]. 408 2. Terminology 410 This section provides a definitive reference for all the terms used 411 in document. 413 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 414 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 415 document are to be interpreted as described in RFC 2119 [RFC2119]. 417 The following terms are used in this document: 419 DNS64: A logical function that synthesizes AAAA records (containing 420 IPv6 addresses) from A records (containing IPv4 addresses). 422 Synthetic RR: A DNS resource record (RR) that is not contained in 423 any zone data file, but has been synthesized from other RRs. An 424 example is a synthetic AAAA record created from an A record. 426 NAT64: A device that translates IPv6 packets to IPv4 packets and 427 vice-versa, with the provision that the communication must be 428 initiated from the IPv6 side. The translation involves not only 429 the IP header, but also the transport header (TCP or UDP). 431 Session: A TCP or UDP session. In other words, the bi-directional 432 flow of packets between two ports on two different hosts. In 433 NAT64, typically one host is an IPv4 host, and the other one is an 434 IPv6 host. 436 5-Tuple: The tuple (source IP address, source port, destination IP 437 address, destination port, transport protocol). A 5-tuple 438 uniquely identifies a session. When a session flows through a 439 NAT64, each session has two different 5-tuples: one with IPv4 440 addresses and one with IPv6 addresses. 442 Session table: A table of sessions kept by a NAT64. Each NAT64 has 443 two session tables, one for TCP and one for UDP. 445 Transport Address: The combination of an IPv6 or IPv4 address and a 446 port. Typically written as (IP address, port); e.g. (192.0.2.15, 447 8001). 449 Mapping: A mapping between an IPv6 transport address and a IPv4 450 transport address. Used to translate the addresses and ports of 451 packets flowing between the IPv6 host and the IPv4 host. In 452 NAT64, the IPv4 transport address is always a transport address 453 assigned to the NAT64 itself, while the IPv6 transport address 454 belongs to some IPv6 host. 456 BIB: Binding Information Base. A table of mappings kept by a NAT64. 457 Each NAT64 has two BIBs, one for TCP and one for UDP. 459 Endpoint-Independent Mapping: In NAT64, using the same mapping for 460 all sessions between an IPv6 that have the same IPv6 transport 461 address endpoint. Endpoint-independent mapping is important for 462 peer-to-peer communication. See [RFC4787] for the definition of 463 the different types of mappings in IPv4-to-IPv4 NATs. 465 Hairpinning: Having a packet do a "U-turn" inside a NAT and come 466 back out the same interface as it arrived on. Hairpinning support 467 is important for peer-to-peer applications, as there are cases 468 when two different hosts on the same side of a NAT can only 469 communicate using sessions that hairpin though the NAT. 471 For a detailed understanding of this document, the reader should also 472 be familiar with DNS terminology [RFC1035] and current NAT 473 terminology [RFC4787]. 475 3. NAT64 Normative Specification 477 A NAT64 is a device with one IPv6 interface and one IPv4 interface. 478 The IPv6 interface MUST have a unicast /96 IPv6 prefix assigned to 479 it, denoted Pref64::/96. The IPv4 interface MUST have one or more 480 unicast IPv4 addresses assigned to it. 482 A NAT64 uses the following dynamic data structures: 484 o UDP BIB 486 o UDP Session Table 487 o TCP BIB 489 o TCP Session Table 491 A NAT64 has two Binding Information Bases: one for TCP and one for 492 UDP. Each BIB entry specifies a mapping between an IPv6 transport 493 address and an IPv4 transport address: 495 (X',x) <--> (T,t) 497 where X' is some IPv6 address, T is an IPv4 address, and x and t are 498 ports. T will always be one of the IPv4 addresses assigned to the 499 IPv4 interface of the NAT64. A given IPv6 or IPv4 transport address 500 can appear in at most one entry in a BIB: for example, (2001:db8::17, 501 4) can appear in at most one TCP and at most one UDP BIB entry. TCP 502 and UDP have separate BIBs because the port number space for TCP and 503 UDP are distinct. 505 A NAT64 also has two session tables: one for TCP sessions and one for 506 UDP sessions. Each entry keeps information on the state of the 507 corresponding session: see Section 3.2. The NAT64 uses the session 508 state information to determine when the session is completed, and 509 also uses session information for ingress filtering. A session can 510 be uniquely identified by either an incoming 5-tuple or an outgoing 511 5-tuple. 513 For each session, there is a corresponding BIB entry, uniquely 514 specified by either the source IPv6 transport address (in the IPv6 515 --> IPv4 direction) or the destination IPv4 transport address (in the 516 IPv4 --> IPv6 direction). However, a single BIB entry can have 517 multiple corresponding sessions. When the last corresponding session 518 is deleted, the BIB entry is deleted. 520 The processing of an incoming IP packet takes the following steps: 522 1. Determining the incoming 5-tuple 524 2. Filtering and updating session information 526 3. Computing the outgoing 5-tuple 528 4. Translating the packet 530 5. Handling hairpinning 532 The details of these steps are specified in the following 533 subsections. 535 This breakdown of the NAT64 behavior into processing steps is done 536 for ease of presentation. A NAT64 MAY perform the steps in a 537 different order, or MAY perform different steps, as long as the 538 externally visible outcome in the same. 540 TBD: Add support for ICMP Query packets. (ICMP Error packets are 541 handled). 543 3.1. Determining the Incoming 5-tuple 545 This step associates a incoming 5-tuple (source IP address, source 546 port, destination IP address, destination port, transport protocol) 547 with every incoming IP packet for use in subsequent steps. 549 If the incoming IP packet contains a complete (un-fragmented) UDP or 550 TCP protocol packet, then the 5-tuple is computed by extracting the 551 appropriate fields from the packet. 553 If the incoming IP packet contains a complete (un-fragmented) ICMP 554 message, then the 5-tuple is computed by extracting the appropriate 555 fields from the IP packet embedded inside the ICMP message. However, 556 the role of source and destination is swapped when doing this: the 557 embedded source IP address becomes the destination IP address in the 558 5-tuple, the embedded source port becomes the destination port in the 559 5-tuple, etc. If it is not possible to determine the 5-tuple 560 (perhaps because not enough of the embedded packet is reproduced 561 inside the ICMP message), then the incoming IP packet is silently 562 discarded. 564 NOTE: The transport protocol is always one of TCP or UDP, even if 565 the IP packet contains an ICMP message. 567 If the incoming IP packet contains a fragment, then more processing 568 may be needed. This specification leaves open the exact details of 569 how a NAT64 handles incoming IP packets containing fragments, and 570 simply requires that a NAT64 handle fragments arriving out-of-order. 571 A NAT64 MAY elect to queue the fragments as they arrive and translate 572 all fragments at the same time. Alternatively, a NAT64 MAY translate 573 the fragments as they arrive, by storing information that allows it 574 to compute the 5-tuple for fragments other than the first. In the 575 latter case, the NAT64 will still need to handle the situation where 576 subsequent fragments arrive before the first. 578 Implementors of NAT64 should be aware that there are a number of 579 well-known attacks against IP fragmentation; see [RFC1858] and 580 [RFC3128]. 582 Assuming it otherwise has sufficient resources, a NAT64 MUST allow 583 the fragments to arrive over a time interval of at least 10 seconds. 584 A NAT64 MAY require that the UDP, TCP, or ICMP header be completely 585 contained within the first fragment. 587 3.2. Filtering and Updating Session Information 589 This step updates the per-session information stored in the 590 appropriate session table. This affects the lifetime of the session, 591 which in turn affects the lifetime of the corresponding BIB entry. 592 This step may also filter incoming packets, if desired. 594 The details of this step depend on the transport protocol (UDP or 595 TCP). 597 3.2.1. UDP Session Handling 599 The state information stored for a UDP session is a timer that tracks 600 the remaining lifetime of the UDP session. The NAT64 decrements this 601 timer at regular intervals. When the timer expires, the UDP session 602 is deleted. 604 The incoming packet is processed as follows: 606 1. If the packet arrived on the IPv4 interface and the NAT64 filters 607 on its IPv4 interface, then the NAT64 checks to see if the 608 incoming packet is allowed according to the address-dependent 609 filtering rule. To do this, it searches for a session table 610 entry with a destination IPv4 address equal to the source IPv4 611 address in the incoming 5-tuple. If such an entry is found 612 (there may be more than one), packet processing continues. 613 Otherwise, the packet is discarded. If the packet is discarded, 614 then an ICMP message SHOULD be sent to the original sender of the 615 packet, unless the discarded packet is itself an ICMP message. 616 The ICMP message, if sent, has a type of 3 (Destination 617 Unreachable) and a code of 13 (Communication Administratively 618 Prohibited). 620 2. The NAT64 searches for the session table entry corresponding to 621 the incoming 5-tuple. If no such entry if found, a new entry is 622 created. 624 3. The NAT64 sets or resets the timer in the session table entry to 625 maximum session lifetime. By default, the maximum session 626 lifetime is 5 minutes, but for specific destination ports in the 627 Well-Known port range (0..1023), the NAT64 MAY use a smaller 628 maximum lifetime. 630 3.2.2. TCP Session Handling 632 TBD: Describe the state machine required to track the state of the 633 TCP session. This is a simplified version of the state machine used 634 by the endpoints. 636 3.2.3. Computing the Outgoing 5-Tuple 638 This step computes the outgoing 5-tuple by translating the addresses 639 and ports in the incoming 5-tuple. The transport protocol in the 640 outgoing 5-tuple is always the same as that in the incoming 5-tuple. 642 In the text below, a reference to the "the BIB" means either the TCP 643 BIB or the UDP BIB as appropriate, as determined by the transport 644 protocol in the 5-tuple. 646 NOTE: Not all addresses are translated using the BIB. BIB entries 647 are used to translate IPv6 source transport addresses to IPv4 648 source transport addresses, and IPv4 destination transport 649 addresses to IPv6 destination transport addresses. They are NOT 650 used to translate IPv6 destination transport addresses to IPv4 651 destination transport addresses, nor to translate IPv4 source 652 transport addresses to IPv6 source transport addresses. The 653 latter cases are handled by adding or removing the /96 prefix. 654 This distinction is important; without it, hairpinning doesn't 655 work correctly. 657 When translating in the IPv6 --> IPv4 direction, let the incoming 658 source and destination transport addresses in the 5-tuple be (S',s) 659 and (D',d) respectively. The outgoing source transport address is 660 computed as follows: 662 If the BIB contains a entry (S',s) <--> (T,t), then the outgoing 663 source transport address is (T,t). 665 Otherwise, create a new BIB entry (S',s) <--> (T,t) as described 666 below. The outgoing source transport address is (T,t). 668 The outgoing destination address is computed as follows: 670 If D' is composed of the NAT64's prefix followed by an IPv4 671 address D, then the outgoing destination transport address is 672 (D,d). 674 Otherwise, discard the packet. 676 When translating in the IPv4 --> IPv6 direction, let the incoming 677 source and destination transport addresses in the 5-tuple be (S,s) 678 and (D,d) respectively. The outgoing source transport address is 679 computed as follows: 681 The outgoing source transport address is (Pref64::S,s). 683 The outgoing destination transport address is computed as follows: 685 If the BIB contains an entry (X',x) <--> (D,d), then the outgoing 686 destination transport address is (X',x). 688 Otherwise, discard the packet. 690 If the rules specify that a new BIB entry is created for a source 691 transport address of (S',s), then the NAT64 allocates an IPv4 692 transport address for this BIB entry as follows: 694 If there exists some other BIB entry containing S' as the IPv6 695 address and mapping it to some IPv4 address T, then use T as the 696 IPv4 address. Otherwise, use any IPv4 address assigned to the 697 IPv4 interface. 699 If the port s is in the Well-Known port range 0..1023, then 700 allocate a port t from this same range. Otherwise, if the port s 701 is in the range 1024..65535, then allocate a port t from this 702 range. Furthermore, if port s is even, then t must be even, and 703 if port s is odd, then t must be odd. 705 In all cases, the allocated IPv4 transport address (T,t) MUST NOT 706 be in use in another entry in the same BIB, but MAY be in use in 707 the other BIB. 709 If it is not possible to allocate an appropriate IPv4 transport 710 address or create a BIB entry for some reason, then the packet is 711 discarded. 713 TBD: Do we delete the session entry if we cannot create a BIB entry? 715 If the rules specify that the packet is discarded, then the NAT64 716 SHOULD send an ICMP reply to the original sender, unless the packet 717 being translated contains an ICMP message. The type should be 3 718 (Destination Unreachable) and the code should be 0 (Network 719 Unreachable in IPv4, and No Route to Destination in IPv6). 721 3.2.4. Translating the Packet 723 This step translates the packet from IPv6 to IPv4 or vica-versa. 725 The translation of the packet is as specified in section 3 and 726 section 4 of SIIT [RFC2765], with the following modifications: 728 o When translating an IP header (sections 3.1 and 4.1), the source 729 and destination IP address fields are set to the source and 730 destination IP addresses from the outgoing 5-tuple. 732 o When the protocol following the IP header is TCP or UDP, then the 733 source and destination ports are modified to the source and 734 destination ports from the 5-tuple. In addition, the TCP or UDP 735 checksum must also be updated to reflect the translated addresses 736 and ports; note that the TCP and UDP checksum covers the pseudo- 737 header which contains the source and destination IP addresses. An 738 algorithm for efficently updating these checksums is described in 739 [RFC3022]. 741 o When the protocol following the IP header is ICMP (sections 3.4 742 and 4.4) the source and destination transport addresses in the 743 embedded packet are set to the destination and source transport 744 addresses from the outgoing 5-tuple (note the swap of source and 745 destination). 747 3.2.5. Handling Hairpinning 749 This step handles hairpinning if necessary. 751 If the destination IP address is an address assigned to the NAT64 752 itself (i.e., is one of the IPv4 addresses assigned to the IPv4 753 interface, or is covered by the /96 prefix assigned to the IPv6 754 interface), then the packet is a hairpin packet. The outgoing 755 5-tuple becomes the incoming 5-tuple, and the packet is treated as if 756 it was received on the outgoing interface. Processing of the packet 757 continues at step 2. 759 TBD: Is there such a thing as a hairpin loop (likely not naturally, 760 but perhaps through a special-crafted attack packet with a spoofed 761 source address)? If so, need to drop packets that hairpin more than 762 once. 764 3.3. FTP ALG 766 TBD: Describe the FTP ALG, a mechanism for translating the embedded 767 IP addresses inside FTP commands, that enables FTP sessions to pass 768 through NAT64. 770 4. Application scenarios 772 In this section, we describe how to apply NAT64/DNS64 to the suitable 773 scenarios described in draft-arkko-townsley-coexistence. 775 4.1. Enterprise IPv6 only network 777 The Enterprise IPv6 only network basically has IPv6 hosts (those that 778 are currently available) and because of different reasons including 779 operational simplicity, wants to run those hosts in IPv6 only mode, 780 while still providing access to the IPv4 Internet. The scenario is 781 depicted in the picture below. 783 +----+ +-------------+ 784 | +------------------+IPv6 Internet+ 785 | | +-------------+ 786 IPv6 host-----------------+ GW | 787 | | +-------------+ 788 | +------------------+IPv4 Internet+ 789 +----+ +-------------+ 791 |-------------------------public v6-----------------------------| 792 |-------public v6---------|NAT|----------public v4--------------| 794 The proposed NAT64/DNS64 is perfectly suitable for this particular 795 scenario. The deployment of the NAT64/DNS64 would be as follows: The 796 NAT64 function should be located in the GW device that connects the 797 IPv6 site to the IPv4 Internet. The DNS64 functionality can be 798 placed in different places. Probably the best trade-off between 799 architectural cleanness deployment simplicity would be to place it in 800 the local recursive DNS server of the enterprise site. The option 801 that is easier to deploy would be to co-locate it with the NAT64 box. 802 The cleanest option would be included in the local resolver of the 803 IPv6 hosts, but this option seems the harder to deploy cause it 804 implies changes to the hosts. 806 The proposed NAT64/DNS64 approach satisfies the requirements of this 807 scenario, in particular cause it doesn't require any changes to 808 current IPv6 hosts in the site to obtain basic functionality. 810 4.2. Reaching servers in private IPv4 space 812 The scenario of servers using IPv4 private addresses and being 813 reached from the IPv6 Internet basically includes the cases that for 814 whatever reason the servers cannot be upgraded to IPv6 and they don't 815 have public VIPv4 addresses and it would be useful to allow IPv6 816 nodes in the IPv6 Internet to reach those servers. This scenario is 817 depicted in the figure below. 819 +----+ 820 IPv6 Host(s)-------(Internet)-----+ GW +------Private IPv4 Servers 821 +----+ 823 |---------public v6---------------|NAT|------private v4----------| 825 This scenario can again be perfectly served by the NAT64 approach. 826 In this case the NAT64 functionality is placed in the GW device 827 connecting the IPv6 Internet to the server's site. In this case, the 828 DNS64 functionality is not needed. Since the server's site is 829 running the NAT64 and the servers, it can publish in its own DNS 830 server the AAAA RR corresponding to the servers i.e. AAAA RR 831 associating the FQDN of the server and the Pref64:ServerIPv4Addr. In 832 this case, there is no need to synthesize AAAA RR cause the site can 833 configure them in the DNS itself. 835 Again, this scenario is satisfied by the NAT64 since it supports the 836 required functionality without requiring changes in the IPv4 servers 837 nor in the IPv6 clients. 839 5. Discussion 841 5.1. About the Prefix used to map the IPv4 address space into IPv6 843 In the NAT64 approach, we need to represent the IPv4 addresses in the 844 IPv6 Internet. Since there is enough address space in IPv6, we can 845 easily embed the IPv4 address into an IPv6 address, so that the IPv4 846 address information can be extracted from the IPv6 address without 847 requiring additional state. One way to that is to use an IPv6 prefix 848 Pref64::/96 and juxtapose the IPv4 address at the end (there are 849 other ways of doing it, but we are not discussing the different 850 formats here). In this document the Pref64::/96 prefix is extracted 851 from the address block assigned to the site running the NAT64 box. 852 However, one could envision the usage of other prefixes for that 853 function. In particular, it would be possible to define a well-known 854 prefix that can be used by the NAT64 devices to map IPv4 (public) 855 addresses into IPv6 addresses, irrespectively of the address space of 856 the site where the NAT64 is located. In this section, we discuss the 857 pro and cons of the different options. 859 the different options for Pref64::/96 are the following 861 Local: A locally assigned prefix out of the address block of the 862 site running the NAT64 box 864 Well-known: A well know prefix that is reserved for this purpose. 865 We have the following different options: 867 IPv4 mapped prefix 869 IPv4 compatible prefix 871 A new prefix assigned by IANA for this purpose 873 The reasons why using a well-known prefix is attractive are the 874 following: Having a global well-know prefix would allow to identify 875 which addresses are "real" IPv6 addresses with native connectivity 876 and which addresses are IPv6 addresses that represent an IPv4 877 address. From an architectural perspective, it seems the right thing 878 to do to make this visible since hosts an applications could react 879 accordingly and avoid or prefer such type of connectivity if needed. 880 From the DNS64 perspective, using the well-know prefix would imply 881 that the same synthetic AAAA RR will be created throughout the IPv6 882 Internet, which would result in consistent view of the RR 883 irrespectively of the location in the topology. From a more 884 practical perspective, having a well-know prefix would allow to 885 completely decouple the DNS64 from the NAT64, since the DNS64 would 886 always use the well-know prefix to create the synthetic AAAA RR and 887 there is no need to configure the same Pref64::/96 both in the DNS64 888 and the NAT64 that work together. 890 Among the different options available for the well-know prefix, the 891 option of using a pre-existing prefix such as the IPv4-mapped or 892 IPv4-compatible prefix has the advantage that would potentially allow 893 the default selection of native connectivity over translated 894 connectivity for legacy hosts in communications involving dual-stack 895 hosts. This is because current RFC3484 default policy table include 896 entries for the IPv4-mapped prefix and the IPv4-compatible prefix, 897 implying that native IPv6 prefixes will be preferred over these. 898 However, current implementations do not use the IPv4-mapped prefix on 899 the wire, beating the purpose of support unmodified hosts. The IPv4- 900 compatible prefix is used by hosts on the wire, but has a higher 901 priority than the IPv4-mapped prefix, which implies that current 902 hosts would prefer translated connectivity over native IPv4 903 connectivity (represented by the IPv4-mapped prefix in the default 904 policy table). So neither of the prefixes that are present in the 905 default policy table would result in the legacy hosts preferring 906 native connectivity over translated connectivity, so it doesn't seem 907 to be a compelling reason to re-use neither the IPv4-mapped not the 908 IPv4-compatible prefix for this. So, we conclude that among the the 909 well know prefix options, the preferred option would be to ask for a 910 new prefix from IANA to be allocated for this. 912 However, there are several issues when considering using the well- 913 know prefix option, namely: 915 The well-know prefix is suitable only for mapping IPv4 public 916 addresses into IPv6. IPv4 public addresses can be mapped using 917 the same prefix cause they are globally unique. However, the 918 well-known prefix is not suitable for mapping IPv4 private 919 addresses. This is so because we cannot leverage on the 920 uniqueness of the IPv4 address to achieve uniqueness of the IPv6 921 address, so we need to use a different IPv6 prefix to disambiguate 922 the different private IPv4 address realms. As we describe above, 923 there is a clear use case for mapping IPv4 private addresses, so 924 there is a pressing need to map IPv4 private addresses. In order 925 to do so we will need to use at least for IPv4 private addresses, 926 IPv6 local prefixes. In that case, the architectural goal of 927 distinguishing the "real" IPv6 addresses from the IPv6 addresses 928 that represent IPv4 addresses can no longer be achieved in a 929 general manner, making this option less attractive. 931 The usage of a single well-known prefix to map IPv4 addresses 932 irrespectively of the NAT64 used, may results in failure modes in 933 sites that have more than one NAT64 device. The main problem is 934 that intra-site routing fluctuations that result in packets of an 935 ongoing communication flow through a different NAT64 box that the 936 one they were initially using (e.g. a change in an ECMP load 937 balancer), would break ongoing communications. This is so because 938 the different NAT64 boxes will use a different IPv4 address, so 939 the IPv4 peer of the communications will receive packets coming 940 from a different IPv4 address. This is avoided using a local 941 address, since each NAT64 box can have a different Pref64::/06 942 associated, to routing fluctuations would not result in using a 943 different NAT64 box. 945 The usage of a well-known prefix is also problematic in the case 946 that different routing domains want to exchange routing 947 information involving these routes. Consider the case of an IPv6 948 site that has multiple providers and that each of these providers 949 provides access to the IPv4 Internet using the well know prefix. 950 Consider the hypothetical case that different parts of the IPv4 951 Internet are reachable through different IPv6 ISPs (yes, this 952 means that in a futuristic scenario, the IPv4 Internet is 953 partitioned). In order to reach the different parts through the 954 different ISPs, more specific routes representing the different 955 IPv4 destinations reachable need to be injected in the IPv6 sites. 956 This basically means that such configuration would imply to import 957 the IPv4 routing entropy into the IPv6 routing system. If 958 different local prefixes are used, then each ISP only announces 959 its own local prefix, and then the burden of defining which IPv4 960 destination is reachable through which ISP is placed somewhere 961 else (e.g. in the DNS64). 963 6. Security Considerations 965 Implications on end-to-end security, IPSec and TLS. 967 Any protocol that protect IP header information are essentially 968 incompatible with NAT64. So, this implies that end to end IPSec 969 verification will fail when AH is used (both transport and tunnel 970 mode) and when ESP is used in transport mode. This is inherent to 971 any network layer translation mechanism. End-to-end IPsec protection 972 can be restored, using UDP encapsulation as described in [RFC2765]. 974 TBD: TLS implications 976 Filtering. 978 NAT64 creates binding state using packets flowing from the IPv6 side 979 to the IPv4 side. So, NAT64 implements by definition, at least, 980 endpoint independent filtering, meaning that in order to enable any 981 packet to flow from the IPv4 side to the IPv6 side, there must have 982 been a packet flowing from the IPv6 side to the IPv4 side the created 983 the binding information to be used for packets in the other 984 direction. Endpoint independent filtering allows that once a binding 985 is created, it can be used by any node on the IPv4 side to send 986 packets to the IPv6 transport address that created the binding. This 987 basically means that as long a the IPv6 node does not open a hole in 988 the NAT64, incoming communications are blocked and that once that the 989 IPv6 node has sent the first packet, this packet opens the door for 990 any node on the IPv4 side to send packets to that IPv6 transport 991 address. It is possible to configure the NAT64 to implement more 992 stringent security policy, if endpoint independent filtering is 993 considered not secure enough. In particular, if the security policy 994 of the NAT64 requires it, is it possible to configure the NAT64 to 995 perform address dependent filtering. This basically means that the 996 binding state created can only be used by to send packets from the 997 IPv4 address to which the original packet that created the binding 998 was sent to. This basically means that the door is open only for 999 that IPv4 address to send packet to the IPv6 transport address. 1001 Attacks to NAT64. 1003 The NAT64 device itself is a potential victim of different type of 1004 attacks. In particular, the NAT64 can be a victim of DoS attacks. 1005 The NAT64 box has a limited number of resources that can be consumed 1006 by attackers creating a DoS attack. The NAT64 has a limited number 1007 of IPv4 address that is uses to create the bindings. Even though the 1008 NAT64 performs address and port translation, it is possible for an 1009 attacker to consume all the IPv4 transport addresses by sending IPv6 1010 packets with different source IPv6 transport address. It should be 1011 noted that this attack can only be launched from the IPv6 side, since 1012 IPv4 packets are not used to create binding state. DoS attacks can 1013 also affect other limited resource available in the NAT64 such as 1014 memory or link capacity. For instance, if the NAT64 implements 1015 reassembly of fragmented packets, it is possible for an attacker to 1016 launch a DoS attack to the memory of the NAT64 device by sending 1017 fragments that the NAT64 will store for a given period. If the 1018 number of fragments if high enough, the memory of the NAT64 could be 1019 exhausted. NAT64 devices should implement proper protection against 1020 such attacks, for instance allocating a limited amount of memory for 1021 fragmented packet storage. 1023 7. IANA Considerations 1025 The IANA is requested to assign an EDNS Option Code value for the SAS 1026 option. 1028 TBD: Set up an IANA registry for SAS flags?? 1030 8. Changes from Previous Draft Versions 1032 Note to RFC Editor: Please remove this section prior to publication 1033 of this document as an RFC. 1035 [[This section lists the changes between the various versions of this 1036 draft.]] 1038 9. Contributors 1040 George Tsirtsis 1042 Qualcomm 1044 tsirtsis@googlemail.com 1046 10. Acknowledgements 1048 Dave Thaler, Dan Wing, Alberto Garcia-Martinez, Reinaldo Penno and 1049 Joao Damas reviewed the document and provided useful comments to 1050 improve it. 1052 The content of the draft was improved thanks to discussions with Fred 1053 Baker and Jari Arkko. 1055 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 1056 Trilogy, a research project supported by the European Commission 1057 under its Seventh Framework Program. 1059 11. References 1061 11.1. Normative References 1063 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1064 Requirement Levels", BCP 14, RFC 2119, March 1997. 1066 [RFC1035] Mockapetris, P., "Domain names - implementation and 1067 specification", STD 13, RFC 1035, November 1987. 1069 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1070 RFC 2671, August 1999. 1072 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1073 (SIIT)", RFC 2765, February 2000. 1075 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1076 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1077 RFC 4787, January 2007. 1079 [I-D.ietf-behave-tcp] 1080 Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1081 Srisuresh, "NAT Behavioral Requirements for TCP", 1082 draft-ietf-behave-tcp-08 (work in progress), 1083 September 2008. 1085 [I-D.ietf-behave-nat-icmp] 1086 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1087 Behavioral Requirements for ICMP protocol", 1088 draft-ietf-behave-nat-icmp-12 (work in progress), 1089 January 2009. 1091 [I-D.bagnulo-behave-dns64] 1092 Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and 1093 M. Endo, "DNS64: DNS extensions for Network Address 1094 Translation from IPv6 Clients to IPv4 Servers", 1095 draft-bagnulo-behave-dns64-02 (work in progress), 1096 March 2009. 1098 11.2. Informative References 1100 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1101 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1102 February 2000. 1104 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1105 Considerations for IP Fragment Filtering", RFC 1858, 1106 October 1995. 1108 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1109 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1111 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1112 Address Translator (Traditional NAT)", RFC 3022, 1113 January 2001. 1115 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 1116 Address Translator - Protocol Translator (NAT-PT) to 1117 Historic Status", RFC 4966, July 2007. 1119 [I-D.ietf-mmusic-ice] 1120 Rosenberg, J., "Interactive Connectivity Establishment 1121 (ICE): A Protocol for Network Address Translator (NAT) 1122 Traversal for Offer/Answer Protocols", 1123 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1125 [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of 1126 Managed Objects for Synchronous Optical Network (SONET) 1127 Linear Automatic Protection Switching (APS) 1128 Architectures", RFC 3498, March 2003. 1130 Authors' Addresses 1132 Marcelo Bagnulo 1133 UC3M 1134 Av. Universidad 30 1135 Leganes, Madrid 28911 1136 Spain 1138 Phone: +34-91-6249500 1139 Fax: 1140 Email: marcelo@it.uc3m.es 1141 URI: http://www.it.uc3m.es/marcelo 1142 Philip Matthews 1143 Unaffiliated 1144 600 March Road 1145 Ottawa, Ontario 1146 Canada 1148 Phone: +1 613-592-4343 x224 1149 Fax: 1150 Email: philip_matthews@magma.ca 1151 URI: 1153 Iljitsch van Beijnum 1154 IMDEA Networks 1155 Av. Universidad 30 1156 Leganes, Madrid 28911 1157 Spain 1159 Phone: +34-91-6246245 1160 Email: iljitsch@muada.com