idnits 2.17.1 draft-ietf-behave-dns64-11.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 (October 1, 2010) is 4955 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) -- 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 (-15) exists of draft-ietf-dnsop-default-local-zones-14 Summary: 1 error (**), 0 flaws (~~), 3 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: April 4, 2011 Shinkuro 6 P. Matthews 7 Alcatel-Lucent 8 I. van Beijnum 9 IMDEA Networks 10 October 1, 2010 12 DNS64: DNS extensions for Network Address Translation from IPv6 Clients 13 to IPv4 Servers 14 draft-ietf-behave-dns64-11 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 April 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 11 65 5.1. Resolving AAAA queries and the answer section . . . . . . 11 66 5.1.1. The answer when there is AAAA data available . . . . . 12 67 5.1.2. The answer when there is an error . . . . . . . . . . 12 68 5.1.3. Dealing with timeouts . . . . . . . . . . . . . . . . 12 69 5.1.4. Special exclusion set for AAAA records . . . . . . . . 13 70 5.1.5. Dealing with CNAME and DNAME . . . . . . . . . . . . . 13 71 5.1.6. Data for the answer when performing synthesis . . . . 13 72 5.1.7. Performing the synthesis . . . . . . . . . . . . . . . 14 73 5.1.8. Querying in parallel . . . . . . . . . . . . . . . . . 14 74 5.2. Generation of the IPv6 representations of IPv4 75 addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 5.3. Handling other Resource Records and the Additional 77 Section . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 5.3.1. PTR Resource Record . . . . . . . . . . . . . . . . . 16 79 5.3.2. Handling the additional section . . . . . . . . . . . 17 80 5.3.3. Other Resource Records . . . . . . . . . . . . . . . . 17 81 5.4. Assembling a synthesized response to a AAAA query . . . . 18 82 5.5. DNSSEC processing: DNS64 in validating resolver mode . . . 18 83 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 19 84 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 19 85 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 20 86 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 20 87 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 20 88 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 21 89 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 21 90 7. Deployment scenarios and examples . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . 24 95 7.3. Example of IPv6-Internet-to-an-IPv4-network setup 96 DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 103 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 104 Appendix A. Motivations and Implications of synthesizing AAAA 105 Resource Records when real AAAA Resource Records 106 exist . . . . . . . . . . . . . . . . . . . . . . . . 30 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 features 139 require performing the DNS64 function directly in the end-hosts 140 themselves. 142 This document is structured as follows: section 2 provides a non- 143 normative overview of the behaviour of DNS64. Section 3 provides a 144 non-normative background required to understand the interaction 145 between DNS64 and DNSSEC. The normative specification of DNS64 is 146 provided in sections 4, 5 and 6. Section 4 defines the terminology, 147 section 5 is the actual DNS64 specification and section 6 covers 148 deployments issues. Section 7 is non-normative and provides a set of 149 examples and typical deployment scenarios. 151 2. Overview 153 This section provides an introduction to the DNS64 mechanism. 155 We assume that we have one or more IPv6/IPv4 translator boxes 156 connecting an IPv4 network and an IPv6 network. The IPv6/IPv4 157 translator device provides translation services between the two 158 networks enabling communication between IPv4-only hosts and IPv6-only 159 hosts. (NOTE: By IPv6-only hosts we mean hosts running IPv6-only 160 applications, hosts that can only use IPv6, as well as cases where 161 only IPv6 connectivity is available to the client. By IPv4-only 162 servers we mean servers running IPv4-only applications, servers that 163 can only use IPv4, as well as cases where only IPv4 connectivity is 164 available to the server). Each IPv6/IPv4 translator used in 165 conjunction with DNS64 must allow communications initiated from the 166 IPv6-only host to the IPv4-only host. 168 To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to 169 learn the address of the responder, DNS64 is used to synthesize a 170 AAAA record from an A record containing a real IPv4 address of the 171 responder, whenever the DNS64 cannot retrieve a AAAA record for the 172 queried name. The DNS64 service appears as a regular DNS server or 173 resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query 174 generated by the IPv6 initiator. It first attempts a resolution for 175 the requested AAAA records. If there are no AAAA records available 176 for the target node (which is the normal case when the target node is 177 an IPv4-only node), DNS64 performs a query for A records. For each A 178 record discovered, DNS64 creates a synthetic AAAA RR from the 179 information retrieved in the A RR. 181 The owner name of a synthetic AAAA RR is the same as that of the 182 original A RR, but an IPv6 representation of the IPv4 address 183 contained in the original A RR is included in the AAAA RR. The IPv6 184 representation of the IPv4 address is algorithmically generated from 185 the IPv4 address and additional parameters configured in the DNS64. 186 Among those parameters configured in the DNS64, there is at least one 187 IPv6 prefix. If not explicitly mentioned, all prefixes are treated 188 equally and the operations described in this document are performed 189 using the prefixes available. So as to be general, we will call any 190 of these prefixes Pref64::/n, and describe the operations made with 191 the generic prefix Pref64::/n. The IPv6 address representing IPv4 192 addresses included in the AAAA RR synthesized by the DNS64 contain 193 Pref64::/n and they also embed the original IPv4 address. 195 The same algorithm and the same Pref64::/n prefix(es) must be 196 configured both in the DNS64 device and the IPv6/IPv4 translator(s), 197 so that both can algorithmically generate the same IPv6 198 representation for a given IPv4 address. In addition, it is required 199 that IPv6 packets addressed to an IPv6 destination address that 200 contains the Pref64::/n be delivered to an IPv6/IPv4 translator that 201 has that particular Pref64::/n configured, so they can be translated 202 into IPv4 packets. 204 Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs 205 are passed back to the IPv6 initiator, which will initiate an IPv6 206 communication with the IPv6 address associated with the IPv4 207 receiver. The packet will be routed to an IPv6/IPv4 translator which 208 will forward it to the IPv4 network. 210 In general, the only shared state between the DNS64 and the IPv6/IPv4 211 translator is the Pref64::/n and an optional set of static 212 parameters. The Pref64::/n and the set of static parameters must be 213 configured to be the same on both; there is no communication between 214 the DNS64 device and IPv6/IPv4 translator functions. The mechanism 215 to be used for configuring the parameters of the DNS64 is beyond the 216 scope of this memo. 218 The prefixes to be used as Pref64::/n and their applicability are 219 discussed in [I-D.ietf-behave-address-format]. There are two types 220 of prefixes that can be used as Pref64::/n. 222 The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved 223 by [I-D.ietf-behave-address-format] for the purpose of 224 representing IPv4 addresses in IPv6 address space. 226 The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is 227 an IPv6 prefix assigned by an organization to create IPv6 228 representations of IPv4 addresses. 230 The main difference in the nature of the two types of prefixes is 231 that the NSP is a locally assigned prefix that is under control of 232 the organization that is providing the translation services, while 233 the Well-Known Prefix is a prefix that has a global meaning since it 234 has been assigned for the specific purpose of representing IPv4 235 addresses in IPv6 address space. 237 The DNS64 function can be performed in any of three places. The 238 terms below are more formally defined in Section 4. 240 The first option is to locate the DNS64 function in authoritative 241 servers for a zone. In this case, the authoritative server provides 242 synthetic AAAA RRs for an IPv4-only host in its zone. This is one 243 type of DNS64 server. 245 Another option is to locate the DNS64 function in recursive name 246 servers serving end hosts. In this case, when an IPv6-only host 247 queries the name server for AAAA RRs for an IPv4-only host, the name 248 server can perform the synthesis of AAAA RRs and pass them back to 249 the IPv6-only initiator. The main advantage of this mode is that 250 current IPv6 nodes can use this mechanism without requiring any 251 modification. This mode is called "DNS64 in DNS recursive resolver 252 mode". This is a second type of DNS64 server, and it is also one 253 type of DNS64 resolver. 255 The last option is to place the DNS64 function in the end hosts, 256 coupled to the local (stub) resolver. In this case, the stub 257 resolver will try to obtain (real) AAAA RRs and in case they are not 258 available, the DNS64 function will synthesize AAAA RRs for internal 259 usage. This mode is compatible with some functions like DNSSEC 260 validation in the end host. The main drawback of this mode is its 261 deployability, since it requires changes in the end hosts. This mode 262 is called "DNS64 in stub-resolver mode". This is the second type of 263 DNS64 resolver. 265 3. Background to DNS64-DNSSEC interaction 267 DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge 268 for DNS64, because DNSSEC is designed to detect changes to DNS 269 answers, and DNS64 may alter answers coming from an authoritative 270 server. 272 A recursive resolver can be security-aware or security-oblivious. 273 Moreover, a security-aware recursive resolver can be validating or 274 non-validating, according to operator policy. In the cases below, 275 the recursive resolver is also performing DNS64, and has a local 276 policy to validate. We call this general case vDNS64, but in all the 277 cases below the DNS64 functionality should be assumed needed. 279 DNSSEC includes some signaling bits that offer some indicators of 280 what the query originator understands. 282 If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit 283 set, the query originator is signaling that it understands DNSSEC. 284 The DO bit does not indicate that the query originator will validate 285 the response. It only means that the query originator can understand 286 responses containing DNSSEC data. Conversely, if the DO bit is 287 clear, that is evidence that the querying agent is not aware of 288 DNSSEC. 290 If a query arrives at a vDNS64 device with the "Checking Disabled" 291 (CD) bit set, it is an indication that the querying agent wants all 292 the validation data so it can do checking itself. By local policy, 293 vDNS64 could still validate, but it must return all data to the 294 querying agent anyway. 296 Here are the possible cases: 298 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with 299 the DO bit clear. In this case, DNSSEC is not a concern, because 300 the querying agent does not understand DNSSEC responses. The 301 DNS64 can do validation of the response, if dictated by its local 302 policy. 304 2. A security-oblivious DNS64 receives a query with the DO bit set, 305 and the CD bit clear or set. This is just like the case of a 306 non-DNS64 case: the server doesn't support it, so the querying 307 agent is out of luck. 309 3. A security-aware and non-validating DNS64 receives a query with 310 the DO bit set and the CD bit clear. Such a resolver is not 311 validating responses, likely due to local policy (see [RFC4035], 312 section 4.2). For that reason, this case amounts to the same as 313 the previous case, and no validation happens. 315 4. A security-aware and non-validating DNS64 receives a query with 316 the DO bit set and the CD bit set. In this case, the DNS64 is 317 supposed to pass on all the data it gets to the query initiator 318 (see section 3.2.2 of [RFC4035]). This case will not work with 319 DNS64, unless the validating resolver is prepared to do DNS64 320 itself. If the DNS64 modifies the record, the client will get 321 the data back and try to validate it, and the data will be 322 invalid as far as the client is concerned. 324 5. A security-aware and validating DNS64 resolver receives a query 325 with the DO bit clear and CD clear. In this case, the resolver 326 validates the data. If it fails, it returns RCODE 2 (Server 327 failure); otherwise, it returns the answer. This is the ideal 328 case for vDNS64. The resolver validates the data, and then 329 synthesizes the new record and passes that to the client. The 330 client, which is presumably not validating (else it should have 331 set DO and CD), cannot tell that DNS64 is involved. 333 6. A security-aware and validating DNS64 resolver receives a query 334 with the DO bit set and CD clear. This works like the previous 335 case, except that the resolver should also set the "Authentic 336 Data" (AD) bit on the response. 338 7. A security-aware and validating DNS64 resolver receives a query 339 with the DO bit set and CD set. This is effectively the same as 340 the case where a security-aware and non-validating recursive 341 resolver receives a similar query, and the same thing will 342 happen: the downstream validator will mark the data as invalid if 343 DNS64 has performed synthesis. The node needs to do DNS64 344 itself, or else communication will fail. 346 4. Terminology 348 This section provides definitions for the special terms used in the 349 document. 351 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 352 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 353 document are to be interpreted as described in RFC 2119 [RFC2119]. 355 Authoritative server: A DNS server that can answer authoritatively a 356 given DNS request. 358 DNS64: A logical function that synthesizes DNS resource records (e.g 359 AAAA records containing IPv6 addresses) from DNS resource records 360 actually contained in the DNS (e.g., A records containing IPv4 361 addresses). 363 DNS64 recursive resolver: A recursive resolver that provides the 364 DNS64 functionality as part of its operation. This is the same 365 thing as "DNS64 in recursive resolver mode". 367 DNS64 resolver: Any resolver (stub resolver or recursive resolver) 368 that provides the DNS64 function. 370 DNS64 server: Any server providing the DNS64 function. This 371 includes the server portion of a recursive resolver when it is 372 providing the DNS64 function. 374 IPv4-only server: Servers running IPv4-only applications, servers 375 that can only use IPv4, as well as cases where only IPv4 376 connectivity is available to the server. 378 IPv6-only hosts: Hosts running IPv6-only applications, hosts that 379 can only use IPv6, as well as cases where only IPv6 connectivity 380 is available to the client. 382 Recursive resolver: A DNS server that accepts requests from one 383 resolver, and asks another server (of some description) for the 384 answer on behalf of the first resolver. Full discussion of DNS 385 recursion is beyond the scope of this document; see [RFC1034] and 386 [RFC1035] for full details. 388 Synthetic RR: A DNS resource record (RR) that is not contained in 389 the authoritative servers' zone data, but which is instead 390 synthesized from other RRs in the same zone. An example is a 391 synthetic AAAA record created from an A record. 393 IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 394 packets and vice-versa. It is only required that the 395 communication initiated from the IPv6 side be supported. 397 For a detailed understanding of this document, the reader should also 398 be familiar with DNS terminology from [RFC1034], [RFC1035] and 399 current NAT terminology from [RFC4787]. Some parts of this document 400 assume familiarity with the terminology of the DNS security 401 extensions outlined in [RFC4035]. It is worth emphasizing that while 402 DNS64 is a logical function separate from the DNS, it is nevertheless 403 closely associated with that protocol. It depends on the DNS 404 protocol, and some behavior of DNS64 will interact with regular DNS 405 responses. 407 5. DNS64 Normative Specification 409 DNS64 is a logical function that synthesizes AAAA records from A 410 records. The DNS64 function may be implemented in a stub resolver, 411 in a recursive resolver, or in an authoritative name server. It 412 works within those DNS functions, and appears on the network as 413 though it were a "plain" DNS resolver or name server conforming to 414 [RFC1034], and [RFC1035]. 416 The implementation SHOULD support mapping of separate IPv4 address 417 ranges to separate IPv6 prefixes for AAAA record synthesis. This 418 allows handling of special use IPv4 addresses [RFC5735]. 420 DNS messages contain several sections. The portion of a DNS message 421 that is altered by DNS64 is the Answer section, which is discussed 422 below in section Section 5.1. The resulting synthetic answer is put 423 together with other sections, and that creates the message that is 424 actually returned as the response to the DNS query. Assembling that 425 response is covered below in section Section 5.4. 427 DNS64 also responds to PTR queries involving addresses containing any 428 of the IPv6 prefixes it uses for synthesis of AAAA RRs. 430 5.1. Resolving AAAA queries and the answer section 432 When the DNS64 receives a query for RRs of type AAAA and class IN, it 433 first attempts to retrieve non-synthetic RRs of this type and class, 434 either by performing a query or, in the case of an authoritative 435 server, by examining its own results. The query may be answered from 436 a local cache, if one is available. DNS64 operation for classes 437 other than IN is undefined, and a DNS64 MUST behave as though no 438 DNS64 function is configured. 440 5.1.1. The answer when there is AAAA data available 442 If the query results in one or more AAAA records in the answer 443 section, the result is returned to the requesting client as per 444 normal DNS semantics, except in the case where any of the AAAA 445 records match a special exclusion set of prefixes, considered in 446 Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64 447 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A 448 for an analysis of the motivations for and the implications of not 449 complying with this recommendation). By default DNS64 450 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs 451 exist. 453 5.1.2. The answer when there is an error 455 If the query results in a response with RCODE other than 0 (No error 456 condition), then there are two possibilities. A result with RCODE=3 457 (Name Error) is handled according to normal DNS operation (which is 458 normally to return the error to the client). This stage is still 459 prior to any synthesis having happened, so a response to be returned 460 to the client does not need any special assembly than would usually 461 happen in DNS operation. 463 Any other RCODE is treated as though the RCODE were 0 (see sections 464 Section 5.1.6 and Section 5.1.7) and the answer section were empty. 465 This is because of the large number of different responses from 466 deployed name servers when they receive AAAA queries without a AAAA 467 record being available (see [RFC4074]). Note that this means, for 468 practical purposes, that several different classes of error in the 469 DNS are all treated as though a AAAA record is not available for that 470 owner name. 472 It is important to note that, as of this writing, some servers 473 respond with RCODE=3 to a AAAA query even if there is an A record 474 available for that owner name. Those servers are in clear violation 475 of the meaning of RCODE 3, and it is expected that they will decline 476 in use as IPv6 deployment increases. 478 5.1.3. Dealing with timeouts 480 If the query receives no answer before the timeout (which might be 481 the timeout from every authoritative server, depending on whether the 482 DNS64 is in recursive resolver mode), it is treated as RCODE=2 483 (Server failure). 485 5.1.4. Special exclusion set for AAAA records 487 Some IPv6 addresses are not actually usable by IPv6-only hosts. If 488 they are returned to IPv6-only querying agents as AAAA records, 489 therefore, the goal of decreasing the number of failure modes will 490 not be attained. Examples include AAAA records with addresses in the 491 ::ffff:0:0/96 network, and possibly (depending on the context) AAAA 492 records with the site's Pref::64/n or the Well-Known Prefix (see 493 below for more about the Well-Known Prefix). A DNS64 implementation 494 SHOULD provide a mechanism to specify IPv6 prefix ranges to be 495 treated as though the AAAA containing them were an empty answer. An 496 implementation SHOULD include the ::ffff/96 network in that range by 497 default. Failure to provide this facility will mean that clients 498 querying the DNS64 function may not be able to communicate with hosts 499 that would be reachable from a dual-stack host. 501 When the DNS64 performs its initial AAAA query, if it receives an 502 answer with only AAAA records containing addresses in the excluded 503 range(s), then it MUST treat the answer as though it were an empty 504 answer, and proceed accordingly. If it receives an answer with at 505 least one AAAA record containing an address outside any of the 506 excluded range(s), then it MAY build an answer section for a response 507 including only the AAAA record(s) that do not contain any of the 508 addresses inside the excluded ranges. That answer section is used in 509 the assembly of a response as detailed in Section 5.4. 510 Alternatively, it MAY treat the answer as though it were an empty 511 answer, and proceed accordingly. It MUST NOT return the offending 512 AAAA records as part of a response. 514 5.1.5. Dealing with CNAME and DNAME 516 If the response contains a CNAME or a DNAME, then the CNAME or DNAME 517 chain is followed until the first terminating A or AAAA record is 518 reached. This may require the DNS64 to ask for an A record, in case 519 the response to the original AAAA query is a CNAME or DNAME without a 520 AAAA record to follow. The resulting AAAA or A record is treated 521 like any other AAAA or A case, as appropriate. 523 When assembling the answer section, any chains of CNAME or DNAME RRs 524 are included as part of the answer along with the synthetic AAAA (if 525 appropriate). 527 5.1.6. Data for the answer when performing synthesis 529 If the query results in no error but an empty answer section in the 530 response, the DNS64 attempts to retrieve A records for the name in 531 question, either by performing another query or, in the case of an 532 authoritative server, by examining its own results. If this new A RR 533 query results in an empty answer or in an error, then the empty 534 result or error is used as the basis for the answer returned to the 535 querying client. If instead the query results in one or more A RRs, 536 the DNS64 synthesizes AAAA RRs based on the A RRs according to the 537 procedure outlined in Section 5.1.7. The DNS64 returns the 538 synthesized AAAA records in the answer section, removing the A 539 records that form the basis of the synthesis. 541 5.1.7. Performing the synthesis 543 A synthetic AAAA record is created from an A record as follows: 545 o The NAME field is set to the NAME field from the A record. 547 o The TYPE field is set to 28 (AAAA). 549 o The CLASS field is set to the original CLASS field, 1. Under this 550 specification, DNS64 for any CLASS other than 1 is undefined. 552 o The TTL field is set to the minimum of the TTL of the original A 553 RR and the SOA RR for the queried domain. (Note that in order to 554 obtain the TTL of the SOA RR, the DNS64 does not need to perform a 555 new query, but it can remember the TTL from the SOA RR in the 556 negative response to the AAAA query. If the SOA RR was not 557 delivered with the negative response to the AAAA query, then the 558 DNS64 SHOULD use a the minimum of the TTL of the original A RR and 559 600 seconds. It is possible instead to query explicitly for the 560 SOA RR and use the result of that query, but this will increase 561 query load and time to resolution for little additional benefit.) 562 This is in keeping with the approach used in negative caching 563 ([RFC2308]. 565 o The RDLENGTH field is set to 16. 567 o The RDATA field is set to the IPv6 representation of the IPv4 568 address from the RDATA field of the A record. The DNS64 MUST 569 check each A RR against configured IPv4 address ranges and select 570 the corresponding IPv6 prefix to use in synthesizing the AAAA RR. 571 See Section 5.2 for discussion of the algorithms to be used in 572 effecting the transformation. 574 5.1.8. Querying in parallel 576 The DNS64 MAY perform the query for the AAAA RR and for the A RR in 577 parallel, in order to minimize the delay. 579 Note: Querying in parallel will result in performing unnecessary A RR 580 queries in the case where no AAAA RR synthesis is required. A 581 possible trade-off would be to perform them sequentially but with a 582 very short interval between them, so if we obtain a fast reply, we 583 avoid doing the additional query. (Note that this discussion is 584 relevant only if the DNS64 function needs to perform external queries 585 t fetch the RR. If the needed RR information is available locally, 586 as in the case of an authoritative server, the issue is no longer 587 relevant.) 589 5.2. Generation of the IPv6 representations of IPv4 addresses 591 DNS64 supports multiple algorithms for the generation of the IPv6 592 representation of an IPv4 address. The constraints imposed on the 593 generation algorithms are the following: 595 The same algorithm to create an IPv6 address from an IPv4 address 596 MUST be used by both a DNS64 to create the IPv6 address to be 597 returned in the synthetic AAAA RR from the IPv4 address contained 598 in an original A RR, and by a IPv6/IPv4 translator to create the 599 IPv6 address to be included in the source address field of the 600 outgoing IPv6 packets from the IPv4 address included in the source 601 address field of the incoming IPv4 packet. 603 The algorithm MUST be reversible; i.e., it MUST be possible to 604 derive the original IPv4 address from the IPv6 representation. 606 The input for the algorithm MUST be limited to the IPv4 address, 607 the IPv6 prefix (denoted Pref64::/n) used in the IPv6 608 representations and optionally a set of stable parameters that are 609 configured in the DNS64 and in the NAT64 (such as fixed string to 610 be used as a suffix). 612 For each prefix Pref64::/n, n MUST be less than or equal to 96. 613 If one or more Pref64::/n are configured in the DNS64 through 614 any means (such as manually configured, or other automatic 615 means not specified in this document), the default algorithm 616 MUST use these prefixes (and not use the Well-Known Prefix). 617 If no prefix is available, the algorithm MUST use the Well- 618 Known Prefix 64:FF9B::/96 defined in 619 [I-D.ietf-behave-address-format] to represent the IPv4 unicast 620 address range 622 [[anchor6: Note in document: The value 64:FF9B::/96 is proposed as 623 the value for the Well-Known prefix and needs to be confirmed 624 whenis published as RFC.]][I-D.ietf-behave-address-format] 626 A DNS64 MUST support the algorithm for generating IPv6 627 representations of IPv4 addresses defined in Section 2 of 628 [I-D.ietf-behave-address-format]. Moreover, the aforementioned 629 algorithm MUST be the default algorithm used by the DNS64. While the 630 normative description of the algorithm is provided in 631 [I-D.ietf-behave-address-format], a sample description of the 632 algorithm and its application to different scenarios is provided in 633 Section 7 for illustration purposes. 635 5.3. Handling other Resource Records and the Additional Section 637 5.3.1. PTR Resource Record 639 If a DNS64 server receives a PTR query for a record in the IP6.ARPA 640 domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the 641 address portion of the QNAME according to the encoding scheme 642 outlined in section 2.5 of [RFC3596], and examine the resulting 643 address to see whether its prefix matches any of the locally- 644 configured Pref64::/n or the default Well-known prefix. There are 645 two alternatives for a DNS64 server to respond to such PTR queries. 646 A DNS64 server MUST provide one of these, and SHOULD NOT provide both 647 at the same time unless different IP6.ARPA zones require answers of 648 different sorts: 650 1. The first option is for the DNS64 server to respond 651 authoritatively for its prefixes. If the address prefix matches 652 any Pref64::/n used in the site, either a NSP or the Well-Known 653 Prefix (i.e. 64:FF9B::/96), then the DNS64 server MAY answer the 654 query using locally-appropriate RDATA. The DNS64 server MAY use 655 the same RDATA for all answers. Note that the requirement is to 656 match any Pref64::/n used at the site, and not merely the 657 locally-configured Pref64::/n. This is because end clients could 658 ask for a PTR record matching an address received through a 659 different (site-provided) DNS64, and if this strategy is in 660 effect, those queries should never be sent to the global DNS. 661 The advantage of this strategy is that it makes plain to the 662 querying client that the prefix is one operated by the (DNS64) 663 site, and that the answers the client is getting are generated by 664 DNS64. The disadvantage is that any useful reverse-tree 665 information that might be in the global DNS is unavailable to the 666 clients querying the DNS64. 668 2. The second option is for the DNS64 nameserver to synthesize a 669 CNAME mapping the IP6.ARPA namespace to the corresponding IN- 670 ADDR.ARPA name. In this case, the DNS64 nameserver SHOULD ensure 671 that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA 672 name, and that there is not an existing CNAME at that name. This 673 is in order to avoid synthesizing a CNAME that makes a CNAME 674 chain longer or that does not actually point to anything. The 675 rest of the response would be the normal DNS processing. The 676 CNAME can be signed on the fly if need be. The advantage of this 677 approach is that any useful information in the reverse tree is 678 available to the querying client. The disadvantage is that it 679 adds additional load to the DNS64 (because CNAMEs have to be 680 synthesized for each PTR query that matches the Pref64::/n), and 681 that it may require signing on the fly. 683 If the address prefix does not match any Pref64::/n, then the DNS64 684 server MUST process the query as though it were any other query; i.e. 685 a recursive nameserver MUST attempt to resolve the query as though it 686 were any other (non-A/AAAA) query, and an authoritative server MUST 687 respond authoritatively or with a referral, as appropriate. 689 5.3.2. Handling the additional section 691 DNS64 synthesis MUST NOT be performed on any records in the 692 additional section of synthesized answers. The DNS64 MUST pass the 693 additional section unchanged. 695 NOTE: It may appear that adding synthetic records to the 696 additional section is desirable, because clients sometimes use the 697 data in the additional section to proceed without having to re- 698 query. There is in general no promise, however, that the 699 additional section will contain all the relevant records, so any 700 client that depends on the additional section being able to 701 satisfy its needs (i.e. without additional queries) is necessarily 702 broken. An IPv6-only client that needs a AAAA record, therefore, 703 will send a query for the necessary AAAA record if it is unable to 704 find such a record in the additional section of an answer it is 705 consuming. For a correctly-functioning client, the effect would 706 be no different if the additional section were empty.The 707 alternative, of removing the A records in the additional section 708 and replacing them with synthetic AAAA records, may cause a host 709 behind a NAT64 to query directly a nameserver that is unaware of 710 the NAT64 in question. The result in this case will be resolution 711 failure anyway, only later in the resolution operation. The 712 prohibition on synthetic data in the additional section reduces, 713 but does not eliminate, the possibility of resolution failures due 714 to cached DNS data from behind the DNS64. See Section 6. 716 5.3.3. Other Resource Records 718 If the DNS64 is in recursive resolver mode, then considerations 719 outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant. 721 All other RRs MUST be returned unchanged. This includes responses to 722 queries for A RRs. 724 5.4. Assembling a synthesized response to a AAAA query 726 A DNS64 uses different pieces of data to build the response returned 727 to the querying client. 729 The query that is used as the basis for synthesis results either in 730 an error, an answer that can be used as a basis for synthesis, or an 731 empty (authoritative) answer. If there is an empty answer, then the 732 DNS64 responds to the original querying client with the answer the 733 DNS64 received to the original (initiator's) query. Otherwise, the 734 response is assembled as follows. 736 The header fields are set according to the usual rules for recursive 737 or authoritative servers, depending on the role that the DNS64 is 738 serving. The question section is copied from the original 739 (initiator's) query. The answer section is populated according to 740 the rules in Section 5.1.7. The authority and additional sections 741 are copied from the response to the final query that the DNS64 742 performed, and used as the basis for synthesis. 744 The final response from the DNS64 is subject to all the standard DNS 745 rules, including truncation [RFC1035] and EDNS0 handling [RFC2671]. 747 5.5. DNSSEC processing: DNS64 in validating resolver mode 749 We consider the case where a recursive resolver that is performing 750 DNS64 also has a local policy to validate the answers according to 751 the procedures outlined in [RFC4035] Section 5. We call this general 752 case vDNS64. 754 The vDNS64 uses the presence of the DO and CD bits to make some 755 decisions about what the query originator needs, and can react 756 accordingly: 758 1. If CD is not set and DO is not set, vDNS64 SHOULD perform 759 validation and do synthesis as needed. See the next item for 760 rules about how to do validation and synthesis. In this case, 761 however, vDNS64 MUST NOT set the AD bit in any response. 763 2. If CD is not set and DO is set, then vDNS64 SHOULD perform 764 validation. Whenever vDNS64 performs validation, it MUST 765 validate the negative answer for AAAA queries before proceeding 766 to query for A records for the same name, in order to be sure 767 that there is not a legitimate AAAA record on the Internet. 768 Failing to observe this step would allow an attacker to use DNS64 769 as a mechanism to circumvent DNSSEC. If the negative response 770 validates, and the response to the A query validates, then the 771 vDNS64 MAY perform synthesis and SHOULD set the AD bit in the 772 answer to the client. This is acceptable, because [RFC4035], 773 section 3.2.3 says that the AD bit is set by the name server side 774 of a security-aware recursive name server if and only if it 775 considers all the RRSets in the Answer and Authority sections to 776 be authentic. In this case, the name server has reason to 777 believe the RRSets are all authentic, so it SHOULD set the AD 778 bit. If the data does not validate, the vDNS64 MUST respond with 779 RCODE=2 (Server failure). 780 A security-aware end point might take the presence of the AD bit 781 as an indication that the data is valid, and may pass the DNS 782 (and DNSSEC) data to an application. If the application attempts 783 to validate the synthesized data, of course, the validation will 784 fail. One could argue therefore that this approach is not 785 desirable, but security aware stub resolvers must not place any 786 reliance on data received from resolvers and validated on their 787 behalf without certain criteria established by [RFC4035], section 788 4.9.3. An application that wants to perform validation on its 789 own should use the CD bit. 791 3. If the CD bit is set and DO is set, then vDNS64 MAY perform 792 validation, but MUST NOT perform synthesis. It MUST return the 793 data to the query initiator, just like a regular recursive 794 resolver, and depend on the client to do the validation and the 795 synthesis itself. 796 The disadvantage to this approach is that an end point that is 797 translation-oblivious but security-aware and validating will not 798 be able to use the DNS64 functionality. In this case, the end 799 point will not have the desired benefit of NAT64. In effect, 800 this strategy means that any end point that wishes to do 801 validation in a NAT64 context must be upgraded to be translation- 802 aware as well. 804 6. Deployment notes 806 While DNS64 is intended to be part of a strategy for aiding IPv6 807 deployment in an internetworking environment with some IPv4-only and 808 IPv6-only networks, it is important to realise that it is 809 incompatible with some things that may be deployed in an IPv4-only or 810 dual-stack context. 812 6.1. DNS resolvers and DNS64 814 Full-service resolvers that are unaware of the DNS64 function can be 815 (mis)configured to act as mixed-mode iterative and forwarding 816 resolvers. In a native IPv4 context, this sort of configuration may 817 appear to work. It is impossible to make it work properly without it 818 being aware of the DNS64 function, because it will likely at some 819 point obtain IPv4-only glue records and attempt to use them for 820 resolution. The result that is returned will contain only A records, 821 and without the ability to perform the DNS64 function the resolver 822 will be unable to answer the necessary AAAA queries. 824 6.2. DNSSEC validators and DNS64 826 An existing DNSSEC validator (i.e. that is unaware of DNS64) might 827 reject all the data that comes from DNS64 as having been tampered 828 with (even if it did not set CD when querying). If it is necessary 829 to have validation behind the DNS64, then the validator must know how 830 to perform the DNS64 function itself. Alternatively, the validating 831 host may establish a trusted connection with a DNS64, and allow the 832 DNS64 recursive resolver to do all validation on its behalf. 834 6.3. DNS64 and multihomed and dual-stack hosts 836 6.3.1. IPv6 multihomed hosts 838 Synthetic AAAA records may be constructed on the basis of the network 839 context in which they were constructed. If a host sends DNS queries 840 to resolvers in multiple networks, it is possible that some of them 841 will receive answers from a DNS64 without all of them being connected 842 via a NAT64. For instance, suppose a system has two interfaces, i1 843 and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2 844 has native IPv6 connectivity only. I1 might receive a AAAA answer 845 from a DNS64 that is configured for a particular NAT64; the IPv6 846 address contained in that AAAA answer will not connect with anything 847 via i2. 849 +---------------+ +-------------+ 850 | i1 (IPv6)+----NAT64--------+IPv4 Internet| 851 | | +-------------+ 852 | host | 853 | | +-------------+ 854 | i2 (IPv6)+-----------------+IPv6 Internet| 855 +---------------+ +-------------+ 857 Figure 1: IPv6 multihomed hosts 859 This example illustrates why it is generally preferable that hosts 860 treat DNS answers from one interface as local to that interface. The 861 answer received on one interface will not work on the other 862 interface. Hosts that attempt to use DNS answers globally may 863 encounter surprising failures in these cases. 865 Note that the issue is not that there are two interfaces, but that 866 there are two networks involved. The same results could be achieved 867 with a single interface routed to two different networks. 869 6.3.2. Accidental dual-stack DNS64 use 871 Similarly, suppose that i1 has IPv6 connectivity and can connect to 872 the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity. 873 In this case, i1 could receive an IPv6 address from a synthetic AAAA 874 that would better be reached via native IPv4. Again, it is worth 875 emphasising that this arises because there are two networks involved. 877 +---------------+ +-------------+ 878 | i1 (IPv6)+----NAT64--------+IPv4 Internet| 879 | | +-------------+ 880 | host | 881 | | +-------------+ 882 | i2 (IPv4)+-----------------+IPv4 Internet| 883 +---------------+ +-------------+ 885 Figure 2: Accidental dual-stack DNS64 use 887 The default configuration of dual-stack hosts is that IPv6 is 888 preferred over IPv4 ([RFC3484]). In that arrangement the host will 889 often use the NAT64 when native IPv4 would be more desirable. For 890 this reason, hosts with IPv4 connectivity to the Internet should 891 avoid using DNS64. This can be partly resolved by ISPs when 892 providing DNS resolvers to clients, but that is not a guarantee that 893 the NAT64 will never be used when a native IPv4 connection should be 894 used. There is no general-purpose mechanism to ensure that native 895 IPv4 transit will always be preferred, because to a DNS64-oblivious 896 host, the DNS64 looks just like an ordinary DNS server. Operators of 897 a NAT64 should expect traffic to pass through the NAT64 even when it 898 is not necessary. 900 6.3.3. Intentional dual-stack DNS64 use 902 Finally, consider the case where the IPv4 connectivity on i2 is only 903 with a LAN, and not with the IPv4 Internet. The IPv4 Internet is 904 only accessible using the NAT64. In this case, it is critical that 905 the DNS64 not synthesize AAAA responses for hosts in the LAN, or else 906 that the DNS64 be aware of hosts in the LAN and provide context- 907 sensitive answers ("split view" DNS answers) for hosts inside the 908 LAN. As with any split view DNS arrangement, operators must be 909 prepared for data to leak from one context to another, and for 910 failures to occur because nodes accessible from one context are not 911 accessible from the other. 913 +---------------+ +-------------+ 914 | i1 (IPv6)+----NAT64--------+IPv4 Internet| 915 | | +-------------+ 916 | host | 917 | | 918 | i2 (IPv4)+---(local LAN only) 919 +---------------+ 921 Figure 3: Intentional dual-stack DNS64 use 923 It is important for deployers of DNS64 to realise that, in some 924 circumstances, making the DNS64 available to a dual-stack host will 925 cause the host to prefer to send packets via NAT64 instead of via 926 native IPv4, with the associated loss of performance or functionality 927 (or both) entailed by the NAT. At the same time, some hosts are not 928 able to learn about DNS servers provisioned on IPv6 addresses, or 929 simply cannot send DNS packets over IPv6. 931 7. Deployment scenarios and examples 933 In this section we illustrate how the DNS64 behaves in different 934 scenarios that are expected to be common. In particular we will 935 consider the following scenarios defined in 936 [I-D.ietf-behave-v6v4-framework]: the an-IPv6-network-to-IPv4- 937 Internet scenario (both with DNS64 in DNS server mode and in stub- 938 resolver mode) and the IPv6-Internet-to-an-IPv4-network setup (with 939 DNS64 in DNS server mode only). 941 In all the examples below, there is a IPv6/IPv4 translator connecting 942 the IPv6 domain to the IPv4 one. Also there is a name server that is 943 a dual-stack node, so it can communicate with IPv6 hosts using IPv6 944 and with IPv4 nodes using IPv4. In addition, we assume that in the 945 examples, the DNS64 function learns which IPv6 prefix it needs to use 946 to map the IPv4 address space through manual configuration. 948 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in 949 DNS server mode 951 In this example, we consider an IPv6 node located in an IPv6-only 952 site that initiates a communication to an IPv4 node located in the 953 IPv4 Internet. 955 The scenario for this case is depicted in the following figure: 957 +---------------------+ +---------------+ 958 |IPv6 network | | IPv4 | 959 | | +-------------+ | Internet | 960 | |--| Name server |--| | 961 | | | with DNS64 | | +----+ | 962 | +----+ | +-------------+ | | H2 | | 963 | | H1 |---| | | +----+ | 964 | +----+ | +------------+ | 192.0.2.1 | 965 | |---| IPv6/IPv4 |--| | 966 | | | Translator | | | 967 | | +------------+ | | 968 | | | | | 969 +---------------------+ +---------------+ 971 Figure 4: An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS 972 server mode 974 The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 975 address 192.0.2.1 and FQDN h2.example.com. 977 The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to 978 its IPv4 interface and it is using the WKP 64:FF9B::/96 to create 979 IPv6 representations of IPv4 addresses. The same prefix is 980 configured in the DNS64 function in the local name server. 982 For this example, assume the typical DNS situation where IPv6 hosts 983 have only stub resolvers, and they are configured with the IP address 984 of a name server that they always have to query and that performs 985 recursive lookups (henceforth called "the recursive nameserver"). 987 The steps by which H1 establishes communication with H2 are: 989 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending 990 a DNS query for a AAAA record for H2 to the recursive name 991 server. The recursive name server implements DNS64 992 functionality. 994 2. The recursive name server resolves the query, and discovers that 995 there are no AAAA records for H2. 997 3. The recursive name server performs an A-record query for H2 and 998 gets back an RRset containing a single A record with the IPv4 999 address 192.0.2.1. The name server then synthesizes a AAAA 1000 record. The IPv6 address in the AAAA record contains the prefix 1001 assigned to the IPv6/IPv4 Translator in the upper 96 bits and the 1002 received IPv4 address in the lower 32 bits i.e. the resulting 1003 IPv6 address is 64:FF9B::192.0.2.1. 1005 4. H1 receives the synthetic AAAA record and sends a packet towards 1006 H2. The packet is sent to the destination address 64:FF9B:: 1007 192.0.2.1. 1009 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 1010 translator and the subsequent communication flows by means of the 1011 IPv6/IPv4 translator mechanisms. 1013 7.2. An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in 1014 stub-resolver mode 1016 This case is depicted in the following figure: 1018 +---------------------+ +---------------+ 1019 |IPv6 network | | IPv4 | 1020 | | +--------+ | Internet | 1021 | |-----| Name |----| | 1022 | +-----+ | | server | | +----+ | 1023 | | H1 | | +--------+ | | H2 | | 1024 | |with |---| | | +----+ | 1025 | |DNS64| | +------------+ | 192.0.2.1 | 1026 | +----+ |---| IPv6/IPv4 |--| | 1027 | | | Translator | | | 1028 | | +------------+ | | 1029 | | | | | 1030 +---------------------+ +---------------+ 1032 Figure 5: An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- 1033 resolver mode 1035 The figure shows an IPv6 node H1 implementing the DNS64 function and 1036 an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com. 1038 The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to 1039 its IPv4 interface and it is using the WKP 64:FF9B::/96 to create 1040 IPv6 representations of IPv4 addresses. The same prefix is 1041 configured in the DNS64 function in H1. 1043 For this example, assume the typical DNS situation where IPv6 hosts 1044 have only stub resolvers, and they are configured with the IP address 1045 of a name server that they always have to query and that performs 1046 recursive lookups (henceforth called "the recursive nameserver"). 1047 The recursive name server does not perform the DNS64 function. 1049 The steps by which H1 establishes communication with H2 are: 1051 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending 1052 a DNS query for a AAAA record for H2 to the recursive name 1053 server. 1055 2. The recursive DNS server resolves the query, and returns the 1056 answer to H1. Because there are no AAAA records in the global 1057 DNS for H2, the answer is empty. 1059 3. The stub resolver at H1 then queries for an A record for H2 and 1060 gets back an A record containing the IPv4 address 192.0.2.1. The 1061 DNS64 function within H1 then synthesizes a AAAA record. The 1062 IPv6 address in the AAAA record contains the prefix assigned to 1063 the IPv6/IPv4 translator in the upper 96 bits, then the received 1064 IPv4 address i.e. the resulting IPv6 address is 64:FF9B:: 1065 192.0.2.1. 1067 4. H1 sends a packet towards H2. The packet is sent to the 1068 destination address 64:FF9B::192.0.2.1. 1070 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 1071 translator and the subsequent communication flows using the IPv6/ 1072 IPv4 translator mechanisms. 1074 7.3. Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS 1075 server mode 1077 In this example, we consider an IPv6 node located in the IPv6 1078 Internet that initiates a communication to an IPv4 node located in 1079 the IPv4 site. 1081 In some cases, this scenario can be addressed without using any form 1082 of DNS64 function. This is so because it is possible to assign a 1083 fixed IPv6 address to each of the IPv4 nodes. Such an IPv6 address 1084 would be constructed using the address transformation algorithm 1085 defined in [I-D.ietf-behave-address-format] that takes as input the 1086 Pref64::/96 and the IPv4 address of the IPv4 node. Note that the 1087 IPv4 address can be a public or a private address; the latter does 1088 not present any additional difficulty, since an NSP must be used as 1089 Pref64::/96 (in this scenario the usage of the Well-Known prefix is 1090 not supported as discussed in [I-D.ietf-behave-address-format]). 1091 Once these IPv6 addresses have been assigned to represent the IPv4 1092 nodes in the IPv6 Internet, real AAAA RRs containing these addresses 1093 can be published in the DNS under the site's domain. This is the 1094 recommended approach to handle this scenario, because it does not 1095 involve synthesizing AAAA records at the time of query. 1097 However, there are some more dynamic scenarios, where synthesizing 1098 AAAA RRs in this setup may be needed. In particular, when DNS Update 1100 [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 1101 nodes, there are two options: One option is to modify the DNS server 1102 that receives the dynamic DNS updates. That would normally be the 1103 authoritative server for the zone. So the authoritative zone would 1104 have normal AAAA RRs that are synthesized as dynamic updates occur. 1105 The other option is modify all the authoritative servers to generate 1106 synthetic AAAA records for a zone, possibly based on additional 1107 constraints, upon the receipt of a DNS query for the AAAA RR. The 1108 first option -- in which the AAAA is synthesized when the DNS update 1109 message is received, and the data published in the relevant zone -- 1110 is recommended over the second option (i.e. the synthesis upon 1111 receipt of the AAAA DNS query). This is because it is usually easier 1112 to solve problems of misconfiguration when the DNS responses are not 1113 being generated dynamically. However, it may be the case where the 1114 primary server (that receives all the updates) cannot be upgraded for 1115 whatever reason, but where a secondary can be upgraded in order to 1116 handle the (comparatively small amount) of AAAA queries. In such 1117 case, it is possible to use the DNS64 as described next. The DNS64 1118 behavior that we describe in this section covers the case of 1119 synthesizing the AAAA RR when the DNS query arrives. 1121 The scenario for this case is depicted in the following figure: 1123 +-----------+ +----------------------+ 1124 | | | IPv4 site | 1125 | IPv6 | +------------+ | +----+ | 1126 | Internet |----| IPv6/IPv4 |--|---| H2 | | 1127 | | | Translator | | +----+ | 1128 | | +------------+ | | 1129 | | | | 192.0.2.1 | 1130 | | +------------+ | | 1131 | |----| Name server|--| | 1132 | | | with DNS64 | | | 1133 +-----------+ +------------+ | | 1134 | | | | 1135 +----+ | | 1136 | H1 | +----------------------+ 1137 +----+ 1139 Figure 6: IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server 1140 mode 1142 The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 1143 address 192.0.2.1 and FQDN h2.example.com. 1145 The IPv6/IPv4 Translator is using a NSP 2001:DB8::/96 to create IPv6 1146 representations of IPv4 addresses. The same prefix is configured in 1147 the DNS64 function in the local name server. The name server that 1148 implements the DNS64 function is the authoritative name server for 1149 the local domain. 1151 The steps by which H1 establishes communication with H2 are: 1153 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending 1154 a DNS query for a AAAA record for H2. The query is eventually 1155 forwarded to the server in the IPv4 site. 1157 2. The local DNS server resolves the query (locally), and discovers 1158 that there are no AAAA records for H2. 1160 3. The name server verifies that h2.example.com and its A RR are 1161 among those that the local policy defines as allowed to generate 1162 a AAAA RR from. If that is the case, the name server synthesizes 1163 a AAAA record from the A RR and the prefix 2001:DB8::/96. The 1164 IPv6 address in the AAAA record is 2001:DB8::192.0.2.1. 1166 4. H1 receives the synthetic AAAA record and sends a packet towards 1167 H2. The packet is sent to the destination address 2001:DB8:: 1168 192.0.2.1. 1170 5. The packet is routed through the IPv6 Internet to the IPv6 1171 interface of the IPv6/IPv4 translator and the communication flows 1172 using the IPv6/IPv4 translator mechanisms. 1174 8. Security Considerations 1176 DNS64 operates in combination with the DNS, and is therefore subject 1177 to whatever security considerations are appropriate to the DNS mode 1178 in which the DNS64 is operating (i.e. authoritative, recursive, or 1179 stub resolver mode). 1181 DNS64 has the potential to interfere with the functioning of DNSSEC, 1182 because DNS64 modifies DNS answers, and DNSSEC is designed to detect 1183 such modification and to treat modified answers as bogus. See the 1184 discussion above in Section 3, Section 5.5, and Section 6.2. 1186 Additionally, for the correct functioning of the translation 1187 services, the DNS64 and the NAT64 need to use the same Pref64. If an 1188 attacker manages to change the Pref64 used by the DNS64, the traffic 1189 generated by the host that receives the synthetic reply will be 1190 delivered to the altered Pref64. This can result in either a DoS 1191 attack (if resulting IPv6 addresses are not assigned to any device) 1192 or in a flooding attack (if the resulting IPv6 addresses are assigned 1193 to devices that do not wish to receive the traffic) or in 1194 eavesdropping attack (in case the Pref64 is routed through the 1195 attacker). 1197 9. IANA Considerations 1199 This memo makes no request of IANA. 1201 10. Contributors 1203 Dave Thaler 1205 Microsoft 1207 dthaler@windows.microsoft.com 1209 11. Acknowledgements 1211 This draft contains the result of discussions involving many people, 1212 including the participants of the IETF BEHAVE Working Group. The 1213 following IETF participants made specific contributions to parts of 1214 the text, and their help is gratefully acknowledged: Jaap Akkerhuis, 1215 Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, 1216 Doug Barton, Marc Blanchet, Cameron Byrne, Brian Carpenter, Zhen Cao, 1217 Hui Deng, Francis Dupont, Patrik Faltstrom, David Harrington, Ed 1218 Jankiewicz, Peter Koch, Suresh Krishnan, Martti Kuparinen, Ed Lewis, 1219 Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata, Simon 1220 Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark Townsley, 1221 Rick van Rein, Stig Venaas, Magnus Westerlund, Jeff Westhead, Florian 1222 Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui. 1224 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 1225 Trilogy, a research project supported by the European Commission 1226 under its Seventh Framework Program. 1228 12. References 1230 12.1. Normative References 1232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1233 Requirement Levels", BCP 14, RFC 2119, March 1997. 1235 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1236 STD 13, RFC 1034, November 1987. 1238 [RFC1035] Mockapetris, P., "Domain names - implementation and 1239 specification", STD 13, RFC 1035, November 1987. 1241 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1242 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1243 RFC 4787, January 2007. 1245 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1246 RFC 2671, August 1999. 1248 [I-D.ietf-behave-address-format] 1249 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1250 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1251 draft-ietf-behave-address-format-10 (work in progress), 1252 August 2010. 1254 12.2. Informative References 1256 [I-D.ietf-behave-v6v4-xlate-stateful] 1257 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1258 NAT64: Network Address and Protocol Translation from IPv6 1259 Clients to IPv4 Servers", 1260 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 1261 progress), July 2010. 1263 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1264 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1265 RFC 2136, April 1997. 1267 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1268 NCACHE)", RFC 2308, March 1998. 1270 [RFC3484] Draves, R., "Default Address Selection for Internet 1271 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1273 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1274 "DNS Extensions to Support IP Version 6", RFC 3596, 1275 October 2003. 1277 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1278 Rose, "DNS Security Introduction and Requirements", 1279 RFC 4033, March 2005. 1281 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1282 Rose, "Resource Records for the DNS Security Extensions", 1283 RFC 4034, March 2005. 1285 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1287 Rose, "Protocol Modifications for the DNS Security 1288 Extensions", RFC 4035, March 2005. 1290 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 1291 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 1293 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 1294 BCP 153, RFC 5735, January 2010. 1296 [I-D.ietf-behave-v6v4-framework] 1297 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1298 IPv4/IPv6 Translation", 1299 draft-ietf-behave-v6v4-framework-10 (work in progress), 1300 August 2010. 1302 [I-D.ietf-dnsop-default-local-zones] 1303 Andrews, M., "Locally-served DNS Zones", 1304 draft-ietf-dnsop-default-local-zones-14 (work in 1305 progress), September 2010. 1307 Appendix A. Motivations and Implications of synthesizing AAAA Resource 1308 Records when real AAAA Resource Records exist 1310 The motivation for synthesizing AAAA RRs when real AAAA RRs exist is 1311 to support the following scenario: 1313 An IPv4-only server application (e.g. web server software) is 1314 running on a dual-stack host. There may also be dual-stack server 1315 applications running on the same host. That host has fully 1316 routable IPv4 and IPv6 addresses and hence the authoritative DNS 1317 server has an A and a AAAA record. 1319 An IPv6-only client (regardless of whether the client application 1320 is IPv6-only, the client stack is IPv6-only, or it only has an 1321 IPv6 address) wants to access the above server. 1323 The client issues a DNS query to a DNS64 resolver. 1325 If the DNS64 only generates a synthetic AAAA if there's no real AAAA, 1326 then the communication will fail. Even though there's a real AAAA, 1327 the only way for communication to succeed is with the translated 1328 address. So, in order to support this scenario, the administrator of 1329 a DNS64 service may want to enable the synthesis of AAAA RRs even 1330 when real AAAA RRs exist. 1332 The implication of including synthetic AAAA RRs when real AAAA RRs 1333 exist is that translated connectivity may be preferred over native 1334 connectivity in some cases where the DNS64 is operated in DNS server 1335 mode. 1337 RFC3484 [RFC3484] rules use longest prefix match to select the 1338 preferred destination address to use. So, if the DNS64 resolver 1339 returns both the synthetic AAAA RRs and the real AAAA RRs, then if 1340 the DNS64 is operated by the same domain as the initiating host, and 1341 a global unicast prefix (called an NSP in 1342 [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR 1343 is likely to be preferred. 1345 This means that without further configuration: 1347 In the "An IPv6 network to the IPv4 Internet" scenario, the host 1348 will prefer translated connectivity if an NSP is used. If the 1349 Well-Known Prefix defined in [I-D.ietf-behave-address-format] is 1350 used, it will probably prefer native connectivity. 1352 In the "IPv6 Internet to an IPv4 network" scenario, it is possible 1353 to bias the selection towards the real AAAA RR if the DNS64 1354 resolver returns the real AAAA first in the DNS reply, when an NSP 1355 is used (the Well-Known Prefix usage is not supported in this 1356 case) 1358 In the "An IPv6 network to IPv4 network" scenario, for local 1359 destinations (i.e., target hosts inside the local site), it is 1360 likely that the NSP and the destination prefix are the same, so we 1361 can use the order of RR in the DNS reply to bias the selection 1362 through native connectivity. If the Well-Known Prefix is used, 1363 the longest prefix match rule will select native connectivity. 1365 The problem can be solved by properly configuring the RFC3484 1366 [RFC3484] policy table. 1368 Authors' Addresses 1370 Marcelo Bagnulo 1371 UC3M 1372 Av. Universidad 30 1373 Leganes, Madrid 28911 1374 Spain 1376 Phone: +34-91-6249500 1377 Fax: 1378 Email: marcelo@it.uc3m.es 1379 URI: http://www.it.uc3m.es/marcelo 1380 Andrew Sullivan 1381 Shinkuro 1382 4922 Fairmont Avenue, Suite 250 1383 Bethesda, MD 20814 1384 USA 1386 Phone: +1 301 961 3131 1387 Email: ajs@shinkuro.com 1389 Philip Matthews 1390 Unaffiliated 1391 600 March Road 1392 Ottawa, Ontario 1393 Canada 1395 Phone: +1 613-592-4343 x224 1396 Fax: 1397 Email: philip_matthews@magma.ca 1398 URI: 1400 Iljitsch van Beijnum 1401 IMDEA Networks 1402 Av. Universidad 30 1403 Leganes, Madrid 28911 1404 Spain 1406 Phone: +34-91-6246245 1407 Email: iljitsch@muada.com