rfc2132-Option60.txt
上传用户:hzq880830
上传日期:2022-08-07
资源大小:59k
文件大小:62k
- 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]