idnits 2.17.00 (12 Aug 2021) /tmp/idnits38913/draft-boucadair-behave-dns-a64-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: But during a transition phase, some hosts with IPv6-only connectivity may not be updated to perform A64 queries. Specific IPv6 DNS servers, called DNS64 recursors, may be used to serve those hosts. A DNS64 recursor may return an A64 record as a response to AAAA query if no AAAA record is available for the specified resource (A64 records are converted to AAAA records in the answer). This behaviour advocates for enhancing the chance for a communication to be established even through a translator). DNS64 recursors SHOULD not be used by dual-stack hosts which do not support A64 query type. When A64 query type is received, only A64 record type MUST be returned. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 7, 2010) is 4267 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: 'RFC1034' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 585, but no explicit reference was found in the text == Outdated reference: draft-ietf-behave-address-format has been published as RFC 6052 == Outdated reference: draft-ietf-behave-dns64 has been published as RFC 6147 == Outdated reference: draft-ietf-behave-v6v4-xlate has been published as RFC 6145 == Outdated reference: draft-ietf-behave-v6v4-xlate-stateful has been published as RFC 6146 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track E. Burgey 5 Expires: March 11, 2011 Orange Labs 6 September 7, 2010 8 A64: DNS Resource Record for IPv4-Embedded IPv6 Address 9 draft-boucadair-behave-dns-a64-02 11 Abstract 13 In the context of IPv4-IPv6 interconnection (or interworking), 14 several solutions have been proposed within IETF. Some of these 15 solutions require the definition of a new IPv4-Embedded IPv6 address 16 which is used to represent an IPv4-only host in an IPv6 realms and 17 the definition of a new mechanism called DNS64 for synthesizing a 18 AAAA record, representing an IPv4-Embedded IPv6 address in the DNS 19 system, from the A record representing the IPv4 address of the IPv4- 20 only host . This IPv4-Embedded IPv6 address, when managed by a 21 translator, is to be considered as "fake" address in a DNS system 22 since it is not necessarily assigned to any host's interface 23 qualified by the associated name. 25 This document defines a new DNS record type and query type to 26 identify IPv4-Embedded IPv6 address from native IPv6 ones. The new 27 record type and query type aim at helping the requesting party to 28 enforce its policies and avoid crossing NAT64 boxes when possible. 29 Native addresses are to be preferred. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 11, 2011. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 4 85 1.2. Contribution of this Draft . . . . . . . . . . . . . . . . 4 86 1.3. Backward Compatibility Issue . . . . . . . . . . . . . . . 5 87 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 3. Q/A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 89 3.1. Why a new RRType is Required? . . . . . . . . . . . . . . 7 90 3.2. Do We Need to Update all DNS Servers to Support this 91 New RRType? . . . . . . . . . . . . . . . . . . . . . . . 8 92 3.3. Does the Proposal Need Hosts to be Upgraded All? . . . . . 9 93 3.4. What is the Impact on the DNS Server Load? . . . . . . . . 10 94 3.5. Are legacy Hosts Impacted? . . . . . . . . . . . . . . . . 10 95 3.6. Location of Recursors . . . . . . . . . . . . . . . . . . 11 96 3.7. How an A64-compliant Host Can Discover an A64-DNS 97 Server? . . . . . . . . . . . . . . . . . . . . . . . . . 11 98 4. IPv4-Embedded IPv6 Record: A64 . . . . . . . . . . . . . . . . 12 99 4.1. A64 Record Type . . . . . . . . . . . . . . . . . . . . . 12 100 4.2. A64 Data Format . . . . . . . . . . . . . . . . . . . . . 12 101 4.3. A64 Query . . . . . . . . . . . . . . . . . . . . . . . . 12 102 4.4. Textual format of A64 records . . . . . . . . . . . . . . 12 103 4.5. IP64.INT Domain . . . . . . . . . . . . . . . . . . . . . 12 104 4.6. Modifications to Existing Query Types . . . . . . . . . . 12 105 4.7. On the Need of a New Query type . . . . . . . . . . . . . 13 106 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 107 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 110 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 111 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 114 1. Introduction 116 1.1. Overall Context 118 Due to IPv4 address depletion, several solutions have been proposed 119 within IETF. Among those solutions, IPv6 is the only perennial 120 solution that should be implemented by service providers. 121 Nevertheless, this implementation won't be in one shot and the co- 122 existence between IPv4 and IPv6 should be managed for a while. In 123 addition to the co-existence issue, interconnection means to enable 124 successful communications between IPv4 and IPv6 realms must be 125 enforced. 127 In this context, BEHAVE WG is currently specifying translator 128 mechanisms which cover both stateful 129 [I-D.ietf-behave-v6v4-xlate-stateful] and stateless 130 [I-D.ietf-behave-v6v4-xlate] modes. The proposed solutions require 131 the definition of a new IPv4-Embedded IPv6 address 132 [I-D.ietf-behave-address-format] which is used to represent an IPv4- 133 only host in an IPv6 realm. This type of addresses, when managed by 134 a translator, is to be considered as "fake" address since it is not 135 assigned to any host and can be confusing for the application. The 136 application querying for this address must be aware that the 137 application running on the host represented by the IPv4-Embedded IPv6 138 address is connected through an IPv4 interface and may be not able to 139 use a reference (e.g., [I-D.carpenter-behave-referral-object]) to an 140 IPv6 address in the packet payload. 142 When an IPv4-Embedded IPv6 address is used as destination address, 143 the traffic will be handled by a translator device and no direct 144 communication would be possible. 146 1.2. Contribution of this Draft 148 The aforementioned "fake" addresses should not be confused with 149 native IPv6 addresses in order to ease the enforcement of means to 150 avoid translators whenever possible. Notifying to the requesting 151 host that the resolved address is not a native address but an IPv4- 152 Embedded IPv6 address (which is behind a NAT) would ease the local 153 policies to prefer direct communications (i.e., avoid using IPv4- 154 mapped IPv6 addresses when a native IPv6 address or a native IPv4 155 address is available ). 157 For the sake of maintaining the reliability of the information 158 maintained and sent by DNS and helping a given host to enforce 159 policies to prefer native communications, a new record type is 160 proposed (A64). This record type stores only IPv4-Embedded IPv6 161 addresses. A new query type A64 is also defined to request A64 162 records or synthesised A64 records. 164 This document does not make any assumption about the use of WKP or 165 LIR IPv6 prefix to build IPv4-Embedded IPv6 addresses. Both schemes 166 are supported. 168 1.3. Backward Compatibility Issue 170 The A64 record proposal suffers from DNS backward compatibility 171 issue. This issue is to be positioned in the following context: 173 o We are still in the early stages of IPv6 deployment and solutions 174 to help smooth migration and ease the transition to full IPv6 175 should be encouraged; 177 o IPv4-Embedded IPv6 addresses will be used in various architecture 178 configurations and guidelines for the use of these addresses to 179 populate DNS servers should be elaborated. This document is a 180 contribution to this effort; 182 o DNS64 proposal as defined in [I-D.ietf-behave-dns64] may be used 183 for serving dual-stack hosts (e.g., context of multi-homing. The 184 device may be attached to distinct domains managed by distinct 185 administrative entities. Means to ease the merging and the 186 consistency of the received information should be implemented, see 187 MIF WG problem statement). DNS servers do not have any means to 188 restrict the use of the service based on the requesting 189 connectivity capabilities. Appropriate solutions are to be put at 190 disposal of the client; 192 o [I-D.ietf-behave-dns64] does not define how to configure static 193 records using IPv4-Embedded IPv6 addresses; 195 o Not all DNS servers are to be upgraded. Only a subset of DNS 196 servers may be updated to support the A64 records. 198 o A procedure for the discovery of these A64-capable DNS servers is 199 described in [I-D.boucadair-behave-dns64-discovery]. When 200 supported, only the appropriate DNS servers will be invoked. 202 o In some contexts, referral procedure should be aware about the 203 type of the remote party (IPv4-only applications running on top of 204 an IPv6-only connected device). This may help avoiding "some" 205 ALGs in the path. 207 2. Terminology 209 This document makes use of the following terms: 211 o Authoritative server: is a DNS server that answers authoritatively 212 for a given DNS query. 214 o Stub resolver: denotes a resolver with minimum functionality, 215 typically for use in end points that depend on a recursive 216 resolver. 218 o Recursive resolver: refers to a DNS server that accepts queries 219 from a resolver, and asks another resolver for the answer on 220 behalf of the first resolver. 222 o Synthetic resource record (RR): denotes a DNS resource record that 223 is not contained in any zone data file, but has been synthesized 224 from other RRs. An example of synthetic RR is a AAAA record 225 created from an A record. 227 o DNS64 function: refers to a function that is provisioned with one 228 or more IPv6 prefix(es) and is able to convert A64 records into 229 AAAA records if there is no AAAA native records and also able to 230 synthesize AAAA records from A records and the specific IPv6 231 prefix if there is no AAAA native records and no A64 records for 232 the requested QNAME. As explained in appendix B of 233 [I-D.ietf-behave-dns64] in some specific cases a DNS64 function 234 may generate a synthetic AAAA records even if a native AAAA 235 records still exists. 237 o DNS_A64 function: A logical function that is provisioned with one 238 or more IPv6 prefix(es) and is able to synthesize A64 records from 239 A records and the specific prefix if there is no A64 records for 240 the requested QNAME. As explained in appendix B of 241 [I-D.ietf-behave-dns64] in some specific case a DNS_A64 function 242 may generate a synthetic A64 records even if a native A64 records 243 (generated by an authoritative server) still exists. 245 o sDNS64 function : A simplified logical function that is able to 246 convert A64 records into AAAA records if there is no AAAA native 247 records. Such simplified function does not need to be provisioned 248 with a specific IPv6 prefix. 250 o Legacy DNS server : A DNS server that has not been updated to 251 manage A64 records and that does not include DNS64 function or 252 DNS_A64 function. 254 o A64_DNS server : A DNS server that is able to store A64 records 255 and process A64 queries. An A64_DNS does not include any DNS_A64 256 function or any DNS64 function 258 o A64_DNS64 server: A server that provides all functionalities of a 259 standard DNS server and includes also a DNS_A64 function. 261 o DNS64 server: A server that provides all functionalities of a 262 standard DNS server and includes also a DNS64 function. 264 o A64_DNS64 recursor: A recursive resolver that provides all 265 functionalities of a standard DNS recursor and also provides the 266 DNS_A64 function as part of its operation. 268 o sDNS stub resolver : A stub resolver embedding a sDNS64 function 269 which is able to manage A64 records and to issue A64 queries. 271 3. Q/A 273 3.1. Why a new RRType is Required? 275 A new record type to enclose IPv4-Embedded IPv6 addresses is required 276 for the following reasons: 278 1. DNS64 proposal as defined in [I-D.ietf-behave-dns64] is tailored 279 for IPv6 only hosts. But it may be confusing for dual-stack 280 hosts receiving an A records and a AAAA records for the same 281 QNAME. If a native IPv6 address is enclosed in the DNS response, 282 IPv6 communication should be selected. If the AAAA record 283 contains an IPv4-Embedded IPv6 address, the dual-stack host 284 should prefer direct IPv4 communications to avoid problems that 285 could appear due to application layer gateway translation in the 286 NAT64. Without an additional mechanism providing information of 287 the nature of the address in the AAAA records or without a 288 mechanism to restrict the use of the DNS64 service based on the 289 requesting connectivity capabilities, dual-stack hosts won't be 290 able to take appropriate decisions. Using A64 records for IPv4- 291 Embedded IPv6 address is a way to distinguish them from native 292 IPv6 address using AAAA records; 294 2. [I-D.ietf-behave-dns64] points out in appendix A.4 the needs to 295 introduce IPv4-Embedded IPv6 address in DNS server that are 296 authoritative for a specific QNAME. The IPv6 prefix used to 297 build this IPv4-Embedded IPv6 address has been chosen by the 298 administrator of the requested QNAME and is not necessarily known 299 by the operator providing the Internet access service to the 300 requesting host. So to solve this problem, a mechanism is needed 301 to exchange information between Internet access provider to 302 distinguish an IPv4-Embedded IPv6 address from a native IPv6 303 address. Exchanging A64 records for IPv4-Embedded IPv6 address 304 instead of AAAA records between DNS recursors and authoritative 305 server solves this issue; 307 3. [I-D.ietf-behave-dns64] describes in appendix B cases where both 308 IPv4-Embedded IPv6 address and native IPv6 can be returned in 309 AAAA records and points out that without a specific mechanism to 310 distinguish between them the standard process may choose the 311 IPv4-Embedded IPv6 address. Using A64 records for IPv4-Embedded 312 IPv6 address solves this issue; 314 4. A dual-stack application receiving an IPv4-Embedded IPv6 address 315 is not aware that the destination application entity is using an 316 IPv4 address. That application entity may not be able to 317 understand any reference in the packet payload to an IPv6 318 address. With the introduction of A64 records, it is possible to 319 develop a new API so that updated (i.e., A64-compliant) dual- 320 stack applications are able to learn that the IPv6 address comes 321 from an A64 records and is an IPv4-Embedded IPv6 address. 322 Operating systems with this new API may embed a sDN64 function to 323 deal with non updated IPv6 applications (i.e., non A64 compliant 324 applications). 326 It was tempting to define only a new query type to indicated whether 327 an enclosed AAAA record does not carry a native IPv6 address, but 328 this does not allow configuring static entries in the DNS pointing to 329 IPv4-Embedded IPv6 addresses. 331 3.2. Do We Need to Update all DNS Servers to Support this New RRType? 333 No. 335 A64_DNS servers or A64_DNS64 recursors are fully compatible with 336 legacy DNS servers, recursors or stub resolvers because the answer to 337 AAAA or to A queries and the recording or caching of AAAA records and 338 A records in not modified. So they can be introduced in the existing 339 DNS system without any trouble. 341 Owing to the DNS64 discovery mechanism described in 342 [I-D.boucadair-behave-dns64-discovery], DNS64 recursors or A64_DNS64 343 recursor are able to distinguish A64-capable DNS servers from legacy 344 DNS servers. 346 A64 resolvers, A64_DNS64 recursors or DNS64 recursors can issue non 347 recursive requests to other servers to retrieve the address of an 348 authoritative server for the QNAME and then use the A64 and DNS64 349 discovery mechanism to check if this authoritative server is an 350 A64_DNS server. If the answer is that there is no A64_DNS server in 351 this domain, this means that there is no A64 records for this QNAME, 352 if the answer is the address of another A64_DNS server that is also 353 authoritative for that domain, the resolver will send this request to 354 this new server. With such a mechanism only one authoritative DNS 355 server for this domain including IPv4-Embedded IPv6 must be upgraded 356 toward to be A64-capable DNS. All intermediate DNS servers may be 357 legacy DNS servers. 359 Only authoritative DNS servers recording an IPv4-Embedded IPv6 360 address must be updated to be A64-capable DNS servers but they don't 361 need DNS64 or A64DN64 function. The IPv4-Embedded IPv6 address can 362 be provisioned by standard processing. A DNS_A64 function may just 363 be useful to simplify the provisioning process. 365 As in the [I-D.ietf-behave-dns64] proposal, only the DNS recursor 366 serving IPv6-only host using the NAT64 service needs to be upgraded 367 toward DNS64 recursor or A64_DNS64 recursor. 369 Other DNS recursor or DNS server can be legacy DNS server. 371 3.3. Does the Proposal Need Hosts to be Upgraded All? 373 No. 375 The DNS64 function is introduced to ensure compatibility with hosts 376 or CPEs that are not updated. In a first step, to use the NAT64 377 service, it is not necessary to upgrade existing hosts or existing 378 CPEs. It is sufficient to add a DNS64 recursor without modifying the 379 legacy DNS recursor. During the DNS address provisioning phase 380 (e.g., using DHCP or PPP), the Internet access service provider 381 provisions the (one or a list of) IP address of a DNS recursor 382 according to the connectivity option subscribed by the customer 383 (i.e., IPv4 only, dual-stack or IPv6 only). For IPv4 only or dual- 384 stack customers, the legacy DNS recursor or an A64_DNS64 recursor is 385 recommended. For IPv6 only customer a DNS64 recursor is recommended. 387 During this first step, dual-stack hosts will never received IPv4- 388 Embedded IPv6 address even if they are recorded in an authoritative 389 A64 DNS server. IPv6 only hosts will have access to all NAT64. Some 390 remaining issues of this first step are: 392 1. IPv6 applications running on IPv6 only host are not able to 393 recognize that the application running on the other host may be 394 IPv4 only and they may experience problem if they exchange 395 reference to an IPv6 address. 397 2. IPv4 only applications running on dual-stack host are not able to 398 access to NAT64 service. 400 To solve the remaining issues, dual-stack hosts and CPEs must be 401 upgraded with sDNS stub resolver and the legacy DNS recursor provided 402 by the Internet access provider must be updated to an A64_DNS64 403 recursor. In the meantime, applications that want to distinguish 404 IPv4-Embedded IPv6 addresses from native IPv6 ones must be upgraded 405 to use a specific API to request A64 records. 407 The A64 and DNS64 discovery mechanism 408 [I-D.boucadair-behave-dns64-discovery] can be used by dual-stack 409 upgraded hosts to modify the pre-configured DNS recursor address with 410 a A64_DNS64 recursor address. 412 As a result, upgraded hosts will be able to use the A64 and DNS64 413 discovery mechanism to modify their configuration if the DNS recursor 414 address, provided by the Internet service access provider, is not the 415 most appropriate one. 417 3.4. What is the Impact on the DNS Server Load? 419 The impact on the DNS server load would be low. 421 There is no need to store, in DNS system, information about the 422 addressing capacity of hosts and the request/answer process remain 423 fully stateless. 425 The amount of data to be stored in A64_DNS server, A64_DNS64 recursor 426 or DNS64 recursor may increase if, for the same QNAME, both A64 427 records and AAAA records are present. But, this situation would be 428 scarce. 430 Compared to DNS64 proposal [I-D.ietf-behave-dns64], a DNS64 recursor 431 or an A64_DNS64 recursor can send three requests instead of two 432 generating therefore extra processing in the DNS server, in the DNS64 433 recursor and in the A64_DNS64 recursor. But this extra processing 434 can be avoided if a new request asking for AAAA, A64 and A records is 435 specified (see [I-D.li-dnsext-ipv4-ipv6]). 437 3.5. Are legacy Hosts Impacted? 439 No. 441 Legacy hosts are not impacted because the AAAA and the A records 442 processing is the same in A64_DNS64 recursors and/or in A64_DNS 443 servers as in legacy DNS servers. 445 If dual-stack or IPv4 only legacy hosts are provisioned with the 446 address of a legacy DNS recursor or of an A64_DNS64 recursor, as 447 recommended in this document, they will not be impacted. 449 If IPv6 only legacy hosts are provisioned with the address of a 450 legacy DNS recursor or of an A64_DNS64 recursor, they will not be 451 impacted. 453 If IPv6 only legacy hosts are provisioned with the address of a DNS64 454 recursor they will benefits from the NAT64 service. 456 3.6. Location of Recursors 458 Specific DNS64 and A64_DNS64 recursors are introduced in this 459 document. 461 A DNS64 function must not be implemented in an authoritative server 462 (for QNAME this server is authoritative for). 464 A DNS_A64 function must not be implemented in an authoritative server 465 (for the QNAME this server is authoritative for) except for 466 provisioning new A64 records in the DNS server. 468 The DNS64 recursor and the A64_DNS64 recursor must be the first DNS 469 recursor managed by the operator providing the NAT64 service 470 requested by the customer. The request coming from the stub-resolver 471 of the host can pass only through recursors that are managed locally 472 like a DNS recursor in a CPE before being intercepted by a DNS64 473 recursor or the A64_DNS64 recursor. 475 The DNS64 recursor or the A64_DNS64 recursor should not accept 476 requests coming from other recursors managed by the operator or from 477 recursors managed by another Internet service provider. This is 478 generally achieved by providing the address of the DNS64 recursor or 479 A64_DNS64 recursor only to hosts or CPEs managed by customers of the 480 Internet service provider. The address of an A64 DNS server (it may 481 be an A64 DNS recursor) or a legacy DNS server may be provided to all 482 other DNS servers, recursors or resolvers. 484 3.7. How an A64-compliant Host Can Discover an A64-DNS Server? 486 By default an host is provisioned by the Internet service provider 487 with the address of a recursor. But an A64-compliant host can change 488 this allocation for a most appropriate one thanks to the mechanism 489 described in [I-D.boucadair-behave-dns64-discovery]. 491 4. IPv4-Embedded IPv6 Record: A64 493 [I-D.ietf-behave-address-format] discusses issues related to how an 494 IPv4 host can be represented in the IPv6 realm. A new address format 495 is proposed. To store an IPv4-Embedded IPv6 address 496 [I-D.ietf-behave-address-format], a new record type is defined. 498 4.1. A64 Record Type 500 The A64 resource record type is a record specific to the Internet 501 class that is destined to store a single IPv4-Embedded IPv6 address. 503 A type value is to be assigned by IANA. 505 4.2. A64 Data Format 507 Same data format for as AAAA records [RFC3596]. 509 4.3. A64 Query 511 An A64 query for a specified domain name in the Internet class 512 returns all associated A64 resource records in the answer section of 513 a response. As AAAA query type, a type A64 query does not perform 514 additional section processing. 516 4.4. Textual format of A64 records 518 Same as for AAAA records [RFC3596]. 520 4.5. IP64.INT Domain 522 In order to not pollute IP6.INT domain with IPv4-inferred records, a 523 new domain SHOULD be defined. 525 The same requirements as those of IP6.INT are to be taken into 526 account for IP64.INT. 528 [Editor note: input on the need of a dedicated domain or use IP6.INT 529 would be welcomed. Authors are in favour of separating both domains 530 in order to ease migration to IPv6-only Internet and avoid 531 interference which may be induced by transition mechanisms.] 533 4.6. Modifications to Existing Query Types 535 All existing query types that perform type A and AAAA processing 536 SHOULD be updated to perform type A, AAAA and A64 processing. 538 Only AAAA records SHOULD be returned when AAAA only type is specified 539 in the query. 541 But during a transition phase, some hosts with IPv6-only connectivity 542 may not be updated to perform A64 queries. Specific IPv6 DNS 543 servers, called DNS64 recursors, may be used to serve those hosts. A 544 DNS64 recursor may return an A64 record as a response to AAAA query 545 if no AAAA record is available for the specified resource (A64 546 records are converted to AAAA records in the answer). This behaviour 547 advocates for enhancing the chance for a communication to be 548 established even through a translator). DNS64 recursors SHOULD not 549 be used by dual-stack hosts which do not support A64 query type. 550 When A64 query type is received, only A64 record type MUST be 551 returned. 553 4.7. On the Need of a New Query type 555 In the context of IPv4-IPv6 co-existence, new query type(s) would be 556 required to achieve the following goals: 558 o Retrieve both A64 and AAAA records by issuing one single query; 560 o Retrieve both IPv4 and IPv6 records (i.e., A, A64 and AAAA) 561 records by issuing one single query; 563 A candidate solution is described in [I-D.li-dnsext-ipv4-ipv6]. 565 5. IANA Considerations 567 A record TYPE is to be assigned by IANA. 569 6. Security Considerations 571 This document does not introduce any security threat to the DNS 572 system. 574 7. Acknowledgements 576 Authors would like to thank Andrew Sullivan for his constructive 577 comments. 579 8. References 580 8.1. Normative References 582 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 583 STD 13, RFC 1034, November 1987. 585 [RFC1035] Mockapetris, P., "Domain names - implementation and 586 specification", STD 13, RFC 1035, November 1987. 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, March 1997. 591 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 592 "DNS Extensions to Support IP Version 6", RFC 3596, 593 October 2003. 595 8.2. Informative Reference 597 [I-D.boucadair-behave-dns64-discovery] 598 Boucadair, M. and E. Burgey, "DNS64 Service Location and 599 Discovery, draft-boucadair-behave-dns64-discovery-00", 600 October 2009. 602 [I-D.carpenter-behave-referral-object] 603 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 604 K. Moore, "A Generic Referral Object for Internet 605 Entities", draft-carpenter-behave-referral-object-01 (work 606 in progress), October 2009. 608 [I-D.ietf-behave-address-format] 609 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 610 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 611 draft-ietf-behave-address-format-10 (work in progress), 612 August 2010. 614 [I-D.ietf-behave-dns64] 615 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 616 "DNS64: DNS extensions for Network Address Translation 617 from IPv6 Clients to IPv4 Servers", 618 draft-ietf-behave-dns64-10 (work in progress), July 2010. 620 [I-D.ietf-behave-v6v4-xlate] 621 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 622 Algorithm", draft-ietf-behave-v6v4-xlate-22 (work in 623 progress), August 2010. 625 [I-D.ietf-behave-v6v4-xlate-stateful] 626 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 627 NAT64: Network Address and Protocol Translation from IPv6 628 Clients to IPv4 Servers", 629 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 630 progress), July 2010. 632 [I-D.li-dnsext-ipv4-ipv6] 633 Li, L., Li, Z., and X. Duan, "DNS Extensions to Support 634 IPv4 and IPv6", draft-li-dnsext-ipv4-ipv6-02 (work in 635 progress), October 2009. 637 Authors' Addresses 639 Mohamed Boucadair 640 France Telecom 641 3, Av Francois Chateau 642 Rennes, 35000 643 France 645 Email: mohamed.boucadair@orange-ftgroup.com 647 Eric Burgey 648 Orange Labs 649 38-40, rue du general Leclerc 650 Issy-les-Moulineaux Cedex 9 92794 651 France 653 Email: eric.burgey@orange-ftgroup.com