idnits 2.17.1 draft-ietf-behave-dns64-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 10 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2010) is 5043 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) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-08 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-11 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-09 == Outdated reference: A later version (-15) exists of draft-ietf-dnsop-default-local-zones-13 Summary: 1 error (**), 0 flaws (~~), 6 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: January 6, 2011 Shinkuro 6 P. Matthews 7 Alcatel-Lucent 8 I. van Beijnum 9 IMDEA Networks 10 July 5, 2010 12 DNS64: DNS extensions for Network Address Translation from IPv6 Clients 13 to IPv4 Servers 14 draft-ietf-behave-dns64-10 16 Abstract 18 DNS64 is a mechanism for synthesizing AAAA records from A records. 19 DNS64 is used with an IPv6/IPv4 translator to enable client-server 20 communication between an IPv6-only client and an IPv4-only server, 21 without requiring any changes to either the IPv6 or the IPv4 node, 22 for the class of applications that work through NATs. This document 23 specifies DNS64, and provides suggestions on how it should be 24 deployed in conjunction with IPv6/IPv4 translators. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 6, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 8 63 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 10 65 5.1. Resolving AAAA queries and the answer section . . . . . . 11 66 5.1.1. The answer when there is AAAA data available . . . . . 11 67 5.1.2. The answer when there is an error . . . . . . . . . . 11 68 5.1.3. Dealing with timeouts . . . . . . . . . . . . . . . . 12 69 5.1.4. Special exclusion set for AAAA records . . . . . . . . 12 70 5.1.5. Dealing with CNAME and DNAME . . . . . . . . . . . . . 12 71 5.1.6. Data for the answer when performing synthesis . . . . 13 72 5.1.7. Performing the synthesis . . . . . . . . . . . . . . . 13 73 5.1.8. Querying in parallel . . . . . . . . . . . . . . . . . 14 74 5.2. Generation of the IPv6 representations of IPv4 75 addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 5.3. Handling other Resource Records and the Additional 77 Section . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5.3.1. PTR Resource Record . . . . . . . . . . . . . . . . . 15 79 5.3.2. Handling the additional section . . . . . . . . . . . 16 80 5.3.3. Other Resource Records . . . . . . . . . . . . . . . . 17 81 5.4. Assembling a synthesized response to a AAAA query . . . . 17 82 5.5. DNSSEC processing: DNS64 in recursive resolver mode . . . 17 83 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 18 84 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 19 85 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 19 86 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 19 87 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 19 88 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 20 89 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 20 90 7. Deployment scenarios and examples . . . . . . . . . . . . . . 21 91 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with 92 DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 22 93 7.2. An example of an-IPv6-network-to-IPv4-Internet setup 94 with DNS64 in stub-resolver mode . . . . . . . . . . . . . 23 95 7.3. Example of IPv6-Internet-to-an-IPv4-network setup 96 DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 24 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 103 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 104 Appendix A. Motivations and Implications of synthesizing AAAA 105 Resource Records when real AAAA Resource Records 106 exist . . . . . . . . . . . . . . . . . . . . . . . . 29 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 109 1. Introduction 111 This document specifies DNS64, a mechanism that is part of the 112 toolbox for IPv6-IPv4 transition and co-existence. DNS64, used 113 together with an IPv6/IPv4 translator such as stateful NAT64 114 [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to 115 initiate communications by name to an IPv4-only server. 117 DNS64 is a mechanism for synthesizing AAAA resource records (RRs) 118 from A RRs. A synthetic AAAA RR created by the DNS64 from an 119 original A RR contains the same owner name of the original A RR but 120 it contains an IPv6 address instead of an IPv4 address. The IPv6 121 address is an IPv6 representation of the IPv4 address contained in 122 the original A RR. The IPv6 representation of the IPv4 address is 123 algorithmically generated from the IPv4 address returned in the A RR 124 and a set of parameters configured in the DNS64 (typically, an IPv6 125 prefix used by IPv6 representations of IPv4 addresses and optionally 126 other parameters). 128 Together with an IPv6/IPv4 translator, these two mechanisms allow an 129 IPv6-only client to initiate communications to an IPv4-only server 130 using the FQDN of the server. 132 These mechanisms are expected to play a critical role in the IPv4- 133 IPv6 transition and co-existence. Due to IPv4 address depletion, it 134 is likely that in the future, many IPv6-only clients will want to 135 connect to IPv4-only servers. In the typical case, the approach only 136 requires the deployment of IPv6/IPv4 translators that connect an 137 IPv6-only network to an IPv4-only network, along with the deployment 138 of one or more DNS64-enabled name servers. However, some advanced 139 features require performing the DNS64 function directly in the end- 140 hosts themselves. 142 2. Overview 144 This section provides a non-normative introduction to the DNS64 145 mechanism. 147 We assume that we have one or more IPv6/IPv4 translator boxes 148 connecting an IPv4 network and an IPv6 network. The IPv6/IPv4 149 translator device provides translation services between the two 150 networks enabling communication between IPv4-only hosts and IPv6-only 151 hosts. (NOTE: By IPv6-only hosts we mean hosts running IPv6-only 152 applications, hosts that can only use IPv6, as well as cases where 153 only IPv6 connectivity is available to the client. By IPv4-only 154 servers we mean servers running IPv4-only applications, servers that 155 can only use IPv4, as well as cases where only IPv4 connectivity is 156 available to the server). Each IPv6/IPv4 translator used in 157 conjunction with DNS64 must allow communications initiated from the 158 IPv6-only host to the IPv4-only host. 160 To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to 161 learn the address of the responder, DNS64 is used to synthesize a 162 AAAA record from an A record containing a real IPv4 address of the 163 responder, whenever the DNS64 cannot retrieve a AAAA record for the 164 queried name. The DNS64 service appears as a regular DNS server or 165 resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query 166 generated by the IPv6 initiator. It first attempts a resolution for 167 the requested AAAA records. If there are no AAAA records available 168 for the target node (which is the normal case when the target node is 169 an IPv4-only node), DNS64 performs a query for A records. For each A 170 record discovered, DNS64 creates a synthetic AAAA RR from the 171 information retrieved in the A RR. 173 The owner name of a synthetic AAAA RR is the same as that of the 174 original A RR, but an IPv6 representation of the IPv4 address 175 contained in the original A RR is included in the AAAA RR. The IPv6 176 representation of the IPv4 address is algorithmically generated from 177 the IPv4 address and additional parameters configured in the DNS64. 178 Among those parameters configured in the DNS64, there is at least one 179 IPv6 prefix. If not explicitly mentioned, all prefixes are treated 180 equally and the operations described in this document are performed 181 using the prefixes available. So as to be general, we will call any 182 of these prefixes Pref64::/n, and describe the operations made with 183 the generic prefix Pref64::/n. The IPv6 address representing IPv4 184 addresses included in the AAAA RR synthesized by the DNS64 contain 185 Pref64::/n and they also embed the original IPv4 address. 187 The same algorithm and the same Pref64::/n prefix(es) must be 188 configured both in the DNS64 device and the IPv6/IPv4 translator(s), 189 so that both can algorithmically generate the same IPv6 190 representation for a given IPv4 address. In addition, it is required 191 that IPv6 packets addressed to an IPv6 destination address that 192 contains the Pref64::/n be delivered to an IPv6/IPv4 translator that 193 has that particular Pref64::/n configured, so they can be translated 194 into IPv4 packets. 196 Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs 197 are passed back to the IPv6 initiator, which will initiate an IPv6 198 communication with the IPv6 address associated with the IPv4 199 receiver. The packet will be routed to an IPv6/IPv4 translator which 200 will forward it to the IPv4 network. 202 In general, the only shared state between the DNS64 and the IPv6/IPv4 203 translator is the Pref64::/n and an optional set of static 204 parameters. The Pref64::/n and the set of static parameters must be 205 configured to be the same on both; there is no communication between 206 the DNS64 device and IPv6/IPv4 translator functions. The mechanism 207 to be used for configuring the parameters of the DNS64 is beyond the 208 scope of this memo. 210 The prefixes to be used as Pref64::/n and their applicability are 211 discussed in [I-D.ietf-behave-address-format]. There are two types 212 of prefixes that can be used as Pref64::/n. 214 The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved 215 by [I-D.ietf-behave-address-format] for the purpose of 216 representing IPv4 addresses in IPv6 address space. 218 The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is 219 an IPv6 prefix assigned by an organization to create IPv6 220 representations of IPv4 addresses. 222 The main difference in the nature of the two types of prefixes is 223 that the NSP is a locally assigned prefix that is under control of 224 the organization that is providing the translation services, while 225 the Well-Known Prefix is a prefix that has a global meaning since it 226 has been assigned for the specific purpose of representing IPv4 227 addresses in IPv6 address space. 229 The DNS64 function can be performed in any of three places. The 230 terms below are more formally defined in Section 4. 232 The first option is to locate the DNS64 function in authoritative 233 servers for a zone. In this case, the authoritative server provides 234 synthetic AAAA RRs for an IPv4-only host in its zone. This is one 235 type of DNS64 server. 237 Another option is to locate the DNS64 function in recursive name 238 servers serving end hosts. In this case, when an IPv6-only host 239 queries the name server for AAAA RRs for an IPv4-only host, the name 240 server can perform the synthesis of AAAA RRs and pass them back to 241 the IPv6-only initiator. The main advantage of this mode is that 242 current IPv6 nodes can use this mechanism without requiring any 243 modification. This mode is called "DNS64 in DNS recursive resolver 244 mode" . This is a second type of DNS64 server, and it is also one 245 type of DNS64 resolver. 247 The last option is to place the DNS64 function in the end hosts, 248 coupled to the local (stub) resolver. In this case, the stub 249 resolver will try to obtain (real) AAAA RRs and in case they are not 250 available, the DNS64 function will synthesize AAAA RRs for internal 251 usage. This mode is compatible with some advanced functions like 252 DNSSEC validation in the end host. The main drawback of this mode is 253 its deployability, since it requires changes in the end hosts. This 254 mode is called "DNS64 in stub-resolver mode". This is the second 255 type of DNS64 resolver. 257 3. Background to DNS64-DNSSEC interaction 259 DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge 260 for DNS64, because DNSSEC is designed to detect changes to DNS 261 answers, and DNS64 may alter answers coming from an authoritative 262 server. 264 A recursive resolver can be security-aware or security-oblivious. 265 Moreover, a security-aware recursive resolver can be validating or 266 non-validating, according to operator policy. In the cases below, 267 the recursive resolver is also performing DNS64, and has a local 268 policy to validate. We call this general case vDNS64, but in all the 269 cases below the DNS64 functionality should be assumed needed. 271 DNSSEC includes some signaling bits that offer some indicators of 272 what the query originator understands. 274 If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit 275 set, the query originator is signaling that it understands DNSSEC. 276 The DO bit does not indicate that the query originator will validate 277 the response. It only means that the query originator can understand 278 responses containing DNSSEC data. Conversely, if the DO bit is 279 clear, that is evidence that the querying agent is not aware of 280 DNSSEC. 282 If a query arrives at a vDNS64 device with the "Checking Disabled" 283 (CD) bit set, it is an indication that the querying agent wants all 284 the validation data so it can do checking itself. By local policy, 285 vDNS64 could still validate, but it must return all data to the 286 querying agent anyway. 288 Here are the possible cases: 290 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with 291 the DO bit clear. In this case, DNSSEC is not a concern, because 292 the querying agent does not understand DNSSEC responses. 294 2. A security-oblivious DNS64 receives a query with the DO bit set, 295 and the CD bit clear or set. This is just like the case of a 296 non-DNS64 case: the server doesn't support it, so the querying 297 agent is out of luck. 299 3. A security-aware and non-validating DNS64 receives a query with 300 the DO bit set and the CD bit clear. Such a resolver is not 301 validating responses, likely due to local policy (see [RFC4035], 302 section 4.2). For that reason, this case amounts to the same as 303 the previous case, and no validation happens. 305 4. A security-aware and non-validating DNS64 receives a query with 306 the DO bit set and the CD bit set. In this case, the resolver is 307 supposed to pass on all the data it gets to the query initiator 308 (see section 3.2.2 of [RFC4035]). This case will not work with 309 DNS64, unless the validating resolver is prepared to do DNS64 310 itself. If the DNS64 server modifies the record, the client will 311 get the data back and try to validate it, and the data will be 312 invalid as far as the client is concerned. 314 5. A security-aware and validating DNS64 node receives a query with 315 the DO bit clear and CD clear. In this case, the resolver 316 validates the data. If it fails, it returns RCODE 2 (Server 317 failure); otherwise, it returns the answer. This is the ideal 318 case for vDNS64. The resolver validates the data, and then 319 synthesizes the new record and passes that to the client. The 320 client, which is presumably not validating (else it should have 321 set DO and CD), cannot tell that DNS64 is involved. 323 6. A security-aware and validating DNS64 node receives a query with 324 the DO bit set and CD clear. This works like the previous case, 325 except that the resolver should also set the "Authentic Data" 326 (AD) bit on the response. 328 7. A security-aware and validating DNS64 node receives a query with 329 the DO bit set and CD set. This is effectively the same as the 330 case where a security-aware and non-validating recursive resolver 331 receives a similar query, and the same thing will happen: the 332 downstream validator will mark the data as invalid if DNS64 has 333 performed synthesis. The node needs to do DNS64 itself, or else 334 communication will fail. 336 4. Terminology 338 This section provides definitions for the special terms used in the 339 document. 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 343 document are to be interpreted as described in RFC 2119 [RFC2119]. 345 Authoritative server: A DNS server that can answer authoritatively a 346 given DNS question. 348 DNS64: A logical function that synthesizes DNS resource records (e.g 349 AAAA records containing IPv6 addresses) from DNS resource records 350 actually contained in the DNS (e.g., A records containing IPv4 351 addresses). 353 DNS64 recursor: A recursive resolver that provides the DNS64 354 functionality as part of its operation. This is the same thing as 355 "DNS64 in recursive resolver mode". 357 DNS64 resolver: Any resolver (stub resolver or recursive resolver) 358 that provides the DNS64 function. 360 DNS64 server: Any server providing the DNS64 function. 362 Recursive resolver: A DNS server that accepts requests from one 363 resolver, and asks another server (of some description) for the 364 answer on behalf of the first resolver. 366 Synthetic RR: A DNS resource record (RR) that is not contained in 367 any zone data file, but has been synthesized from other RRs. An 368 example is a synthetic AAAA record created from an A record. 370 IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 371 packets and vice-versa. It is only required that the 372 communication initiated from the IPv6 side be supported. 374 For a detailed understanding of this document, the reader should also 375 be familiar with DNS terminology from [RFC1034], [RFC1035] and 376 current NAT terminology from [RFC4787]. Some parts of this document 377 assume familiarity with the terminology of the DNS security 378 extensions outlined in [RFC4035]. It is worth emphasizing that while 379 DNS64 is a logical function separate from the DNS, it is nevertheless 380 closely associated with that protocol. It depends on the DNS 381 protocol, and some behavior of DNS64 will interact with regular DNS 382 responses. 384 5. DNS64 Normative Specification 386 DNS64 is a logical function that synthesizes AAAA records from A 387 records. The DNS64 function may be implemented in a stub resolver, 388 in a recursive resolver, or in an authoritative name server. It 389 works within those DNS functions, and appears on the network as 390 though it were a "plain" DNS resolver or name server conforming to 391 [RFC1034], and [RFC1035]. 393 The implementation SHOULD support mapping of separate IPv4 address 394 ranges to separate IPv6 prefixes for AAAA record synthesis. This 395 allows handling of special use IPv4 addresses [RFC5735]. 397 DNS64 also responds to PTR queries involving addresses containing any 398 of the IPv6 prefixes it uses for synthesis of AAAA RRs. 400 5.1. Resolving AAAA queries and the answer section 402 When the DNS64 receives a query for RRs of type AAAA and class IN, it 403 first attempts to retrieve non-synthetic RRs of this type and class, 404 either by performing a query or, in the case of an authoritative 405 server, by examining its own results. The query may be answered from 406 a local cache, if one is available. DNS64 operation for classes 407 other than IN is undefined, and a DNS64 MUST behave as though no 408 DNS64 function is configured. 410 5.1.1. The answer when there is AAAA data available 412 If the query results in one or more AAAA records in the answer 413 section, the result is returned to the requesting client as per 414 normal DNS semantics, except in the case where any of the AAAA 415 records match a special exclusion set of prefixes, considered in 416 Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64 417 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A 418 for an analysis of the motivations for and the implications of not 419 complying with this recommendation). By default DNS64 420 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs 421 exist. 423 5.1.2. The answer when there is an error 425 If the query results in a response with RCODE other than 0 (No error 426 condition), then there are two possibilities. A result with RCODE=3 427 (Name Error) is handled according to normal DNS operation (which is 428 normally to return the error to the client). This stage is still 429 prior to any synthesis having happened, so a response to be returned 430 to the client does not need any special assembly than would usually 431 happen in DNS operation. 433 Any other RCODE is treated as though the RCODE were 0 and the answer 434 section were empty. This is because of the large number of different 435 responses from deployed name servers when they receive AAAA queries 436 without a AAAA record being available (see [RFC4074]). Note that 437 this means, for practical purposes, that several different classes of 438 error in the DNS are all treated as though a AAAA record is not 439 available for that owner name. 441 It is important to note that, as of this writing, some servers 442 respond with RCODE=3 to a AAAA query even if there is an A record 443 available for that owner name. Those servers are in clear violation 444 of the meaning of RCODE 3, and it is expected that they will decline 445 in use as IPv6 deployment increases. 447 5.1.3. Dealing with timeouts 449 If the query receives no answer before the timeout (which might be 450 the timeout from every authoritative server, depending on whether the 451 DNS64 is in recursive resolver mode), it is treated as RCODE=2 452 (Server failure). . 454 5.1.4. Special exclusion set for AAAA records 456 Some IPv6 addresses are not actually usable by IPv6-only hosts. If 457 they are returned to IPv6-only querying agents as AAAA records, 458 therefore, the goal of decreasing the number of failure modes will 459 not be attained. Examples include AAAA records with addresses in the 460 ::ffff:0:0/96 network, and possibly (depending on the context) AAAA 461 records with the site's Pref::64/n or the Well-Known Prefix (see 462 below for more about the Well-Known Prefix). A DNS64 implementation 463 SHOULD provide a mechanism to specify IPv6 prefix ranges to be 464 treated as though the AAAA containing them were an empty answer. An 465 implementation SHOULD include the ::ffff/96 network in that range by 466 default. Failure to provide this facility will mean that clients 467 querying the DNS64 function may not be able to communicate with hosts 468 that would be reachable from a dual-stack host. 470 When the DNS64 performs its initial AAAA query, if it receives an 471 answer with only AAAA records containing addresses in the excluded 472 range(s), then it MUST treat the answer as though it were an empty 473 answer, and proceed accordingly. If it receives an answer with at 474 least one AAAA record containing an address outside any of the 475 excluded range(s), then it MAY build an answer section for a response 476 including only the AAAA record(s) that do not contain any of the 477 addresses inside the excluded ranges. That answer section is used in 478 the assembly of a response as detailed in Section 5.4. 479 Alternatively, it MAY treat the answer as though it were an empty 480 answer, and proceed accordingly. It MUST NOT return the offending 481 AAAA records as part of a response. 483 5.1.5. Dealing with CNAME and DNAME 485 If the response contains a CNAME or a DNAME, then the CNAME or DNAME 486 chain is followed until the first terminating A or AAAA record is 487 reached. This may require the DNS64 to ask for an A record, in case 488 the response to the original AAAA query is a CNAME or DNAME without a 489 AAAA record to follow. The resulting AAAA or A record is treated 490 like any other AAAA or A case, as appropriate. 492 When assembling the answer section, any chains of CNAME or DNAME RRs 493 are included as part of the answer along with the synthetic AAAA (if 494 appropriate). 496 5.1.6. Data for the answer when performing synthesis 498 If the query results in no error but an empty answer section in the 499 response, the DNS64 attempts to retrieve A records for the name in 500 question, either by performing another query or, in the case of an 501 authoritative server, by examining its own results. If this new A RR 502 query results in an empty answer or in an error, then the empty 503 result or error is used as the basis for the answer returned to the 504 querying client. If instead the query results in one or more A RRs, 505 the DNS64 synthesizes AAAA RRs based on the A RRs according to the 506 procedure outlined in Section 5.1.7. The DNS64 returns the 507 synthesized AAAA records in the answer section, removing the A 508 records that form the basis of the synthesis. 510 5.1.7. Performing the synthesis 512 A synthetic AAAA record is created from an A record as follows: 514 o The NAME field is set to the NAME field from the A record 516 o The TYPE field is set to 28 (AAAA) 518 o The CLASS field is set to the original CLASS field, 1. Under this 519 specification, DNS64 for any CLASS other than 1 is undefined. 521 o The TTL field is set to the minimum of the TTL of the original A 522 RR and the SOA RR for the queried domain. (Note that in order to 523 obtain the TTL of the SOA RR, the DNS64 does not need to perform a 524 new query, but it can remember the TTL from the SOA RR in the 525 negative response to the AAAA query. If the SOA RR was not 526 delivered with the negative response to the AAAA query, then the 527 DNS64 SHOULD use a default value of 600 seconds. It is possible 528 instead to query explicitly for the SOA RR and use the result of 529 that query, but this will increase query load and time to 530 resolution for little additional benefit.) This is in keeping 531 with the approach used in negative caching ([RFC2308] 533 o The RDLENGTH field is set to 16 535 o The RDATA field is set to the IPv6 representation of the IPv4 536 address from the RDATA field of the A record. The DNS64 SHOULD 537 check each A RR against configured IPv4 address ranges and select 538 the corresponding IPv6 prefix to use in synthesizing the AAAA RR. 539 See Section 5.2 for discussion of the algorithms to be used in 540 effecting the transformation. 542 5.1.8. Querying in parallel 544 The DNS64 MAY perform the query for the AAAA RR and for the A RR in 545 parallel, in order to minimize the delay. However, this would result 546 in performing unnecessary A RR queries in the case where no AAAA RR 547 synthesis is required. A possible trade-off would be to perform them 548 sequentially but with a very short interval between them, so if we 549 obtain a fast reply, we avoid doing the additional query. (Note that 550 this discussion is relevant only if the DNS64 function needs to 551 perform external queries to fetch the RR. If the needed RR 552 information is available locally, as in the case of an authoritative 553 server, the issue is no longer relevant.) 555 5.2. Generation of the IPv6 representations of IPv4 addresses 557 DNS64 supports multiple algorithms for the generation of the IPv6 558 representation of an IPv4 address. The constraints imposed on the 559 generation algorithms are the following: 561 The same algorithm to create an IPv6 address from an IPv4 address 562 MUST be used by both a DNS64 to create the IPv6 address to be 563 returned in the synthetic AAAA RR from the IPv4 address contained 564 in an original A RR, and by a IPv6/IPv4 translator to create the 565 IPv6 address to be included in the source address field of the 566 outgoing IPv6 packets from the IPv4 address included in the source 567 address field of the incoming IPv4 packet. 569 The algorithm MUST be reversible; i.e., it MUST be possible to 570 derive the original IPv4 address from the IPv6 representation. 572 The input for the algorithm MUST be limited to the IPv4 address, 573 the IPv6 prefix (denoted Pref64::/n) used in the IPv6 574 representations and optionally a set of stable parameters that are 575 configured in the DNS64 and in the NAT64 (such as fixed string to 576 be used as a suffix). 578 For each prefix Pref64::/n, n MUST be less than or equal to 96. 579 If one or more Pref64::/n are configured in the DNS64 through 580 any means (such as manually configured, or other automatic 581 means not specified in this document), the default algorithm 582 MUST use these prefixes (and not use the Well-Known Prefix). 583 If no prefix is available, the algorithm MUST use the Well- 584 Known Prefix 64:FF9B::/96 defined in 586 [I-D.ietf-behave-address-format] to represent the IPv4 unicast 587 address range 589 [[anchor8: Note in document: The value 64:FF9B::/96 is proposed as 590 the value for the Well-Known prefix and needs to be confirmed 591 whenis published as RFC.]][I-D.ietf-behave-address-format] 593 A DNS64 MUST support the algorithm for generating IPv6 594 representations of IPv4 addresses defined in Section 2 of 595 [I-D.ietf-behave-address-format]. Moreover, the aforementioned 596 algorithm MUST be the default algorithm used by the DNS64. While the 597 normative description of the algorithm is provided in 598 [I-D.ietf-behave-address-format], a sample description of the 599 algorithm and its application to different scenarios is provided in 600 Section 7 for illustration purposes. 602 5.3. Handling other Resource Records and the Additional Section 604 5.3.1. PTR Resource Record 606 If a DNS64 server receives a PTR query for a record in the IP6.ARPA 607 domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the 608 address portion of the QNAME according to the encoding scheme 609 outlined in section 2.5 of [RFC3596], and examine the resulting 610 address to see whether its prefix matches any of the locally- 611 configured Pref64::/n. There are two alternatives for a DNS64 server 612 to respond to such PTR queries. A DNS64 server MUST provide one of 613 these, and SHOULD NOT provide both at the same time unless different 614 IP6.ARPA zones require answers of different sorts: 616 1. The first option is for the DNS64 server to respond 617 authoritatively for its prefixes. If the address prefix matches 618 any Pref64::/n used in the site, either a NSP or the Well-Known 619 Prefix (i.e. 64:FF9B::/96), then the DNS64 server MAY answer the 620 query using locally-appropriate RDATA. The DNS64 server MAY use 621 the same RDATA for all answers. Note that the requirement is to 622 match any Pref64::/n used at the site, and not merely the 623 locally-configured Pref64::/n. This is because end clients could 624 ask for a PTR record matching an address received through a 625 different (site-provided) DNS64, and if this strategy is in 626 effect, those queries should never be sent to the global DNS. 627 The advantage of this strategy is that it makes plain to the 628 querying client that the prefix is one operated by the (DNS64) 629 site, and that the answers the client is getting are generated by 630 DNS64. The disadvantage is that any useful reverse-tree 631 information that might be in the global DNS is unavailable to the 632 clients querying the DNS64. 634 2. The second option is for the DNS64 nameserver to synthesize a 635 CNAME mapping the IP6.ARPA namespace to the corresponding IN- 636 ADDR.ARPA name. The rest of the response would be the normal DNS 637 processing. The CNAME can be signed on the fly if need be. The 638 advantage of this approach is that any useful information in the 639 reverse tree is available to the querying client. The 640 disadvantage is that it adds additional load to the DNS64 641 (because CNAMEs have to be synthesized for each PTR query that 642 matches the Pref64::/n), and that it may require signing on the 643 fly. In addition, the generated CNAME could correspond to an 644 unpopulated in-addr.arpa zone, so the CNAME would provide a 645 reference to a non-existent record. 647 If the address prefix does not match any Pref64::/n, then the DNS64 648 server MUST process the query as though it were any other query; i.e. 649 a recursive nameserver MUST attempt to resolve the query as though it 650 were any other (non-A/AAAA) query, and an authoritative server MUST 651 respond authoritatively or with a referral, as appropriate. 653 5.3.2. Handling the additional section 655 DNS64 synthesis MUST NOT be performed on any records in the 656 additional section of synthesized answers. The DNS64 MUST pass the 657 additional section unchanged. 659 It may appear that adding synthetic records to the additional section 660 is desirable, because clients sometimes use the data in the 661 additional section to proceed without having to re-query. There is 662 in general no promise, however, that the additional section will 663 contain all the relevant records, so any client that depends on the 664 additional section being able to satisfy its needs (i.e. without 665 additional queries) is necessarily broken. An IPv6-only client that 666 needs a AAAA record, therefore, will send a query for the necessary 667 AAAA record if it is unable to find such a record in the additional 668 section of an answer it is consuming. For a correctly-functioning 669 client, the effect would be no different if the additional section 670 were empty. 672 The alternative, of removing the A records in the additional section 673 and replacing them with synthetic AAAA records, may cause a host 674 behind a NAT64 to query directly a nameserver that is unaware of the 675 NAT64 in question. The result in this case will be resolution 676 failure anyway, only later in the resolution operation. 678 The prohibition on synthetic data in the additional section reduces, 679 but does not eliminate, the possibility of resolution failures due to 680 cached DNS data from behind the DNS64. See Section 6. 682 5.3.3. Other Resource Records 684 If the DNS64 is in recursive resolver mode, then considerations 685 outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant. 687 All other RRs MUST be returned unchanged. This includes responses to 688 queries for A RRs. 690 5.4. Assembling a synthesized response to a AAAA query 692 A DNS64 uses different pieces of data to build the response returned 693 to the querying client. 695 The query that is used as the basis for synthesis results either in 696 an error, an answer that can be used as a basis for synthesis, or an 697 empty (authoritative) answer. If there is an empty answer, then the 698 DNS64 responds to the original querying client with the answer the 699 DNS64 received to the original (initiator's) query. Otherwise, the 700 response is assembled as follows. 702 The header fields are set according to the usual rules for recursive 703 or authoritative servers, depending on the role that the DNS64 is 704 serving. The question section is copied from the original 705 (initiator's) query. The answer section is populated according to 706 the rules in Section 5.1.7. The authority and additional sections 707 are copied from the response to the final query that the DNS64 708 performed, and used as the basis for synthesis. 710 The final response from the DNS64 is subject to all the standard DNS 711 rules, including truncation [RFC1035] and EDNS0 handling [RFC2671]. 713 5.5. DNSSEC processing: DNS64 in recursive resolver mode 715 We consider the case where a recursive resolver that is performing 716 DNS64 also has a local policy to validate the answers according to 717 the procedures outlined in [RFC4035] Section 5. We call this general 718 case vDNS64. 720 The vDNS64 uses the presence of the DO and CD bits to make some 721 decisions about what the query originator needs, and can react 722 accordingly: 724 1. If CD is not set and DO is not set, vDNS64 SHOULD perform 725 validation and do synthesis as needed. See the next item for 726 rules about how to do validation and synthesis. In this case, 727 however, vDNS64 MUST NOT set the AD bit in any response. 729 2. If CD is not set and DO is set, then vDNS64 SHOULD perform 730 validation. Whenever vDNS64 performs validation, it MUST 731 validate the negative answer for AAAA queries before proceeding 732 to query for A records for the same name, in order to be sure 733 that there is not a legitimate AAAA record on the Internet. 734 Failing to observe this step would allow an attacker to use DNS64 735 as a mechanism to circumvent DNSSEC. If the negative response 736 validates, and the response to the A query validates, then the 737 vDNS64 MAY perform synthesis and SHOULD set the AD bit in the 738 answer to the client. This is acceptable, because [RFC4035], 739 section 3.2.3 says that the AD bit is set by the name server side 740 of a security-aware recursive name server if and only if it 741 considers all the RRSets in the Answer and Authority sections to 742 be authentic. In this case, the name server has reason to 743 believe the RRSets are all authentic, so it SHOULD set the AD 744 bit. If the data does not validate, the vDNS64 MUST respond with 745 RCODE=2 (Server failure). 746 A security-aware end point might take the presence of the AD bit 747 as an indication that the data is valid, and may pass the DNS 748 (and DNSSEC) data to an application. If the application attempts 749 to validate the synthesized data, of course, the validation will 750 fail. One could argue therefore that this approach is not 751 desirable, but security aware stub resolvers must not place any 752 reliance on data received from resolvers and validated on their 753 behalf without certain criteria established by [RFC4035], section 754 4.9.3. An application that wants to perform validation on its 755 own should use the CD bit. 757 3. If the CD bit is set and DO is set, then vDNS64 MAY perform 758 validation, but MUST NOT perform synthesis. It MUST return the 759 data to the query initiator, just like a regular recursive 760 resolver, and depend on the client to do the validation and the 761 synthesis itself. 762 The disadvantage to this approach is that an end point that is 763 translation-oblivious but security-aware and validating will not 764 be able to use the DNS64 functionality. In this case, the end 765 point will not have the desired benefit of NAT64. In effect, 766 this strategy means that any end point that wishes to do 767 validation in a NAT64 context must be upgraded to be translation- 768 aware as well. 770 6. Deployment notes 772 While DNS64 is intended to be part of a strategy for aiding IPv6 773 deployment in an internetworking environment with some IPv4-only and 774 IPv6-only networks, it is important to realise that it is 775 incompatible with some things that may be deployed in an IPv4-only or 776 dual-stack context. 778 6.1. DNS resolvers and DNS64 780 Full-service resolvers that are unaware of the DNS64 function can be 781 (mis)configured to act as mixed-mode iterative and forwarding 782 resolvers. In a native IPv4 context, this sort of configuration may 783 appear to work. It is impossible to make it work properly without it 784 being aware of the DNS64 function, because it will likely at some 785 point obtain IPv4-only glue records and attempt to use them for 786 resolution. The result that is returned will contain only A records, 787 and without the ability to perform the DNS64 function the resolver 788 will be unable to answer the necessary AAAA queries. 790 6.2. DNSSEC validators and DNS64 792 An existing DNSSEC validator (i.e. that is unaware of DNS64) might 793 reject all the data that comes from DNS64 as having been tampered 794 with (even if it did not set CD when querying). If it is necessary 795 to have validation behind the DNS64, then the validator must know how 796 to perform the DNS64 function itself. Alternatively, the validating 797 host may establish a trusted connection with a DNS64, and allow the 798 DNS64 recursor to do all validation on its behalf. 800 6.3. DNS64 and multihomed and dual-stack hosts 802 6.3.1. IPv6 multihomed hosts 804 Synthetic AAAA records may be constructed on the basis of the network 805 context in which they were constructed. If a host sends DNS queries 806 to resolvers in multiple networks, it is possible that some of them 807 will receive answers from a DNS64 without all of them being connected 808 via a NAT64. For instance, suppose a system has two interfaces, i1 809 and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2 810 has native IPv6 connectivity only. I1 might receive a AAAA answer 811 from a DNS64 that is configured for a particular NAT64; the IPv6 812 address contained in that AAAA answer will not connect with anything 813 via i2. 815 +---------------+ +-------------+ 816 | i1 (IPv6)+----NAT64--------+IPv4 Internet| 817 | | +-------------+ 818 | host | 819 | | +-------------+ 820 | i2 (IPv6)+-----------------+IPv6 Internet| 821 +---------------+ +-------------+ 823 Figure 1: IPv6 multihomed hosts 825 This example illustrates why it is generally preferable that hosts 826 treat DNS answers from one interface as local to that interface. The 827 answer received on one interface will not work on the other 828 interface. Hosts that attempt to use DNS answers globally may 829 encounter surprising failures in these cases. 831 Note that the issue is not that there are two interfaces, but that 832 there are two networks involved. The same results could be achieved 833 with a single interface routed to two different networks. 835 6.3.2. Accidental dual-stack DNS64 use 837 Similarly, suppose that i1 has IPv6 connectivity and can connect to 838 the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity. 839 In this case, i1 could receive an IPv6 address from a synthetic AAAA 840 that would better be reached via native IPv4. Again, it is worth 841 emphasising that this arises because there are two networks involved. 843 +---------------+ +-------------+ 844 | i1 (IPv6)+----NAT64--------+IPv4 Internet| 845 | | +-------------+ 846 | host | 847 | | +-------------+ 848 | i2 (IPv4)+-----------------+IPv4 Internet| 849 +---------------+ +-------------+ 851 Figure 2: Accidental dual-stack DNS64 use 853 The default configuration of dual-stack hosts is that IPv6 is 854 preferred over IPv4 ([RFC3484]). In that arrangement the host will 855 often use the NAT64 when native IPv4 would be more desirable. For 856 this reason, hosts with IPv4 connectivity to the Internet should 857 avoid using DNS64. This can be partly resolved by ISPs when 858 providing DNS resolvers to clients, but that is not a guarantee that 859 the NAT64 will never be used when a native IPv4 connection should be 860 used. There is no general-purpose mechanism to ensure that native 861 IPv4 transit will always be preferred, because to a DNS64-oblivious 862 host, the DNS64 looks just like an ordinary DNS server. Operators of 863 a NAT64 should expect traffic to pass through the NAT64 even when it 864 is not necessary. 866 6.3.3. Intentional dual-stack DNS64 use 868 Finally, consider the case where the IPv4 connectivity on i2 is only 869 with a LAN, and not with the IPv4 Internet. The IPv4 Internet is 870 only accessible using the NAT64. In this case, it is critical that 871 the DNS64 not synthesize AAAA responses for hosts in the LAN, or else 872 that the DNS64 be aware of hosts in the LAN and provide context- 873 sensitive answers ("split view" DNS answers) for hosts inside the 874 LAN. As with any split view DNS arrangement, operators must be 875 prepared for data to leak from one context to another, and for 876 failures to occur because nodes accessible from one context are not 877 accessible from the other. 879 +---------------+ +-------------+ 880 | i1 (IPv6)+----NAT64--------+IPv4 Internet| 881 | | +-------------+ 882 | host | 883 | | 884 | i2 (IPv4)+---(local LAN only) 885 +---------------+ 887 Figure 3: Intentional dual-stack DNS64 use 889 It is important for deployers of DNS64 to realise that, in some 890 circumstances, making the DNS64 available to a dual-stack host will 891 cause the host to prefer to send packets via NAT64 instead of via 892 native IPv4, with the associated loss of performance or functionality 893 (or both) entailed by the NAT. At the same time, some hosts are not 894 able to learn about DNS servers provisioned on IPv6 addresses, or 895 simply cannot send DNS packets over IPv6. 897 7. Deployment scenarios and examples 899 In this section, we walk through some sample scenarios that are 900 expected to be common deployment cases. It should be noted that this 901 is provided for illustrative purposes and this section is not 902 normative. The normative definition of DNS64 is provided in 903 Section 5 and the normative definition of the address transformation 904 algorithm is provided in [I-D.ietf-behave-address-format]. 906 In this section we illustrate how the DNS64 behaves in different 907 scenarios that are expected to be common. In particular we will 908 consider the following scenarios defined in 909 [I-D.ietf-behave-v6v4-framework]: the an-IPv6-network-to-IPv4- 910 Internet scenario (both with DNS64 in DNS server mode and in stub- 911 resolver mode) and the IPv6-Internet-to-an-IPv4-network setup (with 912 DNS64 in DNS server mode only). 914 In all the examples below, there is a IPv6/IPv4 translator connecting 915 the IPv6 domain to the IPv4 one. Also there is a name server that is 916 a dual-stack node, so it can communicate with IPv6 hosts using IPv6 917 and with IPv4 nodes using IPv4. In addition, we assume that in the 918 examples, the DNS64 function learns which IPv6 prefix it needs to use 919 to map the IPv4 address space through manual configuration. 921 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in 922 DNS server mode 924 In this example, we consider an IPv6 node located in an IPv6-only 925 site that initiates a communication to an IPv4 node located in the 926 IPv4 Internet. 928 The scenario for this case is depicted in the following figure: 930 +---------------------+ +---------------+ 931 |IPv6 network | | IPv4 | 932 | | +-------------+ | Internet | 933 | |--| Name server |--| | 934 | | | with DNS64 | | +----+ | 935 | +----+ | +-------------+ | | H2 | | 936 | | H1 |---| | | +----+ | 937 | +----+ | +------------+ | 192.0.2.1 | 938 | |---| IPv6/IPv4 |--| | 939 | | | Translator | | | 940 | | +------------+ | | 941 | | | | | 942 +---------------------+ +---------------+ 944 Figure 4: An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS 945 server mode 947 The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 948 address 192.0.2.1 and FQDN h2.example.com 950 The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to 951 its IPv4 interface and it is using the WKP 64:FF9B::/96 to create 952 IPv6 representations of IPv4 addresses. The same prefix is 953 configured in the DNS64 function in the local name server. 955 For this example, assume the typical DNS situation where IPv6 hosts 956 have only stub resolvers, and they are configured with the IP address 957 of a name server that they always have to query and that performs 958 recursive lookups (henceforth called "the recursive nameserver"). 960 The steps by which H1 establishes communication with H2 are: 962 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending 963 a DNS query for a AAAA record for H2 to the recursive name 964 server. The recursive name server implements DNS64 965 functionality. 967 2. The recursive name server resolves the query, and discovers that 968 there are no AAAA records for H2. 970 3. The recursive name server performs an A-record query for H2 and 971 gets back an RRset containing a single A record with the IPv4 972 address 192.0.2.1. The name server then synthesizes a AAAA 973 record. The IPv6 address in the AAAA record contains the prefix 974 assigned to the IPv6/IPv4 Translator in the upper 96 bits and the 975 received IPv4 address in the lower 32 bits i.e. the resulting 976 IPv6 address is 64:FF9B::192.0.2.1 978 4. H1 receives the synthetic AAAA record and sends a packet towards 979 H2. The packet is sent to the destination address 64:FF9B:: 980 192.0.2.1. 982 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 983 translator and the subsequent communication flows by means of the 984 IPv6/IPv4 translator mechanisms. 986 7.2. An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in 987 stub-resolver mode 989 This case is depicted in the following figure: 991 +---------------------+ +---------------+ 992 |IPv6 network | | IPv4 | 993 | | +--------+ | Internet | 994 | |-----| Name |----| | 995 | +-----+ | | server | | +----+ | 996 | | H1 | | +--------+ | | H2 | | 997 | |with |---| | | +----+ | 998 | |DNS64| | +------------+ | 192.0.2.1 | 999 | +----+ |---| IPv6/IPv4 |--| | 1000 | | | Translator | | | 1001 | | +------------+ | | 1002 | | | | | 1003 +---------------------+ +---------------+ 1005 Figure 5: An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- 1006 resolver mode 1008 The figure shows an IPv6 node H1 implementing the DNS64 function and 1009 an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com 1011 The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to 1012 its IPv4 interface and it is using the WKP 64:FF9B::/96 to create 1013 IPv6 representations of IPv4 addresses. The same prefix is 1014 configured in the DNS64 function in H1. 1016 For this example, assume the typical DNS situation where IPv6 hosts 1017 have only stub resolvers, and they are configured with the IP address 1018 of a name server that they always have to query and that performs 1019 recursive lookups (henceforth called "the recursive nameserver"). 1020 The recursive name server does not perform the DNS64 function. 1022 The steps by which H1 establishes communication with H2 are: 1024 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending 1025 a DNS query for a AAAA record for H2 to the recursive name 1026 server. 1028 2. The recursive DNS server resolves the query, and returns the 1029 answer to H1. Because there are no AAAA records in the global 1030 DNS for H2, the answer is empty. 1032 3. The stub resolver at H1 then queries for an A record for H2 and 1033 gets back an A record containing the IPv4 address 192.0.2.1. The 1034 DNS64 function within H1 then synthesizes a AAAA record. The 1035 IPv6 address in the AAAA record contains the prefix assigned to 1036 the IPv6/IPv4 translator in the upper 96 bits, then the received 1037 IPv4 address i.e. the resulting IPv6 address is 64:FF9B:: 1038 192.0.2.1. 1040 4. H1 sends a packet towards H2. The packet is sent to the 1041 destination address 64:FF9B::192.0.2.1. 1043 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 1044 translator and the subsequent communication flows using the IPv6/ 1045 IPv4 translator mechanisms. 1047 7.3. Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS 1048 server mode 1050 In this example, we consider an IPv6 node located in the IPv6 1051 Internet that initiates a communication to an IPv4 node located in 1052 the IPv4 site. 1054 In some cases, this scenario can be addressed without using any form 1055 of DNS64 function. This is so because it is possible to assign a 1056 fixed IPv6 address to each of the IPv4 nodes. Such an IPv6 address 1057 would be constructed using the address transformation algorithm 1058 defined in [I-D.ietf-behave-address-format] that takes as input the 1059 Pref64::/96 and the IPv4 address of the IPv4 node. Note that the 1060 IPv4 address can be a public or a private address; the latter does 1061 not present any additional difficulty, since an NSP must be used as 1062 Pref64::/96 (in this scenario the usage of the Well-Known prefix is 1063 not supported as discussed in [I-D.ietf-behave-address-format]). 1064 Once these IPv6 addresses have been assigned to represent the IPv4 1065 nodes in the IPv6 Internet, real AAAA RRs containing these addresses 1066 can be published in the DNS under the site's domain. This is the 1067 recommended approach to handle this scenario, because it does not 1068 involve synthesizing AAAA records at the time of query. 1070 However, there are some more dynamic scenarios, where synthesizing 1071 AAAA RRs in this setup may be needed. In particular, when DNS Update 1072 [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 1073 nodes, there are two options: One option is to modify the DNS server 1074 that receives the dynamic DNS updates. That would normally be the 1075 authoritative server for the zone. So the authoritative zone would 1076 have normal AAAA RRs that are synthesized as dynamic updates occur. 1077 The other option is modify all the authoritative servers to generate 1078 synthetic AAAA records for a zone, possibly based on additional 1079 constraints, upon the receipt of a DNS query for the AAAA RR. The 1080 first option -- in which the AAAA is synthesized when the DNS update 1081 message is received, and the data published in the relevant zone -- 1082 is recommended over the second option (i.e. the synthesis upon 1083 receipt of the AAAA DNS query). This is because it is usually easier 1084 to solve problems of misconfiguration when the DNS responses are not 1085 being generated dynamically. However, it may be the case where the 1086 primary server (that receives all the updates) cannot be upgraded for 1087 whatever reason, but where a secondary can be upgraded in order to 1088 handle the (comparatively small amount) of AAAA queries. In such 1089 case, it is possible to use the DNS64 as described next. The DNS64 1090 behavior that we describe in this section covers the case of 1091 synthesizing the AAAA RR when the DNS query arrives. 1093 The scenario for this case is depicted in the following figure: 1095 +-----------+ +----------------------+ 1096 | | | IPv4 site | 1097 | IPv6 | +------------+ | +----+ | 1098 | Internet |----| IPv6/IPv4 |--|---| H2 | | 1099 | | | Translator | | +----+ | 1100 | | +------------+ | | 1101 | | | | 192.0.2.1 | 1102 | | +------------+ | | 1103 | |----| Name server|--| | 1104 | | | with DNS64 | | | 1105 +-----------+ +------------+ | | 1106 | | | | 1107 +----+ | | 1108 | H1 | +----------------------+ 1109 +----+ 1111 Figure 6: IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server 1112 mode 1114 The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 1115 address 192.0.2.1 and FQDN h2.example.com. 1117 The IPv6/IPv4 Translator is using a NSP 2001:DB8::/96 to create IPv6 1118 representations of IPv4 addresses. The same prefix is configured in 1119 the DNS64 function in the local name server. The name server that 1120 implements the DNS64 function is the authoritative name server for 1121 the local domain. 1123 The steps by which H1 establishes communication with H2 are: 1125 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending 1126 a DNS query for a AAAA record for H2. The query is eventually 1127 forwarded to the server in the IPv4 site. 1129 2. The local DNS server resolves the query (locally), and discovers 1130 that there are no AAAA records for H2. 1132 3. The name server verifies that h2.example.com and its A RR are 1133 among those that the local policy defines as allowed to generate 1134 a AAAA RR from. If that is the case, the name server synthesizes 1135 a AAAA record from the A RR and the prefix 2001:DB8::/96. The 1136 IPv6 address in the AAAA record is 2001:DB8::192.0.2.1. 1138 4. H1 receives the synthetic AAAA record and sends a packet towards 1139 H2. The packet is sent to the destination address 2001:DB8:: 1140 192.0.2.1. 1142 5. The packet is routed through the IPv6 Internet to the IPv6 1143 interface of the IPv6/IPv4 translator and the communication flows 1144 using the IPv6/IPv4 translator mechanisms. 1146 8. Security Considerations 1148 DNS64 operates in combination with the DNS, and is therefore subject 1149 to whatever security considerations are appropriate to the DNS mode 1150 in which the DNS64 is operating (i.e. authoritative, recursive, or 1151 stub resolver mode). 1153 DNS64 has the potential to interfere with the functioning of DNSSEC, 1154 because DNS64 modifies DNS answers, and DNSSEC is designed to detect 1155 such modification and to treat modified answers as bogus. See the 1156 discussion above in Section 3, Section 5.5, and Section 6.2. 1158 9. IANA Considerations 1160 This memo makes no request of IANA. 1162 10. Contributors 1164 Dave Thaler 1166 Microsoft 1168 dthaler@windows.microsoft.com 1170 11. Acknowledgements 1172 This draft contains the result of discussions involving many people, 1173 including the participants of the IETF BEHAVE Working Group. The 1174 following IETF participants made specific contributions to parts of 1175 the text, and their help is gratefully acknowledged: Jaap Akkerhuis, 1176 Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, 1177 Doug Barton, Marc Blanchet, Cameron Byrne, Brian Carpenter, Zhen Cao, 1178 Hui Deng, Francis Dupont, Patrik Faltstrom, David Harrington, Ed 1179 Jankiewicz, Peter Koch, Suresh Krishnan, Martti Kuparinen, Ed Lewis, 1180 Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata, Simon 1181 Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark Townsley, 1182 Rick van Rein, Stig Venaas, Magnus Westerlund, Jeff Westhead, Florian 1183 Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui. 1185 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 1186 Trilogy, a research project supported by the European Commission 1187 under its Seventh Framework Program. 1189 12. References 1191 12.1. Normative References 1193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1194 Requirement Levels", BCP 14, RFC 2119, March 1997. 1196 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1197 STD 13, RFC 1034, November 1987. 1199 [RFC1035] Mockapetris, P., "Domain names - implementation and 1200 specification", STD 13, RFC 1035, November 1987. 1202 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1203 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1204 RFC 4787, January 2007. 1206 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1207 RFC 2671, August 1999. 1209 [I-D.ietf-behave-address-format] 1210 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1211 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1212 draft-ietf-behave-address-format-08 (work in progress), 1213 May 2010. 1215 12.2. Informative References 1217 [I-D.ietf-behave-v6v4-xlate-stateful] 1218 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1219 NAT64: Network Address and Protocol Translation from IPv6 1220 Clients to IPv4 Servers", 1221 draft-ietf-behave-v6v4-xlate-stateful-11 (work in 1222 progress), March 2010. 1224 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1225 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1226 RFC 2136, April 1997. 1228 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1229 NCACHE)", RFC 2308, March 1998. 1231 [RFC3484] Draves, R., "Default Address Selection for Internet 1232 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1234 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1235 "DNS Extensions to Support IP Version 6", RFC 3596, 1236 October 2003. 1238 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1239 Rose, "DNS Security Introduction and Requirements", 1240 RFC 4033, March 2005. 1242 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1243 Rose, "Resource Records for the DNS Security Extensions", 1244 RFC 4034, March 2005. 1246 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1247 Rose, "Protocol Modifications for the DNS Security 1248 Extensions", RFC 4035, March 2005. 1250 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 1251 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 1253 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 1254 BCP 153, RFC 5735, January 2010. 1256 [I-D.ietf-behave-v6v4-framework] 1257 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1258 IPv4/IPv6 Translation", 1259 draft-ietf-behave-v6v4-framework-09 (work in progress), 1260 May 2010. 1262 [I-D.ietf-dnsop-default-local-zones] 1263 Andrews, M., "Locally-served DNS Zones", 1264 draft-ietf-dnsop-default-local-zones-13 (work in 1265 progress), April 2010. 1267 Appendix A. Motivations and Implications of synthesizing AAAA Resource 1268 Records when real AAAA Resource Records exist 1270 The motivation for synthesizing AAAA RRs when real AAAA RRs exist is 1271 to support the following scenario: 1273 An IPv4-only server application (e.g. web server software) is 1274 running on a dual-stack host. There may also be dual-stack server 1275 applications running on the same host. That host has fully 1276 routable IPv4 and IPv6 addresses and hence the authoritative DNS 1277 server has an A and a AAAA record. 1279 An IPv6-only client (regardless of whether the client application 1280 is IPv6-only, the client stack is IPv6-only, or it only has an 1281 IPv6 address) wants to access the above server. 1283 The client issues a DNS query to a DNS64 resolver. 1285 If the DNS64 only generates a synthetic AAAA if there's no real AAAA, 1286 then the communication will fail. Even though there's a real AAAA, 1287 the only way for communication to succeed is with the translated 1288 address. So, in order to support this scenario, the administrator of 1289 a DNS64 service may want to enable the synthesis of AAAA RRs even 1290 when real AAAA RRs exist. 1292 The implication of including synthetic AAAA RRs when real AAAA RRs 1293 exist is that translated connectivity may be preferred over native 1294 connectivity in some cases where the DNS64 is operated in DNS server 1295 mode. 1297 RFC3484 [RFC3484] rules use longest prefix match to select the 1298 preferred destination address to use. So, if the DNS64 resolver 1299 returns both the synthetic AAAA RRs and the real AAAA RRs, then if 1300 the DNS64 is operated by the same domain as the initiating host, and 1301 a global unicast prefix (called an NSP in 1302 [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR 1303 is likely to be preferred. 1305 This means that without further configuration: 1307 In the "An IPv6 network to the IPv4 Internet" scenario, the host 1308 will prefer translated connectivity if an NSP is used. If the 1309 Well-Known Prefix defined in [I-D.ietf-behave-address-format] is 1310 used, it will probably prefer native connectivity. 1312 In the "IPv6 Internet to an IPv4 network" scenario, it is possible 1313 to bias the selection towards the real AAAA RR if the DNS64 1314 resolver returns the real AAAA first in the DNS reply, when an NSP 1315 is used (the Well-Known Prefix usage is not supported in this 1316 case) 1318 In the "An IPv6 network to IPv4 network" scenario, for local 1319 destinations (i.e., target hosts inside the local site), it is 1320 likely that the NSP and the destination prefix are the same, so we 1321 can use the order of RR in the DNS reply to bias the selection 1322 through native connectivity. If the Well-Known Prefix is used, 1323 the longest prefix match rule will select native connectivity. 1325 The problem can be solved by properly configuring the RFC3484 1326 [RFC3484] policy table. 1328 Authors' Addresses 1330 Marcelo Bagnulo 1331 UC3M 1332 Av. Universidad 30 1333 Leganes, Madrid 28911 1334 Spain 1336 Phone: +34-91-6249500 1337 Fax: 1338 Email: marcelo@it.uc3m.es 1339 URI: http://www.it.uc3m.es/marcelo 1341 Andrew Sullivan 1342 Shinkuro 1343 4922 Fairmont Avenue, Suite 250 1344 Bethesda, MD 20814 1345 USA 1347 Phone: +1 301 961 3131 1348 Email: ajs@shinkuro.com 1350 Philip Matthews 1351 Unaffiliated 1352 600 March Road 1353 Ottawa, Ontario 1354 Canada 1356 Phone: +1 613-592-4343 x224 1357 Fax: 1358 Email: philip_matthews@magma.ca 1359 URI: 1361 Iljitsch van Beijnum 1362 IMDEA Networks 1363 Av. Universidad 30 1364 Leganes, Madrid 28911 1365 Spain 1367 Phone: +34-91-6246245 1368 Email: iljitsch@muada.com