Current DHCP Options specification

1 files changed, 1907 insertions, 0 deletions

diff --git a/doc/rfc2132.txt b/doc/rfc2132.txt
new file mode 100644
index 00000000..e9c4f4b3
--- /dev/null
+++ b/doc/rfc2132.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group                                       S. Alexander
+Request for Comments: 2132                        Silicon Graphics, Inc.
+Obsoletes: 1533                                                 R. Droms
+Category: Standards Track                            Bucknell University
+                                                              March 1997
+
+                DHCP Options and BOOTP Vendor Extensions
+
+Status of this memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+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
+   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 .............................. 11
+    5.  IP Layer Parameters per Interface ........................  13
+    6.  Link Layer Parameters per Interface ....................... 16
+    7.  TCP Parameters ............................................ 17
+    8.  Application and Service Parameters ........................ 18
+    9.  DHCP Extensions ........................................... 25
+
+
+
+Alexander & Droms           Standards Track                     [Page 1]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   10.  Defining new extensions ................................... 31
+   11.  Acknowledgements .......................................... 31
+   12.  References ................................................ 32
+   13.  Security Considerations ................................... 33
+   14.  Authors' Addresses ........................................ 34
+
+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.
+
+   This document updates the definition of DHCP/BOOTP options that
+   appears in RFC1533.  The classing mechanism has been extended to
+   include vendor classes as described in section 8.4 and 9.13.  The new
+   procedure for defining new DHCP/BOOTP options in described in section
+   10.  Several new options, including NIS+ domain and servers, Mobile
+   IP home agent, SMTP server, TFTP server and Bootfile server, have
+   been added.  Text giving definitions used throughout the document has
+   been added in section 1.1.  Text emphasizing the need for uniqueness
+   of client-identifiers has been added to section 9.14.
+
+
+
+
+
+
+
+
+Alexander & Droms           Standards Track                     [Page 2]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+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.2 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           Standards Track                     [Page 3]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+      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           Standards Track                     [Page 4]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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 |
+   +-----+
+
+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.
+
+
+
+Alexander & Droms           Standards Track                     [Page 5]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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.  A positive offset
+   indicates a location east of the zero meridian and a negative offset
+   indicates a location west of the zero meridian.
+
+   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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+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.
+
+
+
+
+
+
+Alexander & Droms           Standards Track                     [Page 6]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+    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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+
+
+Alexander & Droms           Standards Track                     [Page 7]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+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.
+
+
+
+Alexander & Droms           Standards Track                     [Page 8]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+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 | ...
+   +-----+-----+-----+-----+-----+-----+---
+
+
+
+Alexander & Droms           Standards Track                     [Page 9]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+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 |  ...
+   +-----+-----+-----+-----+-----+-----+--
+
+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.
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 10]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   The code for this option is 18.  Its minimum length is 1.
+
+    Code   Len      Extensions Pathname
+   +-----+-----+-----+-----+-----+-----+---
+   |  18 |  n  |  n1 |  n2 |  n3 |  n4 | ...
+   +-----+-----+-----+-----+-----+-----+---
+
+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 |
+   +-----+-----+-----+
+
+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.
+
+
+
+Alexander & Droms           Standards Track                    [Page 11]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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 |
+   +-----+-----+-----+-----+
+
+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.
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 12]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+    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.
+
+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.
+
+
+
+Alexander & Droms           Standards Track                    [Page 13]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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 |
+   +-----+-----+-----+-----+-----+-----+
+
+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 |
+   +-----+-----+-----+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 14]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+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 |
+   +-----+-----+-----+
+
+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.
+
+
+
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 15]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+    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 | ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+---
+
+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.
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 16]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   The code for this option is 36, and its length is 1.
+
+    Code   Len  Value
+   +-----+-----+-----+
+   |  36 |  1  | 0/1 |
+   +-----+-----+-----+
+
+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.
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 17]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   The code for this option is 39, and its length is 1.
+
+    Code   Len  Value
+   +-----+-----+-----+
+   |  39 |  1  | 0/1 |
+   +-----+-----+-----+
+
+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.
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 18]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+    Code   Len         Address 1               Address 2
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+   |  42 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+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 | ...
+   +-----+-----+-----+-----+---
+
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 19]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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 | ... | ... |
+   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+
+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
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 20]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   In the above chart, the notation '0x' indicates a number in base-16
+   (hexadecimal).
+
+   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 |   ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+---
+
+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.
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 21]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+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.
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 22]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+    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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 23]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+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.
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 24]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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 |  ...
+   +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+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.
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 25]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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.
+
+   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 | ...
+      +-----+-----+-----+-----+-----+---
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 26]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+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 | ...
+      +-----+-----+-----+-----+-----+---
+
+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 use the
+   contents of the 'server identifier' field as the destination address
+   for any DHCP messages unicast to the DHCP server.  DHCP clients also
+   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.
+
+
+
+Alexander & Droms           Standards Track                    [Page 27]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+    Code   Len            Address
+   +-----+-----+-----+-----+-----+-----+
+   |  54 |  4  |  a1 |  a2 |  a3 |  a4 |
+   +-----+-----+-----+-----+-----+-----+
+
+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 | ...
+   +-----+-----+-----+-----+---
+
+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.
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 28]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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 |
+   +-----+-----+-----+-----+-----+-----+
+
+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
+
+
+
+Alexander & Droms           Standards Track                    [Page 29]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   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.
+
+   The code for this option is 61, and its minimum length is 2.
+
+   Code   Len   Type  Client-Identifier
+   +-----+-----+-----+-----+-----+---
+   |  61 |  n  |  t1 |  i1 |  i2 | ...
+   +-----+-----+-----+-----+-----+---
+
+
+
+
+
+
+
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 30]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+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@iana.org
+
+   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 author thanks the many (and too numerous to mention!) members of
+   the DHC WG for their tireless and ongoing efforts in the development
+   of DHCP and this document.
+
+   The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
+   Mendonca in organizing DHCP interoperability testing sessions are
+   gratefully acknowledged.
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 31]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   The development of this document was supported in part by grants from
+   the Corporation for National Research Initiatives (CNRI), Bucknell
+   University and Sun Microsystems.
+
+12. References
+
+   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+       Bucknell University, March 1997.
+
+   [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.
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 32]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+   [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
+        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           Standards Track                    [Page 33]
+
+RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
+
+
+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
+   Bucknell University
+   Lewisburg, PA 17837
+
+   Phone: (717) 524-1145
+   EMail: droms@bucknell.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alexander & Droms           Standards Track                    [Page 34]
+