idnits 2.17.1 draft-bagnulo-behave-dns64-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.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: 'I-D.ietf-behave-tcp' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-nat-icmp' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'RFC2766' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: 'RFC1858' is defined on line 1126, but no explicit reference was found in the text == Unused Reference: 'RFC3128' is defined on line 1130, but no explicit reference was found in the text == Unused Reference: 'RFC3022' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 1137, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-ice' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'RFC3498' is defined on line 1165, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-03) exists of draft-bagnulo-behave-nat64-02 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) == Outdated reference: A later version (-03) exists of draft-ietf-6man-addr-select-sol-01 == Outdated reference: A later version (-04) exists of draft-wing-behave-learn-prefix-00 == Outdated reference: A later version (-02) exists of draft-miyata-behave-prefix64-00 Summary: 4 errors (**), 0 flaws (~~), 15 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 A. Sullivan 5 Expires: September 8, 2009 Shinkuro 6 P. Matthews 7 Alcatel-Lucent 8 I. van Beijnum 9 IMDEA Networks 10 M. Endo 11 Yokogawa Electric Corporation 12 March 7, 2009 14 DNS64: DNS extensions for Network Address Translation from IPv6 Clients 15 to IPv4 Servers 16 draft-bagnulo-behave-dns64-02 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may contain material 22 from IETF Documents or IETF Contributions published or made publicly 23 available before November 10, 2008. The person(s) controlling the 24 copyright in some of this material may not have granted the IETF 25 Trust the right to allow modifications of such material outside the 26 IETF Standards Process. Without obtaining an adequate license from 27 the person(s) controlling the copyright in such materials, this 28 document may not be modified outside the IETF Standards Process, and 29 derivative works of it may not be created outside the IETF Standards 30 Process, except to format it for publication as an RFC or to 31 translate it into languages other than English. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on September 8, 2009. 51 Copyright Notice 53 Copyright (c) 2009 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents in effect on the date of 58 publication of this document (http://trustee.ietf.org/license-info). 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. 62 Abstract 64 DNS64 is a mechanism for synthesizing AAAA records from A records. 65 DNS64 is used with NAT64, an IPv6 IPv4 translator to enable client- 66 server communication between an IPv6-only client and an IPv4-only 67 server, without requiring any changes to either the IPv6 or the IPv4 68 node, for the class of applications that work through NATs. This 69 document specifies DNS64, and provides suggestions on how it should 70 be deployed in conjunction with NAT64. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2. Walkthrough . . . . . . . . . . . . . . . . . . . . . . . 6 77 1.2.1. An-IPv6-network-to-IPv4-Internet setup with DNS64 78 in DNS server mode . . . . . . . . . . . . . . . . . . 7 79 1.2.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 80 in stub-resolver mode . . . . . . . . . . . . . . . . 8 81 1.2.3. IPv6-Internet-to-an-IPv4-network setup DNS64 in 82 DNS server mode . . . . . . . . . . . . . . . . . . . 9 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 3. Normative Specification . . . . . . . . . . . . . . . . . . . 13 85 3.1. DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 3.2. Handling PTR RRs . . . . . . . . . . . . . . . . . . . . . 14 87 4. Solution space analysis . . . . . . . . . . . . . . . . . . . 14 88 4.1. Tagging synthetic RR . . . . . . . . . . . . . . . . . . . 15 89 4.2. Dual stack nodes . . . . . . . . . . . . . . . . . . . . . 16 90 4.2.1. Communication initiated from an IPv6-only node 91 towards a dual stack node . . . . . . . . . . . . . . 16 92 4.2.2. Communication initiated from a dual stack node 93 toward an IPv4 only node . . . . . . . . . . . . . . . 17 94 4.3. IPv6 nodes implementing DNSSEC . . . . . . . . . . . . . . 17 95 4.3.1. Recursive resolvers and 96 an-IPv6-network-to-IPv4-Internet . . . . . . . . . . . 18 97 4.3.1.1. Strategy 1: Response-specific DNSSEC 98 information . . . . . . . . . . . . . . . . . . . 19 99 4.3.1.2. Strategy 2: Treat synthesized AAAA similarly 100 to synthesized CNAMEs . . . . . . . . . . . . . . 20 101 4.3.2. IPv6-Internet-to-An-IPv4-network . . . . . . . . . . . 20 102 4.4. Learning the Pref64::/96 prefix . . . . . . . . . . . . . 21 103 4.5. Supporting multiple NAT64 boxes with different 104 associated prefixes . . . . . . . . . . . . . . . . . . . 22 105 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 107 7. Changes from Previous Draft Versions . . . . . . . . . . . . . 23 108 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 111 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 112 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 115 1. Introduction 117 This document specifies DNS64, a mechanism that is part of the 118 toolbox for IPv6-IPv4 transition and co-existence. DNS64, used 119 together with NAT64, allows an IPv6-only client to initiate 120 communications by name to an IPv4-only server. 122 DNS64 is a mechanism for synthesizing AAAA resource records (RR) from 123 A RRs. The synthesis is done by adding a /96 prefix to the IPv4 124 address to create an IPv6 address, where the /96 prefix is assigned 125 to a NAT64 device. 127 NAT64 as defined in a companion document [I-D.bagnulo-behave-nat64] 128 is a mechanism for translating IPv6 packets to IPv4 packets. The 129 translation is done by translating the packet headers according to 130 SIIT [RFC2765], translating the IPv4 server address by adding or 131 removing a /96 prefix, and translating the IPv6 client address by 132 installing mappings in the normal NAT manner. 134 Together, these two mechanisms allow an IPv6-only client to initiate 135 communications to an IPv4-only server using the FQDN of the server. 137 These mechanisms are expected to play a critical role in the IPv4- 138 IPv6 transition and co-existence. Due to IPv4 address depletion, 139 it's likely that in the future, a lot of IPv6-only clients will want 140 to connect to IPv4-only servers. These include hosts running IPv6- 141 only applications, IPv6-only hosts as well as the cases where only 142 IPv6-only connectivity is available between the client and the NAT64. 143 In the general case, the approach only requires the deployment of 144 NAT64-enabled devices that connect an IPv6-only network to the IPv4- 145 only Internet, along with the deployment of one or more DNS64-enabled 146 name servers in the IPv6-only network. However, some advanced 147 features require performing the DNS64 function directly by the end- 148 hosts themselves. 150 1.1. Overview 152 This section provides a non-normative introduction to the DNS64 153 mechanism. 155 We assume that we have a NAT64 box connecting the IPv4 network and 156 the IPv6 network. The NAT64 device provides translation services 157 between the two networks enabling communication between IPv4-only 158 hosts and IPv6-only hosts. NAT64, however, is not symmetric. In 159 order to be able to perform IPv6 - IPv4 translation NAT64 requires 160 state, binding an IPv6 address and port (hereafter called an IPv6 161 transport address) to an IPv4 address and port (hereafter called an 162 IPv4 transport address). Such binding state is created when the 163 first packet flowing from the IPv6 network to the IPv4 network is 164 translated. After the binding state has been created, packets 165 flowing in either direction that are part of that particular flow are 166 translated. The result is that NAT64 only supports communications 167 initiated by the IPv6-only node towards an IPv4-only node. 169 To allow an IPv6 initiator to do the standard DNS lookup to learn the 170 address of the responder, DNS64 is used to synthesize an AAAA record 171 from the A record containing the real IPv4 address of the responder, 172 whenever the DNS64 service cannot retrieve a AAAA record for the 173 requested host name. DNS64 appears as a regular recursive resolver 174 for the IPv6 initiator. The DNS64 node receives a AAAA DNS query 175 generated by the IPv6 initiator. It first attempts a recursive 176 resolution of the requested AAAA record. If there is no AAAA record 177 available for the target node (which is the normal case when the 178 target node is an IPv4-only node), DNS64 performs a query for the A 179 record. If an A record is discovered, DNS64 creates a synthetic AAAA 180 RR by adding the Pref64::/96 of a NAT64 to the responder's IPv4 181 address (i.e. if the IPv4 node has IPv4 address X, then the synthetic 182 AAAA RR will contain the IPv6 address formed as Pref64:X). The 183 synthetic AAAA RR is passed back to the IPv6 initiator, which will 184 initiate an IPv6 communication with the IPv6 address associated to 185 the IPv4 receiver. The packet will be routed to the NAT64 device, 186 which will create the IPv6 to IPv4 address mapping as described in 187 [I-D.bagnulo-behave-nat64]. 189 The only shared state between the DNS64 and the NAT64 is the 190 Pref64::/96 that must be configured to be the same on both; there is 191 no communication between the DNS64 and NAT64 functions. 193 There are two main different setups where DNS64+NAT64 approach is 194 expected to be used (other setups are possible as well, but these two 195 are the main ones identified at the time of this writing). 197 One possible setup that is expected to be common is the case of an 198 end site or an ISP that is providing IPv6-only connectivity or 199 connectivity to IPv6-only hosts that wants to allow the 200 communication from these IPv6-only connected hosts to the IPv4 201 Internet. (This case is called An-IPv6-network-to-IPv4-Internet). 202 In this case, the NAT64 is used to connect the end site or the ISP 203 to the IPv4 Internet and the DNS64 function is provided by the end 204 site or the ISP. 206 The other possible setup that is expected is an IPv4 site that 207 wants that its IPv4 servers to be reachable from the IPv6 208 Internet. (This case is called IPv6-Internet-to-an-IPv4-network). 209 It should be noted that the IPv4 addresses used in the IPv4 site 210 can be either public or private. In this case, the NAT64 is used 211 to connect the IPv4 end site to the IPv6 Internet and the DNS64 212 function is provided by the end site itself. 214 The DNS64 function can be performed in two places. 216 One option is to locate the DNS64 function in recursive name 217 servers serving end hosts. In this case, when an IPv6 device 218 queries the name server for a AAAA RR for an IPv4 only host, the 219 name server can perform the synthesis to the AAAA RR and pass it 220 back to the IPv6 only initiator. The main advantage of this mode 221 is that current IPv6 nodes can use this mechanism without 222 requiring any modification. This mode, called DNS64 in DNS server 223 mode, is expected to be used in both An-IPv6-network-to-IPv4- 224 Internet setup and IPv6-Internet-to-an-IPv4-network setup. 226 The other option is to place the DNS64 function in the end hosts 227 themselves, coupled to the local stub resolver. In this case, the 228 stub resolver will try to obtain (real) AAAA RRs and in case they 229 are not available, the DNS64 function will synthesize the AAAA RR 230 for internal usage. This mode is compatible with some advanced 231 functions like DNSSEC validation in the end host. The main 232 drawback of this mode is its deployability, since it requires 233 changes in the end hosts. This mode, called DNS64 in stub- 234 resolver mode, is expected to be used only in the An-IPv6-network- 235 to-IPv4-Internet setup case. 237 1.2. Walkthrough 239 In this section we illustrate how the DNS64 behaves in the different 240 scenarios that are expected to be common. We consider then 3 241 possible scenarios, namely: 243 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server 244 mode 246 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- 247 resolver mode 249 3. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode 251 The notation used is the following: upper case letters are IPv4 252 addresses; upper case letters with a prime(') are IPv6 addresses; 253 lower case letters are ports; prefixes are indicated by "P::X", which 254 is an IPv6 address built from an IPv4 address X by adding the prefix 255 P, mappings are indicated as "(X,x) <--> (Y',y)". 257 1.2.1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server 258 mode 260 In this example, we consider an IPv6 node located in an IPv6-only 261 site that initiates a communication to a IPv4 node located in the 262 IPv4 Internet. 264 The scenario for this case is depicted in the following figure: 266 +---------------------------------------+ +-----------+ 267 |IPv6 site +-------------+ |IP Addr: | | 268 | +----+ | Name server | +-------+ T | IPv4 | 269 | | H1 | | with DNS64 | | NAT64 |------| Internet | 270 | +----+ +-------------+ +-------+ +-----------+ 271 | |IP addr: Y' | | | |IP addr: X 272 | --------------------------------- | +----+ 273 +---------------------------------------+ | H2 | 274 +----+ 276 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an 277 IPv4 node H2 with IPv4 address X. 279 A NAT64 connects the IPv6 network to the IPv4 Internet. This NAT64 280 has a /96 prefix (called Pref64::/96) associated to its IPv6 281 interface and an IPv4 address T assigned to its IPv4 interface. 283 The other element involved is the local name server. The name server 284 is a dual-stack node, so that H1 can contact it via IPv6, while it 285 can contact IPv4-only name servers via IPv4. 287 The local name server needs to know the /96 prefix assigned to the 288 local NAT64 (Pref64::/96). For the purpose of this example, we 289 assume it learns this through manual configuration. 291 For this example, assume the typical DNS situation where IPv6 hosts 292 have only stub resolvers, and always query a name server that 293 performs recursive lookups (henceforth called "the recursive 294 nameserver"). 296 The steps by which H1 establishes communication with H2 are: 298 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS 299 query for an AAAA record for H2 to the recursive name server. 300 The recursive name server implements DNS64 functionality. 302 2. The recursive name server resolves the query, and discovers that 303 there are no AAAA records for H2. 305 3. The recursive name server queries for an A record for H2 and gets 306 back an A record containing the IPv4 address X. The name server 307 then synthesizes an AAAA record. The IPv6 address in the AAAA 308 record contains the prefix assigned to the NAT64 in the upper 96 309 bits and the IPv4 address X in the lower 32 bits. 311 4. H1 receives the synthetic AAAA record and sends a packet towards 312 H2. The packet is sent from a source transport address of (Y',y) 313 to a destination transport address of (Pref64:X,x), where y and x 314 are ports chosen by H2. 316 5. The packet is routed to the IPv6 interface of the NAT64 and the 317 subsequent communication flows by means of the NAT64 mechanisms 318 as described in the NAT64 319 specification[I-D.bagnulo-behave-nat64]. 321 1.2.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- 322 resolver mode 324 The scenario for this case is depicted in the following figure: 326 +---------------------------------------+ +-----------+ 327 |IPv6 site +-------+ |IP addr: | | 328 | +---------------+ | Name | +-------+ T | IPv4 | 329 | | H1 with DNS64 | | Server| | NAT64 |------| Internet | 330 | +---------------+ +-------+ +-------+ +-----------+ 331 | |IP addr: Y' | | | |IP addr: X 332 | --------------------------------- | +----+ 333 +---------------------------------------+ | H2 | 334 +----+ 336 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an 337 IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64 338 function. 340 A NAT64 connects the IPv6 network to the IPv4 Internet. This NAT64 341 has a /96 prefix (called Pref64::/96) associated to its IPv6 342 interface and an IPv4 address T assigned to its IPv4 interface. 344 H1 needs to know the /96 prefix assigned to the local NAT64 345 (Pref64::/96). For the purpose of this example, we assume it learns 346 this through manual configuration but we will discuss different 347 options for doing this in the analysis section of this document. 349 Also shown is a name server. For the purpose of this example, we 350 assume that the name server is a dual-stack node, so that H1 can 351 contact it via IPv6, while it can contact IPv4-only name servers via 352 IPv4. 354 For this example, assume the typical situation where IPv6 hosts have 355 only stub resolvers and always query a name server that provides 356 recursive lookups (henceforth called "the recursive name server"). 357 The recursive name server does not perform the DNS64 function. 359 The steps by which H1 establishes communication with H2 are: 361 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS 362 query for a AAAA record for H2 to the recursive name server. 364 2. The recursive DNS server resolves the query, and returns the 365 answer to H1. Because there are no AAAA records in the global 366 DNS for H2, the answer is empty. 368 3. The stub resolver at H1 then queries for an A record for H2 and 369 gets back an A record containing the IPv4 address X. The DNS64 370 function within H1 then synthesizes a AAAA record. The IPv6 371 address in the AAAA record contains the prefix assigned to the 372 NAT64 in the upper 96 bits and the IPv4 address X in the lower 32 373 bits. 375 4. H1 sends a packet towards H2. The packet is sent from a source 376 transport address of (Y',y) to a destination transport address of 377 (Pref64:X,x), where y and x are ports chosen by H2. 379 5. The packet is routed to the IPv6 interface of the NAT64 and the 380 subsequent communication flows using the NAT64 mechanisms as 381 described in the NAT64 specification[I-D.bagnulo-behave-nat64]. 383 1.2.3. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode 385 In this example, we consider an IPv6 node located in the IPv6 386 Internet site that initiates a communication to a IPv4 node located 387 in the IPv4 site. 389 This scenario can be addressed without using any form of DNS64 390 function. This is so because it is possible to assign a fixed IPv6 391 address to each of the IPv4 servers. Such an IPv6 address would be 392 constructed as the Pref64::/96 concatenated with the IPv4 address of 393 the IPv4 server. Note that the IPv4 address can be a public or a 394 private address; the latter does not present any additional 395 difficulty. Once these IPv6 addresses have been assigned to 396 represent the IPv4 servers in the IPv6 Internet, real AAAA RRs 397 containing these addresses can be published in the DNS under the 398 site's domain. This is the recommended approach to handle this 399 scenario. 401 However, there are some more dynamic scenarios, where synthesizing 402 AAAA RRs in this setup may be needed. In particular, when DNS Update 403 [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 404 servers, there are two options: One option is to modify the server 405 that receives the dynamic DNS updates. That would normally be the 406 authoritative server for the zone. So the authoritative zone would 407 have normal AAAA RRs that are synthesized as dynamic updates occur. 408 The other option is modify the authoritative server to generate 409 synthetic AAAA records for a zone, possibly based on additional 410 constraints, upon the reception of the DNS query for the AAAA RR. 411 The first option, the synthesis upon the DynDNS update, recommended 412 over the second option, i.e. the synthesis over the reception of the 413 AAAA RR DNS query. The DNS64 behavior that we describe in this 414 section covers the last case i.e. AAAA RR being synthesized when the 415 DNS query arrives. Note that we don't recommend this approach over 416 the previous one where AAAA RR are generated upon the dynamic 417 registration. However, this is specified in this document because 418 this is a part that is related to the DNS64 function. 420 The scenario for this case is depicted in the following figure: 422 +-----------+ +----------------------------------------+ 423 | | | IPv4 site +-------------+ | 424 | IPv6 | +-------+ +----+ | Name server | | 425 | Internet |------| NAT64 | | H2 | | with DNS64 | | 426 +-----------+ +-------+ +----+ +-------------+ | 427 |IP addr: Y' | | |IP addr: X | | 428 +----+ | ----------------------------------- | 429 | H1 | +----------------------------------------+ 430 +----+ 432 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an 433 IPv4 node H2 with IPv4 address X. 435 A NAT64 connects the IPv4 network to the IPv6 Internet. This NAT64 436 has a /96 prefix (called Pref64::/96) associated to its IPv6 437 interface. 439 Also shown is the authoritative name server for the local domain with 440 DNS64 functionality. For the purpose of this example, we assume that 441 the name server is a dual-stack node, so that H1 can contact it via 442 IPv6, while it can be contacted by IPv4-only nodes to receive dynamic 443 DNS updates via IPv4. 445 The local name server needs to know the /96 prefix assigned to the 446 local NAT64 (Pref64::/96). For the purpose of this example, we 447 assume it learns this through manual configuration. 449 The steps by which H1 establishes communication with H2 are: 451 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS 452 query for an AAAA record for H2. The query is eventually 453 forwarded to the server in the IPv4 site. Assume the local name 454 server is implementing DNS64 functionality. 456 2. The local DNS server resolves the query (locally), and discovers 457 that there are no AAAA records for H2. 459 3. The name server verifies that FQDN(H2) and its A RR are among 460 those that the local policy defines as allowed to generate a AAAA 461 RR from. If that is the case, the name server synthesizes an 462 AAAA record from the A RR and the relevant Pref64::/96. The IPv6 463 address in the AAAA record contains the prefix assigned to the 464 NAT64 in the first 96 bits and the IPv4 address X in the lower 32 465 bits. 467 4. H1 receives the synthetic AAAA record and sends a packet towards 468 H2. The packet is sent from a source transport address of (Y',y) 469 to a destination transport address of (Pref64:X,x), where y and x 470 are ports chosen by H2. 472 5. The packet is routed through the IPv6 Internet to the IPv6 473 interface of the NAT64 and the communication flows using the 474 NAT64 mechanisms as described in the NAT64 475 specification[I-D.bagnulo-behave-nat64]. 477 2. Terminology 479 This section provides a definitive reference for all the terms used 480 in document. 482 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 483 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 484 document are to be interpreted as described in RFC 2119 [RFC2119]. 486 The following terms are used in this document: 488 Authoritative server A DNS server that can answer authoritatively 489 for a given DNS question. 491 DNS64: A logical function that synthesizes AAAA records (containing 492 IPv6 addresses) from A records (containing IPv4 addresses). 494 DNS64 recursor: A recursive resolver that provides the DNS64 495 functionality as part of its operation. 497 Recursive resolver: A DNS server that accepts requests from one 498 resolver, and asks another resolver for the answer on behalf of 499 the first resolver. In the context of this document, "the 500 recursive resolver" means a recursive resolver immediately next in 501 the DNS resolution chain from an end point. The end point usually 502 has only a stub resolver available. 504 Synthetic RR: A DNS resource record (RR) that is not contained in 505 any zone data file, but has been synthesized from other RRs. An 506 example is a synthetic AAAA record created from an A record. 508 Stub resolver: A resolver with minimum functionality, typically for 509 use in end points that depend on a recursive resolver. Most end 510 points on the Internet as of this writing use stub resolvers. 512 NAT64: A device that translates IPv6 packets to IPv4 packets and 513 vice-versa, with the provision that the communication must be 514 initiated from the IPv6 side. The translation involves not only 515 the IP header, but also the transport header (TCP or UDP). 517 5-Tuple: The tuple (source IP address, source port, destination IP 518 address, destination port, transport protocol). A 5-tuple 519 uniquely identifies a session. When a session flows through a 520 NAT64, each session has two different 5-tuples: one with IPv4 521 addresses and one with IPv6 addresses. 523 Transport Address: The combination of an IPv6 or IPv4 address and a 524 port. Typically written as (IP address, port); e.g. (192.0.2.15, 525 8001). 527 Mapping: A mapping between an IPv6 transport address and a IPv4 528 transport address. Used to translate the addresses and ports of 529 packets flowing between the IPv6 host and the IPv4 host. In 530 NAT64, the IPv4 transport address is always a transport address 531 assigned to the NAT64 itself, while the IPv6 transport address 532 belongs to some IPv6 host. 534 For a detailed understanding of this document, the reader should also 535 be familiar with DNS terminology [RFC1035] and current NAT 536 terminology [RFC4787]. Some parts of this document assume 537 familiarity with the terminology of the DNS Security extensions 538 outlined in [RFC4035] 540 3. Normative Specification 542 3.1. DNS64 544 A DNS64 is a logical function that synthesizes AAAA records from A 545 records. The DNS64 function may be implemented in a stub resolver, 546 in a recursive resolver or in an authoritative name server. 548 The only configuration parameter required by the DNS64 is the IPv6 549 prefix assigned to a NAT64. This prefix is used to map IPv4 550 addresses into IPv6 addresses, and is denoted Pref64. The DNS64 551 learns this prefix through some means not specified here. 553 When the DNS64 receives a query for RRs of type AAAA and class IN, it 554 first attempts to retrieve non-synthetic RRs of this type and class, 555 either by performing a recursive query or, in the case of an 556 authoritative server, by examining its own results. If this query 557 results in one or more AAAA records or in an error condition, this 558 result is returned to the requesting client as per normal DNS 559 semantics. If the query results in no error but an empty answer 560 section in the response, the DNS64 resolver attempts to retrieve an A 561 record for the name in question. If this query results in an empty 562 result or in an error, this result is returned to the client. If the 563 query results in one or more A RRs, the DNS64 synthesizes AAAA RRs 564 based on the A RRs and the Pref64 prefix of the translator. The 565 DNS64 resolver then returns the synthesized AAAA records to the 566 client. 568 DNS64 MAY perform the query for the AAAA RR and for the A RR in 569 parallel, in order to minimize the delay. However, this would result 570 in performing unnecessary A RR queries in the case that the AAAA RR 571 exists. A possible trade-off would be to make them sequentially but 572 with a very short interval between them, so if we obtain a fast 573 reply, we avoid doing the additional query. (Note that this 574 discussion is relevant only if the DNS64 function needs to perform 575 external queries to fetch the RR. If the needed RR information is 576 available locally, as in the case of an authoritative server, the 577 issue is no longer relevant.) 579 A synthetic AAAA record is created from an A record as follows: 581 o The NAME field is set to the NAME field from the A record 583 o The TYPE field is set to 28 (AAAA) 585 o The CLASS field is set to 1 (IN) 586 o The TTL field is set to the TTL of the original A RR 588 o The RDLENGTH field is set to 16 590 o The RDATA field is set to the IPv6 address whose upper 96 bits are 591 Pref64::/96 and whose lower 32 bits are the IPv4 address from the 592 RDATA field of the A record. 594 3.2. Handling PTR RRs 596 If the DNS64 receives a PTR query for the IP6.ARPA domain, the DNS64 597 searches for the queried prefix on its own list of prefixes (i.e. one 598 or more Pref64 available). If the prefix contained in the query is 599 not included in its own list of prefixes, the DNS64 just forwards the 600 query to the (internal or external) resolver. If the prefix is 601 included in its own prefix list, then the DNS64 translates the QNAME 602 field to the IN-ADDR.ARPA domain by removing the Pref64:/96, and 603 extracting the IPv4 address in reversed order. The DNS64 then sends 604 the translated query to the resolver. When the resulting query is 605 resolved, the DNS64 restores the QNAME field to the IP6.ARPA domain, 606 and sends the DNS response to the original client. 608 4. Solution space analysis 610 So far the document describes the basic functionality that is needed 611 to perform the DNS64 function. However, there are several open 612 issues that require further discussion. This section present the 613 issues and several approaches to deal with them. 615 Having DNS synthesize AAAA records creates a number of issues, as 616 described in [RFC4966]: 618 o The synthesized AAAA records may leak outside their intended 619 scope; 621 o Dual-stack hosts may communicate with IPv4-only servers using IPv6 622 which is then translated to IPv4, rather than using their IPv4 623 connectivity; 625 o Interaction with DNSSEC; 627 o The DNS64 box needs to learn the Pref64::/96 used by the NAT64 628 box; 630 o Supporting the case of multiple NAT64 boxes with different 631 associated prefixes. 633 4.1. Tagging synthetic RR 635 As a general architecture consideration, it seems a good approach to 636 preserve the transparency when the semantics of an existent protocol 637 is changed. In this case, it seems architecturally sound to tag the 638 synthetic RR, so they can be identified as synthetic and act 639 accordingly. There are several ways we can achieve that, but all of 640 them impose some trade-offs between architectural cleanness and 641 deployability. 643 Tagging the synthetic RRs is relevant in the An-IPv6-network-to-IPv4- 644 Internet setup, where the synthesis is not made by the authoritative 645 name server and the following discussion applies. This is not the 646 case when the synthesis is performed by the authoritative DNS server, 647 such as in the case of the setup presented in IPv6-Internet-to-An- 648 IPv4-network. 650 Tagging is mostly useful for troubleshooting, and for translation- 651 aware end points. 653 One option to tag the synthetic RR would be to use a different RR 654 type i.e. not to synthesize AAAA RR but to create a new RR type e.g. 655 AAAASYNT that would be used in this cases. This seems 656 architecturally clean, but the problem is that the host needs to 657 explicitly ask for this new RR type and this is simply incompatible 658 with existing IPv6 hosts. In order to support this, we would need to 659 upgrade the hosts and if we are going to do that, we may as well 660 simply use the DNS64 stub resolver mode. However, it is an explicit 661 goal of DNS64/NAT64 to support unmodified IPv6 hosts, so this could 662 be considered as an optimization but we would still need to 663 synthesize AAAA RR and we still need to mark those. Therefore, this 664 option is rejected. 666 Another option is to create a new RR that would be included in the 667 additional information part of the DNS response, basically saying 668 that one or more of the RRs contained in the DNS response message are 669 synthetic. So, in this case, we could create a new AAAASYNT RR type 670 and queries could be accepted directly for this RR and when a AAAA RR 671 is synthesized for the correspondent FQDN, the AAAASYNT would be 672 included in the additional information part of the DNS response that 673 contains the synthetic AAAA RR. Of course, in order to benefit from 674 this mechanism, the receiving host needs to be upgraded to understand 675 the new AAAASYNT RR, but this is backward compatible, in the sense 676 that if the host does not understand the AAAASYNT RR it would still 677 use the AAAA RR and it would be able to communicate. In addition, a 678 host can query explicitly for the AAAASYNT RR and verify if a given 679 AAAA RR is synthetic or not. This would result in a sort of public 680 repository of synthetic AAAA RRs, which is useful for transparency. 682 One downside with this is that the tag is not directly associated 683 with the synthetic AAAA RR but is some additional information 684 contained in the DNS response. In this sense we are tagging the DNS 685 response message rather than tagging the synthetic RR. Such 686 additional information could be lost in caching servers or other 687 means of relying DNS information, losing the tag. 689 A similar option as the previous one would be to use an EDNS0 option 690 [RFC2671] to tag the DNS responses that contain one or more synthetic 691 AAAA RRs. There are however some additional issues with this. The 692 EDNS0 option can only be included if the DNS query contained the 693 EDNS0 option. It would also be possible to find out if a given AAAA 694 RR is synthetic, since the querying party could ask for the AAAA RR 695 and include the EDNS0 option. 697 Another option would be to use a well known prefix as the 698 Pref64::/96. In this case, we could assume that any AAAA RR 699 containing the well know Pref64::/96 is synthetic. This would 700 achieve tagging the RR itself, since this information can not be lost 701 in caching servers. Additional discussion about the advantages and 702 disadvantages of using a Well-Known prefix can be found 703 [I-D.miyata-behave-prefix64]. 705 4.2. Dual stack nodes 707 When dual stack nodes are involved in the communication, the 708 potential issue is that they end up using translated connectivity 709 even though the native connectivity is available. There are multiple 710 ways to try to deal with this issue, here we consider those related 711 to DNS64. 713 There are two different cases involving dual-stack nodes. 714 Communication initiated from an IPv6-only node towards a dual stack 715 node and communication initiated from a dual stack node towards an 716 IPv4-only node. We will next consider each one of these cases. 718 4.2.1. Communication initiated from an IPv6-only node towards a dual 719 stack node 721 In this case, the IPv6 only node will query for the FQDN of the dual 722 stack node. The DNS64 function will try first to get the AAAA RR. 723 Since there is one available, it will return it and no AAAA RR will 724 be synthesized from the A RR of the dual stack node. However, it 725 should be noted that the DNS64 must first try to get the real AAAA RR 726 before starting the synthesis, if not, it may result in the 727 aforementioned problem. 729 4.2.2. Communication initiated from a dual stack node toward an IPv4 730 only node 732 We consider now the case of a dual stack node is initiating a 733 communication with a IPv4-only node that has a public IPv4 address 734 published in an A RR. Dual stack nodes that have both IPv6 and IPv4 735 connectivity and are configured with an address for a DNS64 as their 736 resolving nameserver may receive responses containing synthetic AAAA 737 resource records. If the node prefers IPv6 over IPv4, using the 738 addresses in the synthetic AAAA RRs means that the node will attempt 739 to communicate through the NAT64 mechanism first, and only fall back 740 to native IPv4 connectivity if connecting through NAT64 fails (if the 741 application tries the full set of destination addresses). We have 742 multiple options to avoid this. 744 One option would be to configure the dual stack nodes not to use the 745 DNS64 mechanism. This would mean that the server they are using 746 should not be performing this function (at least not for them). The 747 drawback of this option is that the translated connectivity would not 748 be usable for backup purposes if the native connectivity is down. 750 The other option is that the dual stack nodes perform the DNS64 in 751 stub resolver mode. In this case, they know which RRs are synthetic 752 and so they know when the connectivity is translated and can be 753 avoided. The problem with this option is that it only works for 754 upgraded dual stack nodes and not with currently available nodes. 756 Another option is that dual stack nodes identify synthetic AAAA RR 757 from their tagging (whatever this is) and avoid using the translated 758 connectivity associated with the synthetic RR. However, again, this 759 option only works for upgraded nodes. 761 Another option not specific to DNS64 includes using the RFC3484 762 policy table e.g. configuring the Pref64::/96 as low priority 763 preference in the table. This option requires some means to properly 764 configure the policy table, which is not currently available (only 765 manual configuration is currently defined) (see 766 [I-D.ietf-6man-addr-select-sol] for more on this topic). 768 4.3. IPv6 nodes implementing DNSSEC 770 DNSSEC presents a special challenge for DNS64, because DNSSEC is 771 designed to detect changes to DNS answers, and DNS64 may alter 772 answers coming from an authoritative server. This section outlines 773 the various cases and discusses possible ways to address the problem. 775 4.3.1. Recursive resolvers and an-IPv6-network-to-IPv4-Internet 777 A recursive resolver can be security-aware or security-oblivious. 778 Moreover, a security-aware recursive name server can be validating or 779 non-validating, according to operator policy. For the purposes of 780 notation, we call these Rso (recursing, security oblivious), Rsav 781 (recursing, security aware and validating), and Rsan (recursing, 782 security aware and non-validating). In the cases below, the 783 recursive server is also performing DNS64, and has a local policy to 784 validate. We call this general case vDNS64, but in all the cases 785 below the DNS64 functionality should be assumed needed. 787 DNSSEC includes some signalling bits that offer some indicators of 788 what the query originator understands. 790 If a query arrives at a vDNS64 with the DO bit set, the query 791 originator is signalling that it understands DNSSEC. The DO bit does 792 not indicate that the query originator will validate the response. 793 It only means that the query originator can understand responses 794 containing DNSSEC data. Conversely, if the DO bit is clear, that is 795 evidence that the querying agent is not aware of DNSSEC. 797 If a query arrives at a vDNS64 with the CD bit set, it is an 798 indication that the querying agent wants all the validation data so 799 it can do checking itself. By local policy, vDNS64 could still 800 validate, but it must return all data to the querying agent anyway. 802 Here are the possible cases: 804 1. Rso recursor receives a query without the DO bit clear. In this 805 case, DNSSEC is not a concern, because the querying agent does 806 not understand DNSSEC responses. 808 2. Rso receives a query with the DO bit set, and the CD bit clear. 809 This is just like the case of a non-DNS64 case: the server 810 doesn't support it, so the querying agent is out of luck. 812 3. Rsan receives a query with the DO bit set and the CD bit clear. 813 An Rsan is not validating responses, likely due to local policy 814 (see [RFC4035], section 4.2). For that reason, this case amounts 815 to the same as the previous case, and no validation happens. 817 4. Rsan receives a query with DO bit set and the CD bit set. In 818 this case, the Rsan is supposed to pass on all the data it gets 819 to the query initiator (this is in section 3.2.2 of 4035). This 820 is a case will be problematic for vNAT64. If it modifies the 821 record, the client will get the data back and try to validate it, 822 and the data will be invalid as far as the client is concerned. 824 5. Rsav receives a query with the DO bit clear and CD clear. In 825 this case, the Rsav validates the data. If it fails, it returns 826 RCODE 2 (SERVFAIL); otherwise, it returns the answer. This is 827 the ideal case for vDNS64. The Rsav validates the data, and then 828 synthesizes the new record and passes that to the client. 830 6. Rsav receives a query with the DO bit set and CD clear. In 831 principle, this ought to work like the previous case, except that 832 the Rsav should also set the AD bit on the response. There is a 833 potential difficulty with the AD bit; it is addressed below. 835 7. Rsav receives a query with DO bit set and CD set. This is 836 effectively the same as the case where an Rsan receives a similar 837 query, and the same thing will happen: the downstream validator 838 will mark the data as invalid. 840 4.3.1.1. Strategy 1: Response-specific DNSSEC information 842 The vDNS64 can use the presence of the DO and CD bits to make some 843 decisions about what the query originator needs, and can react 844 accordingly: 846 1. If CD is not set and DO is not set, vDNS64 SHOULD perform 847 validation and do any translation it wants. The DNS64 MAY 848 translate the A record to AAAA. 850 2. If CD is not set and DO is set, then vDNS64 SHOULD perform 851 validation. If the data validates, the server MAY perform 852 translation, but it MUST NOT set the AD bit. This is acceptable, 853 because whereas the original data validated, the answer that is 854 actually returned to the originating client is not the validated 855 data (and therefore would not itself validate). Similarly, if 856 the data does not validate, the vDNS64 MUST respond with RCODE=2 857 (server failure). 858 A security-aware end point may want the security data, and may 859 want to pass it up to an application, and this strategy will make 860 that data unavailable. One could argue therefore that this 861 approach is not desirable. But security aware stub resolvers 862 MUST NOT place any reliance on data received from resolvers and 863 validated on their behalf without certain criteria established by 864 [RFC4035], section 4.9.3. 866 3. If the CD is set and DO is set, then vDNS64 MUST NOT perform 867 validation, and MUST NOT perform translation. It MUST hand the 868 data back to the query initiator, just like a regular recursing 869 server, and depend on the client to do the validation and the 870 translation itself. 871 The disadvantage to this approach is that an end point that is 872 translation-oblivious but security-aware and validating simply 873 won't be able to use the DNS64 functionality. In this case, the 874 end point will not have the desired benefit of NAT64. In effect, 875 this strategy means that any end point that wishes to do 876 validation in a NAT64 context must be upgraded to be translation- 877 aware as well. 879 4.3.1.2. Strategy 2: Treat synthesized AAAA similarly to synthesized 880 CNAMEs 882 An alternative to the strategy in the previous section is to emulate 883 the approach used by DNAME to synthesize CNAMEs [RFC2672]. In this 884 approach, the vDNS64 synthesizes the AAAA record from the A record. 885 When replying to the query for the AAAA, the server includes the A 886 record in one section of the response. The AAAA record is not signed 887 (the DNS64 server does not have the capability to do so anyway, since 888 it does not have the necessary key). The original A record would be 889 returned in one of two sections: 891 1. In the answer section: a server preparing an answer satisfied by 892 the DNAME substitution includes a synthesized CNAME in the answer 893 section, so by way of analogy a DNS64 server could add the 894 synthesized AAAA to the original A record, and return all of this 895 in the answer section. 896 There are some significant differences, however, between this 897 case and CNAME/DNAME. First, this will mean that clients will 898 receive an A record in response to a AAAA query. Stub resolvers 899 have always expected CNAMEs in response to A record queries; it 900 might be surprising to receive an A record in response to a query 901 for AAAA. In addition, it is likely that some validators will 902 treat the unsigned AAAA record as bogus. 904 2. In the additional section: a DNS64 server could replace the A 905 record with the synthetic AAAA, and put the original A record in 906 the additional section. A validating resolver could then find 907 the A record in the additional, detect that the IP address it 908 contains forms part of the synthetic address, and perform an 909 additional validation step on that A record if so desired. 910 The difficulty here is that the additional data is most likely to 911 be truncated whenever it is necessary to avoid the protocol 912 limits, and in a DNSSEC context that is more likely to happen. 914 4.3.2. IPv6-Internet-to-An-IPv4-network 916 In this scenario, DNSSEC is naturally supported if the IPv4 network 917 simply publishes the AAAA RR containing the IPv6 representations of 918 the IPv4 address of its internal hosts. In this case, these AAAA RR 919 are regular R, and the correspondent RRSIG and NSEC RRs can be 920 created as usual. This is the preferred approach. 922 If we consider dynamic environments, where AAAA RR are created 923 dynamically, the situation is more complex. In the case of a 924 validating security-aware stub resolver, the main issue is how to 925 sign the new synthetic AAAA RRs that are created. If the AAAA RRs 926 are created when the query is received, this would imply that the 927 AAAA RRs need to be signed on-the-fly right after the AAAA RR has 928 been synthesized. This requires that the signing keys be online in 929 the DNS64 server, and that the signing process be very fast, and is 930 one of the reasons that it is better to configure AAAA records in a 931 standard way, as though the authority server were answering AAAA 932 queries for hosts using native IPv6. In the case of a non-validating 933 security-aware stub resolvers contact it , there's no reason to sign 934 synthetic records and the problem is no longer relevant. 936 Probably we may want to recommend that if DNSSEC is used, the AAAA 937 RRs for this case need to be generated manually or when the Dyn DNS 938 update is performed. Question: how does Dyn DNS works with DNSSEC? 940 4.4. Learning the Pref64::/96 prefix 942 The only piece of information that needs to be shared between the 943 devices performing the NAT64 function and the devices performing the 944 DNS64 function is the prefix Pref64::/96. Note that the Pref64::/96 945 must be distributed to all the hosts that are performing the DNS64 946 function in stub-resolver mode and to all the name servers that are 947 performing the DNS64 function. 949 One option is to configure the Pref64::/96 manually in all these 950 devices. While this may work for servers, it doesn't seem the best 951 approach for stub-resolvers. 953 Another option is to define a DHCP option to carry this information. 954 The main issue here is the security, especially when this information 955 is used in conjunction with DNSSEC. 957 Another option is to store this information in a new RR under a well 958 known name within each domain. This information can then be signed 959 using DNSSEC so its distribution would be secured. One possibility 960 is to use a well known name, such as pref64.example.com, or even in 961 example.com. Another possibility is to put it in the reverse zone. 962 So the DNS64-aware system, as part of its initiation step, asks for 963 the reverse lookup of the configured-interface address (i.e. 964 $reverseaddress.ip6.arpa) but with the new RRTYPE (call it 64PREFIX). 965 This way, the data can be part of the signed reverse zone, it can get 966 dynamically determined as part of the protocol establishing the 967 address of the end point, and we don't have to reserve a new special 968 well-known name. 970 For more extensive discussion on this topic, the reader is referred 971 to [I-D.wing-behave-learn-prefix] 973 4.5. Supporting multiple NAT64 boxes with different associated prefixes 975 This discussion applies to the An-IPv6-network-to-IPv4-Internet 976 setup. 978 Consider the case where we have a site with multiple NAT64 boxes. 979 Each of these boxes has a different prefix associated, namely 980 Pref64_1::/96, Pref64_2::/96, ..., Pref64_n::/96. suppose that the 981 site is using one or more servers using providing the DNS64 function. 982 The question that we consider in this section is how these prefixes 983 are managed by the DNS64 function. 985 One option would be to configure only one prefix to each DNS64 986 device. In this case, we would achieve some form of load balance and 987 traffic engineering features, since the hosts configured to use a 988 given DNS64 server will use a given prefix and this means that their 989 traffic will flow through a given NAT64 box. The problem is what 990 happens if the NAT64 box fails. At that point, the DNS64 server 991 should detect the failure and start using an alternative prefix. 992 (Note that it is the NAT64 the one that have failed, but the DNS64 993 server is still working, so the host would not try an alternative 994 DNS64 in this failure mode). The failure could be detected by the 995 DNS64 device pinging itself from its IPv6 address towards its IPv4 996 address through the NAT64 in question. 998 The other option would be to configure multiple prefixes in each 999 DNS64 server. The next question is how these are managed? We can 1000 envision several ways of managing the prefixes in the DNS64 server: 1002 o One option is that the DNS64 synthesizes a single AAAA RR using a 1003 randomly chosen prefix. This would result in load sharing across 1004 the multiple NAT64 boxes. However, this would mean that a given 1005 IPv6 host can use different IPv4 transport addresses in the IPv4 1006 Internet. This is because the different synthesized AAAA RR 1007 contain different prefixes and this means that the communication 1008 is established through a different NAT64 box, hence using a 1009 different IPv4 address. Moreover, it is also possible that when 1010 an IPv6 hosts initiates two different communications using the 1011 same IPv6 transport source address, these are routed through 1012 different NAT64 boxes and they are presented to the IPv4 Internet 1013 as coming from different IPv4 transport source address. While the 1014 endpoint independence requirement doesn't cover the case of 1015 multiple NATs, it does seems that this option is against the 1016 endpoint independent behavior and should be avoided. 1018 o Another option is to track the requesting hosts and always use the 1019 same prefix for a given host. In case of failure, the DNS64 1020 function should detect the NAT64 is down and start using a 1021 different prefix (associated to a working NAT64 box). The 1022 downside of this option is that the DNS64 function needs to keep 1023 track of the hosts and prefixes and working NAT64 boxes. Rather 1024 than actually tracking per-client state, the same result could be 1025 achieved by performing a hash over the client's address and return 1026 AAAA records synthesized using the same Pref64 for all addresses 1027 that hash to the same value. 1029 o Another option is for the DNS64 to return a list of synthesized 1030 AAAA RR, one per available prefix. Besides, the DNS64 function 1031 should keep track of the hosts, so the same prefix order is used 1032 in all the replies to the same host. In this case, the host will 1033 normally use the first one if it is working, so it will always use 1034 the same NAT64 box and if something fails, it should retry with an 1035 alternative address, effectively using a different NAT64 box. 1036 This would provide the fault tolerance capabilities required 1037 without need for the DNS64 to keep track of the state of the NAT64 1038 boxes. 1040 5. Security Considerations 1042 See the discussion on the usage of DNSSEC and DNS64 described in the 1043 analysis section. 1045 6. IANA Considerations 1047 7. Changes from Previous Draft Versions 1049 Note to RFC Editor: Please remove this section prior to publication 1050 of this document as an RFC. 1052 [[This section lists the changes between the various versions of this 1053 draft.]] 1055 8. Contributors 1057 Dave Thaler 1058 Microsoft 1060 dthaler@windows.microsoft.com 1062 9. Acknowledgements 1064 This draft has benefited from the review from Dave Thaler. 1066 This draft contains the result of discussions involving many people, 1067 including: Dan Wing, Jari Arkko, Mark Townsley, Fred Baker, Xing Li, 1068 Hiroshi Miyata, Brian Carpenter, Ed Jankiewicz, Magnus Westerlund, Ed 1069 Lewis, Rob Austein, Matthijs Mekking. 1071 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 1072 Trilogy, a research project supported by the European Commission 1073 under its Seventh Framework Program. 1075 10. References 1077 10.1. Normative References 1079 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1080 Requirement Levels", BCP 14, RFC 2119, March 1997. 1082 [RFC1035] Mockapetris, P., "Domain names - implementation and 1083 specification", STD 13, RFC 1035, November 1987. 1085 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1086 RFC 2671, August 1999. 1088 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 1089 RFC 2672, August 1999. 1091 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1092 (SIIT)", RFC 2765, February 2000. 1094 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1095 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1096 RFC 4787, January 2007. 1098 [I-D.ietf-behave-tcp] 1099 Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1100 Srisuresh, "NAT Behavioral Requirements for TCP", 1101 draft-ietf-behave-tcp-08 (work in progress), 1102 September 2008. 1104 [I-D.ietf-behave-nat-icmp] 1105 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1106 Behavioral Requirements for ICMP protocol", 1107 draft-ietf-behave-nat-icmp-12 (work in progress), 1108 January 2009. 1110 [I-D.bagnulo-behave-nat64] 1111 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 1112 Address and Protocol Translation from IPv6 Clients to IPv4 1113 Servers", draft-bagnulo-behave-nat64-02 (work in 1114 progress), November 2008. 1116 10.2. Informative References 1118 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1119 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1120 February 2000. 1122 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1123 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1124 RFC 2136, April 1997. 1126 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1127 Considerations for IP Fragment Filtering", RFC 1858, 1128 October 1995. 1130 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1131 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1133 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1134 Address Translator (Traditional NAT)", RFC 3022, 1135 January 2001. 1137 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1138 Rose, "DNS Security Introduction and Requirements", 1139 RFC 4033, March 2005. 1141 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1142 Rose, "Resource Records for the DNS Security Extensions", 1143 RFC 4034, March 2005. 1145 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1146 Rose, "Protocol Modifications for the DNS Security 1147 Extensions", RFC 4035, March 2005. 1149 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 1150 Address Translator - Protocol Translator (NAT-PT) to 1151 Historic Status", RFC 4966, July 2007. 1153 [I-D.ietf-mmusic-ice] 1154 Rosenberg, J., "Interactive Connectivity Establishment 1155 (ICE): A Protocol for Network Address Translator (NAT) 1156 Traversal for Offer/Answer Protocols", 1157 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1159 [I-D.ietf-6man-addr-select-sol] 1160 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 1161 "Solution approaches for address-selection problems", 1162 draft-ietf-6man-addr-select-sol-01 (work in progress), 1163 June 2008. 1165 [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of 1166 Managed Objects for Synchronous Optical Network (SONET) 1167 Linear Automatic Protection Switching (APS) 1168 Architectures", RFC 3498, March 2003. 1170 [I-D.wing-behave-learn-prefix] 1171 Wing, D., "Learning the Address Family Translator's IPv6 1172 Prefix", draft-wing-behave-learn-prefix-00 (work in 1173 progress), October 2008. 1175 [I-D.miyata-behave-prefix64] 1176 Miyata, H., "PREFIX64 Comparison", 1177 draft-miyata-behave-prefix64-00 (work in progress), 1178 October 2008. 1180 Authors' Addresses 1182 Marcelo Bagnulo 1183 UC3M 1184 Av. Universidad 30 1185 Leganes, Madrid 28911 1186 Spain 1188 Phone: +34-91-6249500 1189 Fax: 1190 Email: marcelo@it.uc3m.es 1191 URI: http://www.it.uc3m.es/marcelo 1192 Andrew Sullivan 1193 Shinkuro 1194 4922 Fairmont Avenue, Suite 250 1195 Bethesda, MD 20814 1196 USA 1198 Phone: +1 301 961 3131 1199 Email: ajs@shinkuro.com 1201 Philip Matthews 1202 Unaffiliated 1203 600 March Road 1204 Ottawa, Ontario 1205 Canada 1207 Phone: +1 613-592-4343 x224 1208 Fax: 1209 Email: philip_matthews@magma.ca 1210 URI: 1212 Iljitsch van Beijnum 1213 IMDEA Networks 1214 Av. Universidad 30 1215 Leganes, Madrid 28911 1216 Spain 1218 Phone: +34-91-6246245 1219 Email: iljitsch@muada.com 1221 Masahito Endo 1222 Yokogawa Electric Corporation 1224 Email: masahito.endou@jp.yokogawa.com