Network Working Group Alain Durand INTERNET-DRAFT SUN Microsystems, inc. October 25, 2002 Jun-ichiro itojun Hagino Expires April 2002 IIJ Research Laboratory Dave Thaler Microsoft Well known site local unicast addresses to communicate with recursive DNS servers 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 documents specifies 3 well known addresses to configure stub resolvers on IPv6 nodes to enable them to communicate with recursive DNS server with minimum configuration in the network and without running a discovery protocol on the end nodes. This method may be used when no other information about the addresses of recursive DNS servers is available. Implementation of stub resolvers using this as default configuration must provide a way to override this. Copyright notice Copyright (C) The Internet Society (2002). All Rights Reserved. 1. Introduction RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or more IPv6 address and default routes. However, for a node to be fully operational on a network, many other parameters are needed, such as the address of a name server that offer recursive service (a.k.a. recursive DNS server), mail relays, web proxies, etc. Except for name resolution, all the other services are usually described using names, not addresses, such as smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping reasons, a node needs to be configured with the IP address (and not the name) of a recursive DNS server. As IPv6 addresses look much more complex than IPv4 ones, there is some incentive to make this configuration as automatic and simple as possible. Although it would be desirable to have all configuration parameters configured/discovered automatically, it is common practice in IPv4 today to ask the user to do manual configuration for some of them by entering server names in a configuration form. So, a solution that will allow for automatic configuration of the recursive DNS server is seen as an important step forward in the autoconfiguration story. The intended usage scenario for this proposal is a home or enterprise network where IPv6 nodes are plugged/unplugged with minimum management and use local resources available on the network to autoconfigure. This proposal is also useful in cellular networks where all mobile devices are included within the same site. 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 [KEYWORDS]. 2. Well known addresses vs discovery Some of the discussions in the past around DNS server discovery have been trying to characterize the solution space into stateless versus stateful or server oriented versus severless. It is not absolutely clear how much state if any needs to be kept to perform DNS server discovery, and, although the semantic differences between a router and a server are well understood from a conceptual perspective, the current implementations tend to blur the picture. In another attempt to characterize different approaches, one can look at how much intelligence a client needs to have in order to use the service. One avenue is to ask the IPv6 node to participate in a discovery protocol, such as SLP or DHCP, learn the address of the server and send packets to this server. Another one is to configure the IPv6 node with well known addresses and let the local routing system forward packets to the right place. This document explores this later avenue of configuration using well known addresses that does not require participation of the end node in any discovery mechanism. 3. Reserved prefix and addresses The mechanism described here is: - intended for ongoing use and not not just for bootstrapping - intended to populate a stub resolver's list of available recursive servers only if that list is otherwise unpopulated - providing reliability through redundancy using three unicast addresses. 3.1 Stub resolver configuration This memo reserved three well known IPv6 site local addresses. In the absence of any other information about the addresses of recursive DNS servers, IPv6 stub-resolvers MAY use any of those three IPv6 addresses in their list of candidate recursive DNS servers. 3.2 Recursive DNS servers configuration Within sites, one or more recursive DNS server SHOULD be configured with any of those three addresses. It is RECOMMENDED that large sites deploy 3 recursive DNS servers, one for each reserved address. Small site could use only one recursive DNS server and assign the 3 addresses to it. 3.3 Rationale for the choice of three addresses Three was chosen based on common practice in many places in the industry. While it's true that if the first one fails, that it's unlikely the second one will succeed (due to there really being no DNS server at all), using multiple addresses is important so that when ones do exist, the host can fail over to a second server more quickly than routing converges. Three servers is a compromise between extra reliability and increased complexity (maintaining additional servers, having multiple entries in the routing system, additional delays before the stub resolver returns an error,...). Another reason to have multiple addresses is to avoid the need to use of anycast addresses to achieve reliability through redundancy. On top of the classic problems (TCP sessions, ICMP messages,...) using an anycast address would hide the real locations of the recursive DNS servers to the stub resolver, prohibiting it to keep track of which servers are performing correctly. For this particular matter, using well known addresses is no different than configuring the stub resolver with regular addresses taken from the local site. 3.4 Implementation considerations Stub resolver implementation MAY be configured by default using those addresses. However, implementing only the mechanism described in this memo may end up causing some interoperability problems when operating in networks where no recursive DNS server is configured with any of the well known addresses. Thus, stub resolvers MUST implement mechanisms for overriding this default, for example: manual configuration, L2 mechanisms and/or DHCPv6. 4. Routing A solution to enable the stub resolvers to reach the recursive DNS servers is to inject host routes in the local routing system. Examples of methods for injecting host routes and a brief discussion of their fate sharing properties are presented here: a) Manual injection of routes by a router on the same subnet. If the node running the recursive DNS server goes down, the router may or may not be notified and keep announcing the route. b) Running a routing protocol on the same node running the DNS resolver. If the process running the recursive DNS server dies, the routing protocol may or may not be notified and keep announcing the route. c) Running a routing protocol within the same process running the recursive DNS server. If the recursive DNS server and the routing protocol run in separated threads, similar concerns as above are true. d) Developing an "announcement" protocol that the recursive DNS server could use to advertize the host route to the nearby router. Details of such a protocol are out of scope of this document, but something similar to [MLD] is possible. However, the three first mechanisms should cover most cases. An alternate solution is to configure a link with the well known prefix and position the three recursive DNS servers on that link. The advantage of this method is that host routes are not necessary , the well known prefix is advertised to the routing system by the routers on the link. However, in the event of a problem on the physical link, all resolvers will become unreachable. IANA considerations for this prefix are covered in Section 6. 5. Site local versus global scope considerations The rationales for having a site local prefix are: -a) Using a site local prefix will ensure that the traffic to the recursive DNS servers stays local to the site. This will prevent the DNS requests from accidentally leaking out of the site. However, the local resolver can implement a policy to forward DNS resolution of non-local addresses to an external DNS resolver. -b) Reverse DNS resolution of site local addresses is only meaningful within the site. Thus, making sure that such queries are first sent to a recursive DNS server located within the site perimeter increase their likelihood of success. 6. Examples of use This section presents example scenarios showing how the mechanism described in this memo can co-exist with other techniques, namely manual configuration and DHCPv6 discovery. Note: those examples are just there to illustrate some usage scenarios and in no way do they suggest any recommended practices. 6.1 Simple case, general purpose recursive DNS server This example shows the case of a network that manages one recursive DNS server and a large number of nodes running DNS stub resolvers. The recursive DNS server is performing (and caching) all the recursive queries on behalf of the stub resolvers. The recursive DNS server is configured with an IPv6 address taken from the prefix delegated to the site and with the 3 well known addresses defined in this memo. The stub resolvers are either configured with the "real" IPv6 address of the recursive DNS server or with the well known site local unicast addresses defined in this memo. -------------------------------------------- | | | --------------------- | | |DNS stub resolver | | | |configured with the| | | |"real" address of | | | |the recursive DNS | | | |server | | | --------------------- | | ----------- | | | |recursive| | | | |DNS |<---------- | | |server |<---------------- | | ----------- | | | ---------------------- | | |DNS stub resolver | | | |configured with 3 | | | |well known addresses| | | ---------------------- | | | -------------------------------------------- (The recursive DNS server is configured to listen both on its IPv6 address and on the well known address) 6.2 Three recursive DNS servers This is a similar example as above, except that three recursive DNS resolvers are configured instead of just one. ------------------------------------------- | | | --------------------- | | |DNS stub resolver | | | |configured with the| | | |"real" address of | | | |the recursive DNS | | | |server | | | --------------------- | | | | | ----------- | | | |recursive| | | | |DNS |<---------| | | |server 1 |<---------|------ | | ----------- | | | | | | | | ----------- | | | | |recursive| | | | | |DNS |<---------| | | | |server 2 |<---------|-----| | | ----------- | | | | | | | | ----------- | | | | |recursive| | | | | |DNS |<---------- | | | |server 3 |<---------------| | | ----------- | | | ---------------------- | | |DNS stub resolver | | | |configured with 3 | | | |well known addresses| | | ---------------------- | | | ------------------------------------------- (The recursive DNS server is configured to listen both on its IPv6 address and on the well known address) 6.3 DNS forwarder A drawback of the choice of site local scope for the reserved addresses for recursive DNS server is that, in the case of a home/small office network connected to an ISP, DNS traffic cannot be sent directly to the ISP recursive DNS server without having the ISP and all its customers share the same definition of site. In this scenario, the home/small office network is connected to the ISP router (PE) via an edge router (CPE). ------------- / | -------- ----- / | |ISP PE| |CPE| / Customer | | |===========| |====< site | | | | | \ | -------- ----- \ | \ | ------------- The customer router CPE could be configured on its internal interface with one of the reserved site local addresses and listen for DNS queries. It would be configured to use one (or several) of the well known site local unicast addresses within the ISP's site to send its own queries to. It would act as a DNS forwarder, forwarding queries received on its internal interface to the ISP's recursive DNS server. ------------- / | ---------- -------------- / | |ISP | | CPE| / Customer | |DNS |===========| DNS|====< site | |server | <------|---forwarder|-----\---- | ---------- -------------- \ | \ | ------------- In this configuration, the CPE is acting as a multi-sited router. 6.4 DNS forwarder with DHCPv6 interactions In this variant scenario, DHCPv6 is be used between the PE and CPE to do prefix delegation [DELEG] and recursive DNS server discovery. ------------- / | -------- -------------- / | |ISP | |customer CPE| / Customer | |DHCPv6|===========| DHCPv6|====< site | |server| <------|------client| \ | -------- -------------- \ | \ | ------------- This example will show how DHCPv6 and well known site local unicast addresses cooperate to enable the internal nodes to access DNS. The customer router CPE is configured on its internal interface with one of the reserved site local addresses and listen for DNS queries. It would act as a DNS forwarder, as in 5.2, forwarding those queries to the recursive DNS server pointed out by the ISP in the DHCPv6 exchange. ------------- / | ---------- -------------- / | |ISP | |customer CPE| / Customer | |DNS |===========| DNS|====< site | |resolver| <------|---forwarder|-----\---- | ---------- -------------- \ | \ | ------------- The same CPE router could also implement a local DHCPv6 server and advertizes itself as DNS forwarder. ------------- / | -------- -------------- / Customer | |ISP PE| |customer CPE| / site | | |===========|DHCPv6 |====< | | | |server------|-----\---> | -------- -------------- \ | \ | ------------- Within the site: a) DHCPv6 aware clients use DHCPv6 to obtain the address of the DNS forwarder... ------------- / | ---------- -------------- / Customer | |ISP | |customer CPE| / site | |DNS |===========| DNS|====< | |resolver| <------|---forwarder|-----\----DHCPv6 | ---------- -------------- \ client | \ | ------------- (The address of the DNS forwarder is acquired via DHCPv6.) b) other nodes simply send their DNS request to the reserved site local addresses. ------------- / | ---------- -------------- / customer | |ISP | |customer CPE| / site | |DNS |===========| DNS|====< | |resolver| <------|---forwarder|-----\----non DHCPv6| ---------- -------------- \ node | \ | ------------- (Internal nodes use the reserved site local unicast address.) A variant of this scenario is the CPE can decide to pass the global address of the ISP recursive DNS server in the DHCPv6 exchange with the internal nodes. 7. IANA considerations The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out of the site local fec0::/10 prefix. The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 and fec0:000:0000:ffff::3 are to be reserved for recursive DNS server configuration. All other addresses within the fec0:0000:0000:ffff::/64 are reserved for future use and are expected to be assigned only with IESG approval. 8. 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. IPsec/IKE can be used as the well known addresses are used as unicast addresses. The payload can be protected using standard DNS security techniques. If the client can preconfigure a well known private or public key then TSIG [TSIG] can be used with the same packets presented for the query. If this is not the case, then TSIG keys will have to be negotiated using [TKEY]. After the client has the proper key then the query can be performed. The use of site local addresses instead of global addresses will ensure the DNS queries issued by host using this mechanism will not leak out of the site. 9. References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ADDRCONF] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [MLD] Deering, S., Fenner, W., Haberman, B., "Multicast Listener Discovery (MLD) for IPv6", RFC2710, October 1999. [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC2845, May 2000. [TKEY] D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)", RFC2930, September 2000. [DHCPv6] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress), Februray 2002. [DELEG] Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6", draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress), February 2002. 10. Authors' Addresses Alain Durand SUN microsystems, inc. 17 Network Circle, UMPK 17-202 Menlo Park, CA 94025 Email: Alain.Durand@sun.com Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku, Tokyo 101-0054, JAPAN Email: itojun@iijlab.net Dave Thaler Microsoft One Microsoft Way Redmond, CA 98052, USA Email: dthaler@microsoft.com 11. Full Copyright Statement Copyright (C) The Internet Society (2002). 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.