RFC 3315
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Pages: 101
Obsoleted by: 8415
Updated by: 4361 5494 6221 6422 6644 7083 7227 7283 7550
Obsoleted by: 8415
Updated by: 4361 5494 6221 6422 6644 7083 7227 7283 7550
Part 4 of 5 – Pages 61 to 89
21. Authentication of DHCP Messages
Some network administrators may wish to provide authentication of the source and contents of DHCP messages. For example, clients may be subject to denial of service attacks through the use of bogus DHCP servers, or may simply be misconfigured due to unintentionally instantiated DHCP servers. Network administrators may wish to constrain the allocation of addresses to authorized hosts to avoid denial of service attacks in "hostile" environments where the network medium is not physically secured, such as wireless networks or college residence halls. The DHCP authentication mechanism is based on the design of authentication for DHCPv4 [4].21.1. Security of Messages Sent Between Servers and Relay Agents
Relay agents and servers that exchange messages securely use the IPsec mechanisms for IPv6 [7]. If a client message is relayed through multiple relay agents, each of the relay agents must have established independent, pairwise trust relationships. That is, if messages from client C will be relayed by relay agent A to relay
agent B and then to the server, relay agents A and B must be
configured to use IPSec for the messages they exchange, and relay
agent B and the server must be configured to use IPSec for the
messages they exchange.
Relay agents and servers that support secure relay agent to server or
relay agent to relay agent communication use IPsec under the
following conditions:
Selectors Relay agents are manually configured with the
addresses of the relay agent or server to which
DHCP messages are to be forwarded. Each relay
agent and server that will be using IPsec for
securing DHCP messages must also be configured
with a list of the relay agents to which messages
will be returned. The selectors for the relay
agents and servers will be the pairs of addresses
defining relay agents and servers that exchange
DHCP messages on the DHCPv6 UDP ports 546 and
547.
Mode Relay agents and servers use transport mode and
ESP. The information in DHCP messages is not
generally considered confidential, so encryption
need not be used (i.e., NULL encryption can be
used).
Key management Because the relay agents and servers are used
within an organization, public key schemes are
not necessary. Because the relay agents and
servers must be manually configured, manually
configured key management may suffice, but does
not provide defense against replayed messages.
Accordingly, IKE with preshared secrets SHOULD be
supported. IKE with public keys MAY be
supported.
Security policy DHCP messages between relay agents and servers
should only be accepted from DHCP peers as
identified in the local configuration.
Authentication Shared keys, indexed to the source IP address of
the received DHCP message, are adequate in this
application.
Availability Appropriate IPsec implementations are likely to
be available for servers and for relay agents in
more featureful devices used in enterprise and
core ISP networks. IPsec is less likely to be
available for relay agents in low end devices
primarily used in the home or small office
markets.
21.2. Summary of DHCP Authentication
Authentication of DHCP messages is accomplished through the use of
the Authentication option (see section 22.11). The authentication
information carried in the Authentication option can be used to
reliably identify the source of a DHCP message and to confirm that
the contents of the DHCP message have not been tampered with.
The Authentication option provides a framework for multiple
authentication protocols. Two such protocols are defined here.
Other protocols defined in the future will be specified in separate
documents.
Any DHCP message MUST NOT include more than one Authentication
option.
The protocol field in the Authentication option identifies the
specific protocol used to generate the authentication information
carried in the option. The algorithm field identifies a specific
algorithm within the authentication protocol; for example, the
algorithm field specifies the hash algorithm used to generate the
message authentication code (MAC) in the authentication option. The
replay detection method (RDM) field specifies the type of replay
detection used in the replay detection field.
21.3. Replay Detection
The Replay Detection Method (RDM) field determines the type of replay
detection used in the Replay Detection field.
If the RDM field contains 0x00, the replay detection field MUST be
set to the value of a monotonically increasing counter. Using a
counter value, such as the current time of day (for example, an NTP-
format timestamp [9]), can reduce the danger of replay attacks. This
method MUST be supported by all protocols.
21.4. Delayed Authentication Protocol
If the protocol field is 2, the message is using the "delayed
authentication" mechanism. In delayed authentication, the client
requests authentication in its Solicit message, and the server
replies with an Advertise message that includes authentication
information. This authentication information contains a nonce value generated by the source as a message authentication code (MAC) to provide message authentication and entity authentication. The use of a particular technique based on the HMAC protocol [8] using the MD5 hash [16] is defined here.21.4.1. Use of the Authentication Option in the Delayed Authentication Protocol
In a Solicit message, the client fills in the protocol, algorithm and RDM fields in the Authentication option with the client's preferences. The client sets the replay detection field to zero and omits the authentication information field. The client sets the option-len field to 11. In all other messages, the protocol and algorithm fields identify the method used to construct the contents of the authentication information field. The RDM field identifies the method used to construct the contents of the replay detection field. The format of the Authentication information 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHCP realm | | (variable length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC-MD5 | | (128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DHCP realm The DHCP realm that identifies the key used to generate the HMAC-MD5 value. key ID The key identifier that identified the key used to generate the HMAC-MD5 value. HMAC-MD5 The message authentication code generated by applying MD5 to the DHCP message using the key identified by the DHCP realm, client DUID, and key ID.
The sender computes the MAC using the HMAC generation algorithm [8] and the MD5 hash function [16]. The entire DHCP message (setting the MAC field of the authentication option to zero), including the DHCP message header and the options field, is used as input to the HMAC- MD5 computation function. DISCUSSION: Algorithm 1 specifies the use of HMAC-MD5. Use of a different technique, such as HMAC-SHA, will be specified as a separate protocol. The DHCP realm used to identify authentication keys is chosen to be unique among administrative domains. Use of the DHCP realm allows DHCP administrators to avoid conflict in the use of key identifiers, and allows a host using DHCP to use authenticated DHCP while roaming among DHCP administrative domains.21.4.2. Message Validation
Any DHCP message that includes more than one authentication option MUST be discarded. To validate an incoming message, the receiver first checks that the value in the replay detection field is acceptable according to the replay detection method specified by the RDM field. Next, the receiver computes the MAC as described in [8]. The entire DHCP message (setting the MAC field of the authentication option to 0) is used as input to the HMAC-MD5 computation function. If the MAC computed by the receiver does not match the MAC contained in the authentication option, the receiver MUST discard the DHCP message.21.4.3. Key Utilization
Each DHCP client has a set of keys. Each key is identified by <DHCP realm, client DUID, key id>. Each key also has a lifetime. The key may not be used past the end of its lifetime. The client's keys are initially distributed to the client through some out-of-band mechanism. The lifetime for each key is distributed with the key. Mechanisms for key distribution and lifetime specification are beyond the scope of this document. The client and server use one of the client's keys to authenticate DHCP messages during a session (until the next Solicit message sent by the client).
21.4.4. Client Considerations for Delayed Authentication Protocol
The client announces its intention to use DHCP authentication by including an Authentication option in its Solicit message. The server selects a key for the client based on the client's DUID. The client and server use that key to authenticate all DHCP messages exchanged during the session.21.4.4.1. Sending Solicit Messages
When the client sends a Solicit message and wishes to use authentication, it includes an Authentication option with the desired protocol, algorithm and RDM as described in section 21.4. The client does not include any replay detection or authentication information in the Authentication option.21.4.4.2. Receiving Advertise Messages
The client validates any Advertise messages containing an Authentication option specifying the delayed authentication protocol using the validation test described in section 21.4.2. Client behavior, if no Advertise messages include authentication information or pass the validation test, is controlled by local policy on the client. According to client policy, the client MAY choose to respond to an Advertise message that has not been authenticated. The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated Advertise message can make the client vulnerable to spoofing and other attacks. If local users are not explicitly informed that the client has accepted an unauthenticated Advertise message, the users may incorrectly assume that the client has received an authenticated address and is not subject to DHCP attacks through unauthenticated messages. A client MUST be configurable to discard unauthenticated messages, and SHOULD be configured by default to discard unauthenticated messages if the client has been configured with an authentication key or other authentication information. A client MAY choose to differentiate between Advertise messages with no authentication information and Advertise messages that do not pass the validation test; for example, a client might accept the former and discard the latter. If a client does accept an unauthenticated message, the client SHOULD inform any local users and SHOULD log the event.
21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release Messages
If the client authenticated the Advertise message through which the client selected the server, the client MUST generate authentication information for subsequent Request, Confirm, Renew, Rebind or Release messages sent to the server, as described in section 21.4. When the client sends a subsequent message, it MUST use the same key used by the server to generate the authentication information.21.4.4.4. Sending Information-request Messages
If the server has selected a key for the client in a previous message exchange (see section 21.4.5.1), the client MUST use the same key to generate the authentication information throughout the session.21.4.4.5. Receiving Reply Messages
If the client authenticated the Advertise it accepted, the client MUST validate the associated Reply message from the server. The client MUST discard the Reply if the message fails to pass the validation test and MAY log the validation failure. If the Reply fails to pass the validation test, the client MUST restart the DHCP configuration process by sending a Solicit message. If the client accepted an Advertise message that did not include authentication information or did not pass the validation test, the client MAY accept an unauthenticated Reply message from the server.21.4.4.6. Receiving Reconfigure Messages
The client MUST discard the Reconfigure if the message fails to pass the validation test and MAY log the validation failure.21.4.5. Server Considerations for Delayed Authentication Protocol
After receiving a Solicit message that contains an Authentication option, the server selects a key for the client, based on the client's DUID and key selection policies with which the server has been configured. The server identifies the selected key in the Advertise message and uses the key to validate subsequent messages between the client and the server.
21.4.5.1. Receiving Solicit Messages and Sending Advertise Messages
The server selects a key for the client and includes authentication information in the Advertise message returned to the client as specified in section 21.4. The server MUST record the identifier of the key selected for the client and use that same key for validating subsequent messages with the client.21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages and Sending Reply Messages
The server uses the key identified in the message and validates the message as specified in section 21.4.2. If the message fails to pass the validation test or the server does not know the key identified by the 'key ID' field, the server MUST discard the message and MAY choose to log the validation failure. If the message passes the validation test, the server responds to the specific message as described in section 18.2. The server MUST include authentication information generated using the key identified in the received message, as specified in section 21.4.21.5. Reconfigure Key Authentication Protocol
The Reconfigure key authentication protocol provides protection against misconfiguration of a client caused by a Reconfigure message sent by a malicious DHCP server. In this protocol, a DHCP server sends a Reconfigure Key to the client in the initial exchange of DHCP messages. The client records the Reconfigure Key for use in authenticating subsequent Reconfigure messages from that server. The server then includes an HMAC computed from the Reconfigure Key in subsequent Reconfigure messages. Both the Reconfigure Key sent from the server to the client and the HMAC in subsequent Reconfigure messages are carried as the Authentication information in an Authentication option. The format of the Authentication information is defined in the following section. The Reconfigure Key protocol is used (initiated by the server) only if the client and server are not using any other authentication protocol and the client and server have negotiated to use Reconfigure messages.
21.5.1. Use of the Authentication Option in the Reconfigure Key Authentication Protocol
The following fields are set in an Authentication option for the Reconfigure Key Authentication Protocol: protocol 3 algorithm 1 RDM 0 The format of the Authentication information for the Reconfigure Key Authentication Protocol 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Value (128 bits) | +-+-+-+-+-+-+-+-+ | . . . . . +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type of data in Value field carried in this option: 1 Reconfigure Key value (used in Reply message). 2 HMAC-MD5 digest of the message (used in Reconfigure message). Value Data as defined by field.21.5.2. Server considerations for Reconfigure Key protocol
The server selects a Reconfigure Key for a client during the Request/Reply, Solicit/Reply or Information-request/Reply message exchange. The server records the Reconfigure Key and transmits that key to the client in an Authentication option in the Reply message. The Reconfigure Key is 128 bits long, and MUST be a cryptographically strong random or pseudo-random number that cannot easily be predicted.
To provide authentication for a Reconfigure message, the server selects a replay detection value according to the RDM selected by the server, and computes an HMAC-MD5 of the Reconfigure message using the Reconfigure Key for the client. The server computes the HMAC-MD5 over the entire DHCP Reconfigure message, including the Authentication option; the HMAC-MD5 field in the Authentication option is set to zero for the HMAC-MD5 computation. The server includes the HMAC-MD5 in the authentication information field in an Authentication option included in the Reconfigure message sent to the client.21.5.3. Client considerations for Reconfigure Key protocol
The client will receive a Reconfigure Key from the server in the initial Reply message from the server. The client records the Reconfigure Key for use in authenticating subsequent Reconfigure messages. To authenticate a Reconfigure message, the client computes an HMAC-MD5 over the DHCP Reconfigure message, using the Reconfigure Key received from the server. If this computed HMAC-MD5 matches the value in the Authentication option, the client accepts the Reconfigure message.22. 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 22.1. All values in options are represented in network byte order. This document describes the DHCP options defined as part of the base DHCP specification. Other options may be defined in the future in separate documents. 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.
22.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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code An unsigned integer identifying the specific option type carried in this option. option-len An unsigned integer giving the length of the option-data field in this option in octets. option-data The data for the option; the format of this data depends on the definition of the option. DHCPv6 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 22.4 and 22.6.22.2. Client Identifier Option
The Client Identifier option is used to carry a DUID (see section 9) identifying a client between a client and a server. 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) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_CLIENTID (1). option-len Length of DUID in octets.
DUID The DUID for the client.
22.3. Server Identifier Option
The Server Identifier option is used to carry a DUID (see section 9)
identifying a server between a client and a 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) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SERVERID (2).
option-len Length of DUID in octets.
DUID The DUID for the server.
22.4. Identity Association for Non-temporary Addresses Option
The Identity Association for Non-temporary Addresses option (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.
Addresses appearing in an IA_NA option are not temporary addresses
(see section 22.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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 IA_TA IAIDs.
T1 The time at which the client contacts 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.
T2 The time at which the client contacts 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.
IA_NA-options Options associated with this IA_NA.
The IA_NA-options field encapsulates those options that are specific
to this IA_NA. For example, all of the IA Address Options carrying
the addresses associated with this IA_NA are in the IA_NA-options
field.
An IA_NA option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_NA options.
The status of any operations involving this IA_NA is indicated in a
Status Code option 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, values in the T1 and T2
fields indicate the client's preference for those parameters. The
client sets T1 and T2 to 0 if it has no preference for those values.
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 parameters, unless
those 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 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 .5 and .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 T1 and T2 to 0.
If a server receives an IA_NA with T1 greater than T2, and both T1
and T2 are greater than 0, the server ignores the invalid values of
T1 and T2 and processes the IA_NA as though the client had set T1 and
T2 to 0.
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.
Care should be taken in setting T1 or T2 to 0xffffffff ("infinity").
A client will never attempt to extend the lifetimes of any addresses
in an IA with T1 set to 0xffffffff. A client will never attempt to
use a Rebind message to locate a different server to extend the
lifetimes of any addresses in an IA with T2 set to 0xffffffff.
22.5. Identity Association for Temporary Addresses Option
The Identity Association for the Temporary Addresses (IA_TA) option is used to carry an IA_TA, the parameters associated with the IA_TA and the addresses associated with the IA_TA. All of the addresses in this option are used by the client as temporary addresses, as defined in RFC 3041 [12]. The format of the IA_TA 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_TA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . IA_TA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_IA_TA (4). option-len 4 + length of IA_TA-options field. IAID The unique identifier for this IA_TA; the IAID must be unique among the identifiers for all of this client's IA_TAs. The number space for IA_TA IAIDs is separate from the number space for IA_NA IAIDs. IA_TA-options Options associated with this IA_TA. The IA_TA-Options field encapsulates those options that are specific to this IA_TA. For example, all of the IA Address Options carrying the addresses associated with this IA_TA are in the IA_TA-options field. Each IA_TA carries one "set" of temporary addresses; that is, at most one address from each prefix assigned to the link to which the client is attached. An IA_TA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_TA options. The status of any operations involving this IA_TA is indicated in a Status Code option in the IA_TA-options field.
Note that an IA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_TA have expired, the IA can be considered as having expired. An IA_TA option does not include values for T1 and T2. A client MAY request that the lifetimes on temporary addresses be extended by including the addresses in a IA_TA option sent in a Renew or Rebind message to a server. For example, a client would request an extension on the lifetime of a temporary address to allow an application to continue to use an established TCP connection. The client obtains new temporary addresses by sending an IA_TA option with a new IAID to a server. Requesting new temporary addresses from the server is the equivalent of generating new temporary addresses as described in RFC 3041. The server will generate new temporary addresses and return them to the client. The client should request new temporary addresses before the lifetimes on the previously assigned addresses expire. A server MUST return the same set of temporary address for the same IA_TA (as identified by the IAID) as long as those addresses are still valid. After the lifetimes of the addresses in an IA_TA have expired, the IAID may be reused to identify a new IA_TA with new temporary addresses. This option MAY appear in a Confirm message if the lifetimes on the temporary addresses in the associated IA have not expired.22.6. IA Address Option
The IA Address option is used to specify IPv6 addresses associated with an IA_NA or an IA_TA. The IA Address option must be encapsulated in the Options field of an IA_NA or IA_TA option. The 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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_IAADDR (5).
option-len 24 + length of IAaddr-options field.
IPv6 address An IPv6 address.
preferred-lifetime The preferred lifetime for the IPv6 address in
the option, expressed in units of seconds.
valid-lifetime The valid lifetime for the IPv6 address in the
option, expressed in units of seconds.
IAaddr-options Options associated with this address.
In a message sent by a client to a server, values in the preferred
and valid lifetime fields indicate the client's preference for those
parameters. The client may send 0 if it has no preference for the
preferred and valid lifetimes. In a message sent by a server to a
client, the client MUST use the values in the preferred and valid
lifetime fields for the preferred and valid lifetimes. The values in
the preferred and valid lifetimes are the number of seconds remaining
in each lifetime.
A client discards any addresses for which the preferred lifetime is
greater than the valid lifetime. A server ignores the lifetimes set
by the client if the preferred lifetime is greater than the valid
lifetime and ignores the values for T1 and T2 set by the client if
those values are greater than the preferred lifetime.
Care should be taken in setting the valid lifetime of an address to
0xffffffff ("infinity"), which amounts to a permanent assignment of
an address to a client.
An IA Address option may appear only in an IA_NA option or an IA_TA
option. More than one IA Address Option can appear in an IA_NA
option or an IA_TA option.
The status of any operations involving this IA Address is indicated
in a Status Code option in the IAaddr-options field.
22.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
A client MAY include an Option Request option in a Solicit, Request,
Renew, Rebind, Confirm or Information-request message to inform the
server about options the client wants the server to send to the
client. A server MAY include an Option Request option in a
Reconfigure option to indicate which options the client should
request from the server.
22.8. Preference Option
The Preference option is sent by a server to a client to affect 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 | +-+-+-+-+-+-+-+-+ option-code OPTION_PREFERENCE (7). option-len 1. pref-value The preference value for the server in this message. A server MAY include a Preference option in an Advertise message to control the selection of a server by the client. See section 17.1.3 for the use of the Preference option by the client and the interpretation of Preference option data value.22.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 controlling 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 an unsigned, 16 bit 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.22.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 . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_RELAY_MSG (9) option-len Length of DHCP-relay-message 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
22.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 21. 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) +-+-+-+-+-+-+-+-+ | | auth-info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . authentication information . . (variable length) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_AUTH (11) option-len 11 + length of authentication information field protocol The authentication protocol used in this authentication option algorithm The algorithm used in the authentication protocol RDM The replay detection method used in this authentication option Replay detection The replay detection information for the RDM authentication information The authentication information, as specified by the protocol and algorithm used in this authentication option
22.12. Server Unicast Option
The server sends this option to a client to indicate to the client that it is allowed to unicast messages to the server. The format of the Server Unicast 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_UNICAST | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_UNICAST (12). option-len 16. server-address The IP address to which the client should send messages delivered using unicast. The server specifies the IPv6 address to which the client is to send unicast messages in the server-address field. When a client receives this option, where permissible and appropriate, the client sends messages directly to the server using the IPv6 address specified in the server-address field of the option. When the server sends a Unicast option to the client, some messages from the client will not be relayed by Relay Agents, and will not include Relay Agent options from the Relay Agents. Therefore, a server should only send a Unicast option to a client when Relay Agents are not sending Relay Agent options. A DHCP server rejects any messages sent inappropriately using unicast to ensure that messages are relayed by Relay Agents when Relay Agent options are in use. Details about when the client may send messages to the server using unicast are in section 18.22.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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_STATUS_CODE (13).
option-len 2 + length of status-message.
status-code The numeric code for the status encoded in
this option. The status codes are defined in
section 24.4.
status-message A UTF-8 encoded text string suitable for
display to an end user, which MUST NOT be
null-terminated.
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.
22.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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 17.1.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 assigned addresses in the
Reply message to the client, and 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, some servers will commit addresses that are not
actually used by the client.
The problem of unused addresses can be minimized, for example, by
designing the DHCP service so that only one server responds to the
Solicit or by using relatively short lifetimes for assigned
addresses.
22.15. User Class Option
The User Class option is used by a client to identify the type or
category of user or applications it represents.
The format of the User Class option is:
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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. Each instance of the user class data
is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The user-class-len is two 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
includes 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.
22.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 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 .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_VENDOR_CLASS (16).
option-len 4 + length of vendor class data field.
enterprise-number The vendor's registered Enterprise Number as
registered with IANA [6].
vendor-class-data The hardware configuration of the host on
which the client is running.
The vendor-class-data 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 the vendor-class-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The vendor-class-len is two octets long and specifies the length of
the opaque vendor class data in network byte order.
22.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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_VENDOR_OPTS (17)
option-len 4 + length of option-data field
enterprise-number The vendor's registered Enterprise Number as
registered with IANA [6].
option-data An opaque object of option-len octets,
interpreted by vendor-specific code on the
clients and servers
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 host device's IPv6 stack to be
functional.
The encapsulated vendor-specific options field MUST be encoded as a
sequence of code/length/value fields of identical format to the DHCP
options field. The option codes are defined by the vendor identified
in the enterprise-number field and are not managed by IANA. Each of
the encapsulated options is formatted as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| opt-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt-code The code for the encapsulated option.
option-len An unsigned integer giving the length of the
option-data field in this encapsulated option
in octets.
option-data The data area for the encapsulated option.
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.
22.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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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 for parameter assignment policies.
The Interface-ID SHOULD be considered an opaque value, with policies
based on exact match only; that is, the Interface-ID 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 changes, a server
will not be able to use it reliably in parameter assignment policies.
22.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 or an Information-request message. The format of this
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 |
+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_MSG (19).
option-len 1.
msg-type 5 for Renew message, 11 for
Information-request message.
The Reconfigure Message option can only appear in a Reconfigure
message.
22.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. The default behavior, in the absence of this
option, means unwillingness to accept Reconfigure messages, or
instruction not to accept Reconfigure messages, for the client and
server messages, respectively. The following figure gives the format
of the Reconfigure Accept 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_RECONF_ACCEPT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_ACCEPT (20).
option-len 0.
(page 89 continued on part 5)