idnits 2.17.1 draft-ietf-behave-dns64-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 26, 2009) is 5293 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 753, but no explicit reference was found in the text == Unused Reference: 'RFC2672' is defined on line 756, but no explicit reference was found in the text == Unused Reference: 'RFC2765' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-tcp' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-nat-icmp' is defined on line 772, but no explicit reference was found in the text == Unused Reference: 'RFC2766' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'RFC1858' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RFC3128' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC3022' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-ice' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-addr-select-sol' is defined on line 845, but no explicit reference was found in the text == Unused Reference: 'RFC3498' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'I-D.wing-behave-learn-prefix' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'I-D.miyata-behave-prefix64' is defined on line 862, 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.thaler-behave-translator-addressing' -- 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 (-11) exists of draft-iana-rfc3330bis-06 == Outdated reference: A later version (-03) exists of draft-ietf-6man-addr-select-sol-01 == Outdated reference: A later version (-04) exists of draft-wing-behave-learn-prefix-02 == Outdated reference: A later version (-02) exists of draft-venaas-behave-mcast46-00 == Outdated reference: A later version (-15) exists of draft-ietf-dnsop-default-local-zones-08 == Outdated reference: A later version (-06) exists of draft-savolainen-mif-dns-server-selection-00 Summary: 5 errors (**), 0 flaws (~~), 25 warnings (==), 4 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 29, 2010 Shinkuro 6 P. Matthews 7 Alcatel-Lucent 8 I. van Beijnum 9 IMDEA Networks 10 October 26, 2009 12 DNS64: DNS extensions for Network Address Translation from IPv6 Clients 13 to IPv4 Servers 14 draft-ietf-behave-dns64-02 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 29, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 DNS64 is a mechanism for synthesizing AAAA records from A records. 53 DNS64 is used with an IPv6/IPv4 translator to enable client-server 54 communication between an IPv6-only client and an IPv4-only server, 55 without requiring any changes to either the IPv6 or the IPv4 node, 56 for the class of applications that work through NATs. This document 57 specifies DNS64, and provides suggestions on how it should be 58 deployed in conjunction with IPv6/IPv4 translators. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Background to DNS64 - DNSSEC interaction . . . . . . . . . . . 6 65 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 8 67 5.1. Resolving AAAA queries and the answer section . . . . . . 9 68 5.1.1. The answer when there is AAAA data available . . . . . 9 69 5.1.2. The answer when there is an error . . . . . . . . . . 9 70 5.1.3. Special exclusion set for AAAA records . . . . . . . . 9 71 5.1.4. Dealing with CNAME and DNAME . . . . . . . . . . . . . 10 72 5.1.5. Data for the answer when performing synthesis . . . . 10 73 5.1.6. Performing the synthesis . . . . . . . . . . . . . . . 10 74 5.1.7. Querying in parallel . . . . . . . . . . . . . . . . . 11 75 5.2. Generation of the IPv6 representations of IPv4 76 addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5.3. Handling other RRs and the Additional Section . . . . . . 12 78 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 12 79 5.3.2. Handling the additional section . . . . . . . . . . . 13 80 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 14 81 5.4. Assembling a synthesized response to a AAAA query . . . . 14 82 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 14 83 5.6. DNS64 and multihoming . . . . . . . . . . . . . . . . . . 15 84 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 16 86 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 16 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 93 Appendix A. Deployment scenarios and examples . . . . . . . . . . 20 94 A.1. Embed and Zero-Pad algorithm description . . . . . . . . . 21 95 A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in 96 DNS server mode . . . . . . . . . . . . . . . . . . . . . 22 97 A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in 98 stub-resolver mode . . . . . . . . . . . . . . . . . . . . 24 99 A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS 100 server mode . . . . . . . . . . . . . . . . . . . . . . . 25 101 Appendix B. Motivations and Implications of synthesizing AAAA 102 RR when real AAAA RR exists . . . . . . . . . . . . . 27 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 105 1. Introduction 107 This document specifies DNS64, a mechanism that is part of the 108 toolbox for IPv6-IPv4 transition and co-existence. DNS64, used 109 together with an IPv6/IPv4 translator such as NAT64 110 [I-D.bagnulo-behave-nat64], allows an IPv6-only client to initiate 111 communications by name to an IPv4-only server. 113 DNS64 is a mechanism for synthesizing AAAA resource records (RRs) 114 from A RRs. A synthetic AAAA RR created by the DNS64 from an 115 original A RR contains the same FQDN of the original A RR but it 116 contains an IPv6 address instead of an IPv4 address. The IPv6 117 address is an IPv6 representation of the IPv4 address contained in 118 the original A RR. The IPv6 representation of the IPv4 address is 119 algorithmically generated from the IPv4 address returned in the A RR 120 and a set of parameters configured in the DNS64 (typically, an IPv6 121 prefix used by IPv6 representations of IPv4 addresses and optionally 122 other parameters). 124 Together with a IPv6/IPv4 translator, these two mechanisms allow an 125 IPv6-only client to initiate communications to an IPv4-only server 126 using the FQDN of the server. 128 These mechanisms are expected to play a critical role in the IPv4- 129 IPv6 transition and co-existence. Due to IPv4 address depletion, it 130 is likely that in the future, many IPv6-only clients will want to 131 connect to IPv4-only servers. In the typical case, the approach only 132 requires the deployment of IPv6/IPv4 translators that connect an 133 IPv6-only network to an IPv4-only network, along with the deployment 134 of one or more DNS64-enabled name servers. However, some advanced 135 features require performing the DNS64 function directly by the end- 136 hosts themselves. 138 2. Overview 140 This section provides a non-normative introduction to the DNS64 141 mechanism. 143 We assume that we have an IPv6/IPv4 translator box connecting an IPv4 144 network and an IPv6 network. The IPv6/IPv4 translator device 145 provides translation services between the two networks enabling 146 communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By 147 IPv6-only hosts we mean hosts running IPv6-only applications, hosts 148 that can only use IPv6, as well as the cases where only IPv6 149 connectivity is available to the client. By IPv4-only servers we 150 mean servers running IPv4-only applications, servers that can only 151 use IPv4, as well as the cases where only IPv4 connectivity is 152 available to the server). The IPv6/IPv4 translator used in 153 conjunction with DNS64 must allow communications initiated from the 154 IPv6-only host to the IPv4-only host. 156 To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to 157 learn the address of the responder, DNS64 is used to synthesize a 158 AAAA record from an A record containing a real IPv4 address of the 159 responder, whenever the DNS64 service cannot retrieve a AAAA record 160 for the requested host name. The DNS64 device appears as a regular 161 recursive resolver for the IPv6 initiator. The DNS64 box receives an 162 AAAA DNS query generated by the IPv6 initiator. It first attempts a 163 recursive resolution for the requested AAAA records. If there is no 164 AAAA record available for the target node (which is the normal case 165 when the target node is an IPv4-only node), DNS64 performs a query 166 for A records. If any A records are discovered, DNS64 creates a 167 synthetic AAAA RR from the information retrieved in each A RR. 169 The FQDN of a synthetic AAAA RR is the same as that of the original A 170 RR, but an IPv6 representation of the IPv4 address contained in the 171 original A RR is included in the AAAA RR. The IPv6 representation of 172 the IPv4 address is algorithmically generated from the IPv4 address 173 and additional parameters configured in the DNS64. Among those 174 parameters configured in the DNS64, there is at least one IPv6 175 prefix, called Pref64::/n. The IPv6 address representing IPv4 176 addresses included in the AAAA RR synthesized by the DNS64 function 177 contain Pref64::/n and they also embed the original IPv4 address. 179 The same algorithm and the same Pref64::/n prefix or prefixes must be 180 configured both in the DNS64 device and the IPv6/IPv4 translator, so 181 that both can algorithmically generate the same IPv6 representation 182 for a given IPv4 address. In addition, it is required that IPv6 183 packets addressed to an IPv6 destination that contains the Pref64::/n 184 be delivered to the IPv6/IPv4 translator, so they can be translated 185 into IPv4 packets. 187 Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is 188 passed back to the IPv6 initiator, which will initiate an IPv6 189 communication with the IPv6 address associated with the IPv4 190 receiver. The packet will be routed to the IPv6/IPv4 translator 191 which will forward it to the IPv4 network . 193 In general, the only shared state between the DNS64 and the IPv6/IPv4 194 translator is the Pref64::/n and an optional set of static 195 parameters. The Pref64::/n and the set of static parameters must be 196 configured to be the same on both; there is no communication between 197 the DNS64 device and IPv6/IPv4 translator functions. The mechanism 198 to be used for configuring the parameters of the DNS64 is beyond the 199 scope of this memo. 201 The DNS64 function can be performed in two places. 203 One option is to locate the DNS64 function in recursive name 204 servers serving end hosts. In this case, when an IPv6-only host 205 queries the name server for AAAA RRs for an IPv4-only host, the 206 name server can perform the synthesis of AAAA RRs and pass them 207 back to the IPv6 only initiator. The main advantage of this mode 208 is that current IPv6 nodes can use this mechanism without 209 requiring any modification. This mode is called "DNS64 in DNS 210 server mode". 212 The other option is to place the DNS64 function in the end hosts 213 themselves, coupled to the local stub resolver. In this case, the 214 stub resolver will try to obtain (real) AAAA RRs and in case they 215 are not available, the DNS64 function will synthesize AAAA RRs for 216 internal usage. This mode is compatible with some advanced 217 functions like DNSSEC validation in the end host. The main 218 drawback of this mode is its deployability, since it requires 219 changes in the end hosts. This mode is called "DNS64 in stub- 220 resolver mode"". 222 3. Background to DNS64 - DNSSEC interaction 224 DNSSEC presents a special challenge for DNS64, because DNSSEC is 225 designed to detect changes to DNS answers, and DNS64 may alter 226 answers coming from an authoritative server. 228 A recursive resolver can be security-aware or security-oblivious. 229 Moreover, a security-aware recursive name server can be validating or 230 non-validating, according to operator policy. In the cases below, 231 the recursive server is also performing DNS64, and has a local policy 232 to validate. We call this general case vDNS64, but in all the cases 233 below the DNS64 functionality should be assumed needed. 235 DNSSEC includes some signaling bits that offer some indicators of 236 what the query originator understands. 238 If a query arrives at a vDNS64 device with the DO bit set, the query 239 originator is signaling that it understands DNSSEC. The DO bit does 240 not indicate that the query originator will validate the response. 241 It only means that the query originator can understand responses 242 containing DNSSEC data. Conversely, if the DO bit is clear, that is 243 evidence that the querying agent is not aware of DNSSEC. 245 If a query arrives at a vDNS64 device with the CD bit set, it is an 246 indication that the querying agent wants all the validation data so 247 it can do checking itself. By local policy, vDNS64 could still 248 validate, but it must return all data to the querying agent anyway. 250 Here are the possible cases: 252 1. A security-oblivious DNS64 node receives a query with the DO bit 253 clear. In this case, DNSSEC is not a concern, because the 254 querying agent does not understand DNSSEC responses. 256 2. A security-oblivious DNS64 node receives a query with the DO bit 257 set, and the CD bit clear. This is just like the case of a non- 258 DNS64 case: the server doesn't support it, so the querying agent 259 is out of luck. 261 3. A security-aware and non-validating DNS64 node receives a query 262 with the DO bit set and the CD bit clear. Such a resolver is not 263 validating responses, likely due to local policy (see [RFC4035], 264 section 4.2). For that reason, this case amounts to the same as 265 the previous case, and no validation happens. 267 4. A security-aware and non-validating DNS64 node receives a query 268 with the DO bit set and the CD bit set. In this case, the 269 resolver is supposed to pass on all the data it gets to the query 270 initiator (see section 3.2.2 of [RFC4035]). This case will be 271 problematic with DNS64. If the DNS64 server modifies the record, 272 the client will get the data back and try to validate it, and the 273 data will be invalid as far as the client is concerned. 275 5. A security-aware and validating DNS64 node receives a query with 276 the DO bit clear and CD clear. In this case, the resolver 277 validates the data. If it fails, it returns RCODE 2 (SERVFAIL); 278 otherwise, it returns the answer. This is the ideal case for 279 vDNS64. The resolver validates the data, and then synthesizes 280 the new record and passes that to the client. The client, which 281 is presumably not validating (else it would have set DO and CD), 282 cannot tell that DNS64 is involved. 284 6. A security-aware and validating DNS64 node receives a query with 285 the DO bit set and CD clear. In principle, this ought to work 286 like the previous case, except that the resolver should also set 287 the AD bit on the response. 289 7. A security-aware and validating DNS64 node receives a query with 290 the DO bit set and CD set. This is effectively the same as the 291 case where a security-aware and non-validating recursive resolver 292 receives a similar query, and the same thing will happen: the 293 downstream validator will mark the data as invalid if DNS64 has 294 performed synthesis. 296 4. Terminology 298 This section provides definitions for the special terms used in the 299 document. 301 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 302 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 303 document are to be interpreted as described in RFC 2119 [RFC2119]. 305 Authoritative server: A DNS server that can answer authoritatively a 306 given DNS question. 308 DNS64: A logical function that synthesizes DNS resource records (e.g 309 AAAA records containing IPv6 addresses) from DNS resource records 310 actually contained in the global DNS (e.g. A records containing 311 IPv4 addresses). 313 DNS64 recursor: A recursive resolver that provides the DNS64 314 functionality as part of its operation. 316 Recursive resolver: A DNS server that accepts requests from one 317 resolver, and asks another resolver for the answer on behalf of 318 the first resolver. 320 Synthetic RR: A DNS resource record (RR) that is not contained in 321 any zone data file, but has been synthesized from other RRs. An 322 example is a synthetic AAAA record created from an A record. 324 IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 325 packets and vice-versa. It is only required that the 326 communication initiated from the IPv6 side be supported. 328 For a detailed understanding of this document, the reader should also 329 be familiar with DNS terminology from [RFC1034],[RFC1035] and current 330 NAT terminology from [RFC4787]. Some parts of this document assume 331 familiarity with the terminology of the DNS security extensions 332 outlined in [RFC4035]. 334 5. DNS64 Normative Specification 336 A DNS64 is a logical function that synthesizes AAAA records from A 337 records. The DNS64 function may be implemented in a stub resolver, 338 in a recursive resolver, or in an authoritative name server. 340 The implementation SHOULD support mapping of IPv4 address ranges to 341 separate IPv6 prefixes for AAAA record synthesis. This allows 342 handling of special use IPv4 addresses [I-D.iana-rfc3330bis]. 344 Multicast address handling is further specified in 345 [I-D.venaas-behave-mcast46]. 347 5.1. Resolving AAAA queries and the answer section 349 When the DNS64 receives a query for RRs of type AAAA and class IN, it 350 first attempts to retrieve non-synthetic RRs of this type and class, 351 either by performing a query or, in the case of an authoritative 352 server, by examining its own results. 354 5.1.1. The answer when there is AAAA data available 356 If the query results in one or more AAAA records in the answer 357 section, the result is returned to the requesting client as per 358 normal DNS semantics, except in the case where any of the AAAA 359 records match a special exclusion set of prefixes, considered in 360 Section 5.1.3. If there is (non-excluded) AAAA data available, DNS64 361 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix B 362 for an analysis of the motivations for and the implications of not 363 complying with this recommendation). By default DNS64 364 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs 365 exist. 367 5.1.2. The answer when there is an error 369 If the query results in a response with an error code other than 0, 370 the result is handled according to normal DNS operation -- that is, 371 either the resolver tries again using a different server from the 372 authoritative NS RRSet, or it returns the error to the client. This 373 stage is still prior to any synthesis having happened, so a response 374 to be returned to the client does not need any special assembly than 375 would usually happen in DNS operation. 377 5.1.3. Special exclusion set for AAAA records 379 Some IPv6 addresses are not actually usable by IPv6-only hosts. If 380 they are returned to IPv6-only querying agents as AAAA records, 381 therefore, the goal of decreasing the number of failure modes will 382 not be attained. Examples include AAAA records with addresses in the 383 ::ffff/96 network, and possibly (depending on the context) AAAA 384 records with the site's Pref::64/n or the well-known prefix. A DNS64 385 implementation SHOULD provide a mechanism to specify IPv6 prefix 386 ranges to be treated as though the AAAA containing them were an empty 387 answer. An implementation SHOULD include the ::ffff/96 network in 388 that range by default. Failure to provide this facility will mean 389 that clients querying the DNS64 function may not be able to 390 communicate with hosts that would be reachable from a dial-stack 391 host. 393 When the DNS64 performs its initial AAAA query, if it receives an 394 answer with only AAAA records containing addresses in the target 395 range(s), then it MUST treat the answer as though it were an empty 396 answer, and proceed accordingly. If it receives an answer with at 397 least one AAAA record containing an address outside any of the target 398 ranges, then it MAY build an answer section for a response including 399 only the AAAA record(s) that do not contain any of the addresses 400 inside the excluded ranges. That answer section is used in the 401 assembly of a response as detailed in Section 5.4. Alternatively, it 402 MAY treat the answer as though it were an empty answer, and proceed 403 accordingly. It MUST NOT return the offending AAAA records as part 404 of a response. 406 5.1.4. Dealing with CNAME and DNAME 408 If the response contains a CNAME or a DNAME, then the CNAME or DNAME 409 chain is followed until the first terminating A or AAAA record is 410 reached. This may require the DNS64 to ask for an A record, in case 411 the response to the original AAAA query is a CNAME or DNAME without 412 an AAAA record to follow. The resulting AAAA or A record is treated 413 like any other AAAA or A case, as appropriate. 415 When assembling the answer section, the original CNAME or DNAME RR is 416 included as part of the answer, and the synthetic AAAA, if 417 appropriate, is included. 419 5.1.5. Data for the answer when performing synthesis 421 If the query results in no error but an empty answer section in the 422 response, the DNS64 resolver attempts to retrieve A records for the 423 name in question. If this new A RR query results in an empty answer 424 or in an error, then the empty result or error is used as the basis 425 for the answer returned to the querying client. (Transient errors 426 may result in retrying the query, depending on the operation of the 427 resolver; this is just as in Section 5.1.2.) If instead the query 428 results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on 429 the A RRs according to the procedure outlined in Section 5.1.6. The 430 DNS64 resolver then returns the synthesized AAAA records in the 431 answer section to the client, removing the A records that form the 432 basis of the synthesis. 434 5.1.6. Performing the synthesis 436 A synthetic AAAA record is created from an A record as follows: 438 o The NAME field is set to the NAME field from the A record 439 o The TYPE field is set to 28 (AAAA) 441 o The CLASS field is set to 1 (IN) 443 o The TTL field is set to the minimum of the TTL of the original A 444 RR and the SOA RR for the queried domain. (Note that in order to 445 obtain the TTL of the SOA RR the DNS64 does not need to perform a 446 new query, but it can remember the TTL from the SOA RR in the 447 negative response to the AAAA query). 449 o The RDLENGTH field is set to 16 451 o The RDATA field is set to the IPv6 representation of the IPv4 452 address from the RDATA field of the A record. The DNS64 SHOULD 453 check each A RR against IPv4 address ranges and select the 454 corresponding IPv6 prefix to use in synthesizing the AAAA RR. See 455 Section 5.2 for discussion of the algorithms to be used in 456 effecting the transformation. 458 5.1.7. Querying in parallel 460 DNS64 MAY perform the query for the AAAA RR and for the A RR in 461 parallel, in order to minimize the delay. However, this would result 462 in performing unnecessary A RR queries in the case no AAAA RR 463 synthesis is required. A possible trade-off would be to perform them 464 sequentially but with a very short interval between them, so if we 465 obtain a fast reply, we avoid doing the additional query. (Note that 466 this discussion is relevant only if the DNS64 function needs to 467 perform external queries to fetch the RR. If the needed RR 468 information is available locally, as in the case of an authoritative 469 server, the issue is no longer relevant.) 471 5.2. Generation of the IPv6 representations of IPv4 addresses 473 DNS64 supports multiple algorithms for the generation of the IPv6 474 representation of an IPv4 address. The constraints imposed on the 475 generation algorithms are the following: 477 The same algorithm to create an IPv6 address from an IPv4 address 478 MUST be used by both the DNS64 to create the IPv6 address to be 479 returned in the synthetic AAAA RR from the IPv4 address contained 480 in original A RR, and by the IPv6/IPv4 translator to create the 481 IPv6 address to be included in the destination address field of 482 the outgoing IPv6 packets from the IPv4 address included in the 483 destination address field of the incoming IPv4 packet. 485 The algorithm MUST be reversible, i.e. it MUST be possible to 486 extract the original IPv4 address from the IPv6 representation. 488 The input for the algorithm MUST be limited to the IPv4 address, 489 the IPv6 prefix (denoted Pref64::/n) used in the IPv6 490 representations and optionally a set of stable parameters that are 491 configured in the DNS64 (such as fixed string to be used as a 492 suffix). 494 If we note n the length of the prefix Pref64::/n, then n MUST 495 the less or equal than 96. If a Pref64::/n is configured 496 through any means in the DNS64 (such as manually configured, or 497 other automatic mean not specified in this document), the 498 default algorithm MUST use this prefix. If no prefix is 499 available, the algorithm MUST use the Well-Known prefix TBD1 500 defined in [I-D.thaler-behave-translator-addressing] 502 [[anchor9: Note in document: TBD1 in the passage above is to be 503 substituted by whatever prefix is assigned by IANA to be the well- 504 known prefix.]] 506 DNS64 MUST support the following algorithms for generating IPv6 507 representations of IPv4 addresses defined in 508 [I-D.thaler-behave-translator-addressing]: 510 Zero-Pad And Embed, defined in section 3.2.3 of 511 [I-D.thaler-behave-translator-addressing] 513 Compensation-Pad And Embed, defined in section of 3.2.4 of 514 [I-D.thaler-behave-translator-addressing] 516 Embed And Zero-Pad, defined in section of 3.2.5 of 517 [I-D.thaler-behave-translator-addressing] 519 Preconfigured Mapping Table, defined in section of 3.2.6 of 520 [I-D.thaler-behave-translator-addressing] 522 The default algorithm used by DNS64 must be Embed and Zero-Pad. 523 While the normative description of the algorithms is provided in 524 [I-D.thaler-behave-translator-addressing], an sample description of 525 the algorithm and its application to different scenarios is provided 526 in Appendix A for illustration purposes. 528 5.3. Handling other RRs and the Additional Section 530 5.3.1. PTR queries 532 If a DNS64 nameserver receives a PTR query for a record in the 533 IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, 534 reverse the address portion of the QNAME according to the encoding 535 scheme outlined in section 2.5 of [RFC3596] , and examine the 536 resulting address to see whether its prefix matches the locally- 537 configured Pref64::/n. There are two alternatives for a DNS64 538 nameserver to respond to such PTR queries. A DNS64 node MUST provide 539 one of these, and SHOULD NOT provide both at the same time unless 540 different IP6.ARPA zones require answers of different sorts. 542 The first option is for the DNS64 nameserver to respond 543 authoritatively for its prefixes. If the address prefix matches any 544 Pref64::/n used in the site, either a LIR prefix or a well-known 545 prefix used for NAT64 as defined in 546 [I-D.thaler-behave-translator-addressing], then the DNS64 server MAY 547 answer the query using locally-appropriate RDATA. The DNS64 server 548 MAY use the same RDATA for all answers. Note that the requirement is 549 to match any Pref64::/n used at the site, and not merely the locally- 550 configured Pref64::/n. This is because end clients could ask for a 551 PTR record matching an address received through a different (site- 552 provided) DNS64, and if this strategy is in effect, those queries 553 should never be sent to the global DNS. The advantage of this 554 strategy is that it makes plain to the querying client that the 555 prefix is one operated by the DNS64 site, and that the answers the 556 client is getting are generated by the DNS64. The disadvantage is 557 that any useful reverse-tree information that might be in the global 558 DNS is unavailable to the clients querying the DNS64. 560 The second option is for the DNS64 nameserver to synthesize a CNAME 561 mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA 562 name. The rest of the response would be the normal DNS processing. 563 The CNAME can be signed on the fly if need be. The advantage of this 564 approach is that any useful information in the reverse tree is 565 available to the querying client. The disadvantage is that it adds 566 additional load to the DNS64 (because CNAMEs have to be synthesized 567 for each PTR query that matches the Pref64::/n), and that it may 568 require signing on the fly. In addition, the generated CNAME could 569 correspond to an unpopulated in-addr.arpa zone, so the CNAME would 570 provide a reference to a non-existent record. 572 If the address prefix does not match any of the Pref64::/n, then the 573 DNS64 server MUST process the query as though it were any other query 574 -- i.e. a recursive nameserver MUST attempt to resolve the query as 575 though it were any other (non-A/AAAA) query, and an authoritative 576 server MUST respond authoritatively or with a referral, as 577 appropriate. 579 5.3.2. Handling the additional section 581 DNS64 synthesis MUST NOT be performed on any records in the 582 additional section of synthesized answers. The DNS64 MUST pass the 583 additional section unchanged. 585 5.3.3. Other records 587 If the DNS64 is in recursive resolver mode, then it SHOULD also serve 588 the zones specified in [I-D.ietf-dnsop-default-local-zones], rather 589 than forwarding those queries elsewhere to be handled. 591 All other RRs MUST be returned unchanged. 593 5.4. Assembling a synthesized response to a AAAA query 595 The DNS64 uses different pieces of data to build the response 596 returned to the querying client. 598 The query that is used as the basis for synthesis results either in 599 an error, an answer that can be used as a basis for synthesis, or an 600 empty (authoritative) answer. If there is an empty answer, then the 601 DNS64 responds to the original querying client with the answer the 602 DNS64 received to the original AAAA query. Otherwise, the response 603 is assembled as follows. 605 The header fields are set according to the usual rules for recursive 606 or authoritative servers, depending on the role that the DNS64 is 607 serving. The question section is copied from the original AAAA 608 query. The answer section is populated according to the rules in 609 Section 5.1.6. The authority and additional sections are copied from 610 the response to the A query that the DNS64 performed. 612 5.5. DNSSEC processing: DNS64 in recursive server mode 614 We consider the case where the recursive server that is performing 615 DNS64 also has a local policy to validate the answers according to 616 the procedures outlined in [RFC4035] Section 5. We call this general 617 case vDNS64. 619 The vDNS64 uses the presence of the DO and CD bits to make some 620 decisions about what the query originator needs, and can react 621 accordingly: 623 1. If CD is not set and DO is not set, vDNS64 SHOULD perform 624 validation and do synthesis as needed. 626 2. If CD is not set and DO is set, then vDNS64 SHOULD perform 627 validation. Whenever vDNS64 performs validation, it MUST 628 validate the negative answer for AAAA queries before proceeding 629 to query for A records for the same name, in order to be sure 630 that there is not a legitimate AAAA record on the Internet. 631 Failing to observe this step would allow an attacker to use DNS64 632 as a mechanism to circumvent DNSSEC. If the negative response 633 validates, and the response to the A query validates, then the 634 vDNS64 MAY perform synthesis and SHOULD set the AD bit in the 635 answer to the client. This is acceptable, because [RFC4035], 636 section 3.2.3 says that the AD bit is set by the name server side 637 of a security-aware recursive name server if and only if it 638 considers all the RRSets in the Answer and Authority sections to 639 be authentic. In this case, the name server has reason to 640 believe the RRSets are all authentic, so it SHOULD set the AD 641 bit. If the data does not validate, the vDNS64 MUST respond with 642 RCODE=2 (server failure). 643 A security-aware end point might take the presence of the AD bit 644 as an indication that the data is valid, and may pass the DNS 645 (and DNSSEC) data to an application. If the application attempts 646 to validate the synthesized data, of course, the validation will 647 fail. One could argue therefore that this approach is not 648 desirable. But security aware stub resolvers MUST NOT place any 649 reliance on data received from resolvers and validated on their 650 behalf without certain criteria established by [RFC4035], section 651 4.9.3. An application that wants to perform validation on its 652 own should use the CD bit. 654 3. If the CD bit is set and DO is set, then vDNS64 MAY perform 655 validation, but MUST NOT perform synthesis. It MUST hand the 656 data back to the query initiator, just like a regular recursive 657 resolver, and depend on the client to do the validation and the 658 synthesis itself. 659 The disadvantage to this approach is that an end point that is 660 translation-oblivious but security-aware and validating will not 661 be able to use the DNS64 functionality. In this case, the end 662 point will not have the desired benefit of NAT64. In effect, 663 this strategy means that any end point that wishes to do 664 validation in a NAT64 context must be upgraded to be translation- 665 aware as well. 667 5.6. DNS64 and multihoming 669 Synthetic AAAA records may be constructed on the basis of the network 670 context in which they were constructed. Therefore, a synthetic AAAA 671 received from one interface MUST NOT be used to resolve hosts via 672 another network interface. Because it will be hard (if not 673 impossible) for a multihomed system to tell whether a given AAAA is 674 synthetic, a host SHOULD treat any AAAA record received on a given 675 interface as local to that interface; the alternative risks 676 communication failures when the AAAA is used to communicate on 677 another interface. See the discussion in 678 [I-D.savolainen-mif-dns-server-selection]. 680 6. Deployment notes 682 While DNS64 is intended to be part of a strategy for aiding IPv6 683 deployment in an internetworking environment with some IPv4-only and 684 IPv6-only networks, it is important to realise that it is 685 incompatible with some things that may be deployed in an IPv4-only or 686 dual-stack context. 688 6.1. DNS resolvers and DNS64 690 Full-service resolvers that are unaware of the DNS64 function can be 691 (mis)configured to act as mixed-mode iterative and forwarding 692 resolvers. In a native-IPv4 context, this sort of configuration may 693 appear to work. It is impossible to make it work properly without it 694 being aware of the DNS64 function, because it will likely at some 695 point obtain IPv4-only glue records and attempt to use them for 696 resolution. The result that is returned will contain only A records, 697 and without the ability to perform the DNS64 function the resolver 698 will simply be unable to answer the necessary AAAA queries. 700 6.2. DNSSEC validators and DNS64 702 Existing DNSSEC validators (i.e. that are unaware of DNS64) will 703 reject all the data that comes from the DNS64 as having been tampered 704 with. If it is necessary to have validation behind the DNS64, then 705 the validator must know how to perform the DNS64 function itself. 706 Alternatively, the validating host may establish a trusted connection 707 with the DNS64, and allow the DNS64 to do all validation on its 708 behalf. 710 7. Security Considerations 712 See the discussion on the usage of DNSSEC and DNS64 described in the 713 document. 715 8. Contributors 717 Dave Thaler 719 Microsoft 721 dthaler@windows.microsoft.com 723 9. Acknowledgements 725 This draft contains the result of discussions involving many people, 726 including the participants of the IETF BEHAVE Working Group. The 727 following IETF participants made specific contributions to parts of 728 the text, and their help is gratefully acknowledged: Mark Andrews, 729 Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet, 730 Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed 731 Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs 732 Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki 733 Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund, 734 Florian Weimer, Dan Wing, Xu Xiaohu. 736 Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by 737 Trilogy, a research project supported by the European Commission 738 under its Seventh Framework Program. 740 10. References 742 10.1. Normative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, March 1997. 747 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 748 STD 13, RFC 1034, November 1987. 750 [RFC1035] Mockapetris, P., "Domain names - implementation and 751 specification", STD 13, RFC 1035, November 1987. 753 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 754 RFC 2671, August 1999. 756 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 757 RFC 2672, August 1999. 759 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 760 (SIIT)", RFC 2765, February 2000. 762 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 763 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 764 RFC 4787, January 2007. 766 [I-D.ietf-behave-tcp] 767 Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 768 Srisuresh, "NAT Behavioral Requirements for TCP", 769 draft-ietf-behave-tcp-08 (work in progress), 770 September 2008. 772 [I-D.ietf-behave-nat-icmp] 773 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 774 Behavioral Requirements for ICMP protocol", 775 draft-ietf-behave-nat-icmp-12 (work in progress), 776 January 2009. 778 [I-D.thaler-behave-translator-addressing] 779 Thaler, D., "IPv6 Addressing of IPv6/IPv4 Translators", 780 draft-thaler-behave-translator-addressing-00 (work in 781 progress), July 2009. 783 10.2. Informative References 785 [I-D.bagnulo-behave-nat64] 786 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 787 Address and Protocol Translation from IPv6 Clients to IPv4 788 Servers", draft-bagnulo-behave-nat64-03 (work in 789 progress), March 2009. 791 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 792 Translation - Protocol Translation (NAT-PT)", RFC 2766, 793 February 2000. 795 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 796 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 797 RFC 2136, April 1997. 799 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 800 Considerations for IP Fragment Filtering", RFC 1858, 801 October 1995. 803 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 804 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 806 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 807 Address Translator (Traditional NAT)", RFC 3022, 808 January 2001. 810 [RFC3484] Draves, R., "Default Address Selection for Internet 811 Protocol version 6 (IPv6)", RFC 3484, February 2003. 813 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 814 "DNS Extensions to Support IP Version 6", RFC 3596, 815 October 2003. 817 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 819 Rose, "DNS Security Introduction and Requirements", 820 RFC 4033, March 2005. 822 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 823 Rose, "Resource Records for the DNS Security Extensions", 824 RFC 4034, March 2005. 826 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 827 Rose, "Protocol Modifications for the DNS Security 828 Extensions", RFC 4035, March 2005. 830 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 831 Address Translator - Protocol Translator (NAT-PT) to 832 Historic Status", RFC 4966, July 2007. 834 [I-D.iana-rfc3330bis] 835 Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 836 draft-iana-rfc3330bis-06 (work in progress), 837 February 2009. 839 [I-D.ietf-mmusic-ice] 840 Rosenberg, J., "Interactive Connectivity Establishment 841 (ICE): A Protocol for Network Address Translator (NAT) 842 Traversal for Offer/Answer Protocols", 843 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 845 [I-D.ietf-6man-addr-select-sol] 846 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 847 "Solution approaches for address-selection problems", 848 draft-ietf-6man-addr-select-sol-01 (work in progress), 849 June 2008. 851 [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of 852 Managed Objects for Synchronous Optical Network (SONET) 853 Linear Automatic Protection Switching (APS) 854 Architectures", RFC 3498, March 2003. 856 [I-D.wing-behave-learn-prefix] 857 Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix 858 of an IPv6/IPv4 Translator", 859 draft-wing-behave-learn-prefix-02 (work in progress), 860 May 2009. 862 [I-D.miyata-behave-prefix64] 863 Miyata, H. and M. Bagnulo, "PREFIX64 Comparison", 864 draft-miyata-behave-prefix64-02 (work in progress), 865 March 2009. 867 [I-D.venaas-behave-mcast46] 868 Venaas, S., "An IPv4 - IPv6 multicast translator", 869 draft-venaas-behave-mcast46-00 (work in progress), 870 December 2008. 872 [I-D.ietf-dnsop-default-local-zones] 873 Andrews, M., "Locally-served DNS Zones", 874 draft-ietf-dnsop-default-local-zones-08 (work in 875 progress), February 2009. 877 [I-D.savolainen-mif-dns-server-selection] 878 Savolainen, T., "DNS Server Selection on Multi-Homed 879 Hosts", draft-savolainen-mif-dns-server-selection-00 (work 880 in progress), February 2009. 882 Appendix A. Deployment scenarios and examples 884 In this section, we first provide a description of the default 885 address transformation algorithm and then we walk through some sample 886 scenarios that are expected to be common deployment cases. It should 887 be noted that is provided for illustrative purposes and this section 888 is not normative. The normative definition of DNS64 is provided in 889 Section 5 and the normative definition of the address transformation 890 algorithm is provided in [I-D.thaler-behave-translator-addressing]. 892 There are two main different setups where DNS64 is expected to be 893 used (other setups are possible as well, but these two are the main 894 ones identified at the time of this writing). 896 One possible setup that is expected to be common is the case of an 897 end site or an ISP that is providing IPv6-only connectivity or 898 connectivity to IPv6-only hosts that wants to allow the 899 communication from these IPv6-only connected hosts to the IPv4 900 Internet. This case is called An-IPv6-network-to-IPv4-Internet. 901 In this case, the IPv6/IPv4 Translator is used to connect the end 902 site or the ISP to the IPv4 Internet and the DNS64 function is 903 provided by the end site or the ISP. 905 The other possible setup that is expected is an IPv4 site that 906 wants that its IPv4 servers to be reachable from the IPv6 907 Internet. This case is called IPv6-Internet-to-an-IPv4-network. 908 It should be noted that the IPv4 addresses used in the IPv4 site 909 can be either public or private. In this case, the IPv6/IPv4 910 Translator is used to connect the IPv4 end site to the IPv6 911 Internet and the DNS64 function is provided by the end site 912 itself. 914 In this section we illustrate how the DNS64 behaves in the different 915 scenarios that are expected to be common. We consider then 3 916 possible scenarios, namely: 918 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server 919 mode 921 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- 922 resolver mode 924 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server 925 mode 927 The notation used is the following: upper case letters are IPv4 928 addresses; upper case letters with a prime(') are IPv6 addresses; 929 lower case letters are ports; prefixes are indicated by "P::X", which 930 is an IPv6 address built from an IPv4 address X by adding the prefix 931 P, mappings are indicated as "(X,x) <--> (Y',y)". 933 A.1. Embed and Zero-Pad algorithm description 935 In this section we describe the default algorithm for the generation 936 of IPv6 address from IPv4 address to be implemented in the DNS64. 938 The only parameter required by the default algorithm is an IPv6 939 prefix. This prefix is used to map IPv4 addresses into IPv6 940 addresses, and is denoted Pref64. If we note n the length of the 941 prefix Pref64, then n must the less or equal than 96. If an Pref64 942 is configured through any means in the DNS64 (such as manually 943 configured, or other automatic mean not specified in this document), 944 the default algorithm must use this prefix. If no prefix is 945 available the algorithm must use the Well-Know prefix (include here 946 the prefix to be assigned by IANA) defined in 947 [I-D.thaler-behave-translator-addressing] 949 The input for the algorithm are: 951 The IPv4 address: X 953 The IPv6 prefix: Pref64::/n 955 The IPv6 address is generated by concatenating the prefix Pref64::/n, 956 the IPv4 address X and optionally (in case n is strictly smaller than 957 96) an all-zero suffix. So, the resulting IPv6 address would be 958 Pref64:X:: 960 Reverse algorithm 961 We next describe the reverse algorithm of the algorithm described in 962 the previous section. This algorithm allows to generate and IPv4 963 address from an IPv6 address. This reverse algorithm is NOT 964 implemented by the DNS64 but it is implemented in the IPv6/IPv4 965 translator that is serving the same domain the DNS64. 967 The only parameter required by the default algorithm is an IPv6 968 prefix. This prefix is the one originally used to map IPv4 addresses 969 into IPv6 addresses, and is denoted Pref64. 971 The input for the algorithm are: 973 The IPv6 address: X' 975 The IPv6 prefix: Pref64::/n 977 First, the algorithm checks that the fist n bits of the IPv6 address 978 X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n = 979 X'/n. 981 If this is not the case, the algorithm ends and no IPv4 address is 982 generated. 984 If the verification is successful, then the bits between the n+1 985 and the n+32 of the IPv6 address X' are extracted to form the IPv4 986 address. 988 A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server 989 mode 991 In this example, we consider an IPv6 node located in an IPv6-only 992 site that initiates a communication to an IPv4 node located in the 993 IPv4 Internet. 995 The scenario for this case is depicted in the following figure: 997 +---------------------------------------+ +-----------+ 998 |IPv6 site +-------------+ |IP Addr: | | 999 | +----+ | Name server | +-------+ T | IPv4 | 1000 | | H1 | | with DNS64 | |64Trans|------| Internet | 1001 | +----+ +-------------+ +-------+ +-----------+ 1002 | |IP addr: Y' | | | |IP addr: X 1003 | --------------------------------- | +----+ 1004 +---------------------------------------+ | H2 | 1005 +----+ 1007 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an 1008 IPv4 node H2 with IPv4 address X. 1010 A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 1011 Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n) 1012 an IPv4 address T assigned to its IPv4 interface. 1014 The other element involved is the local name server. The name server 1015 is a dual-stack node, so that H1 can contact it via IPv6, while it 1016 can contact IPv4-only name servers via IPv4. 1018 The local name server needs to know the prefix assigned to the local 1019 IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example, 1020 we assume it learns this through manual configuration. 1022 For this example, assume the typical DNS situation where IPv6 hosts 1023 have only stub resolvers, and always query a name server that 1024 performs recursive lookups (henceforth called "the recursive 1025 nameserver"). 1027 The steps by which H1 establishes communication with H2 are: 1029 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS 1030 query for an AAAA record for H2 to the recursive name server. 1031 The recursive name server implements DNS64 functionality. 1033 2. The recursive name server resolves the query, and discovers that 1034 there are no AAAA records for H2. 1036 3. The recursive name server queries for an A record for H2 and gets 1037 back an A record containing the IPv4 address X. The name server 1038 then synthesizes an AAAA record. The IPv6 address in the AAAA 1039 record contains the prefix assigned to the IPv6/IPv4 Translator 1040 in the upper n bits then the IPv4 address X and then an all-zero 1041 padding i.e. the resulting IPv6 address is Pref64:X:: 1043 4. H1 receives the synthetic AAAA record and sends a packet towards 1044 H2. The packet is sent from a source transport address of (Y',y) 1045 to a destination transport address of (Pref64:X::,x), where y and 1046 x are ports chosen by H2. 1048 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 1049 Translator and the subsequent communication flows by means of the 1050 IPv6/IPv4 Translator mechanisms. 1052 A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver 1053 mode 1055 The scenario for this case is depicted in the following figure: 1057 +---------------------------------------+ +-----------+ 1058 |IPv6 site +-------+ |IP addr: | | 1059 | +---------------+ | Name | +-------+ T | IPv4 | 1060 | | H1 with DNS64 | | Server| |64Trans|------| Internet | 1061 | +---------------+ +-------+ +-------+ +-----------+ 1062 | |IP addr: Y' | | | |IP addr: X 1063 | --------------------------------- | +----+ 1064 +---------------------------------------+ | H2 | 1065 +----+ 1067 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an 1068 IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64 1069 function. 1071 A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 1072 Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n) 1073 and an IPv4 address T assigned to its IPv4 interface. 1075 H1 needs to know the prefix assigned to the local IPv6/IPv4 1076 Translator (Pref64::/n). For the purpose of this example, we assume 1077 it learns this through manual configuration. 1079 Also shown is a name server. For the purpose of this example, we 1080 assume that the name server is a dual-stack node, so that H1 can 1081 contact it via IPv6, while it can contact IPv4-only name servers via 1082 IPv4. 1084 For this example, assume the typical situation where IPv6 hosts have 1085 only stub resolvers and always query a name server that provides 1086 recursive lookups (henceforth called "the recursive name server"). 1087 The recursive name server does not perform the DNS64 function. 1089 The steps by which H1 establishes communication with H2 are: 1091 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS 1092 query for a AAAA record for H2 to the recursive name server. 1094 2. The recursive DNS server resolves the query, and returns the 1095 answer to H1. Because there are no AAAA records in the global 1096 DNS for H2, the answer is empty. 1098 3. The stub resolver at H1 then queries for an A record for H2 and 1099 gets back an A record containing the IPv4 address X. The DNS64 1100 function within H1 then synthesizes a AAAA record. The IPv6 1101 address in the AAAA record contains the prefix assigned to the 1102 IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X 1103 and then an all-zero padding i.e. the resulting IPv6 address is 1104 Pref64:X::. 1106 4. H1 sends a packet towards H2. The packet is sent from a source 1107 transport address of (Y',y) to a destination transport address of 1108 (Pref64:X::,x), where y and x are ports chosen by H2. 1110 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 1111 Translator and the subsequent communication flows using the IPv6/ 1112 IPv4 Translator mechanisms. 1114 A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode 1116 In this example, we consider an IPv6 node located in the IPv6 1117 Internet site that initiates a communication to a IPv4 node located 1118 in the IPv4 site. 1120 This scenario can be addressed without using any form of DNS64 1121 function. This is so because it is possible to assign a fixed IPv6 1122 address to each of the IPv4 servers. Such an IPv6 address would be 1123 constructed as the Pref64::/n concatenated with the IPv4 address of 1124 the IPv4 server and an all-zero padding. Note that the IPv4 address 1125 can be a public or a private address; the latter does not present any 1126 additional difficulty, since the LIR prefix must be used a Pref64 (in 1127 this scenario the usage of the WK prefix is not supported). Once 1128 these IPv6 addresses have been assigned to represent the IPv4 servers 1129 in the IPv6 Internet, real AAAA RRs containing these addresses can be 1130 published in the DNS under the site's domain. This is the 1131 recommended approach to handle this scenario, because it does not 1132 involve synthesizing AAAA records at the time of query. Such a 1133 configuration is easier to troubleshoot in the event of problems, 1134 because it always provides the same answer to every query. 1136 However, there are some more dynamic scenarios, where synthesizing 1137 AAAA RRs in this setup may be needed. In particular, when DNS Update 1138 [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 1139 servers, there are two options: One option is to modify the server 1140 that receives the dynamic DNS updates. That would normally be the 1141 authoritative server for the zone. So the authoritative zone would 1142 have normal AAAA RRs that are synthesized as dynamic updates occur. 1143 The other option is modify the authoritative server to generate 1144 synthetic AAAA records for a zone, possibly based on additional 1145 constraints, upon the receipt of a DNS query for the AAAA RR. The 1146 first option -- in which the AAAA is synthesized when the DNS update 1147 message is received, and the data published in the relevant zone -- 1148 is recommended over the second option (i.e. the synthesis upon 1149 receipt of the AAAA DNS query). This is because it is usually easier 1150 to solve problems of misconfiguration and so on when the DNS 1151 responses are not being generated dynamically. For completeness, the 1152 DNS64 behavior that we describe in this section covers the case of 1153 synthesizing the AAAA RR when the DNS query arrives. Nevertheless, 1154 such a configuration is NOT RECOMMENDED. Troubleshooting 1155 configurations that change the data depending on the query they 1156 receive is notoriously hard, and the IPv4/IPv6 translation scenario 1157 is complicated enough without adding additional opportunities for 1158 possible malfunction. 1160 The scenario for this case is depicted in the following figure: 1162 +-----------+ +----------------------------------------+ 1163 | | | IPv4 site +-------------+ | 1164 | IPv6 | +-------+ +----+ | Name server | | 1165 | Internet |------|64Trans| | H2 | | with DNS64 | | 1166 +-----------+ +-------+ +----+ +-------------+ | 1167 |IP addr: Y' | | |IP addr: X | | 1168 +----+ | ----------------------------------- | 1169 | H1 | +----------------------------------------+ 1170 +----+ 1172 The figure shows an IPv6 node H1 which has an IPv6 address Y' and an 1173 IPv4 node H2 with IPv4 address X. 1175 A IPv6/IPv4 Translator connects the IPv4 network to the IPv6 1176 Internet. This IPv6/IPv4 Translator has a prefix (called 1177 Pref64::/n). 1179 Also shown is the authoritative name server for the local domain with 1180 DNS64 functionality. For the purpose of this example, we assume that 1181 the name server is a dual-stack node, so that H1 or a recursive 1182 resolver acting on the request of H1 can contact it via IPv6, while 1183 it can be contacted by IPv4-only nodes to receive dynamic DNS updates 1184 via IPv4. 1186 The local name server needs to know the prefix assigned to the local 1187 IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example, 1188 we assume it learns this through manual configuration. 1190 The steps by which H1 establishes communication with H2 are: 1192 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS 1193 query for an AAAA record for H2. The query is eventually 1194 forwarded to the server in the IPv4 site. 1196 2. The local DNS server resolves the query (locally), and discovers 1197 that there are no AAAA records for H2. 1199 3. The name server verifies that FQDN(H2) and its A RR are among 1200 those that the local policy defines as allowed to generate a AAAA 1201 RR from. If that is the case, the name server synthesizes an 1202 AAAA record from the A RR and the relevant Pref64::/n. The IPv6 1203 address in the AAAA record contains the prefix assigned to the 1204 IPv6/IPv4 Translator in the first n bits and the IPv4 address X 1205 and then an all-zero padding. 1207 4. H1 receives the synthetic AAAA record and sends a packet towards 1208 H2. The packet is sent from a source transport address of (Y',y) 1209 to a destination transport address of (Pref64:X::,x), where y and 1210 x are ports chosen by H2. 1212 5. The packet is routed through the IPv6 Internet to the IPv6 1213 interface of the IPv6/IPv4 Translator and the communication flows 1214 using the IPv6/IPv4 Translator mechanisms. 1216 Appendix B. Motivations and Implications of synthesizing AAAA RR when 1217 real AAAA RR exists 1219 The motivation for synthesizing AAAA RR when a real AAAA RR exists is 1220 to support the following scenario: 1222 An IPv4-only server application (e.g. web server software) is 1223 running on a dual-stack host. There may also be dual-stack server 1224 applications also running on the same host. That host has fully 1225 routable IPv4 and IPv6 addresses and hence the authoritative DNS 1226 server has an A and a AAAA record as a result. 1228 An IPv6-only client (regardless of whether the client application 1229 is IPv6-only, the client stack is IPv6-only, or it only has an 1230 IPv6 address) wants to access the above server. 1232 The client issues a DNS query to a DNS64 recursor. 1234 If the DNS64 only generates a synthetic AAAA if there's no real AAAA, 1235 then the communication will fail. Even though there's a real AAAA, 1236 the only way for communication to succeed is with the translated 1237 address. So, in order to support this scenario, the administrator of 1238 a DNS64 service may want to enable the synthesis of AAAA RR even when 1239 real AAAA RR exist. 1241 The implication of including synthetic AAAA RR when real AAAA RR 1242 exist is that translated connectivity may be preferred over native 1243 connectivity in some cases where the DNS64 is operated in DNS server 1244 mode. 1246 RFC3484 [RFC3484] rules use longest prefix match to select which is 1247 the preferred destination address to use. So, if the DNS64 recursor 1248 returns both the synthetic AAAA RR and the real AAAA RR, then if the 1249 DNS64 is operated by the same domain as the initiating host, and a 1250 global unicast prefix (called the LIR prefix as defined in 1251 [I-D.thaler-behave-translator-addressing]) is used, then the 1252 synthetic AAAA RR is likely to be preferred. 1254 This means that without further configuration: 1256 In the case of An IPv6 network to the IPv4 internet, the host will 1257 prefer translated connectivity if LIR prefix is used. If the 1258 Well-Known (WK) prefix defined in 1259 [I-D.thaler-behave-translator-addressing] is used, it will 1260 probably prefer native connectivity. 1262 In the case of the IPv6 Internet to an IPv4 network, it is 1263 possible to bias the selection towards the real AAAA RR if the 1264 DNS64 recursor returns the real AAAA first in the DNS reply, when 1265 the LIR prefix is used (the WK prefix usage is not recommended in 1266 this case) 1268 In the case of the IPv6 to IPv4 in the same network, for local 1269 destinations (i.e., target hosts inside the local site), it is 1270 likely that the LIR prefix and the destination prefix are the 1271 same, so we can use the order of RR in the DNS reply to bias the 1272 selection through native connectivity. If a WK prefix is used, 1273 the longest prefix match rule will select native connectivity. 1275 So this option introduces problems in the following cases: 1277 An IPv6 network to the IPv4 internet with the LIR prefix 1278 IPv6 to IPv4 in the same network when reaching external 1279 destinations and the LIR prefix is used. 1281 In any case, the problem can be solved by properly configuring the 1282 RFC3484 [RFC3484] policy table, but this requires effort on the part 1283 of the site operator. 1285 Authors' Addresses 1287 Marcelo Bagnulo 1288 UC3M 1289 Av. Universidad 30 1290 Leganes, Madrid 28911 1291 Spain 1293 Phone: +34-91-6249500 1294 Fax: 1295 Email: marcelo@it.uc3m.es 1296 URI: http://www.it.uc3m.es/marcelo 1298 Andrew Sullivan 1299 Shinkuro 1300 4922 Fairmont Avenue, Suite 250 1301 Bethesda, MD 20814 1302 USA 1304 Phone: +1 301 961 3131 1305 Email: ajs@shinkuro.com 1307 Philip Matthews 1308 Unaffiliated 1309 600 March Road 1310 Ottawa, Ontario 1311 Canada 1313 Phone: +1 613-592-4343 x224 1314 Fax: 1315 Email: philip_matthews@magma.ca 1316 URI: 1318 Iljitsch van Beijnum 1319 IMDEA Networks 1320 Av. Universidad 30 1321 Leganes, Madrid 28911 1322 Spain 1324 Phone: +34-91-6246245 1325 Email: iljitsch@muada.com