RFC 8415
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Pages: 154
Proposed Standard
→ Errata
Obsoletes: 3315 3633 3736 4242 7083 7283 7550
Proposed Standard
→ Errata
Obsoletes: 3315 3633 3736 4242 7083 7283 7550
Part 12 of 14 – Pages 121 to 129
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 33: 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 34: 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 35: 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 and IA_TA). 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 36: 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 37: 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 38: 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 39: 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.
(next page on part 13)