rfc2132.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,906 行 · 第 1/5 页

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.