21. DHCP Options
This section preserves the RFC text for DHCPv6, including message exchanges, relay behavior, DUIDs, IA_NA, IA_TA, IA_PD, DHCP options, RKAP authentication, IANA registries, normative requirements, and appendix option-appearance matrices.
Original RFC Text
21. DHCP Options
Options are used to carry additional information and parameters in
DHCP messages. Every option shares a common base format, as
described in Section 21.1. All values in options are represented in
network byte order.
This document specifies the DHCP options defined as part of this base
DHCP specification. Other options have been or may be defined in the
future in separate documents. See [RFC7227] for guidelines regarding
the definition of new options. See Section 24 for additional
information about the DHCPv6 "Option Codes" registry maintained by
IANA.
Unless otherwise noted, each option may appear only in the options
area of a DHCP message and may appear only once. If an option does
appear multiple times, each instance is considered separate and the
data areas of the options MUST NOT be concatenated or otherwise
combined.
Options that are allowed to appear only once are called "singleton
options". The only non-singleton options defined in this document
are the IA_NA (see Section 21.4), Vendor Class (see Section 21.16),
Vendor-specific Information (see Section 21.17), and IA_PD (see
Section 21.21) options. Also, IA Address (see Section 21.6) and IA
Prefix (see Section 21.22) may appear in their respective IA options
more than once.
21.1. Format of DHCP Options
The format of DHCP options is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Option Format
option-code: An unsigned integer identifying the specific option
type carried in this option. A 2-octet field.
option-len: An unsigned integer giving the length of the option-data
field in this option in octets. A 2-octet field.
option-data: The data for the option; the format of this data
depends on the definition of the option. A variable-length field
(the length, in octets, is specified by option-len).
DHCP options are scoped by using encapsulation. Some options apply
generally to the client, some are specific to an IA, and some are
specific to the addresses within an IA. These latter two cases are
discussed in Sections 21.4 and 21.6.
21.2. Client Identifier Option
The Client Identifier option is used to carry a DUID (see Section 11)
that identifies the client. The format of the Client Identifier
option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Client Identifier Option Format
option-code: OPTION_CLIENTID (1).
option-len: Length of DUID in octets.
DUID: The DUID for the client.
21.3. Server Identifier Option
The Server Identifier option is used to carry a DUID (see Section 11)
that identifies the server. The format of the Server Identifier
option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Server Identifier Option Format
option-code: OPTION_SERVERID (2).
option-len: Length of DUID in octets.
DUID: The DUID for the server.
21.4. Identity Association for Non-Temporary Addresses Option
The Identity Association for Non-temporary Addresses (IA_NA) option
is used to carry an IA_NA, the parameters associated with the IA_NA,
and the non-temporary addresses associated with the IA_NA.
A client that needs a short-term / special-purpose address can use a
new IA_NA binding to request an address and release it when finished
with it.
Note: Addresses appearing in an IA_NA option are not temporary
addresses (see Section 21.5).
The format of the IA_NA option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_NA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_NA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Identity Association for Non-Temporary Addresses
Option Format
option-code: OPTION_IA_NA (3).
option-len: 12 + length of IA_NA-options field.
IAID: The unique identifier for this IA_NA; the IAID must be unique
among the identifiers for all of this client's IA_NAs. The number
space for IA_NA IAIDs is separate from the number space for other
IA option types (i.e., IA_PD). A 4-octet field containing an
unsigned integer.
T1: The time interval after which the client should contact the
server from which the addresses in the IA_NA were obtained to
extend the lifetimes of the addresses assigned to the IA_NA; T1 is
a time duration relative to the current time expressed in units of
seconds. A 4-octet field containing an unsigned integer.
T2: The time interval after which the client should contact any
available server to extend the lifetimes of the addresses assigned
to the IA_NA; T2 is a time duration relative to the current time
expressed in units of seconds. A 4-octet field containing an
unsigned integer.
IA_NA-options: Options associated with this IA_NA. A variable-
length field (12 octets less than the value in the option-len
field).
The IA_NA-options field encapsulates those options that are specific
to this IA_NA. For example, all of the IA Address options (see
Section 21.6) carrying the addresses associated with this IA_NA are
in the IA_NA-options field.
Each IA_NA carries one "set" of non-temporary addresses; it is up to
the server policy to determine how many addresses are assigned, but
typically at most one address is assigned from each prefix assigned
to the link to which the client is attached.
An IA_NA option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_NA options (though
each must have a unique IAID).
The status of any operations involving this IA_NA is indicated in a
Status Code option (see Section 21.13) in the IA_NA-options field.
Note that an IA_NA has no explicit "lifetime" or "lease length" of
its own. When the valid lifetimes of all of the addresses in an
IA_NA have expired, the IA_NA can be considered as having expired.
T1 and T2 are included to give servers explicit control over when a
client recontacts the server about a specific IA_NA.
In a message sent by a client to a server, the T1 and T2 fields
SHOULD be set to 0. The server MUST ignore any values in these
fields in messages received from a client.
In a message sent by a server to a client, the client MUST use the
values in the T1 and T2 fields for the T1 and T2 times, unless values
in those fields are 0. The values in the T1 and T2 fields are the
number of seconds until T1 and T2 and are calculated since reception
of the message.
As per Section 7.7, the value 0xffffffff is taken to mean "infinity"
and should be used carefully.
The server selects the T1 and T2 values to allow the client to extend
the lifetimes of any addresses in the IA_NA before the lifetimes
expire, even if the server is unavailable for some short period of
time. Recommended values for T1 and T2 are 0.5 and 0.8 times the
shortest preferred lifetime of the addresses in the IA that the
server is willing to extend, respectively. If the "shortest"
preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and
T2 values are also 0xffffffff. If the time at which the addresses in
an IA_NA are to be renewed is to be left to the discretion of the
client, the server sets the T1 and T2 values to 0. The client MUST
follow the rules defined in Section 14.2.
If a client receives an IA_NA with T1 greater than T2 and both T1 and
T2 are greater than 0, the client discards the IA_NA option and
processes the remainder of the message as though the server had not
included the invalid IA_NA option.
21.5. Identity Association for Temporary Addresses Option
The Identity Association for Temporary Addresses (IA_TA) option is
obsoleted. Please refer to [RFC8415] for historical information on
this option.
The client SHOULD NOT send this option. The server SHOULD NOT send
this option. When the server receives an IA_TA option, the option
SHOULD be ignored and the message processing should continue as
usual.
As this option was never popular among server or client
implementations before being deprecated, any implementations that
still attempt to send it are unlikely to have the option processed.
21.6. IA Address Option
The IA Address option is used to specify an address. In this
document, it is only specified to be encapsulated within an IA_NA.
DHCPv6 Leasequery [RFC5007] makes use of the IA Address option
without encapsulating it in IA_NA. The IAaddr-options field
encapsulates those options that are specific to this address.
The format of the IA Address option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IAADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IAaddr-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: IA Address Option Format
option-code: OPTION_IAADDR (5).
option-len: 24 + length of IAaddr-options field.
IPv6-address: An IPv6 address. A client MUST NOT form an implicit
prefix with a length other than 128 for this address. A 16-octet
field.
preferred-lifetime: The preferred lifetime for the address in the
option, expressed in units of seconds. A 4-octet field containing
an unsigned integer.
valid-lifetime: The valid lifetime for the address in the option,
expressed in units of seconds. A 4-octet field containing an
unsigned integer.
IAaddr-options: Options associated with this address. A variable-
length field (24 octets less than the value in the option-len
field).
In a message sent by a client to a server, the preferred-lifetime and
valid-lifetime fields SHOULD be set to 0. The server MUST ignore any
received values.
The client SHOULD NOT send the IA Address option with an unspecified
address (::).
In a message sent by a server to a client, the client MUST use the
values in the preferred-lifetime and valid-lifetime fields for the
preferred and valid lifetimes. The values in these fields are the
number of seconds remaining in each lifetime.
The client MUST discard any addresses for which the preferred
lifetime is greater than the valid lifetime.
As per Section 7.7, if the valid lifetime of an address is
0xffffffff, it is taken to mean "infinity" and should be used
carefully.
More than one IA Address option can appear in an IA_NA option.
21.7. Option Request Option
The Option Request option is used to identify a list of options in a
message between a client and a server. The format of the Option
Request option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Option Request Option Format
option-code: OPTION_ORO (6).
option-len: 2 * number of requested options.
requested-option-code-n: The option code for an option requested by
the client. Each option code is a 2-octet field containing an
unsigned integer.
A client MUST include an Option Request option in a Solicit, Request,
Renew, Rebind, or Information-request message to inform the server
about options the client wants the server to send to the client.
The Option Request option MUST NOT include the following option
codes:
* Client Identifier (see Section 21.2)
* Server Identifier (see Section 21.3)
* IA_NA (see Section 21.4)
* IA_TA (option obsoleted, see Section 21.5)
* IA_PD (see Section 21.21)
* IA Address (see Section 21.6)
* IA Prefix (see Section 21.22)
* Option Request (this section)
* Elapsed Time (see Section 21.9)
* Preference (see Section 21.8)
* Relay Message (see Section 21.10)
* Authentication (see Section 21.11)
* Server Unicast (option obsoleted, see Section 21.12)
* Status Code (see Section 21.13)
* Rapid Commit (see Section 21.14)
* User Class (see Section 21.15)
* Vendor Class (see Section 21.16)
* Interface-Id (see Section 21.18)
* Reconfigure Message (see Section 21.19)
* Reconfigure Accept (see Section 21.20)
Other top-level option codes MUST appear in the Option Request option
or they will not be sent by the server. Only top-level option codes
MAY appear in the Option Request option. Option codes encapsulated
in a container option SHOULD NOT appear in an Option Request option;
see [RFC7598] for an example of container options. However, options
MAY be defined that specify exceptions to this restriction on
including encapsulated option codes in an Option Request option. For
example, the Option Request option MAY be used to signal support for
a feature even when that option is encapsulated, as in the case of
the Prefix Exclude option [RFC6603]. See [IANA-OPTION-DETAILS].
See [IANA-OPTION-DETAILS] for the authoritative list of which option
codes are required, permitted, or forbidden.
21.8. Preference Option
The Preference option is sent by a server to a client to control the
selection of a server by the client.
The format of the Preference option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value |
+-+-+-+-+-+-+-+-+
Figure 18: Preference Option Format
option-code: OPTION_PREFERENCE (7).
option-len: 1.
pref-value: The preference value for the server in this message.
Allowed values are from 0 (least) to 255 (most preferred).
Absence of option means preference 0. A 1-octet unsigned integer.
A server MAY include a Preference option in an Advertise message to
control the selection of a server by the client. See Section 18.2.9
for information regarding the use of the Preference option by the
client and the interpretation of the Preference option data value.
21.9. Elapsed Time Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ELAPSED_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| elapsed-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Elapsed Time Option Format
option-code: OPTION_ELAPSED_TIME (8).
option-len: 2.
elapsed-time: The amount of time since the client began its current
DHCP transaction. This time is expressed in hundredths of a
second (10^-2 seconds). A 2-octet field containing an unsigned
integer.
A client MUST include an Elapsed Time option in messages to indicate
how long the client has been trying to complete a DHCP message
exchange. The elapsed time is measured from the time at which the
client sent the first message in the message exchange, and the
elapsed-time field is set to 0 in the first message in the message
exchange. Servers and relay agents use the data value in this option
as input to policy that controls how a server responds to a client
message. For example, the Elapsed Time option allows a secondary
DHCP server to respond to a request when a primary server has not
answered in a reasonable time. The elapsed-time value is a 16-bit
(2-octet) unsigned integer. The client uses the value 0xffff to
represent any elapsed-time values greater than the largest time value
that can be represented in the Elapsed Time option.
21.10. Relay Message Option
The Relay Message option carries a DHCP message in a Relay-forward or
Relay-reply message.
The format of the Relay Message option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RELAY_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCP-relay-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Relay Message Option Format
option-code: OPTION_RELAY_MSG (9).
option-len: Length of DHCP-relay-message field.
DHCP-relay-message: In a Relay-forward message, the received
message, relayed verbatim to the next relay agent or server; in a
Relay-reply message, the message to be copied and relayed to the
relay agent or client whose address is in the peer-address field
of the Relay-reply message. The length, in octets, is specified
by option-len.
21.11. Authentication Option
The Authentication option carries authentication information to
authenticate the identity and contents of DHCP messages. The use of
the Authentication option is described in Section 20. The format of
the Authentication option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | algorithm | RDM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| replay detection (64 bits) +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. authentication information .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Authentication Option Format
option-code: OPTION_AUTH (11).
option-len: 11 + length of authentication information field.
protocol: The authentication protocol used in this Authentication
option. A 1-octet unsigned integer.
algorithm: The algorithm used in the authentication protocol. A
1-octet unsigned integer.
RDM: The replay detection method used in this Authentication option.
A 1-octet unsigned integer.
replay detection: The replay detection information for the RDM. A
64-bit (8-octet) field.
authentication information: The authentication information, as
specified by the protocol and algorithm used in this
Authentication option. A variable-length field (11 octets less
than the value in the option-len field).
IANA maintains a registry for the protocol, algorithm, and RDM values
at <https://www.iana.org/assignments/auth-namespaces>.
21.12. Server Unicast Option
The Server Unicast option is obsolete. Please refer to [RFC8415] for
historical information on this option.
The server MUST NOT send this option. When any entity receives the
Server Unicast option, the option SHOULD be ignored and the message
processing should continue as usual.
21.13. Status Code Option
This option returns a status indication related to the DHCP message
or option in which it appears. The format of the Status Code option
is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. status-message .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Status Code Option Format
option-code: OPTION_STATUS_CODE (13).
option-len: 2 + length of status-message field.
status-code: The numeric code for the status encoded in this option.
A 2-octet field containing an unsigned integer.
status-message: A UTF-8 encoded [RFC3629] text string suitable for
display to an end user. MUST NOT be NUL-terminated. A variable-
length field (2 octets less than the value in the option-len
field).
A Status Code option may appear in the "options" field of a DHCP
message and/or in the "options" field of another option. If the
Status Code option does not appear in a message in which the option
could appear, the status of the message is assumed to be Success.
The status-code values are:
+===============+======+===================================+
| Name | Code | Description |
+===============+======+===================================+
| Success | 0 | Success. |
+---------------+------+-----------------------------------+
| UnspecFail | 1 | Failure, reason unspecified; this |
| | | status code is sent by a server |
| | | to indicate a failure not |
| | | explicitly specified in this |
| | | document. |
+---------------+------+-----------------------------------+
| NoAddrsAvail | 2 | The server has no addresses |
| | | available to assign to the IA(s). |
+---------------+------+-----------------------------------+
| NoBinding | 3 | Client record (binding) |
| | | unavailable. |
+---------------+------+-----------------------------------+
| NotOnLink | 4 | The prefix for the address is not |
| | | appropriate for the link to which |
| | | the client is attached. |
+---------------+------+-----------------------------------+
| UseMulticast | 5 | Sent by a server to a client to |
| | | force the client to send messages |
| | | to the server using the |
| | | All_DHCP_Relay_Agents_and_Servers |
| | | multicast address. Obsoleted; no |
| | | longer used. |
+---------------+------+-----------------------------------+
| NoPrefixAvail | 6 | The server has no prefixes |
| | | available to assign to the |
| | | IA_PD(s). |
+---------------+------+-----------------------------------+
Table 3: Status Code Definitions
See the "Status Codes" registry at <https://www.iana.org/assignments/
dhcpv6-parameters> for the current list of status codes.
21.14. Rapid Commit Option
The Rapid Commit option is used to signal the use of the two-message
exchange for address assignment. The format of the Rapid Commit
option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RAPID_COMMIT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Rapid Commit Option Format
option-code: OPTION_RAPID_COMMIT (14).
option-len: 0.
A client MAY include this option in a Solicit message if the client
is prepared to perform the Solicit/Reply message exchange described
in Section 18.2.1.
A server MUST include this option in a Reply message sent in response
to a Solicit message when completing the Solicit/Reply message
exchange.
DISCUSSION:
* Each server that responds with a Reply to a Solicit that includes
a Rapid Commit option will commit the leases in the Reply message
to the client but will not receive any confirmation that the
client has received the Reply message. Therefore, if more than
one server responds to a Solicit that includes a Rapid Commit
option, all but one server will commit leases that are not
actually used by the client; this could result in incorrect
address information in DNS if the DHCP servers update DNS
[RFC4704], and responses to leasequery requests [RFC5007] may
include information on leases not in use by the client.
* The problem of unused leases can be minimized by designing the
DHCP service so that only one server responds to the Solicit or by
using relatively short lifetimes for newly assigned leases.
21.15. User Class Option
The User Class option is used by a client to identify the type or
category of users or applications it represents.
The format of the User Class option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_USER_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. user-class-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: User Class Option Format
option-code: OPTION_USER_CLASS (15).
option-len: Length of user-class-data field.
user-class-data: The user classes carried by the client. The
length, in octets, is specified by option-len.
The information contained in the data area of this option is
contained in one or more opaque fields that represent the user class
or classes of which the client is a member. A server selects
configuration information for the client based on the classes
identified in this option. For example, the User Class option can be
used to configure all clients of people in the accounting department
with a different printer than clients of people in the marketing
department. The user class information carried in this option MUST
be configurable on the client.
The data area of the User Class option MUST contain one or more
instances of user-class-data information. Each instance of user-
class-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
Figure 25: Format of user-class-data Field
The user-class-len field is 2 octets long and specifies the length of
the opaque user-class-data in network byte order.
A server interprets the classes identified in this option according
to its configuration to select the appropriate configuration
information for the client. A server may use only those user classes
that it is configured to interpret in selecting configuration
information for a client and ignore any other user classes. In
response to a message containing a User Class option, a server may
include a User Class option containing those classes that were
successfully interpreted by the server so that the client can be
informed of the classes interpreted by the server.
21.16. Vendor Class Option
This option is used by a client to identify the vendor that
manufactured the hardware on which the client is running. The
information contained in the data area of this option is contained in
one or more opaque fields that identify details of the hardware
configuration. The format of the Vendor Class option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Vendor Class Option Format
option-code: OPTION_VENDOR_CLASS (16).
option-len: 4 + length of vendor-class-data field.
enterprise-number: The vendor's registered Enterprise Number as
maintained by IANA [IANA-PEN]. A 4-octet field containing an
unsigned integer.
vendor-class-data: The hardware configuration of the node on which
the client is running. A variable-length field (4 octets less
than the value in the option-len field).
The vendor-class-data field is composed of a series of separate
items, each of which describes some characteristic of the client's
hardware configuration. Examples of vendor-class-data instances
might include the version of the operating system the client is
running or the amount of memory installed on the client.
Each instance of vendor-class-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
Figure 27: Format of vendor-class-data Field
The vendor-class-len field is 2 octets long and specifies the length
of the opaque vendor-class-data in network byte order.
Servers and clients MUST NOT include more than one instance of
OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance
of OPTION_VENDOR_CLASS can carry multiple vendor-class-data
instances.
21.17. Vendor-Specific Information Option
This option is used by clients and servers to exchange vendor-
specific information.
The format of the Vendor-specific Information option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Vendor-Specific Information Option Format
option-code: OPTION_VENDOR_OPTS (17).
option-len: 4 + length of vendor-option-data field.
enterprise-number: The vendor's registered Enterprise Number as
maintained by IANA [IANA-PEN]. A 4-octet field containing an
unsigned integer.
vendor-option-data: Vendor options, interpreted by vendor-specific
code on the clients and servers. A variable-length field (4
octets less than the value in the option-len field).
The definition of the information carried in this option is vendor
specific. The vendor is indicated in the enterprise-number field.
Use of vendor-specific information allows enhanced operation,
utilizing additional features in a vendor's DHCP implementation. A
DHCP client that does not receive requested vendor-specific
information will still configure the node's IPv6 stack to be
functional.
The vendor-option-data field MUST be encoded as a sequence of
code/length/value fields of format identical to the DHCP options (see
Section 21.1). The suboption codes are defined by the vendor
identified in the enterprise-number field and are not managed by
IANA. Each of the suboptions is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-code | suboption-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. suboption-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: Vendor-Specific Options Format
suboption-code: The code for the suboption. A 2-octet field.
suboption-len: An unsigned integer giving the length of the
suboption-data field in this suboption in octets. A 2-octet
field.
suboption-data: The data area for the suboption. The length, in
octets, is specified by suboption-len.
Multiple instances of the Vendor-specific Information option may
appear in a DHCP message. Each instance of the option is interpreted
according to the option codes defined by the vendor identified by the
Enterprise Number in that option. Servers and clients MUST NOT send
more than one instance of the Vendor-specific Information option with
the same Enterprise Number. Each instance of the Vendor-specific
Information option MAY contain multiple suboptions.
A client that is interested in receiving a Vendor-specific
Information option:
* MUST specify the Vendor-specific Information option in an Option
Request option.
* MAY specify an associated Vendor Class option (see Section 21.16).
* MAY specify the Vendor-specific Information option with
appropriate data.
Servers only return the Vendor-specific Information options if
specified in Option Request options from clients and:
* MAY use the Enterprise Numbers in the associated Vendor Class
options to restrict the set of Enterprise Numbers in the Vendor-
specific Information options returned.
* MAY return all configured Vendor-specific Information options.
* MAY use other information in the message or in its configuration
to determine which set of Enterprise Numbers in the Vendor-
specific Information options to return.
21.18. Interface-Id Option
The relay agent MAY send the Interface-Id option to identify the
interface on which the client message was received. If a relay agent
receives a Relay-reply message with an Interface-Id option, the relay
agent relays the message to the client through the interface
identified by the option.
The format of the Interface-Id option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INTERFACE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. interface-id .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Interface-Id Option Format
option-code: OPTION_INTERFACE_ID (18).
option-len: Length of interface-id field.
interface-id: An opaque value of arbitrary length generated by the
relay agent to identify one of the relay agent's interfaces. The
length, in octets, is specified by option-len.
The server MUST copy the Interface-Id option from the Relay-forward
message into the Relay-reply message the server sends to the relay
agent in response to the Relay-forward message. This option MUST NOT
appear in any message except a Relay-forward or Relay-reply message.
Servers MAY use the interface-id field for parameter assignment
policies. The interface-id value SHOULD be considered an opaque
value, with policies based on exact match only; that is, the
interface-id field SHOULD NOT be internally parsed by the server.
The interface-id value for an interface SHOULD be stable and remain
unchanged -- for example, after the relay agent is restarted; if the
interface-id value changes, a server will not be able to use it
reliably in parameter assignment policies.
21.19. Reconfigure Message Option
A server includes a Reconfigure Message option in a Reconfigure
message to indicate to the client whether the client responds with a
Renew message, a Rebind message, or an Information-request message.
The format of the Reconfigure Message option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |
+-+-+-+-+-+-+-+-+
Figure 31: Reconfigure Message Option Format
option-code: OPTION_RECONF_MSG (19).
option-len: 1.
msg-type: 5 for Renew message, 6 for Rebind message, 11 for
Information-request message. A 1-octet unsigned integer.
The Reconfigure Message option can only appear in a Reconfigure
message.
21.20. Reconfigure Accept Option
A client uses the Reconfigure Accept option to announce to the server
whether the client is willing to accept Reconfigure messages, and a
server uses this option to tell the client whether or not to accept
Reconfigure messages. In the absence of this option, the default
behavior is that the client is unwilling to accept Reconfigure
messages. The format of the Reconfigure Accept option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_ACCEPT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Reconfigure Accept Option Format
option-code: OPTION_RECONF_ACCEPT (20).
option-len: 0.
21.21. Identity Association for Prefix Delegation Option
The IA_PD option is used to carry a prefix delegation identity
association, the parameters associated with the IA_PD, and the
prefixes associated with it. The format of the IA_PD option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_PD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IA_PD-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: Identity Association for Prefix Delegation Option Format
option-code: OPTION_IA_PD (25).
option-len: 12 + length of IA_PD-options field.
IAID: The unique identifier for this IA_PD; the IAID must be unique
among the identifiers for all of this client's IA_PDs. The number
space for IA_PD IAIDs is separate from the number space for other
IA option types (i.e., IA_NA). A 4-octet field containing an
unsigned integer.
T1: The time interval after which the client should contact the
server from which the prefixes in the IA_PD were obtained to
extend the lifetimes of the prefixes delegated to the IA_PD; T1 is
a time duration relative to the message reception time expressed
in units of seconds. A 4-octet field containing an unsigned
integer.
T2: The time interval after which the client should contact any
available server to extend the lifetimes of the prefixes assigned
to the IA_PD; T2 is a time duration relative to the message
reception time expressed in units of seconds. A 4-octet field
containing an unsigned integer.
IA_PD-options: Options associated with this IA_PD. A variable-
length field (12 octets less than the value in the option-len
field).
The IA_PD-options field encapsulates those options that are specific
to this IA_PD. For example, all of the IA Prefix options (see
Section 21.22) carrying the prefixes associated with this IA_PD are
in the IA_PD-options field.
An IA_PD option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_PD options (though
each must have a unique IAID).
The status of any operations involving this IA_PD is indicated in a
Status Code option (see Section 21.13) in the IA_PD-options field.
Note that an IA_PD has no explicit "lifetime" or "lease length" of
its own. When the valid lifetimes of all of the prefixes in an IA_PD
have expired, the IA_PD can be considered as having expired. T1 and
T2 fields are included to give the server explicit control over when
a client should contact the server about a specific IA_PD.
In a message sent by a client to a server, the T1 and T2 fields
SHOULD be set to 0. The server MUST ignore any values in these
fields in messages received from a client.
In a message sent by a server to a client, the client MUST use the
values in the T1 and T2 fields for the T1 and T2 timers, unless
values in those fields are 0. The values in the T1 and T2 fields are
the number of seconds until T1 and T2.
The server selects the T1 and T2 times to allow the client to extend
the lifetimes of any prefixes in the IA_PD before the lifetimes
expire, even if the server is unavailable for some short period of
time. Recommended values for T1 and T2 are 0.5 and 0.8 times the
shortest preferred lifetime of the prefixes in the IA_PD that the
server is willing to extend, respectively. If the time at which the
prefixes in an IA_PD are to be renewed is to be left to the
discretion of the client, the server sets T1 and T2 to 0. The client
MUST follow the rules defined in Section 14.2.
If a client receives an IA_PD with T1 greater than T2 and both T1 and
T2 are greater than 0, the client discards the IA_PD option and
processes the remainder of the message as though the server had not
included the IA_PD option.
21.22. IA Prefix Option
The IA Prefix option is used to specify a prefix associated with an
IA_PD. The IA Prefix option must be encapsulated in the
IA_PD-options field of an IA_PD option (see Section 21.21).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IAPREFIX | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-length | |
+-+-+-+-+-+-+-+-+ IPv6-prefix |
| (16 octets) |
| |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | .
+-+-+-+-+-+-+-+-+ .
. IAprefix-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: IA Prefix Option Format
option-code: OPTION_IAPREFIX (26).
option-len: 25 + length of IAprefix-options field.
preferred-lifetime: The preferred lifetime for the prefix in the
option, expressed in units of seconds. A value of 0xffffffff
represents "infinity" (see Section 7.7). A 4-octet field
containing an unsigned integer.
valid-lifetime: The valid lifetime for the prefix in the option,
expressed in units of seconds. A value of 0xffffffff represents
"infinity". A 4-octet field containing an unsigned integer.
prefix-length: Length for this prefix in bits. A 1-octet unsigned
integer.
IPv6-prefix: An IPv6 prefix. A 16-octet field.
IAprefix-options: Options associated with this prefix. A variable-
length field (25 octets less than the value in the option-len
field).
In a message sent by a client to a server, the preferred-lifetime and
valid-lifetime fields SHOULD be set to 0. The server MUST ignore any
received values in these lifetime fields.
The client SHOULD NOT send an IA Prefix option with 0 in the "prefix-
length" field (and an unspecified value (::) in the "IPv6-prefix"
field). A client MAY send a non-zero value in the "prefix-length"
field and the unspecified value (::) in the "IPv6-prefix" field to
indicate a preference for the size of the prefix to be delegated.
See [RFC8168] for further details on prefix-length hints.
The client MUST discard any prefixes for which the preferred lifetime
is greater than the valid lifetime.
The values in the preferred-lifetime and valid-lifetime fields are
the number of seconds remaining in each lifetime. See
Section 18.2.10.1 for more details on how these values are used for
delegated prefixes.
As per Section 7.7, the value of 0xffffffff for the preferred
lifetime or the valid lifetime is taken to mean "infinity" and should
be used carefully.
An IA Prefix option may appear only in an IA_PD option. More than
one IA Prefix option can appear in a single IA_PD option.
The status of any operations involving this IA Prefix option is
indicated in a Status Code option (see Section 21.13) in the
IAprefix-options field.
21.23. Information Refresh Time Option
This option is requested by clients and returned by servers to
specify an upper bound for how long a client should wait before
refreshing information retrieved from a DHCP server. It is only used
in Reply messages in response to Information-request messages. In
other messages, there will usually be other information that
indicates when the client should contact the server, e.g., T1/T2
times and lifetimes. This option is useful when the configuration
parameters change or during a renumbering event, as clients running
in the stateless mode will be able to update their configuration.
The format of the Information Refresh Time option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OPTION_INFORMATION_REFRESH_TIME| option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| information-refresh-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: Information Refresh Time Option Format
option-code: OPTION_INFORMATION_REFRESH_TIME (32).
option-len: 4.
information-refresh-time: Time duration relative to the current
time, expressed in units of seconds. A 4-octet field containing
an unsigned integer.
A DHCP client MUST request this option in the Option Request option
(see Section 21.7) when sending Information-request messages. A
client MUST NOT request this option in the Option Request option in
any other messages.
A server sending a Reply to an Information-request message SHOULD
include this option if it is requested in the Option Request option
of the Information-request. The option value MUST NOT be smaller
than IRT_MINIMUM. This option MUST only appear in the top-level
options area of Reply messages.
If the Reply to an Information-request message does not contain this
option, the client MUST behave as if the option with the value
IRT_DEFAULT was provided.
A client MUST use the refresh time IRT_MINIMUM if it receives the
option with a value less than IRT_MINIMUM.
As per Section 7.7, the value 0xffffffff is taken to mean "infinity"
and implies that the client should not refresh its configuration data
without some other trigger (such as detecting movement to a new
link).
If a client contacts the server to obtain new data or refresh some
existing data before the refresh time expires, then it SHOULD also
refresh all data covered by this option.
When the client detects that the refresh time has expired, it SHOULD
try to update its configuration data by sending an Information-
request as specified in Section 18.2.6, except that the client MUST
delay sending the first Information-request by a random amount of
time between 0 and INF_MAX_DELAY.
A client MAY have a maximum value for the refresh time, where that
value is used whenever the client receives this option with a value
higher than the maximum. This also means that the maximum value is
used when the received value is "infinity". A maximum value might
make the client less vulnerable to attacks based on forged DHCP
messages. Without a maximum value, a client may be made to use wrong
information for a possibly infinite period of time. There may,
however, be reasons for having a very long refresh time, so it may be
useful for this maximum value to be configurable.
21.24. SOL_MAX_RT Option
A DHCP server sends the SOL_MAX_RT option to a client to override the
default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option
replaces the default value defined in Section 7.6. One use for the
SOL_MAX_RT option is to set a higher value for SOL_MAX_RT; this
reduces the Solicit traffic from a client that has not received a
response to its Solicit messages.
The format of the SOL_MAX_RT option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SOL_MAX_RT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOL_MAX_RT value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36: SOL_MAX_RT Option Format
option-code: OPTION_SOL_MAX_RT (82).
option-len: 4.
SOL_MAX_RT value: Overriding value for SOL_MAX_RT in seconds; MUST
be in this range: 60 <= "value" <= 86400 (1 day). A 4-octet field
containing an unsigned integer.
A DHCP client MUST include the SOL_MAX_RT option code in any Option
Request option (see Section 21.7) it sends in a Solicit message.
The DHCP server MAY include the SOL_MAX_RT option in any response it
sends to a client that has included the SOL_MAX_RT option code in an
Option Request option. The SOL_MAX_RT option is sent as a top-level
option in the message to the client.
A DHCP client MUST ignore any SOL_MAX_RT option values that are less
than 60 or more than 86400.
If a DHCP client receives a message containing a SOL_MAX_RT option
that has a valid value for SOL_MAX_RT, the client MUST set its
internal SOL_MAX_RT parameter to the value contained in the
SOL_MAX_RT option. This value of SOL_MAX_RT is then used by the
retransmission mechanism defined in Sections 15 and 18.2.1.
The purpose of this mechanism is to give network administrators a way
to avoid excessive DHCP traffic if all DHCP servers become
unavailable. Therefore, this value is expected to be retained for as
long as practically possible.
An updated SOL_MAX_RT value applies only to the network interface on
which the client received the SOL_MAX_RT option.
21.25. INF_MAX_RT Option
A DHCP server sends the INF_MAX_RT option to a client to override the
default value of INF_MAX_RT. The value of INF_MAX_RT in the option
replaces the default value defined in Section 7.6. One use for the
INF_MAX_RT option is to set a higher value for INF_MAX_RT; this
reduces the Information-request traffic from a client that has not
received a response to its Information-request messages.
The format of the INF_MAX_RT option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INF_MAX_RT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INF_MAX_RT value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: INF_MAX_RT Option Format
option-code: OPTION_INF_MAX_RT (83).
option-len: 4.
INF_MAX_RT value: Overriding value for INF_MAX_RT in seconds; MUST
be in this range: 60 <= "value" <= 86400 (1 day). A 4-octet field
containing an unsigned integer.
A DHCP client MUST include the INF_MAX_RT option code in any Option
Request option (see Section 21.7) it sends in an Information-request
message.
The DHCP server MAY include the INF_MAX_RT option in any response it
sends to a client that has included the INF_MAX_RT option code in an
Option Request option. The INF_MAX_RT option is a top-level option
in the message to the client.
A DHCP client MUST ignore any INF_MAX_RT option values that are less
than 60 or more than 86400.
If a DHCP client receives a message containing an INF_MAX_RT option
that has a valid value for INF_MAX_RT, the client MUST set its
internal INF_MAX_RT parameter to the value contained in the
INF_MAX_RT option. This value of INF_MAX_RT is then used by the
retransmission mechanism defined in Sections 15 and 18.2.6.
An updated INF_MAX_RT value applies only to the network interface on
which the client received the INF_MAX_RT option.