diff --git a/doc/draft-ietf-dhc-authentication-02.txt b/doc/draft-ietf-dhc-authentication-02.txt new file mode 100644 index 00000000..e6134472 --- /dev/null +++ b/doc/draft-ietf-dhc-authentication-02.txt @@ -0,0 +1,278 @@ + +Network Working Group R. Droms (Editor) +INTERNET DRAFT Bucknell University +Obsoletes: draft-ietf-dhc-authentication-01.txt February 1996 + Expires August 1996 + + + Authentication for DHCP Messages + + +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 + + The Dynamic Host Configuration Protocol (DHCP) [1] provides a + framework for passing configuration information to hosts on a TCP/IP + network. In some situations, network administrators may wish to + constrain the allocation of addresses to authorized hosts. + Additionally, some network administrators may wish to provide for + client authentication of DHCP messages from DHCP servers. The goal of + this proposal is to suggest a technique through which authorization + tickets can be easily generated and newly attached hosts with proper + authorization can be automatically configured from an authenticated + DHCP server. + +Introduction + + DHCP transports protocol stack configuration parameters from + centrally administered servers to TCP/IP hosts. Among those + parameters are an IP address. DHCP servers can be configured to + dynamically allocate addresses from a pool of addresses, eliminating + a manual step in configuration of TCP/IP hosts. + + + + +Droms [Page 1] + +DRAFT Authentication for DHCP Messages February 1996 + + + In some situations, network administrators may wish to constrain the + allocation of addresses to authorized hosts. Such constraint may be + desirable in "hostile" environments where the network medium is not + physically secured, such as wireless networks or college residence + halls. + + Additionally, some network administrators may wish to provide + authentication of DHCP messages from DHCP servers. In some + environments, clients may be subject to denial of service attacks + through the use of bogus DHCP servers, or may simply be misconfigured + due to unintentionally instantiated DHCP servers. + + The goal of this proposal is to suggest a technique through which + authorization tickets can be easily generated and newly attached + hosts with proper authorization can be automatically configured from + an authenticated DHCP server. + +Overview + + The idea behind this proposal is to use well-known techniques to + authenticate the source and contents of DHCP messages. Each + authenticated DHCP message will include an encrypted value generated + by the source as a message authentication code (MAC), and will + contain a message digest confirming that the message contents have + not been altered in transit. + + There is one "feature" of DHCP that complicates the authentication of + DHCP messages. DHCP clients use limited broadcast for all messages. + To allow for delivery of DHCP messages to servers that are not on the + same subnet, a DHCP relay agent on the same subnet as the client + receives the initial message and forwards the message on to the DHCP + server. The relay agent changes the contents of two fields - + 'giaddr' and 'hops' - in the DHCP message. Thus, the message digest, + which is to be computed by the client and confirmed by the server, + cannot include the 'giaddr' and 'hops' fields. + +Message authentication + + Suppose the sender, S, and receiver, R, share a secret key, K, where + K is unique to any messages exchanged between S and R. S and R are a + DHCP client/server pair. S forms the MAC by encoding a counter value + with K. This counter should be monotonically increasing and large + enough to hold an NTP-format timestamp. The MAC: + + counter, f(K, MD(message + counter)) + + (where MD is a message digest function as specified below) is + included in the DHCP message generated by S. Encoding function f + + + +Droms [Page 2] + +DRAFT Authentication for DHCP Messages February 1996 + + + must have the characteristics that K cannot be deduced from the MAC + and f(K, MD(message + counter)) can't be guessed. R can then compute + f(K, MD(message + counter)) to verify that S must have known K. + Using a counter value such as the current time of day can reduce the + danger of replay attacks. + +Key management + + Assume that the shared key, K, is distributed to the client through + some out-of-band mechanism. The client must store K locally for use + in all authenticated DHCP messages. The server must know the Ks for + all authorized clients. + + To avoid centralized management of a list of random keys, suppose K + for each client is generated from some value unique to that client. + That is, K = f(MK, unique-id), where MK is a secret master key and f + is an encoding function as described above. + + Each DHCP client must have a unique "client-id" through which its + interactions with the DHCP server (specifically, the address + currently allocated to the client) can be identified. This client-id + may be a MAC address or a manufacturer's serial number; the specific + choice of client-id is left to the network administrator. The + client-id meets the requirements of the unique-id used to generate K + in the previous paragraph. + + Without knowledge of the master key MK, an unauthorized client cannot + generate its own key K. The server can quickly validate an incoming + message from a new client by regenerating K from the client-id. For + known clients, the server can choose to recover the client's K + dynamically from the client-id in the DHCP message, or can choose to + precompute and cache all of the Ks a priori. + +Selection of encoding function + + The exact encoding function is TBD. One suggestion is to borrow from + DNSSEC, in which the encoding function is designated by an identifier + in the message. The identifier then selects no encoding, a default + encoding (using the Public Key Cryptographic Standard as specified in + DNSSEC) which must be provided, or one of several other optional + encodings. + +Message contents verification + + MD5 is a well-known mechanism for generating a digest that can + confirm the the contents of a message have not been altered in + transit. The only modification to MD5 for use in DHCP is to require + that the 'giaddr' and 'hops' fields be set to all 0s for the MD5 + + + +Droms [Page 3] + +DRAFT Authentication for DHCP Messages February 1996 + + + computation. + +Message contents + + Putting all of this together, S builds: + + DHCP message, counter, f(K, MD5(message - ('giaddr' and 'hops') + + counter)) + + where K is the client's key. R can then verify the contents of the + message from the MD5 digest value, and verify that S must have held + the shared secret key from the value of f(K, MD5(message - ('giaddr' + and 'hops') + counter)) + +Applicability and Specification + + This scheme is equally applicable to authentication of both DHCPv4 + and DHCPv6 messages. If this mechanism is adopted as part of the + DHCPv4 or DHCPv6 specification, the authentication data will be + encoded as an option. + +Acknowledgments + + Jeff Schiller and Christian Huitema developed this scheme during a + terminal room BOF at the Dallas IETF meeting, December 1996. The + editor of this document transcribed the notes from that discussion. + Thanks to John Wilkins, Ran Atkinson and Thomas Narten for reviewing + a draft of this proposal, and to Shawn Mamros for noticing that the + original draft neglected to account for the 'hops' field. + +References + + [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, + Bucknell University, October 1993. + +Security Considerations + + This memo describes authentication and verification mechanisms for DHCP + +Editor's Address + + Ralph Droms + Computer Science Department + 323 Dana Engineering + Bucknell University + Lewisburg, PA 17837 + + Phone: (717) 524-1145 + + + +Droms [Page 4] + +DRAFT Authentication for DHCP Messages February 1996 + + + EMail: droms@bucknell.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Droms [Page 5] + diff --git a/doc/draft-ietf-dhc-options-1533update-03.txt b/doc/draft-ietf-dhc-options-1533update-03.txt new file mode 100644 index 00000000..94896e3a --- /dev/null +++ b/doc/draft-ietf-dhc-options-1533update-03.txt @@ -0,0 +1,2183 @@ + + +Network Working Group S. Alexander +INTERNET DRAFT Silicon Graphics, Inc. +Obsoletes: draft-ietf-dhc-options-1533update-02.txt R. Droms + Bucknell University + April 1996 + Expires October 1996 + + + DHCP Options and BOOTP Vendor Extensions + + +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 + + The Dynamic Host Configuration Protocol (DHCP) [1] provides a + framework for passing configuration information to hosts on a TCP/IP + network. Configuration parameters and other control information are + carried in tagged data items that are stored in the 'options' field + of the DHCP message. The data items themselves are also called + "options." + + This document specifies the current set of DHCP options. Future + options will be specified in separate RFCs. The current list of + valid options is also available in ftp://ftp.isi.edu/in- + notes/iana/assignments [22]. + + All of the vendor information extensions defined in RFC 1497 [2] may + be used as DHCP options. The definitions given in RFC 1497 are + included in this document, which supersedes RFC 1497. All of the + DHCP options defined in this document, except for those specific to + DHCP as defined in section 9, may be used as BOOTP vendor information + + + +Alexander & Droms [Page 1] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + + extensions. + +Table of Contents + + 1. Introduction .............................................. 2 + 2. BOOTP Extension/DHCP Option Field Format .................. 4 + 3. RFC 1497 Vendor Extensions ................................ 5 + 4. IP Layer Parameters per Host .............................. 12 + 5. IP Layer Parameters per Interface ........................ 14 + 6. Link Layer Parameters per Interface ....................... 18 + 7. TCP Parameters ............................................ 19 + 8. Application and Service Parameters ........................ 20 + 9. DHCP Extensions ........................................... 28 + 10. Defining new extensions ................................... 35 + 11. Acknowledgements .......................................... 35 + 12. References ................................................ 36 + 13. Security Considerations ................................... 37 + 14. Authors' Addresses ........................................ 38 + A. Changes to draft-ietf-dhc-options-1533update-00.txt........ 39 + +1. Introduction + + This document specifies options for use with both the Dynamic Host + Configuration Protocol and the Bootstrap Protocol. + + The full description of DHCP packet formats may be found in the DHCP + specification document [1], and the full description of BOOTP packet + formats may be found in the BOOTP specification document [3]. This + document defines the format of information in the last field of DHCP + packets ('options') and of BOOTP packets ('vend'). The remainder of + this section defines a generalized use of this area for giving + information useful to a wide class of machines, operating systems and + configurations. Sites with a single DHCP or BOOTP server that is + shared among heterogeneous clients may choose to define other, site- + specific formats for the use of the 'options' field. + + Section 2 of this memo describes the formats of DHCP options and + BOOTP vendor extensions. Section 3 describes options defined in + previous documents for use with BOOTP (all may also be used with + DHCP). Sections 4-8 define new options intended for use with both + DHCP and BOOTP. Section 9 defines options used only in DHCP. + + References further describing most of the options defined in sections + 2-6 can be found in section 12. The use of the options defined in + section 9 is described in the DHCP specification [1]. + + Information on registering new options is contained in section 10. + + + + +Alexander & Droms [Page 2] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +1.1 Requirements + + Throughout this document, the words that are used to define the + significance of particular requirements are capitalized. These words + are: + + o "MUST" + + This word or the adjective "REQUIRED" means that the + item is an absolute requirement of this specification. + + o "MUST NOT" + + This phrase means that the item is an absolute prohibition + of this specification. + + o "SHOULD" + + This word or the adjective "RECOMMENDED" means that there + may exist valid reasons in particular circumstances to ignore + this item, but the full implications should be understood and + the case carefully weighed before choosing a different course. + + o "SHOULD NOT" + + This phrase means that there may exist valid reasons in + particular circumstances when the listed behavior is acceptable + or even useful, but the full implications should be understood + and the case carefully weighed before implementing any behavior + described with this label. + + o "MAY" + + This word or the adjective "OPTIONAL" means that this item is + truly optional. One vendor may choose to include the item + because a particular marketplace requires it or because it + enhances the product, for example; another vendor may omit the + same item. + +1. Terminology + + This document uses the following terms: + + o "DHCP client" + + A DHCP client or "client" is an Internet host using DHCP to obtain + configuration parameters such as a network address. + + + + +Alexander & Droms [Page 3] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + + o "DHCP server" + + A DHCP server of "server"is an Internet host that returns + configuration parameters to DHCP clients. + + o "binding" + + A binding is a collection of configuration parameters, including + at least an IP address, associated with or "bound to" a DHCP + client. Bindings are managed by DHCP servers. + +2. BOOTP Extension/DHCP Option Field Format + + DHCP options have the same format as the BOOTP 'vendor extensions' + defined in RFC 1497 [2]. Options may be fixed length or variable + length. All options begin with a tag octet, which uniquely + identifies the option. Fixed-length options without data consist of + only a tag octet. Only options 0 and 255 are fixed length. All + other options are variable-length with a length octet following the + tag octet. The value of the length octet does not include the two + octets specifying the tag and length. The length octet is followed + by "length" octets of data. + Options containing NVT ASCII data SHOULD NOT include a trailing NULL; + however, the receiver of such options MUST be prepared to delete + trailing nulls if they exist. + The receiver MUST NOT + require that a trailing null be included in the data. In the case + of some variable-length + options the length field is a constant but must still be specified. + + Any options defined subsequent to this document MUST contain a + length octet even if the length is fixed or zero. + + All multi-octet quantities are in network byte-order. + + When used with BOOTP, the first four octets of the vendor information + field have been assigned to the "magic cookie" (as suggested in RFC + 951). This field identifies the mode in which the succeeding data is + to be interpreted. The value of the magic cookie is the 4 octet + dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in + network byte order. + + All of the "vendor extensions" defined in RFC 1497 are also DHCP + options. + + Option codes 128 to 254 (decimal) are reserved for site-specific + options. + + + + +Alexander & Droms [Page 4] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + + Except for the options in section 9, all options may be used with + either DHCP or BOOTP. + + Many of these options have their default values specified in other + documents. In particular, RFC 1122 [4] specifies default values for + most IP and TCP configuration parameters. + + Many options supply one or more 32-bit IP address. Use of IP + addresses rather than fully-qualified Domain Names (FQDNs) may make + future renumbering of IP hosts more difficult. Use of these addresses + is discouraged at sites that may require renumbering. + +3. RFC 1497 Vendor Extensions + + This section lists the vendor extensions as defined in RFC + 1497. They are defined here for completeness. + +3.1. Pad Option + + The pad option can be used to cause subsequent fields to align on + word boundaries. + + The code for the pad option is 0, and its length is 1 octet. + + Code + +-----+ + | 0 | + +-----+ + +3.2. End Option + + The end option marks the end of valid information in the vendor + field. Subsequent octets should be filled with pad options. + + The code for the end option is 255, and its length is 1 octet. + + Code + +-----+ + | 255 | + +-----+ + + + + + + + + + + + +Alexander & Droms [Page 5] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +3.3. Subnet Mask + + The subnet mask option specifies the client's subnet mask as per RFC + 950 [5]. + + If both the subnet mask and the router option are specified in a DHCP + reply, the subnet mask option MUST be first. + + The code for the subnet mask option is 1, and its length is 4 octets. + + Code Len Subnet Mask + +-----+-----+-----+-----+-----+-----+ + | 1 | 4 | m1 | m2 | m3 | m4 | + +-----+-----+-----+-----+-----+-----+ + +3.4. Time Offset + + The time offset field specifies the offset of the client's subnet in + seconds from Coordinated Universal Time (UTC). The offset is + expressed as a two's complement 32-bit integer. The code for the time + offset option is 2, and its length is 4 octets. + + Code Len Time Offset + +-----+-----+-----+-----+-----+-----+ + | 2 | 4 | n1 | n2 | n3 | n4 | + +-----+-----+-----+-----+-----+-----+ + +3.5. Router Option + + The router option specifies a list of IP addresses for routers on the + client's subnet. Routers SHOULD be listed in order of preference. + + The code for the router option is 3. The minimum length for the + router option is 4 octets, and the length MUST always be a multiple + of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 3 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + + + + + + + + + + + +Alexander & Droms [Page 6] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +3.6. Time Server Option + + The time server option specifies a list of RFC 868 [6] time servers + available to the client. Servers SHOULD be listed in order of + preference. + + The code for the time server option is 4. The minimum length for + this option is 4 octets, and the length MUST always be a multiple of + 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 4 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +3.7. Name Server Option + + The name server option specifies a list of IEN 116 [7] name servers + available to the client. Servers SHOULD be listed in order of + preference. + + The code for the name server option is 5. The minimum length for + this option is 4 octets, and the length MUST always be a multiple of + 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 5 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +3.8. Domain Name Server Option + + The domain name server option specifies a list of Domain Name System + (STD 13, RFC 1035 [8]) name servers available to the client. Servers + SHOULD be listed in order of preference. + + The code for the domain name server option is 6. The minimum length + for this option is 4 octets, and the length MUST always be a multiple + of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 6 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + + + + + + + +Alexander & Droms [Page 7] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +3.9. Log Server Option + + The log server option specifies a list of MIT-LCS UDP log servers + available to the client. Servers SHOULD be listed in order of + preference. + + The code for the log server option is 7. The minimum length for this + option is 4 octets, and the length MUST always be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 7 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +3.10. Cookie Server Option + + The cookie server option specifies a list of RFC 865 [9] cookie + servers available to the client. Servers SHOULD be listed in order + of preference. + + The code for the log server option is 8. The minimum length for this + option is 4 octets, and the length MUST always be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 8 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +3.11. LPR Server Option + + The LPR server option specifies a list of RFC 1179 [10] line printer + servers available to the client. Servers SHOULD be listed in order + of preference. + + The code for the LPR server option is 9. The minimum length for this + option is 4 octets, and the length MUST always be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 9 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + + + + + + + + + + +Alexander & Droms [Page 8] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +3.12. Impress Server Option + + The Impress server option specifies a list of Imagen Impress servers + available to the client. Servers SHOULD be listed in order of + preference. + + The code for the Impress server option is 10. The minimum length for + this option is 4 octets, and the length MUST always be a multiple of + 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 10 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +3.13. Resource Location Server Option + + This option specifies a list of RFC 887 [11] Resource Location + servers available to the client. Servers SHOULD be listed in order + of preference. + + The code for this option is 11. The minimum length for this option + is 4 octets, and the length MUST always be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 11 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +3.14. Host Name Option + + This option specifies the name of the client. The name may or may + not be qualified with the local domain name (see section 3.17 for the + preferred way to retrieve the domain name). See RFC 1035 for + character set restrictions. + + The code for this option is 12, and its minimum length is 1. + + Code Len Host Name + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 12 | n | h1 | h2 | h3 | h4 | h5 | h6 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + + + + + + + + + +Alexander & Droms [Page 9] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +3.15. Boot File Size Option + + This option specifies the length in 512-octet blocks of the default + boot image for the client. The file length is specified as an + unsigned 16-bit integer. + + The code for this option is 13, and its length is 2. + + Code Len File Size + +-----+-----+-----+-----+ + | 13 | 2 | l1 | l2 | + +-----+-----+-----+-----+ + +3.16. Merit Dump File + + This option specifies the path-name of a file to which the client's + core image should be dumped in the event the client crashes. The + path is formatted as a character string consisting of characters from + the NVT ASCII character set. + + The code for this option is 14. Its minimum length is 1. + + Code Len Dump File Pathname + +-----+-----+-----+-----+-----+-----+--- + | 14 | n | n1 | n2 | n3 | n4 | ... + +-----+-----+-----+-----+-----+-----+--- + +3.17. Domain Name + + This option specifies the domain name that client should use when + resolving hostnames via the Domain Name System. + + The code for this option is 15. Its minimum length is 1. + + Code Len Domain Name + +-----+-----+-----+-----+-----+-----+-- + | 15 | n | d1 | d2 | d3 | d4 | ... + +-----+-----+-----+-----+-----+-----+-- + + + + + + + + + + + + + +Alexander & Droms [Page 10] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +3.18. Swap Server + + This specifies the IP address of the client's swap server. + + The code for this option is 16 and its length is 4. + + Code Len Swap Server Address + +-----+-----+-----+-----+-----+-----+ + | 16 | n | a1 | a2 | a3 | a4 | + +-----+-----+-----+-----+-----+-----+ + +3.19. Root Path + + This option specifies the path-name that contains the client's root + disk. The path is formatted as a character string consisting of + characters from the NVT ASCII character set. + + The code for this option is 17. Its minimum length is 1. + + Code Len Root Disk Pathname + +-----+-----+-----+-----+-----+-----+--- + | 17 | n | n1 | n2 | n3 | n4 | ... + +-----+-----+-----+-----+-----+-----+--- + +3.20. Extensions Path + + A string to specify a file, retrievable via TFTP, which contains + information which can be interpreted in the same way as the 64-octet + vendor-extension field within the BOOTP response, with the following + exceptions: + + - the length of the file is unconstrained; + - all references to Tag 18 (i.e., instances of the + BOOTP Extensions Path field) within the file are + ignored. + + The code for this option is 18. Its minimum length is 1. + + Code Len Extensions Pathname + +-----+-----+-----+-----+-----+-----+--- + | 18 | n | n1 | n2 | n3 | n4 | ... + +-----+-----+-----+-----+-----+-----+--- + + + + + + + + + +Alexander & Droms [Page 11] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +4. IP Layer Parameters per Host + + This section details the options that affect the operation of the IP + layer on a per-host basis. + +4.1. IP Forwarding Enable/Disable Option + + This option specifies whether the client should configure its IP + layer for packet forwarding. A value of 0 means disable IP + forwarding, and a value of 1 means enable IP forwarding. + + The code for this option is 19, and its length is 1. + + Code Len Value + +-----+-----+-----+ + | 19 | 1 | 0/1 | + +-----+-----+-----+ + +4.2. Non-Local Source Routing Enable/Disable Option + + This option specifies whether the client should configure its IP + layer to allow forwarding of datagrams with non-local source routes + (see Section 3.3.5 of [4] for a discussion of this topic). A value + of 0 means disallow forwarding of such datagrams, and a value of 1 + means allow forwarding. + + The code for this option is 20, and its length is 1. + + Code Len Value + +-----+-----+-----+ + | 20 | 1 | 0/1 | + +-----+-----+-----+ + + + + + + + + + + + + + + + + + + + +Alexander & Droms [Page 12] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +4.3. Policy Filter Option + + This option specifies policy filters for non-local source routing. + The filters consist of a list of IP addresses and masks which specify + destination/mask pairs with which to filter incoming source routes. + + Any source routed datagram whose next-hop address does not match one + of the filters should be discarded by the client. + + See [4] for further information. + + The code for this option is 21. The minimum length of this option is + 8, and the length MUST be a multiple of 8. + + Code Len Address 1 Mask 1 + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ + | 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ + Address 2 Mask 2 + +-----+-----+-----+-----+-----+-----+-----+-----+--- + | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+--- + +4.4. Maximum Datagram Reassembly Size + + This option specifies the maximum size datagram that the client + should be prepared to reassemble. The size is specified as a 16-bit + unsigned integer. The minimum value legal value is 576. + + The code for this option is 22, and its length is 2. + + Code Len Size + +-----+-----+-----+-----+ + | 22 | 2 | s1 | s2 | + +-----+-----+-----+-----+ + + + + + + + + + + + + + + + + +Alexander & Droms [Page 13] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +4.5. Default IP Time-to-live + + This option specifies the default time-to-live that the client should + use on outgoing datagrams. The TTL is specified as an octet with a + value between 1 and 255. + + The code for this option is 23, and its length is 1. + + Code Len TTL + +-----+-----+-----+ + | 23 | 1 | ttl | + +-----+-----+-----+ + +4.6. Path MTU Aging Timeout Option + + This option specifies the timeout (in seconds) to use when aging Path + MTU values discovered by the mechanism defined in RFC 1191 [12]. The + timeout is specified as a 32-bit unsigned integer. + + The code for this option is 24, and its length is 4. + + Code Len Timeout + +-----+-----+-----+-----+-----+-----+ + | 24 | 4 | t1 | t2 | t3 | t4 | + +-----+-----+-----+-----+-----+-----+ + +4.7. Path MTU Plateau Table Option + + This option specifies a table of MTU sizes to use when performing + Path MTU Discovery as defined in RFC 1191. The table is formatted as + a list of 16-bit unsigned integers, ordered from smallest to largest. + The minimum MTU value cannot be smaller than 68. + + The code for this option is 25. Its minimum length is 2, and the + length MUST be a multiple of 2. + + Code Len Size 1 Size 2 + +-----+-----+-----+-----+-----+-----+--- + | 25 | n | s1 | s2 | s1 | s2 | ... + +-----+-----+-----+-----+-----+-----+--- + +5. IP Layer Parameters per Interface + + This section details the options that affect the operation of the IP + layer on a per-interface basis. It is expected that a client can + issue multiple requests, one per interface, in order to configure + interfaces with their specific parameters. + + + + +Alexander & Droms [Page 14] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +5.1. Interface MTU Option + + This option specifies the MTU to use on this interface. The MTU is + specified as a 16-bit unsigned integer. The minimum legal value for + the MTU is 68. + + The code for this option is 26, and its length is 2. + + Code Len MTU + +-----+-----+-----+-----+ + | 26 | 2 | m1 | m2 | + +-----+-----+-----+-----+ + +5.2. All Subnets are Local Option + + This option specifies whether or not the client may assume that all + subnets of the IP network to which the client is connected use the + same MTU as the subnet of that network to which the client is + directly connected. A value of 1 indicates that all subnets share + the same MTU. A value of 0 means that the client should assume that + some subnets of the directly connected network may have smaller MTUs. + + The code for this option is 27, and its length is 1. + + Code Len Value + +-----+-----+-----+ + | 27 | 1 | 0/1 | + +-----+-----+-----+ + +5.3. Broadcast Address Option + + This option specifies the broadcast address in use on the client's + subnet. Legal values for broadcast addresses are specified in + section 3.2.1.3 of [4]. + + The code for this option is 28, and its length is 4. + + Code Len Broadcast Address + +-----+-----+-----+-----+-----+-----+ + | 28 | 4 | b1 | b2 | b3 | b4 | + +-----+-----+-----+-----+-----+-----+ + + + + + + + + + + +Alexander & Droms [Page 15] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +5.4. Perform Mask Discovery Option + + This option specifies whether or not the client should perform subnet + mask discovery using ICMP. A value of 0 indicates that the client + should not perform mask discovery. A value of 1 means that the + client should perform mask discovery. + + The code for this option is 29, and its length is 1. + + Code Len Value + +-----+-----+-----+ + | 29 | 1 | 0/1 | + +-----+-----+-----+ + +5.5. Mask Supplier Option + + This option specifies whether or not the client should respond to + subnet mask requests using ICMP. A value of 0 indicates that the + client should not respond. A value of 1 means that the client should + respond. + + The code for this option is 30, and its length is 1. + + Code Len Value + +-----+-----+-----+ + | 30 | 1 | 0/1 | + +-----+-----+-----+ + +5.6. Perform Router Discovery Option + + This option specifies whether or not the client should solicit + routers using the Router Discovery mechanism defined in RFC 1256 + [13]. A value of 0 indicates that the client should not perform + router discovery. A value of 1 means that the client should perform + router discovery. + + The code for this option is 31, and its length is 1. + + Code Len Value + +-----+-----+-----+ + | 31 | 1 | 0/1 | + +-----+-----+-----+ + + + + + + + + + +Alexander & Droms [Page 16] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +5.7. Router Solicitation Address Option + + This option specifies the address to which the client should transmit + router solicitation requests. + + The code for this option is 32, and its length is 4. + + Code Len Address + +-----+-----+-----+-----+-----+-----+ + | 32 | 4 | a1 | a2 | a3 | a4 | + +-----+-----+-----+-----+-----+-----+ + +5.8. Static Route Option + + This option specifies a list of static routes that the client should + install in its routing cache. If multiple routes to the same + destination are specified, they are listed in descending order of + priority. + + The routes consist of a list of IP address pairs. The first address + is the destination address, and the second address is the router for + the destination. + + The default route (0.0.0.0) is an illegal destination for a static + route. See section 3.5 for information about the router option. + + The code for this option is 33. The minimum length of this option is + 8, and the length MUST be a multiple of 8. + + Code Len Destination 1 Router 1 + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ + | 33 | n | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ + Destination 2 Router 2 + +-----+-----+-----+-----+-----+-----+-----+-----+--- + | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+--- + + + + + + + + + + + + + + +Alexander & Droms [Page 17] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +6. Link Layer Parameters per Interface + + This section lists the options that affect the operation of the data + link layer on a per-interface basis. + +6.1. Trailer Encapsulation Option + + This option specifies whether or not the client should negotiate the + use of trailers (RFC 893 [14]) when using the ARP protocol. A value + of 0 indicates that the client should not attempt to use trailers. A + value of 1 means that the client should attempt to use trailers. + + The code for this option is 34, and its length is 1. + + Code Len Value + +-----+-----+-----+ + | 34 | 1 | 0/1 | + +-----+-----+-----+ + +6.2. ARP Cache Timeout Option + + This option specifies the timeout in seconds for ARP cache entries. + The time is specified as a 32-bit unsigned integer. + + The code for this option is 35, and its length is 4. + + Code Len Time + +-----+-----+-----+-----+-----+-----+ + | 35 | 4 | t1 | t2 | t3 | t4 | + +-----+-----+-----+-----+-----+-----+ + +6.3. Ethernet Encapsulation Option + + This option specifies whether or not the client should use Ethernet + Version 2 (RFC 894 [15]) or IEEE 802.3 (RFC 1042 [16]) encapsulation + if the interface is an Ethernet. A value of 0 indicates that the + client should use RFC 894 encapsulation. A value of 1 means that the + client should use RFC 1042 encapsulation. + + The code for this option is 36, and its length is 1. + + Code Len Value + +-----+-----+-----+ + | 36 | 1 | 0/1 | + +-----+-----+-----+ + + + + + + +Alexander & Droms [Page 18] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +7. TCP Parameters + + This section lists the options that affect the operation of the TCP + layer on a per-interface basis. + +7.1. TCP Default TTL Option + + This option specifies the default TTL that the client should use when + sending TCP segments. The value is represented as an 8-bit unsigned + integer. The minimum value is 1. + + The code for this option is 37, and its length is 1. + + Code Len TTL + +-----+-----+-----+ + | 37 | 1 | n | + +-----+-----+-----+ + +7.2. TCP Keepalive Interval Option + + This option specifies the interval (in seconds) that the client TCP + should wait before sending a keepalive message on a TCP connection. + The time is specified as a 32-bit unsigned integer. A value of zero + indicates that the client should not generate keepalive messages on + connections unless specifically requested by an application. + + The code for this option is 38, and its length is 4. + + Code Len Time + +-----+-----+-----+-----+-----+-----+ + | 38 | 4 | t1 | t2 | t3 | t4 | + +-----+-----+-----+-----+-----+-----+ + +7.3. TCP Keepalive Garbage Option + + This option specifies the whether or not the client should send TCP + keepalive messages with a octet of garbage for compatibility with + older implementations. A value of 0 indicates that a garbage octet + should not be sent. A value of 1 indicates that a garbage octet + should be sent. + + The code for this option is 39, and its length is 1. + + Code Len Value + +-----+-----+-----+ + | 39 | 1 | 0/1 | + +-----+-----+-----+ + + + + +Alexander & Droms [Page 19] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +8. Application and Service Parameters + + This section details some miscellaneous options used to configure + miscellaneous applications and services. + +8.1. Network Information Service Domain Option + + This option specifies the name of the client's NIS [17] domain. The + domain is formatted as a character string consisting of characters + from the NVT ASCII character set. + + The code for this option is 40. Its minimum length is 1. + + Code Len NIS Domain Name + +-----+-----+-----+-----+-----+-----+--- + | 40 | n | n1 | n2 | n3 | n4 | ... + +-----+-----+-----+-----+-----+-----+--- + +8.2. Network Information Servers Option + + This option specifies a list of IP addresses indicating NIS servers + available to the client. Servers SHOULD be listed in order of + preference. + + The code for this option is 41. Its minimum length is 4, and the + length MUST be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 41 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +8.3. Network Time Protocol Servers Option + + This option specifies a list of IP addresses indicating NTP [18] + servers available to the client. Servers SHOULD be listed in order + of preference. + + The code for this option is 42. Its minimum length is 4, and the + length MUST be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 42 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + + + + + + +Alexander & Droms [Page 20] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +8.4. Vendor Specific Information + + This option is used by clients and servers to exchange vendor- + specific information. The information is an opaque object of n + octets, presumably interpreted by vendor-specific code on the clients + and servers. The definition of this information is vendor specific. + The vendor is indicated in the vendor class identifier option. + Servers not equipped to interpret the vendor-specific information + sent by a client MUST ignore it (although it may be reported). + Clients which do not receive desired vendor-specific information + SHOULD make an attempt to operate without it, although they may do so + (and announce they are doing so) in a degraded mode. + + If a vendor potentially encodes more than one item of information in + this option, then the vendor SHOULD encode the option using + "Encapsulated vendor-specific options" as described below: + + The Encapsulated vendor-specific options field SHOULD be encoded as a + sequence of code/length/value fields of identical syntax to the DHCP + options field with the following exceptions: + + 1) There SHOULD NOT be a "magic cookie" field in the encapsulated + vendor-specific extensions field. + + 2) Codes other than 0 or 255 MAY be redefined by the vendor within + the encapsulated vendor-specific extensions field, but SHOULD + conform to the tag-length-value syntax defined in section 2. + + 3) Code 255 (END), if present, signifies the end of the + encapsulated vendor extensions, not the end of the vendor + extensions field. If no code 255 is present, then the end of + the enclosing vendor-specific information field is taken as the + end of the encapsulated vendor-specific extensions field. + + The code for this option is 43 and its minimum length is 1. + + Code Len Vendor-specific information + +-----+-----+-----+-----+--- + | 43 | n | i1 | i2 | ... + +-----+-----+-----+-----+--- + + When encapsulated vendor-specific extensions are used, the + information bytes 1-n have the following format: + + Code Len Data item Code Len Data item Code + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ + | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... | + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ + + + +Alexander & Droms [Page 21] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +8.5. NetBIOS over TCP/IP Name Server Option + + The NetBIOS name server (NBNS) option specifies a list of RFC + 1001/1002 [19] [20] NBNS name servers listed in order of preference. + + The code for this option is 44. The minimum length of the option is + 4 octets, and the length must always be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- + | 44 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- + +8.6. NetBIOS over TCP/IP Datagram Distribution Server Option + + The NetBIOS datagram distribution server (NBDD) option specifies a + list of RFC 1001/1002 NBDD servers listed in order of preference. The + code for this option is 45. The minimum length of the option is 4 + octets, and the length must always be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- + | 45 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- + +8.7. NetBIOS over TCP/IP Node Type Option + + The NetBIOS node type option allows NetBIOS over TCP/IP clients which + are configurable to be configured as described in RFC 1001/1002. The + value is specified as a single octet which identifies the client type + as follows: + + Value Node Type + ----- --------- + 0x1 B-node + 0x2 P-node + 0x4 M-node + 0x8 H-node + + In the above chart, the notation '0x' indicates a number in base-16 + (hexadecimal). + + + + + + + + + + +Alexander & Droms [Page 22] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + + The code for this option is 46. The length of this option is always + 1. + + Code Len Node Type + +-----+-----+-----------+ + | 46 | 1 | see above | + +-----+-----+-----------+ + +8.8. NetBIOS over TCP/IP Scope Option + + The NetBIOS scope option specifies the NetBIOS over TCP/IP scope + parameter for the client as specified in RFC 1001/1002. See [19], + [20], and [8] for character-set restrictions. + + The code for this option is 47. The minimum length of this option is + 1. + + Code Len NetBIOS Scope + +-----+-----+-----+-----+-----+-----+---- + | 47 | n | s1 | s2 | s3 | s4 | ... + +-----+-----+-----+-----+-----+-----+---- + +8.9. X Window System Font Server Option + + This option specifies a list of X Window System [21] Font servers + available to the client. Servers SHOULD be listed in order of + preference. + + The code for this option is 48. The minimum length of this option is + 4 octets, and the length MUST be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+--- + | 48 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+--- + + + + + + + + + + + + + + + + +Alexander & Droms [Page 23] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +8.10. X Window System Display Manager Option + + This option specifies a list of IP addresses of systems that are + running the X Window System Display Manager and are available to the + client. + + Addresses SHOULD be listed in order of preference. + + The code for the this option is 49. The minimum length of this option + is 4, and the length MUST be a multiple of 4. + + Code Len Address 1 Address 2 + + +-----+-----+-----+-----+-----+-----+-----+-----+--- + | 49 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+--- + +8.11. Network Information Service+ Domain Option + + This option specifies the name of the client's NIS+ [17] domain. The + domain is formatted as a character string consisting of characters + from the NVT ASCII character set. + + The code for this option is 64. Its minimum length is 1. + + Code Len NIS Client Domain Name + +-----+-----+-----+-----+-----+-----+--- + | 64 | n | n1 | n2 | n3 | n4 | ... + +-----+-----+-----+-----+-----+-----+--- + +8.12. Network Information Service+ Servers Option + + This option specifies a list of IP addresses indicating NIS+ servers + available to the client. Servers SHOULD be listed in order of + preference. + + The code for this option is 65. Its minimum length is 4, and the + length MUST be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 65 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + + + + + + + + +Alexander & Droms [Page 24] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +8.13. Mobile IP Home Agent option + + This option specifies a list of IP addresses indicating mobile IP + home agents available to the client. Agents SHOULD be listed in + order of preference. + + The code for this option is 68. Its minimum length is 0 (indicating + no home agents are available) and the length MUST be a multiple of 4. + It is expected that the usual length will be four octets, containing + a single home agent's address. + + Code Len Home Agent Addresses (zero or more) + +-----+-----+-----+-----+-----+-----+-- + | 68 | n | a1 | a2 | a3 | a4 | ... + +-----+-----+-----+-----+-----+-----+-- + +8.14. Simple Mail Transport Protocol (SMTP) Server Option + + The SMTP server option specifies a list of SMTP servers available to + the client. Servers SHOULD be listed in order of preference. + + The code for the SMTP server option is 69. The minimum length for + this option is 4 octets, and the length MUST always be a multiple of + 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 69 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +8.15. Post Office Protocol (POP3) Server Option + + The POP3 server option specifies a list of POP3 available to the + client. Servers SHOULD be listed in order of preference. + + The code for the POP3 server option is 70. The minimum length for + this option is 4 octets, and the length MUST always be a multiple of + 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 70 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + + + + + + + + +Alexander & Droms [Page 25] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +8.16. Network News Transport Protocol (NNTP) Server Option + + The NNTP server option specifies a list of NNTP available to the + client. Servers SHOULD be listed in order of preference. + + The code for the NNTP server option is 71. The minimum length for + this option is 4 octets, and the length MUST always be a multiple of + 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 71 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +8.17. Default World Wide Web (WWW) Server Option + + The WWW server option specifies a list of WWW available to the + client. Servers SHOULD be listed in order of preference. + + The code for the WWW server option is 72. The minimum length for + this option is 4 octets, and the length MUST always be a multiple of + 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 72 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +8.18. Default Finger Server Option + + The Finger server option specifies a list of Finger available to the + client. Servers SHOULD be listed in order of preference. + + The code for the Finger server option is 73. The minimum length for + this option is 4 octets, and the length MUST always be a multiple of + 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 73 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + + + + + + + + + + +Alexander & Droms [Page 26] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +8.19. Default Internet Relay Chat (IRC) Server Option + + The IRC server option specifies a list of IRC available to the + client. Servers SHOULD be listed in order of preference. + + The code for the IRC server option is 74. The minimum length for + this option is 4 octets, and the length MUST always be a multiple of + 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 74 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +8.20. StreetTalk Server Option + + The StreetTalk server option specifies a list of StreetTalk servers + available to the client. Servers SHOULD be listed in order of + preference. + + The code for the StreetTalk server option is 75. The minimum length + for this option is 4 octets, and the length MUST always be a multiple + of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 75 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + +8.21. StreetTalk Directory Assistance (STDA) Server Option + + The StreetTalk Directory Assistance (STDA) server option specifies a + list of STDA servers available to the client. Servers SHOULD be + listed in order of preference. + + The code for the StreetTalk Directory Assistance server option is 76. + The minimum length for this option is 4 octets, and the length MUST + always be a multiple of 4. + + Code Len Address 1 Address 2 + +-----+-----+-----+-----+-----+-----+-----+-----+-- + | 76 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... + +-----+-----+-----+-----+-----+-----+-----+-----+-- + + + + + + + + +Alexander & Droms [Page 27] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +9. DHCP Extensions + + This section details the options that are specific to DHCP. + +9.1. Requested IP Address + + This option is used in a client request (DHCPDISCOVER) to allow the + client to request that a particular IP address be assigned. + + The code for this option is 50, and its length is 4. + + Code Len Address + +-----+-----+-----+-----+-----+-----+ + | 50 | 4 | a1 | a2 | a3 | a4 | + +-----+-----+-----+-----+-----+-----+ + +9.2. IP Address Lease Time + + This option is used in a client request (DHCPDISCOVER or DHCPREQUEST) + to allow the client to request a lease time for the IP address. In a + server reply (DHCPOFFER), a DHCP server uses this option to specify + the lease time it is willing to offer. + + The time is in units of seconds, and is specified as a 32-bit + unsigned integer. + + The code for this option is 51, and its length is 4. + + Code Len Lease Time + +-----+-----+-----+-----+-----+-----+ + | 51 | 4 | t1 | t2 | t3 | t4 | + +-----+-----+-----+-----+-----+-----+ + +9.3. Option Overload + + This option is used to indicate that the DHCP 'sname' or 'file' + fields are being overloaded by using them to carry DHCP options. A + DHCP server inserts this option if the returned parameters will + exceed the usual space allotted for options. + + If this option is present, the client interprets the specified + additional fields after it concludes interpretation of the standard + option fields. + + + + + + + + +Alexander & Droms [Page 28] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + + The code for this option is 52, and its length is 1. Legal values + for this option are: + + Value Meaning + ----- -------- + 1 the 'file' field is used to hold options + 2 the 'sname' field is used to hold options + 3 both fields are used to hold options + + Code Len Value + +-----+-----+-----+ + | 52 | 1 |1/2/3| + +-----+-----+-----+ + +9.4 TFTP server name + + This option is used to identify a TFTP server when the 'sname' + field in the DHCP header has been used for DHCP options. + + The code for this option is 66, and its minimum length is 1. + + Code Len TFTP server + +-----+-----+-----+-----+-----+--- + | 66 | n | c1 | c2 | c3 | ... + +-----+-----+-----+-----+-----+--- + +9.5 Bootfile name + + This option is used to identify a bootfile when the 'file' field in + the DHCP header has been used for DHCP options. + + The code for this option is 67, and its minimum length is 1. + + Code Len Bootfile name + +-----+-----+-----+-----+-----+--- + | 67 | n | c1 | c2 | c3 | ... + +-----+-----+-----+-----+-----+--- + + + + + + + + + + + + + + +Alexander & Droms [Page 29] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +9.6. DHCP Message Type + + This option is used to convey the type of the DHCP message. The code + for this option is 53, and its length is 1. Legal values for this + option are: + + Value Message Type + ----- ------------ + 1 DHCPDISCOVER + 2 DHCPOFFER + 3 DHCPREQUEST + 4 DHCPDECLINE + 5 DHCPACK + 6 DHCPNAK + 7 DHCPRELEASE + 8 DHCPINFORM + + Code Len Type + +-----+-----+-----+ + | 53 | 1 | 1-9 | + +-----+-----+-----+ + +9.7. Server Identifier + + This option is used in DHCPOFFER and DHCPREQUEST messages, and may + optionally be included in the DHCPACK and DHCPNAK messages. DHCP + servers include this option in the DHCPOFFER in order to allow the + client to distinguish between lease offers. DHCP clients indicate + which of several lease offers is being accepted by including this + option in a DHCPREQUEST message. + + The identifier is the IP address of the selected server. + + The code for this option is 54, and its length is 4. + + Code Len Address + +-----+-----+-----+-----+-----+-----+ + | 54 | 4 | a1 | a2 | a3 | a4 | + +-----+-----+-----+-----+-----+-----+ + + + + + + + + + + + + +Alexander & Droms [Page 30] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +9.8. Parameter Request List + + This option is used by a DHCP client to request values for specified + configuration parameters. The list of requested parameters is + specified as n octets, where each octet is a valid DHCP option code + as defined in this document. + + The client MAY list the options in order of preference. The DHCP + server is not required to return the options in the requested order, + but MUST try to insert the requested options in the order requested + by the client. + + The code for this option is 55. Its minimum length is 1. + + Code Len Option Codes + +-----+-----+-----+-----+--- + | 55 | n | c1 | c2 | ... + +-----+-----+-----+-----+--- + +9.9. Message + + This option is used by a DHCP server to provide an error message to a + DHCP client in a DHCPNAK message in the event of a failure. A client + may use this option in a DHCPDECLINE message to indicate the why the + client declined the offered parameters. The message consists of n + octets of NVT ASCII text, which the client may display on an + available output device. + + The code for this option is 56 and its minimum length is 1. + + Code Len Text + +-----+-----+-----+-----+--- + | 56 | n | c1 | c2 | ... + +-----+-----+-----+-----+--- + + + + + + + + + + + + + + + + + +Alexander & Droms [Page 31] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +9.10. Maximum DHCP Message Size + + This option specifies the maximum length DHCP message that it is + willing to accept. The length is specified as an unsigned 16-bit + integer. A client may use the maximum DHCP message size option in + DHCPDISCOVER or DHCPREQUEST messages, but should not use the option + in DHCPDECLINE messages. + + The code for this option is 57, and its length is 2. The minimum + legal value is 576 octets. + + Code Len Length + +-----+-----+-----+-----+ + | 57 | 2 | l1 | l2 | + +-----+-----+-----+-----+ + +9.11. Renewal (T1) Time Value + + This option specifies the time interval from address assignment until + the client transitions to the RENEWING state. + + The value is in units of seconds, and is specified as a 32-bit + unsigned integer. + + The code for this option is 58, and its length is 4. + + Code Len T1 Interval + +-----+-----+-----+-----+-----+-----+ + | 58 | 4 | t1 | t2 | t3 | t4 | + +-----+-----+-----+-----+-----+-----+ + +9.12. Rebinding (T2) Time Value + + This option specifies the time interval from address assignment until + the client transitions to the REBINDING state. + + The value is in units of seconds, and is specified as a 32-bit + unsigned integer. + + The code for this option is 59, and its length is 4. + + Code Len T2 Interval + +-----+-----+-----+-----+-----+-----+ + | 59 | 4 | t1 | t2 | t3 | t4 | + +-----+-----+-----+-----+-----+-----+ + + + + + + +Alexander & Droms [Page 32] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +9.13. Vendor class identifier + + This option is used by DHCP clients to optionally identify the vendor + type and configuration of a DHCP client. The information is a string + of n octets, interpreted by servers. Vendors may choose to define + specific vendor class identifiers to convey particular configuration + or other identification information about a client. For example, the + identifier may encode the client's hardware configuration. Servers + not equipped to interpret the class-specific information sent by a + client MUST ignore it (although it may be reported). Servers that + respond SHOULD only use option 43 to return the vendor-specific + information to the client. + + The code for this option is 60, and its minimum length is 1. + + Code Len Vendor class Identifier + +-----+-----+-----+-----+--- + | 60 | n | i1 | i2 | ... + +-----+-----+-----+-----+--- + +9.14. Client-identifier + + This option is used by DHCP clients to specify their unique + identifier. DHCP servers use this value to index their database of + address bindings. This value is expected to be unique for all + clients in an administrative domain. + + Identifiers SHOULD be treated as opaque objects by DHCP servers. + + The client identifier MAY consist of type-value pairs similar to the + 'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist + of a hardware type and hardware address. In this case the type field + SHOULD be one of the ARP hardware types defined in STD2 [22]. A + hardware type of 0 (zero) should be used when the value field + contains an identifier other than a hardware address (e.g. a fully + qualified domain name). + + For correct identification of clients, each client's client- + identifier MUST be unique among the client-identifiers used on the + subnet to which the client is attached. Vendors and system + administrators are responsible for choosing client-identifiers that + meet this requirement for uniqueness. + + + + + + + + + +Alexander & Droms [Page 33] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + + The code for this option is 61, and its minimum length is 2. + + Code Len Type Client-Identifier + +-----+-----+-----+-----+-----+--- + | 61 | n | t1 | i1 | i2 | ... + +-----+-----+-----+-----+-----+--- + +9.15. User Class Information + + This option is used by a DHCP client to optionally identify the type + or category of user or applications it represents. The information + contained in this option is an NVT ASCII text object that represents + the user class of which the client is a member. + + DHCP administrators may define specific user class identifiers to + convey information about a client's software configuration or about + its user's preferences. For example, an identifier may specify that + a particular DHCP client is a member of the class "accounting + auditors", which have special service needs such as a particular + database server. + + Servers not equipped to interpret any of user classes specified by a + client MUST ignore it (although it may be reported). Otherwise, + servers SHOULD respond with the set of options corresponding to the + user class specified by the client. Further, if the server responds, + it MUST return this option to the client. + + Clients which do not receive information for the user class requested + SHOULD make an attempt to operate without it, although they may do so + (and may announce they are doing so) in a degraded mode. + + The code for this option is 77. The minimum length for this option + is two. + + Code Len text1 + +-----+-----+-----+-----+----- + | 77 | N | c1 | c2 | ... + +-----+-----+-----+-----+----- + + + + + + + + + + + + + +Alexander & Droms [Page 34] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +10. Defining new extensions + + The author of a new DHCP option will follow these steps to obtain + acceptance of the option as a part of the DHCP Internet Standard: + + 1. The author devises the new option. + 2. The author requests a number for the new option from IANA by + contacting: + Internet Assigned Numbers Authority (IANA) + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, California 90292-6695 + + or by email as: iana@isi.edu + + 3. The author documents the new option, using the newly obtained + option number, as an Internet Draft. + 4. The author submits the Internet Draft for review through the IETF + standards process as defined in "Internet Official Protocol + Standards" (STD 1). The new option will be submitted for eventual + acceptance as an Internet Standard. + 5. The new option progresses through the IETF standards process; the + new option will be reviewed by the Dynamic Host Configuration + Working Group (if that group still exists), or as an Internet + Draft not submitted by an IETF working group. + 6. If the new option fails to gain acceptance as an Internet + Standard, the assigned option number will be returned to IANA for + reassignment. + + This procedure for defining new extensions will ensure that: + + * allocation of new option numbers is coordinated from a single + authority, + * new options are reviewed for technical correctness and + appropriateness, and + * documentation for new options is complete and published. + +11. Acknowledgements + + The authors would like to thank Philip Almquist for his feedback + on this document. The comments of the DHCP Working Group are + also gratefully acknowledged. In particular, Mike Carney and + Jon Dreyer from SunSelect suggested the current format of the + Vendor-specific Information option. + + RFC 1497 is based on earlier work by Philip Prindeville, with + help from Drew Perkins, Bill Croft, and Steve Deering. + + + + +Alexander & Droms [Page 35] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +12. References + + [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531, + Bucknell University, October 1993. + + [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, + USC/Information Sciences Institute, August 1993. + + [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951, + Stanford University and Sun Microsystems, September 1985. + + [4] Braden, R., Editor, "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, USC/Information Sciences + Institute, October 1989. + + [5] Mogul, J., and J. Postel, "Internet Standard Subnetting + Procedure", STD 5, RFC 950, USC/Information Sciences Institute, + August 1985. + + [6] Postel, J., and K. Harrenstien, "Time Protocol", STD 26, RFC + 868, USC/Information Sciences Institute, SRI, May 1983. + + [7] Postel, J., "Name Server", IEN 116, USC/Information Sciences + Institute, August 1979. + + [8] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + [9] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865, + USC/Information Sciences Institute, May 1983. + + [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The + Wollongong Group, August 1990. + + [11] Accetta, M., "Resource Location Protocol", RFC 887, CMU, + December 1983. + + [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, + DECWRL, Stanford University, November 1990. + + [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, + Xerox PARC, September 1991. + + [14] Leffler, S. and M. Karels, "Trailer Encapsulations", RFC 893, + U. C. Berkeley, April 1984. + + [15] Hornig, C., "Standard for the Transmission of IP Datagrams over + + + +Alexander & Droms [Page 36] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + + Ethernet Networks", RFC 894, Symbolics, April 1984. + + [16] Postel, J. and J. Reynolds, "Standard for the Transmission of + IP Datagrams Over IEEE 802 Networks", RFC 1042, USC/Information + Sciences Institute, February 1988. + + [17] Sun Microsystems, "System and Network Administration", March + 1990. + + [18] Mills, D., "Internet Time Synchronization: The Network Time + Protocol", RFC 1305, UDEL, March 1992. + + [19] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service + on a TCP/UDP transport: Concepts and Methods", STD 19, RFC 1001, + March 1987. + + [20] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service + on a TCP/UDP transport: Detailed Specifications", STD 19, RFC + 1002, March 1987. + + [21] Scheifler, R., "FYI On the X Window System", FYI 6, RFC 1198, + MIT Laboratory for Computer Science, January 1991. + + [22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + USC/Information Sciences Institute, July 1992. + +13. Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + + + + + + + +Alexander & Droms [Page 37] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +14. Authors' Addresses + + Steve Alexander + Silicon Graphics, Inc. + 2011 N. Shoreline Boulevard + Mailstop 510 + Mountain View, CA 94043-1389 + + Phone: (415) 933-6172 + EMail: sca@engr.sgi.com + + Ralph Droms + Computer Science Department + 323 Dana Engineering + Bucknell University + Lewisburg, PA 17837 + + Phone: (717) 524-1145 + EMail: droms@bucknell.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Alexander & Droms [Page 38] + +DRAFT DHCP Options and BOOTP Vendor Extensions April 1996 + + +A. Changes to draft-ietf-dhc-options-1533update-0[0-3].txt: + +* Section 8.4 - changed to indicate vendor-specific information is + interpreted based on vendor class identifier. + +* Section 9.13 - changed "Class-identifier" to "Vendor class + identifier" + +* Added section 9.15 describing "User class identifier" + +* Added "Many options supply one or more 32-bit IP address. Use of IP + addresses rather than fully-qualified Domain Names (FQDNs) may make + future renumbering of IP hosts more difficult. Use of these addresses + is discouraged at sites that may require renumbering." to section 2. + +* In section 3.4 (Time Offset), replaced "signed" with "two's + complement". + +* In section 2, replaced "should" with "MUST" in "Any options defined + subsequent to this document MUST contain a length octet even if the + length is fixed or zero. + +* Added sections 1.1 and 1.2 defining requirements language and DHCP + terminology used throughout the document. + +* Added text to section 9.14 to emphasize the need for uniqueness + among client-identifiers: + + "For correct identification of clients, each client's client-identifier + MUST be unique among the client-identifiers used on the subnet to + which the client is attached. Vendors and system administrators are + responsible for choosing client-identifiers that meet this requirement + for uniqueness." + +* Modified section 10 to specify a new procedure for defining new DHCP + options. + + + + + + + + + + + + + + + +Alexander & Droms [Page 39] + diff --git a/doc/draft-ietf-dhc-options-opt127-02.txt b/doc/draft-ietf-dhc-options-opt127-02.txt new file mode 100644 index 00000000..d42a33ea --- /dev/null +++ b/doc/draft-ietf-dhc-options-opt127-02.txt @@ -0,0 +1,167 @@ + + +Network Working Group R. Droms +INTERNET DRAFT Bucknell University +Obsoletes: draft-ietf-dhc-options-opt127-01.txt April 1996 + Expires October 1996 + + + An Extension to the DHCP Option Codes + + +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 + + The Dynamic Host Configuration Protocol (DHCP) provides a framework + for passing configuration information to hosts on a TCP/IP network. + This document defines a new option to extend the available option + codes. + +Introduction + + The Dynamic Host Configuration Protocol (DHCP) [1] provides a + framework for passing configuration information to hosts on a TCP/IP + network. Configuration parameters and other control information are + carried in tagged data items that are stored in the 'options' field + of the DHCP message. The data items themselves are also called + "options." + + Each option is assigned a one-octet option code. Options 128-254 are + reserved for local use and at this time over half of the available + options in the range 0-127 and option 255 have been assigned. This + document defines a new option to extend the available option codes + and new option to request the parameters represented by those new + + + +Droms [Page 1] + +DRAFT An extension to the DHCP Option Codes April 1996 + + + option codes. + +Definition of option 127 + + Option code 127 indicates that the DHCP option has a two-octet + extended option code. The format of these options is: + + Extended + Code Len option code Data... + +-----+-----+-----+-----+-----+-----+---- + | 127 | XXX | oh | ol | d1 | d2 | ... + +-----+-----+-----+-----+-----+-----+---- + + Other than the two-octet extended option code, these options are + encoded and carried in DHCP messages identically to the options + defined in RFC 1533 [2]. The high-order and low-order octets of the + extended option code are stored in 'oh' and 'ol', respectively. The + number of octets given in the 'len' field includes the two-octet + extended option code. + + The two-octet extended option codes will be assigned through the + mechanisms defined for the assignment of new options [3] after the + current one-octet option codes have been exhausted. + +Definition of option 126 + + This option is used by a DHCP client to request values for specified + configuration paramaters that are identified by extended option codes + as defined above. The list of n requested parameters is specified as + 2n octets, where each pair of octets is a valid extended option code. + + The client MAY list the options in order of preference. The DHCP + server is not required to return the options in the requested order, + but MUST try to insert the requested options in the order requested + by the client. + + The code for this option is 126. Its minimum length is 2. + + Extended + Code Len option codes + +-----+-----+-----+-----+-----+-----+---- + | 126 | XXX | c1h | c1l | c2h | c2l | ... + +-----+-----+-----+-----+-----+-----+---- + + + + + + + + +Droms [Page 2] + +DRAFT An extension to the DHCP Option Codes April 1996 + + +References + + [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531, + Bucknell University, October 1993. + + [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 1533, Lachman Associates, October 1993. + + [3] Droms, R., "Procedure for Defining New DHCP Options", Work in + progress, February, 1996. + +Security Considerations + + Security issues are not discussed in this document. + +Author's Address + + Ralph Droms + Computer Science Department + 323 Dana Engineering + Bucknell University + Lewisburg, PA 17837 + + Phone: (717) 524-1145 + EMail: droms@bucknell.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Droms [Page 3] + diff --git a/doc/draft-ietf-dhc-renumbering-00.txt b/doc/draft-ietf-dhc-renumbering-00.txt new file mode 100644 index 00000000..c0f00843 --- /dev/null +++ b/doc/draft-ietf-dhc-renumbering-00.txt @@ -0,0 +1,390 @@ + + +INTERNET-DRAFT Lowell Gilbert +DHC Working Group Epilogue Technology Corporation +Network Area April 1996 + Expires October 1996 + + + Graceful renumbering of networks with DHCP + + +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 + + This document proposes a method for improving the ability of the + Dynamic Host Configuration Protocol (DHCP) to assist in renumbering + an internet. DHCP is already capable of supporting host renumbering + by assigning a new address when a client attempts to renegotiate an + existing lease, but this proposal makes host renumbering more + graceful by providing for a transition period in which the client can + use both addresses. + + + + + + + +Gilbert [Page 1] + +DRAFT Graceful renumbering of networks with DHCP April 1996 + + +Introduction + + This document proposes a method for improving the ability of the + Dynamic Host Configuration Protocol (DHCP) to assist in renumbering an + internet. DHCP is already capable of supporting host renumbering by + assigning a new address when a client attempts to renegotiate an + existing lease, but this proposal makes host renumbering more graceful + by providing for a transition period in which the client can use both + addresses. This enables the client to avoid disruption of existing + communications that may have already bound themselves to the original + address. This also enables the client to avoid disruption of new + communications (when the existing address would no longer be valid) by + ensuring they are bound to the new address. + + This proposal adds to the core DHC protocol a mechanism by which a + DHCP client may acquire an additional IP address to eventually replace + one already in use. A new option is defined for the server to start + this process in the client. Significant modifications to the + protocol's state machine are avoided by starting up a whole new state + machine for handling the new address. + + +Motivations + + Host addresses may need to change for a number of reasons. For + example, if the address assignment scheme is based on CIDR + guidelines, when a site changes its provider hosts within the site + may need to change their addresses. + + The intention of the mechanism described here is to allow system + administrators to specify a graceful transition period during + renumbering to minimize disruption caused by address changes, + particularly for hosts for which continuous availability is an + important factor. + + + + + + + + + + +Gilbert [Page 2] + +DRAFT Graceful renumbering of networks with DHCP April 1996 + + +Document Independence + + The most important point to note about this proposal is that it can + be issued as a separate document from the protocol specification. + There are three factors that make this practical: + + * the graceful renumbering support is optional, + + * the graceful renumbering support will be completely impossible + for some existing platforms (i.e. those which aren't capable of + having multiple addresses at one time anyway), + + * the graceful renumbering support doesn't in any way affect the + operation of hosts or servers that don't implement it. + Therefore, there's no good reason that it can't be split out on + its own, to progress on its own (separate) merits. + + +Design Goals + + * full backward compatibility with DHCP implementations compliant + with RFC1541. This is essential for acceptance of new + implementations with the new functionality. + + * no changes to relay agents. This is the key to the general DHCP + migration strategy. The simpler a relay agent is, the more + likely it is to be included in other network devices. + + * minimal impact upon the standards status (and advancement) of the + base DHCP protocol. Acceptance of the core protocol is a + prerequisite for acceptance of this one. + + +Terminology: + + + Use of the terms MUST, SHOULD, or SHOULD NOT in this document implies + the usual meanings with respect to implementing this specification. + However, none of this specification need be implemented for an + implementation to be considered compliant with DHCP (for which + compliance with RFC 1541 is necessary and sufficient). + + + +Gilbert [Page 3] + +DRAFT Graceful renumbering of networks with DHCP April 1996 + + +Requirements + + This proposal requires that any client be capable of binding more + than one address to an interface at a time, and also that the client + be able to distinguish among these addresses for the purpose of + binding existing and new transport connections. It also requires + that any server be able to track multiple bindings per client. If + these requirements cannot be met, then the host in question can still + implement DHCP, but won't be able to implement graceful renumbering + support. + + A new option (the "renumbering" option) is defined for use in DHCPACK + and DHCPDISCOVER messages. The length of this option is 4 octets. + The presence of this option in a DHCPACK indicates that the client + should initialize a new DHCP state machine for a new address. The + option shall contain a "magic cookie" value which the server can use + in tracking requests for new addresses; the client MUST NOT attempt + to interpret the value. + + This proposal assumes that a DHCP Server would have to be configured + with the new (post-renumbering) addresses, prior to the + reconfiguration of any of the Relay Agents that point to that Server. + Once the Server is configured with the new addresses, the Relay + Agents that point to that server could be reconfigured on their own, + without requiring any coordination with the Server. Under those + conditions, this proposal can accommodate a situation where a client + would receive a DHCPACK with the "renumbering" option, but the Relay + Agent that serves the client would not be configured (yet) with a new + (post-renumbering) address. + + +Protocol Summary + + + A renumbering option in a DHCPACK packet requests the client to begin + trying to get a post-renumbering address. The post-renumbering + address has its own DHCP state machine, which runs in parallel with + the one for the pre-renumbering address (with both addresses active + on the interface) until the lease runs out on the pre-renumbering + address. Then the original state machine dies a quiet death. + + + + +Gilbert [Page 4] + +DRAFT Graceful renumbering of networks with DHCP April 1996 + + +Client behaviour + + + When a client receives the renumbering option in a DHCPACK packet, it + MUST immediately initialize a new state machine for handling the new + address. The old state machine SHOULD NOT attempt to renegotiate the + lease after this point, and may terminate at any time thereafter, up + to and including the termination of the lease. When the lease + expires, the client MUST stop using that address and SHOULD release + all resources related to that address. + + When the new state machine is initialized, it starts in the INIT + state. Once it starts, it is responsible for acquiring a post- + renumbering address and keeping this address on the interface; the + responsibilities of the old state machine are now limited to deciding + when to terminate. + + The renumbering option MUST be returned in the client's DHCPINIT + message exactly as it was included in the DHCPACK message. The state + machine then proceeds as normal, completely separate from the + original state machine. When it receives a DHCPACK (for the *new* + address), it SHOULD, if possible, arrange that the new address will + be the address used by default on that particular interface. This + means that any new transport connections should be bound to the new + address, and that datagram protocols should switch to the new address + as soon as practical. + + + When a client receives the renumbering option in a DHCPACK packet, + the client does the following: + + (1) If the received DHCPACK packet causes the DHCP state machine + transition from Requesting to Bound state, then the client checks + whether it has another DHCP state machine. If such a machine + exists, then the client sends a DHCPRELEASE on the new machine, + and terminates the new machine. The old machine continues to + operate according to the normal DHCP operations. If no such (old) + machine exists, then the new machine starts to operate according + to the normal DHCP operations. + + (2) If the DHCPACK packet is received when the state machine is + + + +Gilbert [Page 5] + +DRAFT Graceful renumbering of networks with DHCP April 1996 + + + already in Bound, or Renewing, or Rebinding state, then the client + marks the state machine as "deprecated" and immediately initiates + another state machine. When the new state machine is initialized, + it starts in the INIT state. The renumbering option MUST be + returned in the client's DHCPINIT message exactly as it was + included in the DHCPACK message. The state machine then proceeds + as normal, completely separate from the original state machine. + Once the new state machine starts, it attempts to acquire a post- + renumbering address. If the attempt is successful, the client + assigns this address on the interface; the responsibilities of the + old state machine at that point would become limited to deciding + when to terminate. + + When a client receives a DHCPACK packet without the renumbering + option the client does the following: + + (1) If the received DHCPACK causes the DHCP state machine to + transition into the Bound state, the client checks if it has + another state machine which is marked as "deprecated". If yes, + then the client SHOULD start using the newly acquired address for + all the new transport connections, and that datagram protocols + SHOULD switch to the new address as soon as practical. The + existing connections are still bound to the old address (the + address associated with the "deprecated" state machine). The + "deprecated" machine SHOULD NOT attempt to renegotiate the lease + after this point, and may terminate at any time thereafter, up to + and including the termination of the lease. When the lease on the + address associated with the "deprecated" state machine expires, + the client MUST stop using that address and SHOULD release all + resources related to that address. + + (2) In all other cases the client follows the standard DHCP + procedures. + + + +Server behaviour + + + As part of its database of addresses, a DHCP server MUST maintain + state information for every address (or block of addresses) + + + +Gilbert [Page 6] + +DRAFT Graceful renumbering of networks with DHCP April 1996 + + + indicating whether that address is deprecated. When a DHCPREQUEST + arrives, the server MUST check this state information. + + If the address being requested is not deprecated, the server + continues as provided in RFC 1541. If, however, the address has been + deprecated the server prepares a DHCPACK using the remainder of the + available lease time, and in addition adds a renumbering option. The + method of choosing a value for the renumbering option is an + implentation decision. The server should be prepared to handle + further negotiations on the deprecated address, even though the + client is expected to stop such negotiations once it attempts to + acquire a replacement address. + + If the server has no post-renumbering addresses available to offer to + the client, it SHOULD offer the previous, deprecated address, in + order to signal the problem to the client. + + + +Relay Agent behaviour + + + The only requirement that this proposal places on relay agents is + that they MUST place a "new" (i.e., post-renumbering) address for + itself in the 'giaddr' field when passing on a DHCP message. Since + this can, in the worst case, be accomplished by hand-configuration, + modifications to relay agent software are not absolutely necessary. + + + +Discussion + + + The option's cookie can be used for anything that the server wants. + Two obvious possibilities are that it could be common across the + whole renumbering, and that it could represent a binding to a + particular client. Because the client's new state machine starts in + INIT, the server will be able to gather subnet information from the + broadcast DHCPDISCOVER. + + The idea behind using a new option to tell the client to initiate + + + +Gilbert [Page 7] + +DRAFT Graceful renumbering of networks with DHCP April 1996 + + + this process is that it avoids all of the problems that I saw in + (Yakov Rekhter's) original version of this proposal. Those had to do + with figuring out when to shut down a new state machine, and with the + extra traffic from sending an extra DHCPDISCOVER every time you went + back into the BOUND state. + + +Acknowledgements + + + This document owes a great deal to Yakov Rekhter's initial + suggestions on the same subject. Input from both him and Ralph Droms + had significant further effect on the document. + + +References + + + [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531, + Bucknell University, October 1993. + +Security Considerations + + + Security issues are not discussed in this document. + +Author's Address + + Lowell Gilbert + Lowell@Epilogue.Com + + + + + + + + + + + + + + +Gilbert [Page 8]