Draft Update to RFC2937 September 2001 dnsext/dhc working group Aidan Williams Internet Engineering Task Force Motorola INTERNET-DRAFT Erik Guttman November 2000 Sun Microsystems Expires March 2001 Update to RFC2937: The Name Service Search Option for DHCP $Revision: 1.4 $ $Date: 2001/09/13 23:47:07 $ Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract Hosts may use the Dynamic Host Configuration Protocol (RFC2131) [DHCP] as a mechanism to retrieve configuration information. The Name Service Search Option for DHCP (RFC2937) [NSSO] allows the DHCP server to specify the order in which various kinds of name services Expires March 2001 [Page 1] Draft Update to RFC2937 September 2001 are consulted on a host. RFC2937 uses a list of DHCP option code numbers to identify the specific name service type, in the order it is to be consulted. This specification extends RFC2937 to support name service types which currently have no DHCP option number -- either because they do not need additional configuration information, or because this configuration is not typically supplied via DHCP. 1. Introduction Historically, a variety of name services mechanisms have been used in IP networks (e.g. DNS, NIS, NIS+, NetBIOS over IP). Many DHCP options supplying configuration information specific to name services have already been specified [DHCP-OPT] (e.g. DNS server IP addresses), as well as an option specifying the order in which they should be consulted [NSSO]. More recently, multicast DNS [mDNS] has been proposed as a useful name service mechanism in zeroconf networks [ZEROCONF]. mDNS in a zeroconf network does not require configuration. In networks configured using DHCP, options to enable/disable mDNS, specify the multicast scope, and set the order in which the scopes are to be used are required. This specification extends the existing name service search option for DHCP to support mDNS. An additional DHCP option is not required to support mDNS configuration. An IANA number space for "DHCP Name Service Search Option" numbers is defined which is backwardly compatible with RFC2937. 2. Definitions 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 [3]. This document also uses the following terms: DHCP client DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. Expires March 2001 [Page 2] Draft Update to RFC2937 September 2001 DHCP server A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. 3. Relationship to RFC2937 The relationship to the previous Name Service Search Option definition in RFC2937 can be summarised as follows: ¸ Backwardly compatibile with RFC2937, and the same DHCP option number is used (117). ¸ New IANA number space for "DHCP Name Service Search Option" numbers. ¸ Has a search option number range for private use. ¸ Doesn't require a name service to have a DHCP option that configures the name service IP address. 4. Name Service Search Option Format DHCP option code number 117 is assigned to the Name Service Search Option. The minimum length is 2 bytes. The option format is shown in the following diagram: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 117 | Len | Name Service Search Option 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name Service Search Option 2 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the above diagram, Name Service Option 1 and Name Service Option 2 are 16-bit, network byte ordered integers. A DHCP server lists the integers in order of preference, highest to lowest. The order of the integers corresponds to the order in which a host should consult each name service. Len is the number of bytes used by the Name Service Search Options. For example, two options would result in Len=4. Expires March 2001 [Page 3] Draft Update to RFC2937 September 2001 5. Name Service Search Option Numbers The IANA number space for "DHCP Name Service Search Option" numbers is defined in the following way: 0 Use local naming information (compatible with RFC2937). This is a special case. 1-127 Corresponding DHCP option number to configure this name service with a server IP address (RFC2132) [DHCP-OPT]. 128-191 Name services without DHCP option codes to configure them. 192-254 Private use. 255 Reserved. RFC2937 uses the DHCP option code [DHCP-OPT] for configuration of the name service to identify it in the search list. The above allocation of the name service search number space retains backward compatibility with RFC2937 by allocating search list numbers from the number range corresponding to private DHCP options. 5.1. Search Numbers Derived from DHCP options IANA has allocated the following DHCP option numbers that configure IP addresses for name services: 6 Domain Name Server Option 41 Network Information Servers Option 44 NetBIOS over TCP/IP Name Server Option 65 Network Information Service+ Servers Option 5.2. Search Numbers Defined in this Specification This document defines the Name Service Search Option number in the table below. Other name services not requiring a DHCP option may extend this list (for example, mDNS with a scope other than link- local). 0 Use local naming information. A special case retained for backward compatibility with RFC2937. 128 Use link-local multicast DNS, as defined in [mDNS]. Expires March 2001 [Page 4] Draft Update to RFC2937 September 2001 6. Host Behaviour A host MAY ignore Name Service Search Options that it does not recognise. A host SHOULD use the name services specified in the search option list, in order. 6.1. Enabling/Disabling mDNS The presence of the mDNS name service search option in the search list enables the use of multicast DNS on a host. A host using DHCP SHOULD NOT enable multicast DNS unless the mDNS name service is listed in the Name Service Search Option list. An alternative approach is to have a seperate DHCP option to enable/disable mDNS. If mDNS is to be used with multicast scopes larger than link-local, it is reasonable to be able to specify the order in which different scopes are consulted. For example using a search path of mdns-link-local, netbios, mdns-site-local, isp- dns. 6.2. Multiple Interfaces mDNS behavior depends upon configuration obtained by DHCP. As noted in Section 3.6 of [DHCP], "A client with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for those separate interfaces." Each interface is enabled to use mDNS separately. This makes good sense. For example, a telecommuter may use a multihomed host, one interface attached to a LAN in a home office, the other attached via a WAN to a corporate network. The interface connected to the LAN will issue requests using mDNS, while the interface connected to the WAN, configured by DHCP, does not have mDNS enabled. A mDNS enabled host SHOULD issue requests and respond to them from each multicast enabled interface, by default, if it lacks any DNS or DHCP configuration. A mDNS enabled host which has manual DNS configuration or receives DHCP configuration MUST NOT issue mDNS requests or respond to them (from the configured interface) unless it receives an mDNS Enable option. In this case, the host which SHOULD issue mDNS requests Expires March 2001 [Page 5] Draft Update to RFC2937 September 2001 respond to them on interface upon which the DHCP option was received, according to the parameters provided in the mDNS Enable option. If a host offers manual configuraration to enable mDNS on an interface, the host's behavior is left unspecified by this document. 7. Example A DHCP server may configure a client to first consult multicast DNS and then DNS by sending the following DHCP option: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 117 | 4 | 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8. Security Considerations Relies on DHCP security. Include erik's section on mdns security? 9. IANA Considerations The IANA number space for "DHCP Name Service Search Options" is defined in the following way: 0 Use local naming information (compatible with RFC2937). This is a special case. 1-127 The values for this range are derived from the existing IANA registry for DHCP options (bootp-dhcp-paramters). The bootp-dhcp-parameters number range 1-127 is mapped directly into the "DHCP Name Service Search Option" number space. 128-191 Name services without DHCP option codes to configure them. Allocations are be made by IANA according to the "Specification Required" policy described in RFC2434. Expires March 2001 [Page 6] Draft Update to RFC2937 September 2001 192-254 "Private use" as described in RFC2434. 255 Reserved. 10. Acknowledgements This document builds on the previous specification by Carl Smith in RFC2937. The authors thank Robert Elz, Bernard Aboba and Stuart Cheshire for their comments. 11. References [DHCP] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, March 1997 [DHCP-OPT] S. Alexander and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC2132, March 1997. [NSSO] C. Smith, "The Name Service Search Option for DHCP", RFC2937, September 2000 [mDNS] Levon Esibov, Bernard Aboba, Dave Thaler, "Multicast DNS", draft-ietf-dnsext-mdns-03.txt, July 2001, work-in-progress [ZEROCONF] Myron Hattig, "ZeroConf Requirements", draft-ietf-zeroconf- reqts-08.txt, June 2001, work-in-progress Expires March 2001 [Page 7] Draft Update to RFC2937 September 2001 12. Author's Addresses Aidan Williams Motorola Australian Research Centre Locked Bag 5028 Botany, NSW, 1455, Australia Aidan.Williams@motorola.com Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany Phone: +49 7263 911 701 Messages: +49 6221 356 202 Email: erik.guttman@sun.com 13. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 March 2001 [Page 8] Draft Update to RFC2937 September 2001 Table of Contents Status of this Memo ........................................... 1 Copyright Notice .............................................. 1 Abstract ...................................................... 1 1 Introduction ................................................. 2 2 Definitions .................................................. 2 3 Relationship to RFC2937 ...................................... 3 4 Name Service Search Option Format ............................ 3 5 Name Service Search Option Numbers ........................... 4 5.1 Search Numbers Derived from DHCP options ................... 4 5.2 Search Numbers Defined in this Specification ............... 4 6 Host Behaviour ............................................... 5 6.1 Enabling/Disabling mDNS .................................... 5 6.2 Multiple Interfaces ........................................ 5 7 Example ...................................................... 6 8 Security Considerations ...................................... 6 9 IANA Considerations .......................................... 6 10 Acknowledgements ............................................ 7 11 References .................................................. 7 12 Author's Addresses .......................................... 8 13 Full Copyright Statement .................................... 8 Expires March 2001 [Page 9]