IPNG Working Group Dave Thaler INTERNET-DRAFT Microsoft Expires January 2002 Jun-ichiro itojun Hagino IIJ Research Laboratory July 10, 2001 IPv6 Stateless DNS Discovery Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 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 a "work in progress". To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document specifies the steps a host takes in deciding how to autoconfigure information (other than the host's name itself) required for name resolution in IP version 6. The autoconfiguration process includes determining whether such information should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for acquiring a list of DNS server addresses, a domain Expires April 2001 [Page 1] Draft Stateless DNS Discovery November 2001 search path, and the domain name of the host via a stateless mechanism. The details of autoconfiguration using the stateful protocol are specified elsewhere. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Expires April 2001 [Page 2] Draft Stateless DNS Discovery November 2001 1. Introduction RFC 2462 [ADDRCONF] specifies "OtherConfigFlag" as a per-interface variable, which is set from the value of the "O" ("Other stateful configuration") flag in Router Advertisements received. When OtherConfigFlag is set on an interface, information related to name resolution is obtained using the stateful autoconfiguration mechanism. However, when OtherConfigFlag is not set, it does not describe how to obtain such information. This is the purpose of this document. (NOTE: Should we specify whether each parameter below is per-host or per-interface? A possible argument for "no" is that it may not be the same on different platforms today.) For a host to effectively resolve names of other hosts, and potentially allow resolution of its name to be performed, the following parameters are typically required: o One or more addresses of Domain Name Service (DNS) [RFC1034, RFC1035] servers. The function of name-to-address resolution (or vice versa) in IP is performed by DNS, which requires that at least one DNS Server be known and reachable by a device desiring to perform name resolution. o Domain name of the host itself. o Search path. It is currently common practice for the search path to be computed by a device based on its domain name. However, a DHCP option [DOMSEARCH] has been proposed, and so search path configuration is likely to be a requirement in general. A design team recommendation [DDDT] contains an analysis of the requirements and solution space, which was used as the basis for this document. 2. Overview A well-known site-local IPv6 anycast address is assigned to all DNS servers in the site, and host routes are propagated in the site's routing tables. A host initially sends a specific DNS query using UDP to this anycast address, and the reply for this specific query contains Expires April 2001 [Page 3] Draft Stateless DNS Discovery November 2001 any parameters the host should use. (Note: There has been some discussion of what DNS record type should be used. [DDDT] recommended the use of SRV records, and a proposal using SRV records was presented at the interim Working Group meeting in Seattle. However, since information other than servers must be included, and encoding multiple types of information was done through creative interpretation of the SRV field descriptions, there was some pushback against the use of SRV records. Other options include TXT records, and defining a new record type. This version (-02) of this document will describe the use of TXT records, but a future version may change to define a new record type instead, depending on feedback received from the WG. The goal is still to encode all information in a single response, so that only 1 message exchange is required.) 3. DNS Server Configuration Name resolution information can be encoded in TXT records as follows. The DNS server list is expressed with a string of the form "dnsservers=
[,
]*" where the attributevalue is a comma-separated list of one or more addresses (either IPv4 or IPv6) in string literal format suitable for passing to getaddrinfo. The domain name to use is expressed with a string of the form "domainname=" where the attributevalue is the domain name the client should use. The domain suffix search path is expressed with a string of the form "searchpath=[,]*" where the attributevalue is a comma-separated list of domain suffixes. Name resolution information can be expressed as defaults for the entire site, as well as per-subnet overrides if desired. To express site defaults, the record owner used is a wildcard, namely *._dnsinfo.local.arpa. The format of per-subnet overrides is described in the next section. (NOTE: Is local.arpa the right well-known domain to use? We may need to define a separate one.) Each of the attributes described herein are optional, and any combination may be used, except that only one record per Expires April 2001 [Page 4] Draft Stateless DNS Discovery November 2001 attributename should be present per owner (site or subnet) string. *._dnsinfo.local.arpa IN TXT "dnsservers=fec0:0:1::1,fec0:0:2::2" *._dnsinfo.local.arpa IN TXT "domainname=example.com" *._dnsinfo.local.arpa IN TXT "searchpath=foo.example.com, bar.example.com,example.com" Table 1: Example configuration The DNS server must also be assigned the well-known site-local anycast address, and a host route must be injected into the site's routing infrastructure. Route injection can be done via any of several methods, including: a) Run the server on a router, and configure it to inject the host route. b) Run a routing protocol on the server, and configure it to inject the host route. Note that this requires that the server and its router(s) must run the same routing protocol, at least for communication between the router(s) and the server(s) on the link. However, a server does not need to participate fully in the routing protocol, it only needs to be able to inject routes. c) Run multiple servers on the same link(s), and configure their local router(s) to inject host routes for the anycast address into the site's routing infrastructure. Running multiple servers on the same link provides robustness to the failure of a server, while routing provides robustness to the loss of routers and other links. There may still be some failures, however, such as a unidirectional failure of the router's interface, which are not handled by this option. d) Modify the routers on the link to periodically solicit (using Neighbor Discovery) the anycast address, and inject the host route based on whether a reply is received. e) Use a host-to-router protocol for communicating anycast group joins to routers. There is now work in progress [HOST- ANYCAST] in this regard. Expires April 2001 [Page 5] Draft Stateless DNS Discovery November 2001 4. Host Behavior When an interface comes up, and a host determines that the OtherConfigFlag on the interface is off, then it takes the following actions. The host constructs a DNS query for TXT records for "._dnsinfo.local.arpa.", where is constructed from an onlink prefix as follows: 1) Determine the onlink prefix to use. Any onlink site-local prefix is used, if present. Otherwise, any onlink global prefix is used. If no other onlink prefixes are present (e.g., if no routers are present), the link-local prefix is used as a last resort. 2) Convert the subnet prefix to a string by taking the lower case string literal representation, with no zero compression, and replacing all colons with underscores. Table 2 below shows some examples. This notation is used so that it uses only one token, is unique per prefix, and is human readable. Prefix String ----------------- -------------------------------------- fec0:0:0:1::/64 fec0_0000_0000_0001._dnsinfo.local.arpa 3ffe:ffff:0:1234::/64 3ffe_ffff_0000_1234._dnsinfo.local.arpa fe80::/64 fe80_0000_0000_0000._dnsinfo.local.arpa Table 2: Example queries Once the query is formed, the host sends out the query using UDP to the well-known anycast address. If no response is received after DNS_RETRANS_TIMER seconds, the query is repeated, up to a maximum of MAX_DNS_QUERIES total messages. (TODO: Compare to DHCP. Does DHCP retry eventually, if no server was initially found?) Since the query is sent to an anycast address, the reply will necessarily come from a different address. The host must not discard the reply simply because the source address is different. A more detailed discussion of this issue can be found in [ANYCAST]. Expires April 2001 [Page 6] Draft Stateless DNS Discovery November 2001 Upon receiving a response, the host parses the TXT records and acts on the information as follows. If a dnsservers attribute is present, the list of server addresses is extracted from the value. If no such attribute is present (or if no reply is received), an implementation-specific default list is used. For example: o an implementation MAY use an empty list (effectively disabling name resolution), o a host MAY use a DNS server list containing only the anycast address, subject to the limitations discussed in the next section, o a host MAY use mDNS [MDNS] only, or o a host MAY use some combination of the above. In general, the list obtained is used in the same way as if the list had been obtained (or failed to be obtained) via DHCP. If a domainname attribute is present, the domain name is extracted from the value. The domain name (or lack thereof) is used in the same way as if the list had been obtained (or failed to be obtained) via DHCP. If the searchpath attribute is present, the search path is extracted from the value. If not present, the host uses the search path it would use if no path had been obtained if DHCP were in use. 4.1. Alternative Host Behavior A host MAY choose to skip TXT queries and use the anycast address for sending normal DNS queries, if the following limitations are acceptable: o The host cannot obtain the domain name for the host itself, nor a domain search path. o Queries that undergo IPv6 fragmentation may not be handled well, as fragments may reach different servers. Therefore, queries SHOULD fit into the IPv6 minimum link MTU. Expires April 2001 [Page 7] Draft Stateless DNS Discovery November 2001 o When a response comes back with the TC (truncated) bit set, the host cannot issue TCP fallback queries due to the limitations with TCP and anycast. The rule on allowing replies that come from a source different from the query destination still applies. 5. Protocol Constants DNS_RETRANS_TIMER 3 seconds MAX_DNS_QUERIES 3 transmissions 6. Security Considerations Ensuring that queries reach a legitimate DNS server relies on the security of the IPv6 routing infrastructure. The issues here are the same as those for protecting basic IPv6 connectivity. (NOTE: need to verify the text below makes sense.) Since anycast is used, IPsec/IKE cannot be used. However, the payload can be protected as follows. If the client can preconfigure a well known private or public key then TSIG [TSIG] or DNSSEC [DNSSEC] can be used with the same packets presented for the query. If this is not the case, then either TSIG keys will have to be negotiated using [TKEY] or a Diffie-Hellman Key [DIFFSEC] exchange will have to take place using DNSSEC. After the client has the proper key then the query can be performed. 7. IANA Considerations The IANA should assign a single site-local IPv6 address to be used as an anycast address assigned to DNS servers. 8. Acknowledgements The IPv6 DNS Discovery Design Team [DDDT] provided recommendations that formed the basis of this specification. The IPv6 Working Group provided valuable feedback on the mechanism. Aaron Schader provided helpful comments on this draft. Expires April 2001 [Page 8] Draft Stateless DNS Discovery November 2001 9. References [ADDRCONF] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [ANYCAST] Hagino, Jun-ichiro itojun, and K. Ettikan, "An analysis of IPv6 anycast", draft-ietf-ipngwg-ipv6-anycast- analysis-00.txt, Work in progress, July 2001. [DDDT] Thaler, D., Editor, "Analysis of DNS Server Discovery Mechanisms for IPv6", draft-ietf-ipngwg-dns-discovery- analysis-00.txt [DIFFSEC] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. [DNSSEC] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [DOMSEARCH] B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc- domsearch-01.txt, December 2000. [HOST-ANYCAST] Haberman, B., and D. Thaler, "Host-based Anycast using MLD", draft-haberman-ipngwg-host-anycast-00.txt, February 2001. [MDNS] Esibov, L., Aboba, B., and D. Thaler, draft-ietf-dnsext- mdns-03.txt, July 2001. [TKEY] D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)" RFC 2930, September 2000. [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. Expires April 2001 [Page 9] Draft Stateless DNS Discovery November 2001 10. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires April 2001 [Page 10]