Network Working Group M. Boucadair Internet-Draft E. Burgey Intended status: Standards Track France Telecom Expires: April 22, 2010 October 19, 2009 DNS64 Service Location and Discovery draft-boucadair-behave-dns64-discovery-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Boucadair & Burgey Expires April 22, 2010 [Page 1] Internet-Draft DNS64 Service Discovery October 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo proposes a set of solutions for the discovery of DNS64 [I-D.ietf-behave-dns64] service. Three solution candidates are proposed: SRV RR, DHCP and RA-based. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Boucadair & Burgey Expires April 22, 2010 [Page 2] Internet-Draft DNS64 Service Discovery October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 4 1.2. Technical Issues . . . . . . . . . . . . . . . . . . . . . 4 1.3. Contribution of this Draft . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Discovery of DNS64 Service . . . . . . . . . . . . . . . . . . 6 3.1. DNS-based Approach: DNS64 SRV RR . . . . . . . . . . . . . 6 3.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. DNS64 SRV RR Definition . . . . . . . . . . . . . . . 7 3.1.3. Example Usage . . . . . . . . . . . . . . . . . . . . 8 3.2. DHCP-based Approach . . . . . . . . . . . . . . . . . . . 8 3.3. RA-based Approach . . . . . . . . . . . . . . . . . . . . 9 4. On the Location of A64_DNS and AAAA_DNS Functions . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Boucadair & Burgey Expires April 22, 2010 [Page 3] Internet-Draft DNS64 Service Discovery October 2009 1. Introduction 1.1. Overall Context Recently, due to IPv4 address depletion, several solutions have been proposed within IETF. Among those solutions, IPv6 is the only perennial solution that should be implemented by service providers. Nevertheless, this implementation won't be in one shot and the co- existence between IPv4 and IPv6 should be managed for a while. In addition to the co-existence issue, interconnection means to enable successful communications between IPv4 and IPv6 realms must be enforced. In this context, BEHAVE WG is currently specifying translator mechanisms which cover both stateful [I-D.ietf-behave-v6v4-xlate-stateful] and stateless [I-D.ietf-behave-v6v4-xlate] modes. The proposed solutions require the definition of a new IPv4-mapped IPv6 address [I-D.ietf-behave-address-format] which is used to represent an IPv4- only host in an IPv6 realms and the definition of a new mechanism called DNS64 for synthesizing a AAAA record, representing an IPv4- mapped IPv6 address in the DNS system, from the A record representing the IPv4 address of the IPv4-only host [I-D.ietf-behave-dns64]. This IPv4-mapped IPv6 address, when managed by a translator, is to be considered as "fake" address in a DNS system since it is not necessarily assigned to any host's interface qualified by the associated name. In fact, the IPv4-mapped IPv6 address represents the IPv6 interface of the translator used to translate packet exchanged with the IPv4 host. Moreover, it can be confusing for applications since the application querying for this address must be aware that the application running on the host represented by the IPv4-mapped IPv6 address is connected through an IPv4 interface and may be not able to use a reference [I-D.carpenter-behave-referral-object] to an IPv6 address in the packet payload. When an IPv4-mapped IPv6 address is used as destination address, the traffic will be handled by a translator device and no direct communication would be possible. 1.2. Technical Issues This memo discusses issues that may be encountered when deploying DNS64 mechanism in operational networks. Particularly, In order to avoid crossing NAT64 boxes, natives communications should be encouraged. Therefore, an IPv6 host should be able to prefer a Boucadair & Burgey Expires April 22, 2010 [Page 4] Internet-Draft DNS64 Service Discovery October 2009 native destination IPv6 address to reach a remote peer instead of any IPv4-mapped IPv6 address synthesised through the DNS64 mechanism. Furthermore, a dual-stack host should be able to prefer the native IPv4 address instead of any IPv4-mapped IPv6 address but should be able to prefer the native IPv6 address instead of any IPv4 one. Consequently, the activation of the DNS64 mechanism must be avoided for dual-stack hosts if they are not able to distinguish native AAAA records from synthesised AAAA records. A solution to distinguish native AAAA records from synthesised AAAA records is proposed in [I-D.boucadair-behave-dns-a64]. This proposal introduces a new A64 DNS Record Type for synthesised AAAA records. But, as this new record type will not be "understood" by existing implementations, it is necessary, during a transition phase, to return, to non-updated IPv6 applications or non updated IPv6 DNS stub resolvers, AAAA records for synthesised AAAA records. Therefore the original DNS64 mechanism is updated as follows: o Rely on DNS64 mechanism as described in [I-D.ietf-behave-dns64]. When supported, a DNS server returns AAAA records for native IPv6 addresses records and IPv4-mapped IPv6 addresses. This mechanism may be used during the transition phase. o Introduce A64-capable DNS which returns AAAA records for native IPv6 addresses and A64 records for IPv4-mapped IPv6 addresses. 1.3. Contribution of this Draft This document focuses on the following issues: o Discovery of a compliant DNS server which is able to generate synthesised AAAA records [I-D.ietf-behave-dns64]. o Ability to distinguish native AAAA records from synthesised AAAA records. 2. Terminology This document makes use of the following terms. o Authoritative server: A DNS server that can answer authoritatively for a given DNS query. o Stub resolver: A resolver with minimum functionality, typically for use in end points that depends on a recursive resolver. Most Boucadair & Burgey Expires April 22, 2010 [Page 5] Internet-Draft DNS64 Service Discovery October 2009 end points on the Internet use stub resolvers. o Recursive resolver: A DNS server that accepts requests from one resolver, and asks another resolver for the answer on behalf of the first resolver. o AAAA_DNS function: A logical function that synthesizes AAAA records (containing IPv6 addresses) from A64 records if there is no AAAA native records and generate also AAAA records from A records(containing IPv4 addresses) if there is no AAAA native records and no A64 records for the requested domain name. o A64_DNS function: A logical function that returns A64 records or synthesizes A64 records (containing IPv6 addresses) from A records (containing IPv4 addresses). o AAAA_DNS server: A DNS server which supports AAAA_DNS function. o A64_DNS server: A DNS server which supports A64_DNS function. o A64_DNS recursor: A recursive resolver that provides the A64_DNS function as part of its operation. o Synthetic RR: A DNS resource record (RR) that is not contained in any zone data file, but has been synthesized from other RRs. An example is a synthetic AAAA record created from an A record. o DNS64 service: Denotes the service offered by a DNS server which is supporting AAAA_DNS or A64_DNS functions. o A DNS server that includes neither AAAA_DNS nor A64_DNS function and is not able to manage A64 records is called a "DNS64 uncompliant DNS server". 3. Discovery of DNS64 Service 3.1. DNS-based Approach: DNS64 SRV RR 3.1.1. Rationale This section proposes to define a new SRV RR [RFC2782] for the location of DNS64 service. DNS64 service is unambiguously distinguished from native AAAA-capable DNS servers. DNS64 service should not be invoked for the resolution of native AAAA records. A decision-making process may be enforced in the client side to drive the invocation of DNS64 service or native IPv6 DNS server appropriately. Otherwise, the traffic which may go through the Boucadair & Burgey Expires April 22, 2010 [Page 6] Internet-Draft DNS64 Service Discovery October 2009 translators is not optimised and extra-processing would be required. The DNS64 service can also be defined using S-NAPTR [RFC3958] or U-NAPTR [RFC4848]. 3.1.2. DNS64 SRV RR Definition The format of the generic SRV RR defined in [RFC2782] is as follows: _Service._Proto.Name TTL Class SRV Priority Weight Port Target Within this memo, only the description of "Service" and "Target" are re-produced below. For more information about the description of the fields, the reader is invited to refer to [RFC2782]. o Service: The symbolic name of the desired service. For the DNS64 service, "DNS64" is proposed as a service name for the location of DNS64 service. If the proposal is adopted, a formal service name is to be assigned by IANA. When used in an SRV RR, the assigned service name must be prepended with an "_" character. o Target: The domain name of the target host. There must be one or more address records for this name. A Target of "." means that the service is decidedly not available at this domain. In order to retrieve a the IP address of a DNS server supporting the DNS64 service, the client should be SRV-capable and should be configured to issue a dedicated SRV query. The result of the corresponding query should be used to retrieve the synthesised IPv6 addresses representing IPv4 hosts. A host should be provided with DNS servers which support AAAA records and servers which support DNS64 service. In order to avoid invoking NAT64 boxes, a client should be configured in order to prefer requesting native IPv6 DNS servers first. If not result has been retrieved, DNS64 can be then invoked. This sequential approach may increase the required delay for the establishment of a communication. Several solutions (out o scope of this document) can be envisaged such as: 1. Issue simultaneous queries; 2. Define a new record type/query type to identify an IPv4-mapped IPv6 address from a native IPv6 one; 3. Define a new query type to retrieve all existing records. Boucadair & Burgey Expires April 22, 2010 [Page 7] Internet-Draft DNS64 Service Discovery October 2009 3.1.3. Example Usage A client is provisioned with the QNAME to be used for the resolution of DNS64 service. If a client wants to discover a DNS server that provides DNS64 service for the domain MyInternetAccessDomain.com., it does a lookup of _DNS64._udp.MyInternetAccessDomain.com. 3.2. DHCP-based Approach DHCPv6 can be used to provision the IP address(es) of DNS server(s) which are capable to provide DNS64 service. A new option is required for this purpose. The format of the proposed DHCPv6 Option is shown in the figure hereafter: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DNS64 | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Address(es) of DNS Server (s) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Below is provided the description of the fields: o Type: OPTION_DNS64. To be assigned by IANA for DNS64 service. o option-length: variable o Address(es) of DNS Server (s): One or a list of IP addresses of DNS server(s) supporting the DNS64 service. o valid-lifetime: The valid lifetime for the address(es) enclosed in the option, expressed in units of seconds. TBC. Boucadair & Burgey Expires April 22, 2010 [Page 8] Internet-Draft DNS64 Service Discovery October 2009 3.3. RA-based Approach This section describes a RA-based solution which is similar to the one described in [RFC5006] for the discovery of RRDNS servers. This option is used to convey the IPv6 address of the DNS server (s) supporting the DNS64 service. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DNS64 | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Address(es) of DNS Server (s) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Below is provided the description of the fields: o Type: OPTION_DNS64. To be assigned by IANA for DNS64 service. o option-length: variable o Address(es) of DNS Server (s): One or a list of IP addresses of DNS server(s) supporting the DNS64 service. o valid-lifetime: The valid lifetime for the address(es) enclosed in the option, expressed in units of seconds. TBC. 4. On the Location of A64_DNS and AAAA_DNS Functions AAAA_DNS function should be located in a stub resolver or may be located in the first recursive resolver after the stub resolver. AAAA_DNS function should not be activated in a stub resolver located on a dual-stack host with access to public IPv4 and IPv6 networks. An exception to this rule may happen to manage communication between IPv6-only application on dual-stack host and IPv4-only application, but such case may not be common. AAAA_DNS function should not be activated in a resolver called by a Boucadair & Burgey Expires April 22, 2010 [Page 9] Internet-Draft DNS64 Service Discovery October 2009 stub resolver located on a dual-stack host with access to public IPv4 and IPv6 networks. AAAA_DNS function must not be activated on an authoritative server. A64 records, may be used on authoritative DNS servers, but only if the IPv4-mapped IPv6 addresses stored in this record has a global scope. In that case this records may be introduced in the server with standard provisioning tools, but in some cases it may be preferable to provision only the A records and to use an A64_DNS function to generate the corresponding A64 records. More generally, an A64_DNS function should be located in a recursive DNS resolver chosen so that, for all IPv4-mapped IPv6 addresses stored in A64 records generated by this A64_DNS function, the translator interface represented by this IPv6 address is the best suitable to translate packets exchanged between any of the hosts using a stub resolver sending requests to this DNS resolver and the IPv4 interface represented by the IPv4 address mapped in this IPv6 address. 5. IANA Considerations This memo requests the use of "_DNS64" service label. This service is associated only with UDP transport. 6. Security Considerations Security considerations discussed in [RFC2782] should be taken into account. 7. Acknowledgements TBC 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. Boucadair & Burgey Expires April 22, 2010 [Page 10] Internet-Draft DNS64 Service Discovery October 2009 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006. [RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007. [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007. 8.2. Informative References [I-D.carpenter-behave-referral-object] Carpenter, B., Boucadair, M., Brim, S., Halpern, J., Jiang, S., and K. Moore, "A Generic Referral Object for Internet Entities", draft-carpenter-behave-referral-object-00 (work in progress), May 2009. [I-D.ietf-behave-address-format] Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-00 (work in progress), August 2009. [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-00 (work in progress), July 2009. [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in progress), September 2009. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Boucadair & Burgey Expires April 22, 2010 [Page 11] Internet-Draft DNS64 Service Discovery October 2009 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work in progress), October 2009. Authors' Addresses Mohamed Boucadair France Telecom 3, Av Francois Chateau Rennes, 35000 France Email: mohamed.boucadair@orange-ftgroup.com Eric Burgey France Telecom Paris, France Email: eric.burgey@orange-ftgroup.com Boucadair & Burgey Expires April 22, 2010 [Page 12]