HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 01:48:57 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 17 Mar 1998 16:30:00 GMT ETag: "2e7a4f-1fb6-350ea508" Accept-Ranges: bytes Content-Length: 8118 Connection: close Content-Type: text/plain Network Working Group Yakov Rekhter, cisco Systems INTERNET DRAFT Ralph Droms, Bucknell University Obsoletes: draft-ietf-dhc-fqdn-opt-02.txt July 1997 Expires January 1998 An option for FQDNs in DHCP options Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract DHCP [DHCP] can be used to automate the process of configuring TCP/IP host computers. However, some of the DHCP options carry IP addresses rather than Fully Qualified Domain Names (FQDN). Use of IP addresses constrains the DHCP client to use the addresses that were in use at the time the client received its configuration information; these addresses may change over time, (e.g., a server may be assigned a new IP address), so that the IP addresses used by the client may become invalid. An alternative to passing IP addresses is to pass FQDNs instead of (numeric) IP addresses. Doing this allows a client to defer binding between a particular network entity (e.g., a server) and its IP address until run time. As stated in [Carpenter:96], "Deferring the binding avoids the risk of changed mapping between IP addresses and specific network entities (due to changing addressing information). Moreover, reliance on FQDNs (rather than IP addresses) also localizes to the DNS the changes needed to deal with changing addressing information due to renumbering." Rekhter, Droms [Page 1] DRAFT An option for FQDNs in DHCP options July 1997 This document defines a new DHCP option that allows the use of FQDNs instead of IP addresses in DHCP options. 1. FQDN Option The FQDN option allows the use of FQDNs rather than IP addresses in DHCP options. The FQDN option contains other DHCP options, which then carry FQDNs rather than IP addresses as data. The code for the FQDN option is 89. The Len field gives the total length of all of the DHCP options contained in the FQDN option. The Code, Len, Subcode and Sublen are all one octet long. The FQDN field is variable length. For each subcode carried in the FQDN option, the IP address in the option represented by the subcode is replaced by a FQDN. The Sublen field shall be set to the length (in octets) of the FQDN carried in the option; the length specified by the Sublen field does not include the Subcode and Sublen fields. The FQDN field carries the FQDN itself. +----------+----------+ | Code | Len | +----------+----------+---------+-----------+-------------------- | Subcode | Sublen | FQDN +----------+----------+---------+-----------+-------------------- .................. +----------+----------+---------+-----------+-------------------- | Subcode | Sublen | FQDN +----------+----------+---------+-----------+-------------------- 1.1 DHCP options containing a list of parameters More than one triple with a given subcode may appear within a single FQDN option. The FQDNs contained in triples with the same subcode should be treated as a list of parameters for the DHCP option represented by the subcode. Because FQDNs are variable length, lists of FQDNs cannot be encoded in DHCP options within the FQDN option. DHCP Options that can carry a list of IP addresses should be coded as multiple subcodes in the Rekhter, Droms [Page 2] DRAFT An option for FQDNs in DHCP options July 1997 FQDN option, to differentiate among the variable-length FQDNs. If the order of the IP addresses in the option identified by the subcode was meaningful, e.g., representing a priority or preference order, the order retains that same meaning in multiple instances of the same subcode in the FQDN option. DHCP options that carry pairs of IP addresses, e.g., the static route option (code 33), MUST NOT be encoded in the FQDN option. This option only allows the use of FQDNs for options that have been elsewhere defined to carry IP addresses. If the FQDN option is used, the DNS server option (code 6) SHOULD be specified before any FQDN options, and the client's protocol software MUST initialize its DNS resolver with that DNS server address before resolving any FQDNs in subsequent options. Not all DHCP options that specify IP addresses may be sensibly transmitted as FQDNs; for example, options that specify an IP address-subnet mask pair MUST NOT be encoded in the FQDN option. The DNS server option SHOULD NOT be encoded in the FQDN option because, under most circumstances, the FQDN of a DNS server cannot be resolved until the IP address fo a server is available. The router option SHOULD NOT be encoded as an FQDN because queries to the DNS server may require that the client's protocol software be initialized with the router's IP address; e.g., the DNS server may be on a different subnet. 1.2 Example The following illustrates how the FQDN option could be used to carry FQDNs for 2 LPR Servers with FQDNs lpr1.xxx.org and lpr2.yy.org, and one Network Information Server with FQDN nis.zzzz.org. +---+---+ |89 |41 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |41 |12 | n | i | s | . | z | z | z | z | . | o | r | g | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 9 |12 | l | p | r | 1 | . | x | x | x | . | o | r | g | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 9 |11 | l | p | r | 2 | . | y | y | . | o | r | g | +---+---+---+---+---+---+---+---+---+---+---+---+---+ 2. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [1]. Rekhter, Droms [Page 3] DRAFT An option for FQDNs in DHCP options July 1997 The DHCP FQDN option introduces DNS into the client configuration process, so that compromises to the DNS system may compromise the security of client configuration. 3. References [Carpenter:96] Carpenter, B., Rekhter, Y., "Renumbering needs work", RFC1900, February 1996. [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, March 1997. 4. Acknowledgments The authors gratefully acknowledge the input and review of the Dynamic Host Configuration working group. They also thank cisco Systems and Bucknell University for their support in the development of this document. 5. Author Information Yakov Rekhter cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134 Phone: (914) 528-0090 email: yakov@cisco.com Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 email: droms@bucknell.edu Rekhter, Droms [Page 4]