idnits 2.17.00 (12 Aug 2021) /tmp/idnits54819/draft-boucadair-behave-dns64-discovery-00.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.ii 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 abstract seems to contain references ([I-D.ietf-behave-dns64]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == 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 (October 19, 2009) is 4590 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) == Missing Reference: 'I-D.boucadair-behave-dns-a64' is mentioned on line 148, but not defined == Unused Reference: 'RFC3646' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC4339' is defined on line 422, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4339 ** Obsolete normative reference: RFC 5006 (Obsoleted by RFC 6106) == Outdated reference: A later version (-01) exists of draft-carpenter-behave-referral-object-00 == 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: 4 errors (**), 0 flaws (~~), 11 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 E. Burgey 4 Intended status: Standards Track France Telecom 5 Expires: April 22, 2010 October 19, 2009 7 DNS64 Service Location and Discovery 8 draft-boucadair-behave-dns64-discovery-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 22, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This memo proposes a set of solutions for the discovery of DNS64 57 [I-D.ietf-behave-dns64] service. Three solution candidates are 58 proposed: SRV RR, DHCP and RA-based. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [RFC2119]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 4 70 1.2. Technical Issues . . . . . . . . . . . . . . . . . . . . . 4 71 1.3. Contribution of this Draft . . . . . . . . . . . . . . . . 5 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Discovery of DNS64 Service . . . . . . . . . . . . . . . . . . 6 74 3.1. DNS-based Approach: DNS64 SRV RR . . . . . . . . . . . . . 6 75 3.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 6 76 3.1.2. DNS64 SRV RR Definition . . . . . . . . . . . . . . . 7 77 3.1.3. Example Usage . . . . . . . . . . . . . . . . . . . . 8 78 3.2. DHCP-based Approach . . . . . . . . . . . . . . . . . . . 8 79 3.3. RA-based Approach . . . . . . . . . . . . . . . . . . . . 9 80 4. On the Location of A64_DNS and AAAA_DNS Functions . . . . . . 9 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 1.1. Overall Context 93 Recently, due to IPv4 address depletion, several solutions have been 94 proposed within IETF. Among those solutions, IPv6 is the only 95 perennial solution that should be implemented by service providers. 96 Nevertheless, this implementation won't be in one shot and the co- 97 existence between IPv4 and IPv6 should be managed for a while. In 98 addition to the co-existence issue, interconnection means to enable 99 successful communications between IPv4 and IPv6 realms must be 100 enforced. 102 In this context, BEHAVE WG is currently specifying translator 103 mechanisms which cover both stateful 104 [I-D.ietf-behave-v6v4-xlate-stateful] and stateless 105 [I-D.ietf-behave-v6v4-xlate] modes. The proposed solutions require 106 the definition of a new IPv4-mapped IPv6 address 107 [I-D.ietf-behave-address-format] which is used to represent an IPv4- 108 only host in an IPv6 realms and the definition of a new mechanism 109 called DNS64 for synthesizing a AAAA record, representing an IPv4- 110 mapped IPv6 address in the DNS system, from the A record representing 111 the IPv4 address of the IPv4-only host [I-D.ietf-behave-dns64]. 113 This IPv4-mapped IPv6 address, when managed by a translator, is to be 114 considered as "fake" address in a DNS system since it is not 115 necessarily assigned to any host's interface qualified by the 116 associated name. In fact, the IPv4-mapped IPv6 address represents 117 the IPv6 interface of the translator used to translate packet 118 exchanged with the IPv4 host. 120 Moreover, it can be confusing for applications since the application 121 querying for this address must be aware that the application running 122 on the host represented by the IPv4-mapped IPv6 address is connected 123 through an IPv4 interface and may be not able to use a reference 124 [I-D.carpenter-behave-referral-object] to an IPv6 address in the 125 packet payload. 127 When an IPv4-mapped IPv6 address is used as destination address, the 128 traffic will be handled by a translator device and no direct 129 communication would be possible. 131 1.2. Technical Issues 133 This memo discusses issues that may be encountered when deploying 134 DNS64 mechanism in operational networks. Particularly, In order to 135 avoid crossing NAT64 boxes, natives communications should be 136 encouraged. Therefore, an IPv6 host should be able to prefer a 137 native destination IPv6 address to reach a remote peer instead of any 138 IPv4-mapped IPv6 address synthesised through the DNS64 mechanism. 140 Furthermore, a dual-stack host should be able to prefer the native 141 IPv4 address instead of any IPv4-mapped IPv6 address but should be 142 able to prefer the native IPv6 address instead of any IPv4 one. 143 Consequently, the activation of the DNS64 mechanism must be avoided 144 for dual-stack hosts if they are not able to distinguish native AAAA 145 records from synthesised AAAA records. 147 A solution to distinguish native AAAA records from synthesised AAAA 148 records is proposed in [I-D.boucadair-behave-dns-a64]. This proposal 149 introduces a new A64 DNS Record Type for synthesised AAAA records. 150 But, as this new record type will not be "understood" by existing 151 implementations, it is necessary, during a transition phase, to 152 return, to non-updated IPv6 applications or non updated IPv6 DNS stub 153 resolvers, AAAA records for synthesised AAAA records. 155 Therefore the original DNS64 mechanism is updated as follows: 157 o Rely on DNS64 mechanism as described in [I-D.ietf-behave-dns64]. 158 When supported, a DNS server returns AAAA records for native IPv6 159 addresses records and IPv4-mapped IPv6 addresses. This mechanism 160 may be used during the transition phase. 162 o Introduce A64-capable DNS which returns AAAA records for native 163 IPv6 addresses and A64 records for IPv4-mapped IPv6 addresses. 165 1.3. Contribution of this Draft 167 This document focuses on the following issues: 169 o Discovery of a compliant DNS server which is able to generate 170 synthesised AAAA records [I-D.ietf-behave-dns64]. 172 o Ability to distinguish native AAAA records from synthesised AAAA 173 records. 175 2. Terminology 177 This document makes use of the following terms. 179 o Authoritative server: A DNS server that can answer authoritatively 180 for a given DNS query. 182 o Stub resolver: A resolver with minimum functionality, typically 183 for use in end points that depends on a recursive resolver. Most 184 end points on the Internet use stub resolvers. 186 o Recursive resolver: A DNS server that accepts requests from one 187 resolver, and asks another resolver for the answer on behalf of 188 the first resolver. 190 o AAAA_DNS function: A logical function that synthesizes AAAA 191 records (containing IPv6 addresses) from A64 records if there is 192 no AAAA native records and generate also AAAA records from A 193 records(containing IPv4 addresses) if there is no AAAA native 194 records and no A64 records for the requested domain name. 196 o A64_DNS function: A logical function that returns A64 records or 197 synthesizes A64 records (containing IPv6 addresses) from A records 198 (containing IPv4 addresses). 200 o AAAA_DNS server: A DNS server which supports AAAA_DNS function. 202 o A64_DNS server: A DNS server which supports A64_DNS function. 204 o A64_DNS recursor: A recursive resolver that provides the A64_DNS 205 function as part of its operation. 207 o Synthetic RR: A DNS resource record (RR) that is not contained in 208 any zone data file, but has been synthesized from other RRs. An 209 example is a synthetic AAAA record created from an A record. 211 o DNS64 service: Denotes the service offered by a DNS server which 212 is supporting AAAA_DNS or A64_DNS functions. 214 o A DNS server that includes neither AAAA_DNS nor A64_DNS function 215 and is not able to manage A64 records is called a "DNS64 216 uncompliant DNS server". 218 3. Discovery of DNS64 Service 220 3.1. DNS-based Approach: DNS64 SRV RR 222 3.1.1. Rationale 224 This section proposes to define a new SRV RR [RFC2782] for the 225 location of DNS64 service. DNS64 service is unambiguously 226 distinguished from native AAAA-capable DNS servers. DNS64 service 227 should not be invoked for the resolution of native AAAA records. A 228 decision-making process may be enforced in the client side to drive 229 the invocation of DNS64 service or native IPv6 DNS server 230 appropriately. Otherwise, the traffic which may go through the 231 translators is not optimised and extra-processing would be required. 233 The DNS64 service can also be defined using S-NAPTR [RFC3958] or 234 U-NAPTR [RFC4848]. 236 3.1.2. DNS64 SRV RR Definition 238 The format of the generic SRV RR defined in [RFC2782] is as follows: 240 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 242 Within this memo, only the description of "Service" and "Target" are 243 re-produced below. For more information about the description of the 244 fields, the reader is invited to refer to [RFC2782]. 246 o Service: The symbolic name of the desired service. For the DNS64 247 service, "DNS64" is proposed as a service name for the location of 248 DNS64 service. If the proposal is adopted, a formal service name 249 is to be assigned by IANA. When used in an SRV RR, the assigned 250 service name must be prepended with an "_" character. 252 o Target: The domain name of the target host. There must be one or 253 more address records for this name. A Target of "." means that 254 the service is decidedly not available at this domain. 256 In order to retrieve a the IP address of a DNS server supporting the 257 DNS64 service, the client should be SRV-capable and should be 258 configured to issue a dedicated SRV query. The result of the 259 corresponding query should be used to retrieve the synthesised IPv6 260 addresses representing IPv4 hosts. 262 A host should be provided with DNS servers which support AAAA records 263 and servers which support DNS64 service. In order to avoid invoking 264 NAT64 boxes, a client should be configured in order to prefer 265 requesting native IPv6 DNS servers first. If not result has been 266 retrieved, DNS64 can be then invoked. 268 This sequential approach may increase the required delay for the 269 establishment of a communication. Several solutions (out o scope of 270 this document) can be envisaged such as: 272 1. Issue simultaneous queries; 274 2. Define a new record type/query type to identify an IPv4-mapped 275 IPv6 address from a native IPv6 one; 277 3. Define a new query type to retrieve all existing records. 279 3.1.3. Example Usage 281 A client is provisioned with the QNAME to be used for the resolution 282 of DNS64 service. 284 If a client wants to discover a DNS server that provides DNS64 285 service for the domain MyInternetAccessDomain.com., it does a lookup 286 of _DNS64._udp.MyInternetAccessDomain.com. 288 3.2. DHCP-based Approach 290 DHCPv6 can be used to provision the IP address(es) of DNS server(s) 291 which are capable to provide DNS64 service. A new option is required 292 for this purpose. 294 The format of the proposed DHCPv6 Option is shown in the figure 295 hereafter: 297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | OPTION_DNS64 | option-length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 | | 303 | Address(es) of DNS Server (s) | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | valid-lifetime | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Below is provided the description of the fields: 311 o Type: OPTION_DNS64. To be assigned by IANA for DNS64 service. 313 o option-length: variable 315 o Address(es) of DNS Server (s): One or a list of IP addresses of 316 DNS server(s) supporting the DNS64 service. 318 o valid-lifetime: The valid lifetime for the address(es) enclosed in 319 the option, expressed in units of seconds. 321 TBC. 323 3.3. RA-based Approach 325 This section describes a RA-based solution which is similar to the 326 one described in [RFC5006] for the discovery of RRDNS servers. 328 This option is used to convey the IPv6 address of the DNS server (s) 329 supporting the DNS64 service. 331 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | OPTION_DNS64 | option-length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 | | 337 | Address(es) of DNS Server (s) | 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | valid-lifetime | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Below is provided the description of the fields: 345 o Type: OPTION_DNS64. To be assigned by IANA for DNS64 service. 347 o option-length: variable 349 o Address(es) of DNS Server (s): One or a list of IP addresses of 350 DNS server(s) supporting the DNS64 service. 352 o valid-lifetime: The valid lifetime for the address(es) enclosed in 353 the option, expressed in units of seconds. 355 TBC. 357 4. On the Location of A64_DNS and AAAA_DNS Functions 359 AAAA_DNS function should be located in a stub resolver or may be 360 located in the first recursive resolver after the stub resolver. 362 AAAA_DNS function should not be activated in a stub resolver located 363 on a dual-stack host with access to public IPv4 and IPv6 networks. 364 An exception to this rule may happen to manage communication between 365 IPv6-only application on dual-stack host and IPv4-only application, 366 but such case may not be common. 368 AAAA_DNS function should not be activated in a resolver called by a 369 stub resolver located on a dual-stack host with access to public IPv4 370 and IPv6 networks. AAAA_DNS function must not be activated on an 371 authoritative server. 373 A64 records, may be used on authoritative DNS servers, but only if 374 the IPv4-mapped IPv6 addresses stored in this record has a global 375 scope. In that case this records may be introduced in the server 376 with standard provisioning tools, but in some cases it may be 377 preferable to provision only the A records and to use an A64_DNS 378 function to generate the corresponding A64 records. 380 More generally, an A64_DNS function should be located in a recursive 381 DNS resolver chosen so that, for all IPv4-mapped IPv6 addresses 382 stored in A64 records generated by this A64_DNS function, the 383 translator interface represented by this IPv6 address is the best 384 suitable to translate packets exchanged between any of the hosts 385 using a stub resolver sending requests to this DNS resolver and the 386 IPv4 interface represented by the IPv4 address mapped in this IPv6 387 address. 389 5. IANA Considerations 391 This memo requests the use of "_DNS64" service label. This service 392 is associated only with UDP transport. 394 6. Security Considerations 396 Security considerations discussed in [RFC2782] should be taken into 397 account. 399 7. Acknowledgements 401 TBC 403 8. References 405 8.1. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 411 specifying the location of services (DNS SRV)", RFC 2782, 412 February 2000. 414 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 415 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 416 December 2003. 418 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 419 Service Location Using SRV RRs and the Dynamic Delegation 420 Discovery Service (DDDS)", RFC 3958, January 2005. 422 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server 423 Information Approaches", RFC 4339, February 2006. 425 [RFC4848] Daigle, L., "Domain-Based Application Service Location 426 Using URIs and the Dynamic Delegation Discovery Service 427 (DDDS)", RFC 4848, April 2007. 429 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 430 "IPv6 Router Advertisement Option for DNS Configuration", 431 RFC 5006, September 2007. 433 8.2. Informative References 435 [I-D.carpenter-behave-referral-object] 436 Carpenter, B., Boucadair, M., Brim, S., Halpern, J., 437 Jiang, S., and K. Moore, "A Generic Referral Object for 438 Internet Entities", 439 draft-carpenter-behave-referral-object-00 (work in 440 progress), May 2009. 442 [I-D.ietf-behave-address-format] 443 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 444 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 445 draft-ietf-behave-address-format-00 (work in progress), 446 August 2009. 448 [I-D.ietf-behave-dns64] 449 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 450 "DNS64: DNS extensions for Network Address Translation 451 from IPv6 Clients to IPv4 Servers", 452 draft-ietf-behave-dns64-00 (work in progress), July 2009. 454 [I-D.ietf-behave-v6v4-xlate] 455 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 456 Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in 457 progress), September 2009. 459 [I-D.ietf-behave-v6v4-xlate-stateful] 460 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 461 Address and Protocol Translation from IPv6 Clients to IPv4 462 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work 463 in progress), October 2009. 465 Authors' Addresses 467 Mohamed Boucadair 468 France Telecom 469 3, Av Francois Chateau 470 Rennes, 35000 471 France 473 Email: mohamed.boucadair@orange-ftgroup.com 475 Eric Burgey 476 France Telecom 477 Paris, 478 France 480 Email: eric.burgey@orange-ftgroup.com