HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 01:48:55 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 11 Apr 1996 22:00:00 GMT ETag: "2ed71c-1737-316d80e0" Accept-Ranges: bytes Content-Length: 5943 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-00.txt April 1996 Expires October 1996 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 to defer binding between a particular network entity (e.g., a server) and its IP address until run time. As stated in [Carpenter:95], "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 April 1996 This document defines a new DHCP option that allows the use of FQDNs instead of IP addresses in DHCP options. Definitions The following defines the format of the FQDN option. +----------+----------+ | Code | Length | +----------+----------+---------+-----------+-------------------- |Subcode |Sublength | FQDN +----------+----------+---------+-----------+-------------------- .................. +----------+----------+---------+-----------+-------------------- |Subcode |Sublength | FQDN +----------+----------+---------+-----------+-------------------- The option consists of a Code and Length fields followed by a variable number of triples. The code, length, subcode, and sublength fields are all one octet long. The FQDN field is of variable length. The code value for this option is TBD. The length field specifies the total length (in octets) of all the triples carried in the option. For each subcode carried in the FQDN option, the IP address in the option represented by the subcode is replace by a FQDN. The sublength field shall be set to the length (in octets) of the FQDN carried in the option. The FQDN field carries the FQDN itself. More that one triple with a given subcode may appear within a single FQDN option. Options that can carry a list of IP addresses should be coded as multiple subcodes in the FQDN option, to differentiate among the variable-length FQDNs. This option only allows the use of FQDNs for options that have been elsewhere defined to carry IP addresses. Rekhter, Droms [Page 2] DRAFT An option for FQDNs in DHCP options April 1996 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. +---+---+ |xx |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 | +---+---+---+---+---+---+---+---+---+---+---+---+---+ Security Considerations Security issues are not discussed in this document. References [Carpenter:95] Carpenter, B., Rekhter, Y., "Renumbering considered unavoidable", Internet Draft [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, October 1993 Acknowledgements To be supplied. Rekhter, Droms [Page 3] DRAFT An option for FQDNs in DHCP options April 1996 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]