--- /dev/null
+
+
+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
+ <draft-ietf-dhc-options-1533update-03.txt>
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+INTERNET-DRAFT Lowell Gilbert
+DHC Working Group Epilogue Technology Corporation
+Network Area April 1996
+ Expires October 1996
+
+
+ Graceful renumbering of networks with DHCP
+ <draft-ietf-dhc-renumbering-00.txt>
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
projects / thirdparty / dhcp.git / commitdiff
