idnits 2.17.1 draft-ietf-behave-dns64-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 3 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 (December 16, 2009) is 5246 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2671' is defined on line 816, but no explicit reference was found in the text == Unused Reference: 'RFC2672' is defined on line 819, but no explicit reference was found in the text == Unused Reference: 'RFC2765' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'RFC2766' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'RFC1858' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'RFC3128' is defined on line 855, but no explicit reference was found in the text == Unused Reference: 'RFC3022' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-ice' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-addr-select-sol' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'RFC3498' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'I-D.wing-behave-learn-prefix' is defined on line 907, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-02 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-05 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-03) exists of draft-ietf-6man-addr-select-sol-02 == Outdated reference: A later version (-02) exists of draft-venaas-behave-mcast46-01 == Outdated reference: A later version (-15) exists of draft-ietf-dnsop-default-local-zones-09 == Outdated reference: A later version (-06) exists of draft-savolainen-mif-dns-server-selection-01 Summary: 5 errors (**), 0 flaws (~~), 22 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: June 19, 2010 Shinkuro 6 P. Matthews 7 Alcatel-Lucent 8 I. van Beijnum 9 IMDEA Networks 10 December 16, 2009 12 DNS64: DNS extensions for Network Address Translation from IPv6 Clients 13 to IPv4 Servers 14 draft-ietf-behave-dns64-04 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 to IETF 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), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 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 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on June 19, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Background to DNS64 - DNSSEC interaction . . . . . . . . . . . 6 69 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9 71 5.1. Resolving AAAA queries and the answer section . . . . . . 9 72 5.1.1. The answer when there is AAAA data available . . . . . 9 73 5.1.2. The answer when there is an error . . . . . . . . . . 9 74 5.1.3. Special exclusion set for AAAA records . . . . . . . . 10 75 5.1.4. Dealing with CNAME and DNAME . . . . . . . . . . . . . 10 76 5.1.5. Data for the answer when performing synthesis . . . . 11 77 5.1.6. Performing the synthesis . . . . . . . . . . . . . . . 11 78 5.1.7. Querying in parallel . . . . . . . . . . . . . . . . . 11 79 5.2. Generation of the IPv6 representations of IPv4 80 addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 5.3. Handling other RRs and the Additional Section . . . . . . 13 82 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 13 83 5.3.2. Handling the additional section . . . . . . . . . . . 14 84 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 14 85 5.4. Assembling a synthesized response to a AAAA query . . . . 14 86 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 14 87 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16 88 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 16 89 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 16 90 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 16 91 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 16 92 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 17 93 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 17 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 100 Appendix A. Deployment scenarios and examples . . . . . . . . . . 21 101 A.1. Example of IPv6/IPv4 address transformation algorithm . . 22 102 A.2. Example of An-IPv6-network-to-IPv4-Internet setup with 103 DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 23 104 A.3. An example of an-IPv6-network-to-IPv4-Internet setup 105 with DNS64 in stub-resolver mode . . . . . . . . . . . . . 24 106 A.4. Example of IPv6-Internet-to-an-IPv4-network setup 107 DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 26 108 Appendix B. Motivations and Implications of synthesizing AAAA 109 RR when real AAAA RR exists . . . . . . . . . . . . . 28 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 112 1. Introduction 114 This document specifies DNS64, a mechanism that is part of the 115 toolbox for IPv6-IPv4 transition and co-existence. DNS64, used 116 together with an IPv6/IPv4 translator such as NAT64 117 [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to 118 initiate communications by name to an IPv4-only server. 120 DNS64 is a mechanism for synthesizing AAAA resource records (RRs) 121 from A RRs. A synthetic AAAA RR created by the DNS64 from an 122 original A RR contains the same FQDN of the original A RR but it 123 contains an IPv6 address instead of an IPv4 address. The IPv6 124 address is an IPv6 representation of the IPv4 address contained in 125 the original A RR. The IPv6 representation of the IPv4 address is 126 algorithmically generated from the IPv4 address returned in the A RR 127 and a set of parameters configured in the DNS64 (typically, an IPv6 128 prefix used by IPv6 representations of IPv4 addresses and optionally 129 other parameters). 131 Together with a IPv6/IPv4 translator, these two mechanisms allow an 132 IPv6-only client to initiate communications to an IPv4-only server 133 using the FQDN of the server. 135 These mechanisms are expected to play a critical role in the IPv4- 136 IPv6 transition and co-existence. Due to IPv4 address depletion, it 137 is likely that in the future, many IPv6-only clients will want to 138 connect to IPv4-only servers. In the typical case, the approach only 139 requires the deployment of IPv6/IPv4 translators that connect an 140 IPv6-only network to an IPv4-only network, along with the deployment 141 of one or more DNS64-enabled name servers. However, some advanced 142 features require performing the DNS64 function directly by the end- 143 hosts themselves. 145 2. Overview 147 This section provides a non-normative introduction to the DNS64 148 mechanism. 150 We assume that we have an IPv6/IPv4 translator box connecting an IPv4 151 network and an IPv6 network. The IPv6/IPv4 translator device 152 provides translation services between the two networks enabling 153 communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By 154 IPv6-only hosts we mean hosts running IPv6-only applications, hosts 155 that can only use IPv6, as well as the cases where only IPv6 156 connectivity is available to the client. By IPv4-only servers we 157 mean servers running IPv4-only applications, servers that can only 158 use IPv4, as well as the cases where only IPv4 connectivity is 159 available to the server). The IPv6/IPv4 translator used in 160 conjunction with DNS64 must allow communications initiated from the 161 IPv6-only host to the IPv4-only host. 163 To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to 164 learn the address of the responder, DNS64 is used to synthesize a 165 AAAA record from an A record containing a real IPv4 address of the 166 responder, whenever the DNS64 service cannot retrieve a AAAA record 167 for the requested host name. The DNS64 device appears as a regular 168 recursive resolver for the IPv6 initiator. The DNS64 box receives an 169 AAAA DNS query generated by the IPv6 initiator. It first attempts a 170 recursive resolution for the requested AAAA records. If there is no 171 AAAA record available for the target node (which is the normal case 172 when the target node is an IPv4-only node), DNS64 performs a query 173 for A records. If any A records are discovered, DNS64 creates a 174 synthetic AAAA RR from the information retrieved in each A RR. 176 The FQDN of a synthetic AAAA RR is the same as that of the original A 177 RR, but an IPv6 representation of the IPv4 address contained in the 178 original A RR is included in the AAAA RR. The IPv6 representation of 179 the IPv4 address is algorithmically generated from the IPv4 address 180 and additional parameters configured in the DNS64. Among those 181 parameters configured in the DNS64, there is at least one IPv6 182 prefix, called Pref64::/n. The IPv6 address representing IPv4 183 addresses included in the AAAA RR synthesized by the DNS64 function 184 contain Pref64::/n and they also embed the original IPv4 address. 186 The same algorithm and the same Pref64::/n prefix or prefixes must be 187 configured both in the DNS64 device and the IPv6/IPv4 translator, so 188 that both can algorithmically generate the same IPv6 representation 189 for a given IPv4 address. In addition, it is required that IPv6 190 packets addressed to an IPv6 destination that contains the Pref64::/n 191 be delivered to the IPv6/IPv4 translator, so they can be translated 192 into IPv4 packets. 194 Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is 195 passed back to the IPv6 initiator, which will initiate an IPv6 196 communication with the IPv6 address associated with the IPv4 197 receiver. The packet will be routed to the IPv6/IPv4 translator 198 which will forward it to the IPv4 network . 200 In general, the only shared state between the DNS64 and the IPv6/IPv4 201 translator is the Pref64::/n and an optional set of static 202 parameters. The Pref64::/n and the set of static parameters must be 203 configured to be the same on both; there is no communication between 204 the DNS64 device and IPv6/IPv4 translator functions. The mechanism 205 to be used for configuring the parameters of the DNS64 is beyond the 206 scope of this memo. 208 The prefixes to be used as Pref64::/n and their applicability are 209 discussed in [I-D.ietf-behave-address-format]. There are two types 210 of prefixes that can be used as Pref64::/n. 212 The Pref64::/n can be the Well-Known prefix 64:FF9B::/96 reserved 213 by [I-D.ietf-behave-address-format] for the purpose of 214 representing IPv4 addresses in IPv6 address space. 216 The Pref64::/n can be a Network Specific Prefix (NSP). An NSP is 217 an IPv6 prefix assigned by an organization for to create IPv6 218 representations of IPv4 addresses. 220 The main different in the nature of the two types of prefixes is that 221 the NSP is a locally assigned prefix that is under control of the 222 organization that is providing the translation services, while the 223 Well-Known prefix is a prefix that has a global meaning since it has 224 been assigned for the specific purpose of representing IPv4 addresses 225 in IPv6 address space. 227 The DNS64 function can be performed in two places. 229 One option is to locate the DNS64 function in recursive name 230 servers serving end hosts. In this case, when an IPv6-only host 231 queries the name server for AAAA RRs for an IPv4-only host, the 232 name server can perform the synthesis of AAAA RRs and pass them 233 back to the IPv6 only initiator. The main advantage of this mode 234 is that current IPv6 nodes can use this mechanism without 235 requiring any modification. This mode is called "DNS64 in DNS 236 server mode". 238 The other option is to place the DNS64 function in the end hosts 239 themselves, coupled to the local stub resolver. In this case, the 240 stub resolver will try to obtain (real) AAAA RRs and in case they 241 are not available, the DNS64 function will synthesize AAAA RRs for 242 internal usage. This mode is compatible with some advanced 243 functions like DNSSEC validation in the end host. The main 244 drawback of this mode is its deployability, since it requires 245 changes in the end hosts. This mode is called "DNS64 in stub- 246 resolver mode"". 248 3. Background to DNS64 - DNSSEC interaction 250 DNSSEC presents a special challenge for DNS64, because DNSSEC is 251 designed to detect changes to DNS answers, and DNS64 may alter 252 answers coming from an authoritative server. 254 A recursive resolver can be security-aware or security-oblivious. 256 Moreover, a security-aware recursive name server can be validating or 257 non-validating, according to operator policy. In the cases below, 258 the recursive server is also performing DNS64, and has a local policy 259 to validate. We call this general case vDNS64, but in all the cases 260 below the DNS64 functionality should be assumed needed. 262 DNSSEC includes some signaling bits that offer some indicators of 263 what the query originator understands. 265 If a query arrives at a vDNS64 device with the DO bit set, the query 266 originator is signaling that it understands DNSSEC. The DO bit does 267 not indicate that the query originator will validate the response. 268 It only means that the query originator can understand responses 269 containing DNSSEC data. Conversely, if the DO bit is clear, that is 270 evidence that the querying agent is not aware of DNSSEC. 272 If a query arrives at a vDNS64 device with the CD bit set, it is an 273 indication that the querying agent wants all the validation data so 274 it can do checking itself. By local policy, vDNS64 could still 275 validate, but it must return all data to the querying agent anyway. 277 Here are the possible cases: 279 1. A security-oblivious DNS64 node receives a query with the DO bit 280 clear. In this case, DNSSEC is not a concern, because the 281 querying agent does not understand DNSSEC responses. 283 2. A security-oblivious DNS64 node receives a query with the DO bit 284 set, and the CD bit clear. This is just like the case of a non- 285 DNS64 case: the server doesn't support it, so the querying agent 286 is out of luck. 288 3. A security-aware and non-validating DNS64 node receives a query 289 with the DO bit set and the CD bit clear. Such a resolver is not 290 validating responses, likely due to local policy (see [RFC4035], 291 section 4.2). For that reason, this case amounts to the same as 292 the previous case, and no validation happens. 294 4. A security-aware and non-validating DNS64 node receives a query 295 with the DO bit set and the CD bit set. In this case, the 296 resolver is supposed to pass on all the data it gets to the query 297 initiator (see section 3.2.2 of [RFC4035]). This case will be 298 problematic with DNS64. If the DNS64 server modifies the record, 299 the client will get the data back and try to validate it, and the 300 data will be invalid as far as the client is concerned. 302 5. A security-aware and validating DNS64 node receives a query with 303 the DO bit clear and CD clear. In this case, the resolver 304 validates the data. If it fails, it returns RCODE 2 (SERVFAIL); 305 otherwise, it returns the answer. This is the ideal case for 306 vDNS64. The resolver validates the data, and then synthesizes 307 the new record and passes that to the client. The client, which 308 is presumably not validating (else it would have set DO and CD), 309 cannot tell that DNS64 is involved. 311 6. A security-aware and validating DNS64 node receives a query with 312 the DO bit set and CD clear. In principle, this ought to work 313 like the previous case, except that the resolver should also set 314 the AD bit on the response. 316 7. A security-aware and validating DNS64 node receives a query with 317 the DO bit set and CD set. This is effectively the same as the 318 case where a security-aware and non-validating recursive resolver 319 receives a similar query, and the same thing will happen: the 320 downstream validator will mark the data as invalid if DNS64 has 321 performed synthesis. 323 4. Terminology 325 This section provides definitions for the special terms used in the 326 document. 328 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 329 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 330 document are to be interpreted as described in RFC 2119 [RFC2119]. 332 Authoritative server: A DNS server that can answer authoritatively a 333 given DNS question. 335 DNS64: A logical function that synthesizes DNS resource records (e.g 336 AAAA records containing IPv6 addresses) from DNS resource records 337 actually contained in the global DNS (e.g. A records containing 338 IPv4 addresses). 340 DNS64 recursor: A recursive resolver that provides the DNS64 341 functionality as part of its operation. 343 Recursive resolver: A DNS server that accepts requests from one 344 resolver, and asks another resolver for the answer on behalf of 345 the first resolver. 347 Synthetic RR: A DNS resource record (RR) that is not contained in 348 any zone data file, but has been synthesized from other RRs. An 349 example is a synthetic AAAA record created from an A record. 351 IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 352 packets and vice-versa. It is only required that the 353 communication initiated from the IPv6 side be supported. 355 For a detailed understanding of this document, the reader should also 356 be familiar with DNS terminology from [RFC1034],[RFC1035] and current 357 NAT terminology from [RFC4787]. Some parts of this document assume 358 familiarity with the terminology of the DNS security extensions 359 outlined in [RFC4035]. 361 5. DNS64 Normative Specification 363 A DNS64 is a logical function that synthesizes AAAA records from A 364 records. The DNS64 function may be implemented in a stub resolver, 365 in a recursive resolver, or in an authoritative name server. 367 The implementation SHOULD support mapping of IPv4 address ranges to 368 separate IPv6 prefixes for AAAA record synthesis. This allows 369 handling of special use IPv4 addresses [I-D.iana-rfc3330bis]. 370 Multicast address handling is further specified in 371 [I-D.venaas-behave-mcast46]. 373 5.1. Resolving AAAA queries and the answer section 375 When the DNS64 receives a query for RRs of type AAAA and class IN, it 376 first attempts to retrieve non-synthetic RRs of this type and class, 377 either by performing a query or, in the case of an authoritative 378 server, by examining its own results. 380 5.1.1. The answer when there is AAAA data available 382 If the query results in one or more AAAA records in the answer 383 section, the result is returned to the requesting client as per 384 normal DNS semantics, except in the case where any of the AAAA 385 records match a special exclusion set of prefixes, considered in 386 Section 5.1.3. If there is (non-excluded) AAAA data available, DNS64 387 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix B 388 for an analysis of the motivations for and the implications of not 389 complying with this recommendation). By default DNS64 390 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs 391 exist. 393 5.1.2. The answer when there is an error 395 If the query results in a response with an error code other than 0, 396 the result is handled according to normal DNS operation -- that is, 397 either the resolver tries again using a different server from the 398 authoritative NS RRSet, or it returns the error to the client. This 399 stage is still prior to any synthesis having happened, so a response 400 to be returned to the client does not need any special assembly than 401 would usually happen in DNS operation. 403 5.1.3. Special exclusion set for AAAA records 405 Some IPv6 addresses are not actually usable by IPv6-only hosts. If 406 they are returned to IPv6-only querying agents as AAAA records, 407 therefore, the goal of decreasing the number of failure modes will 408 not be attained. Examples include AAAA records with addresses in the 409 ::ffff/96 network, and possibly (depending on the context) AAAA 410 records with the site's Pref::64/n or the Well-Known prefix (see 411 below for more about the Well-Known prefix). A DNS64 implementation 412 SHOULD provide a mechanism to specify IPv6 prefix ranges to be 413 treated as though the AAAA containing them were an empty answer. An 414 implementation SHOULD include the ::ffff/96 network in that range by 415 default. Failure to provide this facility will mean that clients 416 querying the DNS64 function may not be able to communicate with hosts 417 that would be reachable from a dial-stack host. 419 When the DNS64 performs its initial AAAA query, if it receives an 420 answer with only AAAA records containing addresses in the target 421 range(s), then it MUST treat the answer as though it were an empty 422 answer, and proceed accordingly. If it receives an answer with at 423 least one AAAA record containing an address outside any of the target 424 ranges, then it MAY build an answer section for a response including 425 only the AAAA record(s) that do not contain any of the addresses 426 inside the excluded ranges. That answer section is used in the 427 assembly of a response as detailed in Section 5.4. Alternatively, it 428 MAY treat the answer as though it were an empty answer, and proceed 429 accordingly. It MUST NOT return the offending AAAA records as part 430 of a response. 432 5.1.4. Dealing with CNAME and DNAME 434 If the response contains a CNAME or a DNAME, then the CNAME or DNAME 435 chain is followed until the first terminating A or AAAA record is 436 reached. This may require the DNS64 to ask for an A record, in case 437 the response to the original AAAA query is a CNAME or DNAME without 438 an AAAA record to follow. The resulting AAAA or A record is treated 439 like any other AAAA or A case, as appropriate. 441 When assembling the answer section, the original CNAME or DNAME RR is 442 included as part of the answer, and the synthetic AAAA, if 443 appropriate, is included. 445 5.1.5. Data for the answer when performing synthesis 447 If the query results in no error but an empty answer section in the 448 response, the DNS64 resolver attempts to retrieve A records for the 449 name in question. If this new A RR query results in an empty answer 450 or in an error, then the empty result or error is used as the basis 451 for the answer returned to the querying client. (Transient errors 452 may result in retrying the query, depending on the operation of the 453 resolver; this is just as in Section 5.1.2.) If instead the query 454 results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on 455 the A RRs according to the procedure outlined in Section 5.1.6. The 456 DNS64 resolver then returns the synthesized AAAA records in the 457 answer section to the client, removing the A records that form the 458 basis of the synthesis. 460 5.1.6. Performing the synthesis 462 A synthetic AAAA record is created from an A record as follows: 464 o The NAME field is set to the NAME field from the A record 466 o The TYPE field is set to 28 (AAAA) 468 o The CLASS field is set to 1 (IN) 470 o The TTL field is set to the minimum of the TTL of the original A 471 RR and the SOA RR for the queried domain. (Note that in order to 472 obtain the TTL of the SOA RR the DNS64 does not need to perform a 473 new query, but it can remember the TTL from the SOA RR in the 474 negative response to the AAAA query). 476 o The RDLENGTH field is set to 16 478 o The RDATA field is set to the IPv6 representation of the IPv4 479 address from the RDATA field of the A record. The DNS64 SHOULD 480 check each A RR against IPv4 address ranges and select the 481 corresponding IPv6 prefix to use in synthesizing the AAAA RR. See 482 Section 5.2 for discussion of the algorithms to be used in 483 effecting the transformation. 485 5.1.7. Querying in parallel 487 DNS64 MAY perform the query for the AAAA RR and for the A RR in 488 parallel, in order to minimize the delay. However, this would result 489 in performing unnecessary A RR queries in the case no AAAA RR 490 synthesis is required. A possible trade-off would be to perform them 491 sequentially but with a very short interval between them, so if we 492 obtain a fast reply, we avoid doing the additional query. (Note that 493 this discussion is relevant only if the DNS64 function needs to 494 perform external queries to fetch the RR. If the needed RR 495 information is available locally, as in the case of an authoritative 496 server, the issue is no longer relevant.) 498 5.2. Generation of the IPv6 representations of IPv4 addresses 500 DNS64 supports multiple algorithms for the generation of the IPv6 501 representation of an IPv4 address. The constraints imposed on the 502 generation algorithms are the following: 504 The same algorithm to create an IPv6 address from an IPv4 address 505 MUST be used by both the DNS64 to create the IPv6 address to be 506 returned in the synthetic AAAA RR from the IPv4 address contained 507 in original A RR, and by the IPv6/IPv4 translator to create the 508 IPv6 address to be included in the destination address field of 509 the outgoing IPv6 packets from the IPv4 address included in the 510 destination address field of the incoming IPv4 packet. 512 The algorithm MUST be reversible, i.e. it MUST be possible to 513 extract the original IPv4 address from the IPv6 representation. 515 The input for the algorithm MUST be limited to the IPv4 address, 516 the IPv6 prefix (denoted Pref64::/n) used in the IPv6 517 representations and optionally a set of stable parameters that are 518 configured in the DNS64 (such as fixed string to be used as a 519 suffix). 521 If we note n the length of the prefix Pref64::/n, then n MUST 522 the less or equal than 96. If a Pref64::/n is configured 523 through any means in the DNS64 (such as manually configured, or 524 other automatic mean not specified in this document), the 525 default algorithm MUST use this prefix. If no prefix is 526 available, the algorithm MUST use the Well-Known prefix 64: 527 FF9B::/96 defined in [I-D.ietf-behave-address-format] 529 [[anchor9: Note in document: The value 64:FF9B::/96 is proposed as 530 the value for the Well-Known prefix and needs to be confirmed 531 whenis published as RFC.]][I-D.ietf-behave-address-format] 533 DNS64 MUST support the algorithm for generating IPv6 representations 534 of IPv4 addresses defined Section 2 of 535 [I-D.ietf-behave-address-format]. Moreover, the aforementioned 536 algorithm MUST be the default algorithm used by DNS64. While the 537 normative description of the algorithm is provided in 538 [I-D.ietf-behave-address-format], an sample description of the 539 algorithm and its application to different scenarios is provided in 540 Appendix A for illustration purposes. 542 5.3. Handling other RRs and the Additional Section 544 5.3.1. PTR queries 546 If a DNS64 nameserver receives a PTR query for a record in the 547 IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, 548 reverse the address portion of the QNAME according to the encoding 549 scheme outlined in section 2.5 of [RFC3596] , and examine the 550 resulting address to see whether its prefix matches the locally- 551 configured Pref64::/n. There are two alternatives for a DNS64 552 nameserver to respond to such PTR queries. A DNS64 node MUST provide 553 one of these, and SHOULD NOT provide both at the same time unless 554 different IP6.ARPA zones require answers of different sorts. 556 The first option is for the DNS64 nameserver to respond 557 authoritatively for its prefixes. If the address prefix matches any 558 Pref64::/n used in the site, either a NSP prefix or the Well-Known 559 prefix used for NAT64 (i.e. 64:FF9B::/96) as defined in 560 [I-D.ietf-behave-address-format], then the DNS64 server MAY answer 561 the query using locally-appropriate RDATA. The DNS64 server MAY use 562 the same RDATA for all answers. Note that the requirement is to 563 match any Pref64::/n used at the site, and not merely the locally- 564 configured Pref64::/n. This is because end clients could ask for a 565 PTR record matching an address received through a different (site- 566 provided) DNS64, and if this strategy is in effect, those queries 567 should never be sent to the global DNS. The advantage of this 568 strategy is that it makes plain to the querying client that the 569 prefix is one operated by the DNS64 site, and that the answers the 570 client is getting are generated by the DNS64. The disadvantage is 571 that any useful reverse-tree information that might be in the global 572 DNS is unavailable to the clients querying the DNS64. 574 The second option is for the DNS64 nameserver to synthesize a CNAME 575 mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA 576 name. The rest of the response would be the normal DNS processing. 577 The CNAME can be signed on the fly if need be. The advantage of this 578 approach is that any useful information in the reverse tree is 579 available to the querying client. The disadvantage is that it adds 580 additional load to the DNS64 (because CNAMEs have to be synthesized 581 for each PTR query that matches the Pref64::/n), and that it may 582 require signing on the fly. In addition, the generated CNAME could 583 correspond to an unpopulated in-addr.arpa zone, so the CNAME would 584 provide a reference to a non-existent record. 586 If the address prefix does not match any of the Pref64::/n, then the 587 DNS64 server MUST process the query as though it were any other query 588 -- i.e. a recursive nameserver MUST attempt to resolve the query as 589 though it were any other (non-A/AAAA) query, and an authoritative 590 server MUST respond authoritatively or with a referral, as 591 appropriate. 593 5.3.2. Handling the additional section 595 DNS64 synthesis MUST NOT be performed on any records in the 596 additional section of synthesized answers. The DNS64 MUST pass the 597 additional section unchanged. 599 5.3.3. Other records 601 If the DNS64 is in recursive resolver mode, then it SHOULD also serve 602 the zones specified in [I-D.ietf-dnsop-default-local-zones], rather 603 than forwarding those queries elsewhere to be handled. 605 All other RRs MUST be returned unchanged. 607 5.4. Assembling a synthesized response to a AAAA query 609 The DNS64 uses different pieces of data to build the response 610 returned to the querying client. 612 The query that is used as the basis for synthesis results either in 613 an error, an answer that can be used as a basis for synthesis, or an 614 empty (authoritative) answer. If there is an empty answer, then the 615 DNS64 responds to the original querying client with the answer the 616 DNS64 received to the original AAAA query. Otherwise, the response 617 is assembled as follows. 619 The header fields are set according to the usual rules for recursive 620 or authoritative servers, depending on the role that the DNS64 is 621 serving. The question section is copied from the original AAAA 622 query. The answer section is populated according to the rules in 623 Section 5.1.6. The authority and additional sections are copied from 624 the response to the A query that the DNS64 performed. 626 5.5. DNSSEC processing: DNS64 in recursive server mode 628 We consider the case where the recursive server that is performing 629 DNS64 also has a local policy to validate the answers according to 630 the procedures outlined in [RFC4035] Section 5. We call this general 631 case vDNS64. 633 The vDNS64 uses the presence of the DO and CD bits to make some 634 decisions about what the query originator needs, and can react 635 accordingly: 637 1. If CD is not set and DO is not set, vDNS64 SHOULD perform 638 validation and do synthesis as needed. 640 2. If CD is not set and DO is set, then vDNS64 SHOULD perform 641 validation. Whenever vDNS64 performs validation, it MUST 642 validate the negative answer for AAAA queries before proceeding 643 to query for A records for the same name, in order to be sure 644 that there is not a legitimate AAAA record on the Internet. 645 Failing to observe this step would allow an attacker to use DNS64 646 as a mechanism to circumvent DNSSEC. If the negative response 647 validates, and the response to the A query validates, then the 648 vDNS64 MAY perform synthesis and SHOULD set the AD bit in the 649 answer to the client. This is acceptable, because [RFC4035], 650 section 3.2.3 says that the AD bit is set by the name server side 651 of a security-aware recursive name server if and only if it 652 considers all the RRSets in the Answer and Authority sections to 653 be authentic. In this case, the name server has reason to 654 believe the RRSets are all authentic, so it SHOULD set the AD 655 bit. If the data does not validate, the vDNS64 MUST respond with 656 RCODE=2 (server failure). 657 A security-aware end point might take the presence of the AD bit 658 as an indication that the data is valid, and may pass the DNS 659 (and DNSSEC) data to an application. If the application attempts 660 to validate the synthesized data, of course, the validation will 661 fail. One could argue therefore that this approach is not 662 desirable. But security aware stub resolvers MUST NOT place any 663 reliance on data received from resolvers and validated on their 664 behalf without certain criteria established by [RFC4035], section 665 4.9.3. An application that wants to perform validation on its 666 own should use the CD bit. 668 3. If the CD bit is set and DO is set, then vDNS64 MAY perform 669 validation, but MUST NOT perform synthesis. It MUST hand the 670 data back to the query initiator, just like a regular recursive 671 resolver, and depend on the client to do the validation and the 672 synthesis itself. 673 The disadvantage to this approach is that an end point that is 674 translation-oblivious but security-aware and validating will not 675 be able to use the DNS64 functionality. In this case, the end 676 point will not have the desired benefit of NAT64. In effect, 677 this strategy means that any end point that wishes to do 678 validation in a NAT64 context must be upgraded to be translation- 679 aware as well. 681 6. Deployment notes 683 While DNS64 is intended to be part of a strategy for aiding IPv6 684 deployment in an internetworking environment with some IPv4-only and 685 IPv6-only networks, it is important to realise that it is 686 incompatible with some things that may be deployed in an IPv4-only or 687 dual-stack context. 689 6.1. DNS resolvers and DNS64 691 Full-service resolvers that are unaware of the DNS64 function can be 692 (mis)configured to act as mixed-mode iterative and forwarding 693 resolvers. In a native-IPv4 context, this sort of configuration may 694 appear to work. It is impossible to make it work properly without it 695 being aware of the DNS64 function, because it will likely at some 696 point obtain IPv4-only glue records and attempt to use them for 697 resolution. The result that is returned will contain only A records, 698 and without the ability to perform the DNS64 function the resolver 699 will simply be unable to answer the necessary AAAA queries. 701 6.2. DNSSEC validators and DNS64 703 Existing DNSSEC validators (i.e. that are unaware of DNS64) will 704 reject all the data that comes from the DNS64 as having been tampered 705 with. If it is necessary to have validation behind the DNS64, then 706 the validator must know how to perform the DNS64 function itself. 707 Alternatively, the validating host may establish a trusted connection 708 with the DNS64, and allow the DNS64 to do all validation on its 709 behalf. 711 6.3. DNS64 and multihomed and dual-stack hosts 713 6.3.1. IPv6 multihomed hosts 715 Synthetic AAAA records may be constructed on the basis of the network 716 context in which they were constructed. If a host sends DNS queries 717 to resolvers in multiple networks, it is possible that some of them 718 will receive answers from a DNS64 without all of them being connected 719 via a NAT64. For instance, suppose a system has two interfaces, i1 720 and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2 721 has native IPv6 connectivity only. I1 might receive a AAAA answer 722 from a DNS64 that is configured for a particular NAT64; the IPv6 723 address contained in that AAAA answer will not connect with anything 724 via i2. 726 This example illustrates why it is generally preferable that hosts 727 treat DNS answers from one interface as local to that interface. The 728 answer received on one interface will not work on the other 729 interface. Hosts that attempt to use DNS answers globally may 730 encounter surprising failures in these cases. For more discussion of 731 this topic, see [I-D.savolainen-mif-dns-server-selection]. 733 Note that the issue is not that there are two interfaces, but that 734 there are two networks involved. The same results could be achieved 735 with a single interface routed to two different networks. 737 6.3.2. Accidental dual-stack DNS64 use 739 Similarly, suppose that i1 has IPv6 connectivity and can connect to 740 the IPv4 Internet through NAT64, but i2 has IPv4 native transit. In 741 this case, i1 could receive an IPv6 address from a synthetic AAAA 742 that would better be reached via native IPv4 transit. Again, it is 743 worth emphasising that this arises because there are two networks 744 involved. 746 Since it is most likely that the host will attempt AAAA resolution 747 first, in this arrangement the host will often use the NAT64 when a 748 native IPv4 would be preferable. For this reason, hosts with IPv4 749 connectivity to the Internet should avoid using DNS64. This can be 750 partly resolved by ISPs when providing DNS resolvers to clients, but 751 that is not a guarantee that the NAT64 will never be used when a 752 native IPv4 connection should be used. There is no general-purpose 753 mechanism to ensure that native IPv4 transit will always be 754 preferred, because to a DNS64-oblivious host, the DNS64 looks just 755 like an ordinary DNS server. Operators of a NAT64 should expect 756 traffic to pass through the NAT64 even when it is not necessary. 758 6.3.3. Intentional dual-stack DNS64 use 760 Finally, consider the case where the IPv4 connectivity on i2 is only 761 to a LAN, with an IPv6-only connection on i1 to the Internet, 762 connecting to the IPv4 Internet via NAT64. Traffic to the LAN may 763 not be routable from the global Internet, as is often the case (for 764 instance) with LANs using RFC1918 addresses. In this case, it is 765 critical that the DNS64 not synthesize AAAA responses for hosts in 766 the LAN, or else that the DNS64 be aware of hosts in the LAN and 767 provide context-sensitive answers ("split view" DNS answers) for 768 hosts inside the LAN. As with any split view DNS arrangement, 769 operators must be prepared for data to leak from one context to 770 another, and for failures to occur because nodes accessible from one 771 context are not accessible from the other. 773 7. Security Considerations 775 See the discussion on the usage of DNSSEC and DNS64 described in the 776 document. 778 8. Contributors 780 Dave Thaler 782 Microsoft 784 dthaler@windows.microsoft.com 786 9. Acknowledgements 788 This draft contains the result of discussions involving many people, 789 including the participants of the IETF BEHAVE Working Group. The 790 following IETF participants made specific contributions to parts of 791 the text, and their help is gratefully acknowledged: Mark Andrews, 792 Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet, 793 Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed 794 Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs 795 Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki 796 Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund, 797 Florian Weimer, Dan Wing, Xu Xiaohu. 799 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 800 Trilogy, a research project supported by the European Commission 801 under its Seventh Framework Program. 803 10. References 805 10.1. Normative References 807 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 808 Requirement Levels", BCP 14, RFC 2119, March 1997. 810 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 811 STD 13, RFC 1034, November 1987. 813 [RFC1035] Mockapetris, P., "Domain names - implementation and 814 specification", STD 13, RFC 1035, November 1987. 816 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 817 RFC 2671, August 1999. 819 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 820 RFC 2672, August 1999. 822 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 823 (SIIT)", RFC 2765, February 2000. 825 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 826 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 827 RFC 4787, January 2007. 829 [I-D.ietf-behave-address-format] 830 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 831 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 832 draft-ietf-behave-address-format-02 (work in progress), 833 December 2009. 835 10.2. Informative References 837 [I-D.ietf-behave-v6v4-xlate-stateful] 838 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 839 Address and Protocol Translation from IPv6 Clients to IPv4 840 Servers", draft-ietf-behave-v6v4-xlate-stateful-05 (work 841 in progress), December 2009. 843 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 844 Translation - Protocol Translation (NAT-PT)", RFC 2766, 845 February 2000. 847 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 848 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 849 RFC 2136, April 1997. 851 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 852 Considerations for IP Fragment Filtering", RFC 1858, 853 October 1995. 855 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 856 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 858 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 859 Address Translator (Traditional NAT)", RFC 3022, 860 January 2001. 862 [RFC3484] Draves, R., "Default Address Selection for Internet 863 Protocol version 6 (IPv6)", RFC 3484, February 2003. 865 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 866 "DNS Extensions to Support IP Version 6", RFC 3596, 867 October 2003. 869 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 871 Rose, "DNS Security Introduction and Requirements", 872 RFC 4033, March 2005. 874 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 875 Rose, "Resource Records for the DNS Security Extensions", 876 RFC 4034, March 2005. 878 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 879 Rose, "Protocol Modifications for the DNS Security 880 Extensions", RFC 4035, March 2005. 882 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 883 Address Translator - Protocol Translator (NAT-PT) to 884 Historic Status", RFC 4966, July 2007. 886 [I-D.iana-rfc3330bis] 887 Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 888 draft-iana-rfc3330bis-11 (work in progress), August 2009. 890 [I-D.ietf-mmusic-ice] 891 Rosenberg, J., "Interactive Connectivity Establishment 892 (ICE): A Protocol for Network Address Translator (NAT) 893 Traversal for Offer/Answer Protocols", 894 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 896 [I-D.ietf-6man-addr-select-sol] 897 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 898 "Solution approaches for address-selection problems", 899 draft-ietf-6man-addr-select-sol-02 (work in progress), 900 July 2009. 902 [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of 903 Managed Objects for Synchronous Optical Network (SONET) 904 Linear Automatic Protection Switching (APS) 905 Architectures", RFC 3498, March 2003. 907 [I-D.wing-behave-learn-prefix] 908 Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/ 909 IPv4 Translator", draft-wing-behave-learn-prefix-04 (work 910 in progress), October 2009. 912 [I-D.venaas-behave-mcast46] 913 Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An 914 IPv4 - IPv6 multicast translator", 915 draft-venaas-behave-mcast46-01 (work in progress), 916 July 2009. 918 [I-D.ietf-dnsop-default-local-zones] 919 Andrews, M., "Locally-served DNS Zones", 920 draft-ietf-dnsop-default-local-zones-09 (work in 921 progress), November 2009. 923 [I-D.savolainen-mif-dns-server-selection] 924 Savolainen, T., "DNS Server Selection on Multi-Homed 925 Hosts", draft-savolainen-mif-dns-server-selection-01 (work 926 in progress), October 2009. 928 Appendix A. Deployment scenarios and examples 930 In this section, we first provide an example of the address 931 transformation algorithm and then we walk through some sample 932 scenarios that are expected to be common deployment cases. It should 933 be noted that is provided for illustrative purposes and this section 934 is not normative. The normative definition of DNS64 is provided in 935 Section 5 and the normative definition of the address transformation 936 algorithm is provided in [I-D.ietf-behave-address-format]. 938 There are two main different setups where DNS64 is expected to be 939 used (other setups are possible as well, but these two are the main 940 ones identified at the time of this writing). 942 One possible setup that is expected to be common is the case of an 943 end site or an ISP that is providing IPv6-only connectivity or 944 connectivity to IPv6-only hosts that wants to allow the 945 communication from these IPv6-only connected hosts to the IPv4 946 Internet. This case is called An-IPv6-network-to-IPv4-Internet. 947 In this case, the IPv6/IPv4 Translator is used to connect the end 948 site or the ISP to the IPv4 Internet and the DNS64 function is 949 provided by the end site or the ISP. 951 The other possible setup that is expected is an IPv4 site that 952 wants that its IPv4 servers to be reachable from the IPv6 953 Internet. This case is called IPv6-Internet-to-an-IPv4-network. 954 It should be noted that the IPv4 addresses used in the IPv4 site 955 can be either public or private. In this case, the IPv6/IPv4 956 Translator is used to connect the IPv4 end site to the IPv6 957 Internet and the DNS64 function is provided by the end site 958 itself. 960 In this section we illustrate how the DNS64 behaves in the different 961 scenarios that are expected to be common. We consider then 3 962 possible scenarios, namely: 964 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server 965 mode 967 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- 968 resolver mode 970 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server 971 mode 973 The notation used is the following: upper case letters are IPv4 974 addresses; upper case letters with a prime(') are IPv6 addresses; 975 lower case letters are ports; prefixes are indicated by "P::X", which 976 is an IPv6 address built from an IPv4 address X by adding the prefix 977 P, mappings are indicated as "(X,x) <--> (Y',y)". 979 A.1. Example of IPv6/IPv4 address transformation algorithm 981 In this section we describe the algorithm for the generation of IPv6 982 address from IPv4 address to be implemented in the DNS64 in the case 983 of a Pref64::/n with n=96. 985 The only parameter required by the default algorithm is an IPv6 986 prefix. This prefix is used to map IPv4 addresses into IPv6 987 addresses, and is denoted Pref64::/96. If an Pref64::/96 is 988 configured through any means in the DNS64 (such as manually 989 configured, or other automatic mean not specified in this document), 990 the default algorithm will use this prefix. If no prefix is 991 available the algorithm will use the Well-Know prefix (64:FF9B::/96) 992 defined in [I-D.ietf-behave-address-format] 994 The input for the algorithm are: 996 The IPv4 address: X 998 The IPv6 prefix: Pref64::/96 1000 The IPv6 address is generated by concatenating the prefix 1001 Pref64::/96, the IPv4 address X So, the resulting IPv6 address would 1002 be Pref64:X 1004 Reverse algorithm 1006 We next describe the reverse algorithm of the algorithm described in 1007 the previous section. This algorithm allows to generate and IPv4 1008 address from an IPv6 address. This reverse algorithm is NOT 1009 implemented by the DNS64 but it is implemented in the IPv6/IPv4 1010 translator that is serving the same domain the DNS64. 1012 The only parameter required by the default algorithm is an IPv6 1013 prefix. This prefix is the one originally used to map IPv4 addresses 1014 into IPv6 addresses, and is denoted Pref64::/96. 1016 The input for the algorithm are: 1018 The IPv6 address: X' 1020 The IPv6 prefix: Pref64::/n 1022 First, the algorithm checks that the fist 96 bits of the IPv6 address 1023 X' match with the prefix Pref64::/96 i.e. verifies that Pref64::/96 = 1024 X'/96. 1026 If this is not the case, the algorithm ends and no IPv4 address is 1027 generated. 1029 If the verification is successful, then last 32 bits of address X' 1030 are extracted to form the IPv4 address. 1032 A.2. Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in 1033 DNS server mode 1035 In this example, we consider an IPv6 node located in an IPv6-only 1036 site that initiates a communication to an IPv4 node located in the 1037 IPv4 Internet. In this example, the Pref64::/n has n equal to 96. 1039 The scenario for this case is depicted in the following figure: 1041 +---------------------------------------+ +-----------+ 1042 |IPv6 site +-------------+ |IP Addr: | | 1043 | +----+ | Name server | +-------+ T | IPv4 | 1044 | | H1 | | with DNS64 | |64Trans|------| Internet | 1045 | +----+ +-------------+ +-------+ +-----------+ 1046 | |IP addr: Y' | | | |IP addr: X 1047 | --------------------------------- | +----+ 1048 +---------------------------------------+ | H2 | 1049 +----+ 1051 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an 1052 IPv4 node H2 with IPv4 address X. 1054 A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 1055 Internet. This IPv6/IPv4 Translator has a prefix (called 1056 Pref64::/96) an IPv4 address T assigned to its IPv4 interface. 1058 The other element involved is the local name server. The name server 1059 is a dual-stack node, so that H1 can contact it via IPv6, while it 1060 can contact IPv4-only name servers via IPv4. 1062 The local name server needs to know the prefix assigned to the local 1063 IPv6/IPv4 Translator (Pref64::/96). For the purpose of this example, 1064 we assume it learns this through manual configuration. 1066 For this example, assume the typical DNS situation where IPv6 hosts 1067 have only stub resolvers, and always query a name server that 1068 performs recursive lookups (henceforth called "the recursive 1069 nameserver"). 1071 The steps by which H1 establishes communication with H2 are: 1073 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS 1074 query for an AAAA record for H2 to the recursive name server. 1075 The recursive name server implements DNS64 functionality. 1077 2. The recursive name server resolves the query, and discovers that 1078 there are no AAAA records for H2. 1080 3. The recursive name server queries for an A record for H2 and gets 1081 back an A record containing the IPv4 address X. The name server 1082 then synthesizes an AAAA record. The IPv6 address in the AAAA 1083 record contains the prefix assigned to the IPv6/IPv4 Translator 1084 in the upper 96 bits then the IPv4 address X i.e. the resulting 1085 IPv6 address is Pref64:X 1087 4. H1 receives the synthetic AAAA record and sends a packet towards 1088 H2. The packet is sent from a source transport address of (Y',y) 1089 to a destination transport address of (Pref64:X,x), where y and x 1090 are ports chosen by H2. 1092 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 1093 Translator and the subsequent communication flows by means of the 1094 IPv6/IPv4 Translator mechanisms. 1096 A.3. An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in 1097 stub-resolver mode 1099 The scenario also considers a Pref64::/n with n equal to 96. This 1100 case is depicted in the following figure: 1102 +---------------------------------------+ +-----------+ 1103 |IPv6 site +-------+ |IP addr: | | 1104 | +---------------+ | Name | +-------+ T | IPv4 | 1105 | | H1 with DNS64 | | Server| |64Trans|------| Internet | 1106 | +---------------+ +-------+ +-------+ +-----------+ 1107 | |IP addr: Y' | | | |IP addr: X 1108 | --------------------------------- | +----+ 1109 +---------------------------------------+ | H2 | 1110 +----+ 1112 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an 1113 IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64 1114 function. 1116 A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 1117 Internet. This IPv6/IPv4 Translator has a prefix (called 1118 Pref64::/96) and an IPv4 address T assigned to its IPv4 interface. 1120 H1 needs to know the prefix assigned to the local IPv6/IPv4 1121 Translator (Pref64::/96). For the purpose of this example, we assume 1122 it learns this through manual configuration. 1124 Also shown is a name server. For the purpose of this example, we 1125 assume that the name server is a dual-stack node, so that H1 can 1126 contact it via IPv6, while it can contact IPv4-only name servers via 1127 IPv4. 1129 For this example, assume the typical situation where IPv6 hosts have 1130 only stub resolvers and always query a name server that provides 1131 recursive lookups (henceforth called "the recursive name server"). 1132 The recursive name server does not perform the DNS64 function. 1134 The steps by which H1 establishes communication with H2 are: 1136 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS 1137 query for a AAAA record for H2 to the recursive name server. 1139 2. The recursive DNS server resolves the query, and returns the 1140 answer to H1. Because there are no AAAA records in the global 1141 DNS for H2, the answer is empty. 1143 3. The stub resolver at H1 then queries for an A record for H2 and 1144 gets back an A record containing the IPv4 address X. The DNS64 1145 function within H1 then synthesizes a AAAA record. The IPv6 1146 address in the AAAA record contains the prefix assigned to the 1147 IPv6/IPv4 Translator in the upper 96 bits, then the IPv4 address 1148 X i.e. the resulting IPv6 address is Pref64:X. 1150 4. H1 sends a packet towards H2. The packet is sent from a source 1151 transport address of (Y',y) to a destination transport address of 1152 (Pref64:X,x), where y and x are ports chosen by H2. 1154 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 1155 Translator and the subsequent communication flows using the IPv6/ 1156 IPv4 Translator mechanisms. 1158 A.4. Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS 1159 server mode 1161 In this example, we consider an IPv6 node located in the IPv6 1162 Internet site that initiates a communication to a IPv4 node located 1163 in the IPv4 site. Once again, in this example, the Pref64::/n has n 1164 equal to 96. 1166 This scenario can be addressed without using any form of DNS64 1167 function. This is so because it is possible to assign a fixed IPv6 1168 address to each of the IPv4 servers. Such an IPv6 address would be 1169 constructed as the Pref64::/96 concatenated with the IPv4 address of 1170 the IPv4 server. Note that the IPv4 address can be a public or a 1171 private address; the latter does not present any additional 1172 difficulty, since the NSP prefix must be used a Pref64::/96 (in this 1173 scenario the usage of the Well-Known prefix is not supported). Once 1174 these IPv6 addresses have been assigned to represent the IPv4 servers 1175 in the IPv6 Internet, real AAAA RRs containing these addresses can be 1176 published in the DNS under the site's domain. This is the 1177 recommended approach to handle this scenario, because it does not 1178 involve synthesizing AAAA records at the time of query. Such a 1179 configuration is easier to troubleshoot in the event of problems, 1180 because it always provides the same answer to every query. 1182 However, there are some more dynamic scenarios, where synthesizing 1183 AAAA RRs in this setup may be needed. In particular, when DNS Update 1184 [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 1185 servers, there are two options: One option is to modify the server 1186 that receives the dynamic DNS updates. That would normally be the 1187 authoritative server for the zone. So the authoritative zone would 1188 have normal AAAA RRs that are synthesized as dynamic updates occur. 1189 The other option is modify the authoritative server to generate 1190 synthetic AAAA records for a zone, possibly based on additional 1191 constraints, upon the receipt of a DNS query for the AAAA RR. The 1192 first option -- in which the AAAA is synthesized when the DNS update 1193 message is received, and the data published in the relevant zone -- 1194 is recommended over the second option (i.e. the synthesis upon 1195 receipt of the AAAA DNS query). This is because it is usually easier 1196 to solve problems of misconfiguration and so on when the DNS 1197 responses are not being generated dynamically. For completeness, the 1198 DNS64 behavior that we describe in this section covers the case of 1199 synthesizing the AAAA RR when the DNS query arrives. Nevertheless, 1200 such a configuration is not recommended. Troubleshooting 1201 configurations that change the data depending on the query they 1202 receive is notoriously hard, and the IPv4/IPv6 translation scenario 1203 is complicated enough without adding additional opportunities for 1204 possible malfunction. 1206 The scenario for this case is depicted in the following figure: 1208 +-----------+ +----------------------------------------+ 1209 | | | IPv4 site +-------------+ | 1210 | IPv6 | +-------+ +----+ | Name server | | 1211 | Internet |------|64Trans| | H2 | | with DNS64 | | 1212 +-----------+ +-------+ +----+ +-------------+ | 1213 |IP addr: Y' | | |IP addr: X | | 1214 +----+ | ----------------------------------- | 1215 | H1 | +----------------------------------------+ 1216 +----+ 1218 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an 1219 IPv4 node H2 with IPv4 address X. 1221 A IPv6/IPv4 Translator connects the IPv4 network to the IPv6 1222 Internet. This IPv6/IPv4 Translator has a prefix (called 1223 Pref64::/96). 1225 Also shown is the authoritative name server for the local domain with 1226 DNS64 functionality. For the purpose of this example, we assume that 1227 the name server is a dual-stack node, so that H1 or a recursive 1228 resolver acting on the request of H1 can contact it via IPv6, while 1229 it can be contacted by IPv4-only nodes to receive dynamic DNS updates 1230 via IPv4. 1232 The local name server needs to know the prefix assigned to the local 1233 IPv6/IPv4 Translator (Pref64::/96). For the purpose of this example, 1234 we assume it learns this through manual configuration. 1236 The steps by which H1 establishes communication with H2 are: 1238 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS 1239 query for an AAAA record for H2. The query is eventually 1240 forwarded to the server in the IPv4 site. 1242 2. The local DNS server resolves the query (locally), and discovers 1243 that there are no AAAA records for H2. 1245 3. The name server verifies that FQDN(H2) and its A RR are among 1246 those that the local policy defines as allowed to generate a AAAA 1247 RR from. If that is the case, the name server synthesizes an 1248 AAAA record from the A RR and the relevant Pref64::/96. The IPv6 1249 address in the AAAA record contains the prefix assigned to the 1250 IPv6/IPv4 Translator in the first 96 bits and the IPv4 address X. 1252 4. H1 receives the synthetic AAAA record and sends a packet towards 1253 H2. The packet is sent from a source transport address of (Y',y) 1254 to a destination transport address of (Pref64:X,x), where y and x 1255 are ports chosen by H2. 1257 5. The packet is routed through the IPv6 Internet to the IPv6 1258 interface of the IPv6/IPv4 Translator and the communication flows 1259 using the IPv6/IPv4 Translator mechanisms. 1261 Appendix B. Motivations and Implications of synthesizing AAAA RR when 1262 real AAAA RR exists 1264 The motivation for synthesizing AAAA RR when a real AAAA RR exists is 1265 to support the following scenario: 1267 An IPv4-only server application (e.g. web server software) is 1268 running on a dual-stack host. There may also be dual-stack server 1269 applications also running on the same host. That host has fully 1270 routable IPv4 and IPv6 addresses and hence the authoritative DNS 1271 server has an A and a AAAA record as a result. 1273 An IPv6-only client (regardless of whether the client application 1274 is IPv6-only, the client stack is IPv6-only, or it only has an 1275 IPv6 address) wants to access the above server. 1277 The client issues a DNS query to a DNS64 recursor. 1279 If the DNS64 only generates a synthetic AAAA if there's no real AAAA, 1280 then the communication will fail. Even though there's a real AAAA, 1281 the only way for communication to succeed is with the translated 1282 address. So, in order to support this scenario, the administrator of 1283 a DNS64 service may want to enable the synthesis of AAAA RR even when 1284 real AAAA RR exist. 1286 The implication of including synthetic AAAA RR when real AAAA RR 1287 exist is that translated connectivity may be preferred over native 1288 connectivity in some cases where the DNS64 is operated in DNS server 1289 mode. 1291 RFC3484 [RFC3484] rules use longest prefix match to select which is 1292 the preferred destination address to use. So, if the DNS64 recursor 1293 returns both the synthetic AAAA RR and the real AAAA RR, then if the 1294 DNS64 is operated by the same domain as the initiating host, and a 1295 global unicast prefix (called the NSP prefix as defined in 1296 [I-D.ietf-behave-address-format]) is used, then the synthetic AAAA RR 1297 is likely to be preferred. 1299 This means that without further configuration: 1301 In the case of An IPv6 network to the IPv4 internet, the host will 1302 prefer translated connectivity if NSP prefix is used. If the 1303 Well-Known prefix defined in [I-D.ietf-behave-address-format] is 1304 used, it will probably prefer native connectivity. 1306 In the case of the IPv6 Internet to an IPv4 network, it is 1307 possible to bias the selection towards the real AAAA RR if the 1308 DNS64 recursor returns the real AAAA first in the DNS reply, when 1309 the NSP prefix is used (the Well-Known prefix usage is not 1310 recommended in this case) 1312 In the case of the IPv6 to IPv4 in the same network, for local 1313 destinations (i.e., target hosts inside the local site), it is 1314 likely that the NSP prefix and the destination prefix are the 1315 same, so we can use the order of RR in the DNS reply to bias the 1316 selection through native connectivity. If a Well-Known prefix is 1317 used, the longest prefix match rule will select native 1318 connectivity. 1320 So this option introduces problems in the following cases: 1322 An IPv6 network to the IPv4 internet with the NSP prefix 1324 IPv6 to IPv4 in the same network when reaching external 1325 destinations and the NSP prefix is used. 1327 In any case, the problem can be solved by properly configuring the 1328 RFC3484 [RFC3484] policy table, but this requires effort on the part 1329 of the site operator. 1331 Authors' Addresses 1333 Marcelo Bagnulo 1334 UC3M 1335 Av. Universidad 30 1336 Leganes, Madrid 28911 1337 Spain 1339 Phone: +34-91-6249500 1340 Fax: 1341 Email: marcelo@it.uc3m.es 1342 URI: http://www.it.uc3m.es/marcelo 1344 Andrew Sullivan 1345 Shinkuro 1346 4922 Fairmont Avenue, Suite 250 1347 Bethesda, MD 20814 1348 USA 1350 Phone: +1 301 961 3131 1351 Email: ajs@shinkuro.com 1353 Philip Matthews 1354 Unaffiliated 1355 600 March Road 1356 Ottawa, Ontario 1357 Canada 1359 Phone: +1 613-592-4343 x224 1360 Fax: 1361 Email: philip_matthews@magma.ca 1362 URI: 1364 Iljitsch van Beijnum 1365 IMDEA Networks 1366 Av. Universidad 30 1367 Leganes, Madrid 28911 1368 Spain 1370 Phone: +34-91-6246245 1371 Email: iljitsch@muada.com