18. DHCP Configuration Exchanges
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
18. DHCP Configuration Exchanges
A client initiates a message exchange with a server or servers to
acquire or update configuration information of interest. A client
has many reasons to initiate the configuration exchange. Some of the
more common ones are:
1. as part of the operating system configuration/bootstrap process,
2. when requested to do so by the application layer (through an
operating-system-specific API),
3. when a Router Advertisement indicates that DHCPv6 is available
for address configuration (see Section 4.2 of [RFC4861]),
4. as required to extend the lifetime of address(es) and/or
delegated prefix(es), using Renew and Rebind messages, or
5. upon the receipt of a Reconfigure message, when requested to do
so by a server.
The client is responsible for creating IAs and requesting that a
server assign addresses and/or delegated prefixes to the IAs. The
client first creates the IAs and assigns IAIDs to them. The client
then transmits a Solicit message containing the IA options describing
the IAs. The client MUST NOT be using any of the addresses or
delegated prefixes for which it tries to obtain the bindings by
sending the Solicit message. In particular, if the client had some
valid bindings and has chosen to start the server discovery process
to obtain the same bindings from a different server, the client MUST
stop using the addresses and delegated prefixes for the bindings that
it had obtained from the previous server (see Section 18.2.7 for more
details on what "stop using" means in this context) and that it is
now trying to obtain from a new server.
A DHCP client that does not need to have a DHCP server assign IP
addresses or delegated prefixes to it can obtain configuration
information such as a list of available DNS servers [RFC3646] or NTP
servers [RFC5908] through a single message and reply exchange with a
DHCP server. To obtain configuration information, the client first
sends an Information-request message (see Section 18.2.6) to the
All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond
with a Reply message containing the configuration information for the
client (see Section 18.3.6).
To request the assignment of one or more addresses or delegated
prefixes, a client first locates a DHCP server and then requests the
assignment of addresses/prefixes and other configuration information
from the server. The client does this by sending the Solicit message
(see Section 18.2.1) to the All_DHCP_Relay_Agents_and_Servers
multicast address and collecting Advertise messages from the servers
that respond to the client's message; the client then selects a
server from which it wants to obtain configuration information. This
process is referred to as server discovery. When the client has
selected the server, it sends a Request message to that server as
described in Section 18.2.2.
A client willing to perform the Solicit/Reply message exchange
described in Section 18.2.1 includes a Rapid Commit option (see
Section 21.14) in its Solicit message.
Servers that can assign addresses or delegated prefixes to the IAs
respond to the client with an Advertise message or Reply message if
the client included a Rapid Commit option and the server is
configured to accept it.
If the server responds with an Advertise message, the client
initiates a configuration exchange as described in Section 18.2.2.
A server may initiate a message exchange with a client by sending a
Reconfigure message to cause the client to send a Renew, Rebind, or
Information-request message to refresh its configuration information
as soon as the Reconfigure message is received by the client.
Figure 9 shows a timeline diagram of the messages exchanged between a
client and two servers for the typical lifecycle of one or more
leases. This starts with the four-message Solicit/Advertise/Request/
Reply exchange to obtain the lease(s), followed by a two-message
Renew/Reply exchange to extend the lifetime on the lease(s), and then
ends with a two-message Release/Reply exchange to end the client's
use of the lease(s).
Server Server
(not selected) Client (selected)
v v v
| | |
| Begins initialization |
| | |
start of | _____________/|\_____________ |
4-message |/ Solicit | Solicit \|
exchange | | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/|
| \________ | /Advertise |
| Advertise\ |/ |
| \ | |
| Collects Advertises |
| \ | |
| Selects configuration |
| | |
| _____________/|\_____________ |
|/ Request | Request \|
| | |
| | Commits configuration
| | |
end of | | _____________/|
4-message | |/ Reply |
exchange | | |
| Initialization complete |
| | |
. . .
. . .
| T1 (renewal) timer expires |
| | |
2-message | _____________/|\_____________ |
exchange |/ Renew | Renew \|
| | |
| | Commits extended lease(s)
| | |
| | _____________/|
| |/ Reply |
. . .
. . .
| | |
| Graceful shutdown |
| | |
2-message | _____________/|\_____________ |
exchange |/ Release | Release \|
| | |
| | Discards lease(s)
| | |
| | _____________/|
| |/ Reply |
| | |
v v v
Figure 9: Timeline Diagram of the Messages Exchanged Between a
Client and Two Servers for the Typical Lifecycle of One or More
Leases
18.1. A Single Exchange for Multiple IA Options
This document assumes that a client SHOULD use a single transaction
for all of the IA options required on an interface; this simplifies
the client implementation and reduces the potential number of
transactions required. To facilitate a client's use of a single
transaction for all IA options, servers MUST return the same T1/T2
values for all IA options in a Reply (see Sections 18.3.2, 18.3.4,
and 18.3.5) so that the client will generate a single transaction
when renewing or rebinding its leases. However, because some servers
may not yet conform to this requirement, a client MUST be prepared to
select appropriate T1/T2 times as described in Section 18.2.4.
18.2. Client Behavior
A client uses the Solicit message to discover DHCP servers configured
to assign leases or return other configuration parameters on the link
to which the client is attached.
A client uses Request, Renew, Rebind, Release, and Decline messages
during the normal lifecycle of addresses and delegated prefixes.
When a client detects that it may have moved to a new link, it uses
Confirm if it only has addresses and Rebind if it has delegated
prefixes (and addresses). It uses Information-request messages when
it needs configuration information but no addresses and no prefixes.
When a client requests multiple IA option types or multiple instances
of the same IA types in a Solicit, Request, Renew, or Rebind, it is
possible that the available server(s) may only be configured to offer
a subset of them. When possible, the client SHOULD use the best
configuration available and continue to request the additional IAs in
subsequent messages. This allows the client to maintain a single
session and state machine. In practice, especially in the case of
handling IA_NA and IA_PD requests [RFC7084], this situation should be
rare or a result of a temporary operational error. Thus, it is more
likely that the client will get all configuration if it continues, in
each subsequent configuration exchange, to request all the
configuration information it is programmed to try to obtain,
including any stateful configuration options for which no results
were returned in previous message exchanges.
Upon receipt of a Reconfigure message from the server, a client
responds with a Renew, Rebind, or Information-request message as
indicated by the Reconfigure Message option (see Section 21.19). The
client SHOULD be suspicious of the Reconfigure message (they may be
faked), and it MUST NOT abandon any resources it might have already
obtained. The client SHOULD treat the Reconfigure message as if the
T1 timer had expired. The client will expect the server to send IAs
and/or other configuration information to the client in a Reply
message.
18.2.1. Creation and Transmission of Solicit Messages
The client sets the "msg-type" field to SOLICIT. The client
generates a transaction ID and inserts this value in the
"transaction-id" field.
The client MUST include a Client Identifier option (see Section 21.2)
to identify itself to the server. The client includes IA options for
any IAs to which it wants the server to assign leases.
The client MUST include an Elapsed Time option (see Section 21.9) to
indicate how long the client has been trying to complete the current
DHCP message exchange.
The client uses IA_NA options (see Section 21.4) to request the
assignment of non-temporary addresses and IA_PD options (see
Section 21.21) to request prefix delegation. IA_NA or IA_PD options,
or a combination, can be included in DHCP messages. In addition,
multiple instances of any IA option type can be included.
The client MAY include addresses in IA Address options (see
Section 21.6) encapsulated within IA_NA option as hints to the server
about the addresses for which the client has a preference.
The client MAY include values in IA Prefix options (see
Section 21.22) encapsulated within IA_PD options as hints for the
delegated prefix and/or prefix length for which the client has a
preference. See Section 18.2.4 for more on prefix-length hints.
The client MUST include an Option Request option (ORO) (see
Section 21.7) to request the SOL_MAX_RT option (see Section 21.24)
and any other options the client is interested in receiving. The
client MAY additionally include instances of those options that are
identified in the Option Request option, with data values as hints to
the server about parameter values the client would like to have
returned.
The client includes a Reconfigure Accept option (see Section 21.20)
if the client is willing to accept Reconfigure messages from the
server.
The client MUST NOT include any other options in the Solicit message,
except as specifically allowed in the definition of individual
options.
The first Solicit message from the client on the interface SHOULD be
delayed by a random amount of time between 0 and SOL_MAX_DELAY. This
random delay helps desynchronize clients that start a DHCP session at
the same time, such as after recovery from a power failure or after a
router outage after seeing that DHCP is available in Router
Advertisement messages (see Section 4.2 of [RFC4861]).
The client transmits the message according to Section 15, using the
following parameters:
* IRT: SOL_TIMEOUT
* MRT: SOL_MAX_RT
* MRC: 0
* MRD: 0
A client that wishes to use the Rapid Commit two-message exchange
includes a Rapid Commit option (see Section 21.14) in its Solicit
message. The client may receive a number of different replies from
different servers. The client will make note of any valid Advertise
messages that it receives. The client will discard any Reply
messages that do not contain the Rapid Commit option.
Upon receipt of a valid Reply with the Rapid Commit option, the
client processes the message as described in Section 18.2.10.
At the end of the first RT period, if no suitable Reply messages are
received but the client has valid Advertise messages, then the client
processes the Advertise as described in Section 18.2.9.
If the client subsequently receives a valid Reply message that
includes a Rapid Commit option, it does one of the following:
* processes the Reply message as described in Section 18.2.10 and
discards any Reply messages received in response to the Request
message
* processes any Reply messages received in response to the Request
message and discards the Reply message that includes the Rapid
Commit option
If the client is waiting for an Advertise message, the mechanism
described in Section 15 is modified as follows for use in the
transmission of Solicit messages. The message exchange is not
terminated by the receipt of an Advertise before the first RT has
elapsed. Rather, the client collects valid Advertise messages until
the first RT has elapsed. Also, the first RT MUST be selected to be
strictly greater than IRT by choosing RAND to be strictly greater
than 0.
A client MUST collect valid Advertise messages for the first RT
seconds, unless it receives a valid Advertise message with a
preference value of 255. The preference value is carried in the
Preference option (see Section 21.8). Any valid Advertise that does
not include a Preference option is considered to have a preference
value of 0. If the client receives a valid Advertise message that
includes a Preference option with a preference value of 255, the
client immediately begins a client-initiated message exchange (as
described in Section 18.2.2) by sending a Request message to the
server from which the Advertise message was received. If the client
receives a valid Advertise message that does not include a Preference
option with a preference value of 255, the client continues to wait
until the first RT elapses. If the first RT elapses and the client
has received a valid Advertise message, the client SHOULD continue
with a client-initiated message exchange by sending a Request
message.
If the client does not receive any valid Advertise messages before
the first RT has elapsed, it then applies the retransmission
mechanism described in Section 15. The client terminates the
retransmission process as soon as it receives any valid Advertise
message, and the client acts on the received Advertise message
without waiting for any additional Advertise messages.
A DHCP client SHOULD choose MRC and MRD values of 0. If the DHCP
client is configured with either MRC or MRD set to a value other than
0, it MUST stop trying to configure the interface if the message
exchange fails. After the DHCP client stops trying to configure the
interface, it SHOULD restart the reconfiguration process after some
external event, such as user input, system restart, or when the
client is attached to a new link.
18.2.2. Creation and Transmission of Request Messages
The client uses a Request message to populate IAs with leases and
obtain other configuration information. The client includes one or
more IA options in the Request message. The server then returns
leases and other information about the IAs to the client in IA
options in a Reply message.
The client sets the "msg-type" field to REQUEST. The client
generates a transaction ID and inserts this value in the
"transaction-id" field.
The client MUST include the identifier of the destination server in a
Server Identifier option (see Section 21.3).
The client MUST include a Client Identifier option (see Section 21.2)
to identify itself to the server. The client adds any other
appropriate options, including one or more IA options.
The client MUST include an Elapsed Time option (see Section 21.9) to
indicate how long the client has been trying to complete the current
DHCP message exchange.
The client MUST include an Option Request option (see Section 21.7)
to request the SOL_MAX_RT option (see Section 21.24) and any other
options the client is interested in receiving. The client MAY
additionally include instances of those options that are identified
in the Option Request option, with data values as hints to the server
about parameter values the client would like to have returned.
The client includes a Reconfigure Accept option (see Section 21.20)
if the client is willing to accept Reconfigure messages from the
server.
The client transmits the message according to Section 15, using the
following parameters:
* IRT: REQ_TIMEOUT
* MRT: REQ_MAX_RT
* MRC: REQ_MAX_RC
* MRD: 0
If the message exchange fails, the client takes an action based on
the client's local policy. Examples of actions the client might take
include the following:
* Select another server from a list of servers known to the client
-- for example, servers that responded with an Advertise message.
* Initiate the server discovery process described in Section 18.
* Terminate the configuration process and report failure.
18.2.3. Creation and Transmission of Confirm Messages
The client uses a Confirm message when it has only addresses (no
delegated prefixes) assigned by a DHCP server to determine if it is
still connected to the same link when the client detects a change in
network information as described in Section 18.2.12.
The client sets the "msg-type" field to CONFIRM. The client
generates a transaction ID and inserts this value in the
"transaction-id" field.
The client MUST include a Client Identifier option (see Section 21.2)
to identify itself to the server.
The client MUST include an Elapsed Time option (see Section 21.9) to
indicate how long the client has been trying to complete the current
DHCP message exchange.
The client includes IA options for all of the IAs assigned to the
interface for which the Confirm message is being sent. The IA
options include all of the addresses the client currently has
associated with those IAs. The client SHOULD set the T1 and T2
fields in any IA_NA options (see Section 21.4) and the preferred-
lifetime and valid-lifetime fields in the IA Address options (see
Section 21.6) to 0, as the server will ignore these fields.
The first Confirm message from the client on the interface MUST be
delayed by a random amount of time between 0 and CNF_MAX_DELAY. The
client transmits the message according to Section 15, using the
following parameters:
* IRT: CNF_TIMEOUT
* MRT: CNF_MAX_RT
* MRC: 0
* MRD: CNF_MAX_RD
If the client receives no responses before the message transmission
process terminates, as described in Section 15, the client SHOULD
continue to use any leases, using the last known lifetimes for those
leases, and SHOULD continue to use any other previously obtained
configuration parameters.
18.2.4. Creation and Transmission of Renew Messages
To extend the preferred and valid lifetimes for the leases assigned
to the IAs and obtain new addresses or delegated prefixes for IAs,
the client sends a Renew message to the server from which the leases
were obtained; the Renew message includes IA options for the IAs
whose lease lifetimes are to be extended. The client includes IA
Address options (see Section 21.6) within IA_NA (see Section 21.4)
options for the addresses assigned to the IAs. The client includes
IA Prefix options (see Section 21.22) within IA_PD options (see
Section 21.21) for the delegated prefixes assigned to the IAs.
The server controls the time at which the client should contact the
server to extend the lifetimes on assigned leases through the T1 and
T2 values assigned to an IA. However, as the client SHOULD renew/
rebind all IAs from the server at the same time, the client MUST
select T1 and T2 times from all IA options that will guarantee that
the client initiates transmissions of Renew/Rebind messages not later
than at the T1/T2 times associated with any of the client's bindings
(earliest T1/T2).
At time T1, the client initiates a Renew/Reply message exchange to
extend the lifetimes on any leases in the IA.
A client MUST also initiate a Renew/Reply message exchange before
time T1 if the client's link-local address used in previous
interactions with the server is no longer valid and it is willing to
receive Reconfigure messages. This updates the server's information
so it is able to continue to communicate with the client (either
directly or via Relay-reply messages).
If T1 or T2 had been set to 0 by the server (for an IA_NA or IA_PD)
in a previous Reply, the client may, at its discretion, send a Renew
or Rebind message, respectively. The client MUST follow the rules
defined in Section 14.2.
The client sets the "msg-type" field to RENEW. The client generates
a transaction ID and inserts this value in the "transaction-id"
field.
The client MUST include a Server Identifier option (see Section 21.3)
in the Renew message, identifying the server with which the client
most recently communicated.
The client MUST include a Client Identifier option (see Section 21.2)
to identify itself to the server. The client adds any appropriate
options, including one or more IA options.
The client MUST include an Elapsed Time option (see Section 21.9) to
indicate how long the client has been trying to complete the current
DHCP message exchange.
For IAs to which leases have been assigned, the client includes a
corresponding IA option containing an IA Address option for each
address assigned to the IA and an IA Prefix option for each prefix
assigned to the IA. The client MUST NOT include addresses and
prefixes in any IA option that the client did not obtain from the
server or that are no longer valid (that have a valid lifetime of 0).
The client MAY include an IA option for each binding it desires but
has been unable to obtain. In this case, if the client includes the
IA_PD option to request prefix delegation, the client MAY include the
IA Prefix option encapsulated within the IA_PD option, with the
"IPv6-prefix" field set to 0 and the "prefix-length" field set to the
desired length of the prefix to be delegated. The server MAY use
this value as a hint for the prefix length. The client SHOULD NOT
include an IA Prefix option with the "IPv6-prefix" field set to 0
unless it is supplying a hint for the prefix length.
The client includes an Option Request option (see Section 21.7) to
request the SOL_MAX_RT option (see Section 21.24) and any other
options the client is interested in receiving. The client MAY
include options with data values as hints to the server about
parameter values the client would like to have returned.
The client transmits the message according to Section 15, using the
following parameters:
* IRT: REN_TIMEOUT
* MRT: REN_MAX_RT
* MRC: 0
* MRD: Remaining time until earliest T2
The message exchange is terminated when the earliest time T2 is
reached. While the client is responding to a Reconfigure, the client
ignores and discards any additional Reconfigure messages it may
receive.
The message exchange is terminated when the earliest time T2 is
reached, at which point the client begins the Rebind message exchange
(see Section 18.2.5).
18.2.5. Creation and Transmission of Rebind Messages
At time T2 (which will only be reached if the server to which the
Renew message was sent starting at time T1 has not responded), the
client initiates a Rebind/Reply message exchange with any available
server.
A Rebind is also used to verify delegated prefix bindings but with
different retransmission parameters as described in Section 18.2.3.
The client constructs the Rebind message as described in
Section 18.2.4, with the following differences:
* The client sets the "msg-type" field to REBIND.
* The client does not include the Server Identifier option (see
Section 21.3) in the Rebind message.
The client transmits the message according to Section 15, using the
following parameters:
* IRT: REB_TIMEOUT
* MRT: REB_MAX_RT
* MRC: 0
* MRD: Remaining time until valid lifetimes of all leases in all IAs
have expired
If all leases for an IA have expired, the client may choose to
include this IA in subsequent Rebind messages to indicate that the
client is interested in assignment of the leases to this IA.
The message exchange is terminated when the valid lifetimes of all
leases across all IAs have expired, at which time the client uses the
Solicit message to locate a new DHCP server and sends a Request for
the expired IAs to the new server. If the terminated Rebind exchange
was initiated as a result of receiving a Reconfigure message, the
client terminates the reconfigure process and resumes as if the
Reconfigure message had not been received.
18.2.6. Creation and Transmission of Information-request Messages
The client uses an Information-request message to obtain
configuration information without requesting addresses and/or
delegated prefixes to be assigned.
The client sets the "msg-type" field to INFORMATION-REQUEST. The
client generates a transaction ID and inserts this value in the
"transaction-id" field.
The client SHOULD include a Client Identifier option (see
Section 21.2) to identify itself to the server (however, see
Section 4.3.1 of [RFC7844] for reasons why a client may not want to
include this option). If the client does not include a Client
Identifier option, the server will not be able to return any client-
specific options to the client, or the server may choose not to
respond to the message at all.
The client MUST include an Elapsed Time option (see Section 21.9) to
indicate how long the client has been trying to complete the current
DHCP message exchange.
The client MUST include an Option Request option (see Section 21.7)
to request the INF_MAX_RT option (see Section 21.25), the Information
Refresh Time option (see Section 21.23), and any other options the
client is interested in receiving. The client MAY include options
with data values as hints to the server about parameter values the
client would like to have returned.
When responding to a Reconfigure, the client MUST include a Server
Identifier option (see Section 21.3) with the identifier from the
Reconfigure message to which the client is responding.
The first Information-request message from the client on the
interface MUST be delayed by a random amount of time between 0 and
INF_MAX_DELAY. The client transmits the message according to
Section 15, using the following parameters:
* IRT: INF_TIMEOUT
* MRT: INF_MAX_RT
* MRC: 0
* MRD: 0
18.2.7. Creation and Transmission of Release Messages
To release one or more leases, a client sends a Release message to
the server.
The client sets the "msg-type" field to RELEASE. The client
generates a transaction ID and places this value in the "transaction-
id" field.
The client MUST include a Server Identifier option (see Section 21.3)
in the Renew message, identifying the server that allocated the
lease(s).
The client MUST include a Client Identifier option (see Section 21.2)
to identify itself to the server.
The client MUST include an Elapsed Time option (see Section 21.9) to
indicate how long the client has been trying to complete the current
DHCP message exchange.
The client includes options containing the IAs for the leases it is
releasing in the "options" field. The leases to be released MUST be
included in the IAs. Any leases for the IAs the client wishes to
continue to use MUST NOT be added to the IAs.
The client MUST stop using all of the leases being released before
the client begins the Release message exchange process. For an
address, this means the address MUST have been removed from the
interface. For a delegated prefix, this means the prefix MUST have
been advertised with a Preferred Lifetime and a Valid Lifetime of 0
in a Router Advertisement message as described in part (e) of
Section 5.5.3 of [RFC4862]; also see requirement L-13 in Section 4.3
of [RFC7084].
The client MUST NOT use any of the addresses it is releasing as the
source address in the Release message or in any subsequently
transmitted message.
Because Release messages may be lost, the client should retransmit
the Release if no Reply is received. However, there are scenarios
where the client may not wish to wait for the normal retransmission
timeout before giving up (e.g., on power down). Implementations
SHOULD retransmit one or more times but MAY choose to terminate the
retransmission procedure early.
The client transmits the message according to Section 15, using the
following parameters:
* IRT: REL_TIMEOUT
* MRT: 0
* MRC: REL_MAX_RC
* MRD: 0
If leases are released but the Reply from a DHCP server is lost, the
client will retransmit the Release message, and the server may
respond with a Reply indicating a status of NoBinding. Therefore,
the client does not treat a Reply message with a status of NoBinding
in a Release message exchange as if it indicates an error.
Note that if the client fails to release the lease, each lease
assigned to the IA will be reclaimed by the server when the valid
lifetime of that lease expires.
18.2.8. Creation and Transmission of Decline Messages
If a client detects that one or more addresses assigned to it by a
server are already in use by another node, the client sends a Decline
message to the server to inform it that the address is suspect.
The Decline message is not used in prefix delegation; thus, the
client MUST NOT include IA_PD options (see Section 21.21) in the
Decline message.
The client sets the "msg-type" field to DECLINE. The client
generates a transaction ID and places this value in the "transaction-
id" field.
The client MUST include a Server Identifier option (see Section 21.3)
in the Decline message, identifying the server that allocated the
lease(s).
The client MUST include a Client Identifier option (see Section 21.2)
to identify itself to the server.
The client MUST include an Elapsed Time option (see Section 21.9) to
indicate how long the client has been trying to complete the current
DHCP message exchange.
The client includes options containing the IAs for the addresses it
is declining in the "options" field. The addresses to be declined
MUST be included in the IAs. Any addresses for the IAs the client
wishes to continue to use should not be added to the IAs.
The client MUST NOT use any of the addresses it is declining as the
source address in the Decline message or in any subsequently
transmitted message.
The client transmits the message according to Section 15, using the
following parameters:
* IRT: DEC_TIMEOUT
* MRT: 0
* MRC: DEC_MAX_RC
* MRD: 0
If addresses are declined but the Reply from a DHCP server is lost,
the client will retransmit the Decline message, and the server may
respond with a Reply indicating a status of NoBinding. Therefore,
the client does not treat a Reply message with a status of NoBinding
in a Decline message exchange as if it indicates an error.
The client SHOULD NOT send a Release message for other bindings it
may have received just because it sent a Decline message. The client
SHOULD retain the non-conflicting bindings. The client SHOULD treat
the failure to acquire a binding (due to the conflict) as equivalent
to not having received the binding, insofar as how it behaves when
sending Renew and Rebind messages.
18.2.9. Receipt of Advertise Messages
Upon receipt of one or more valid Advertise messages, the client
selects one or more Advertise messages based upon the following
criteria.
* Those Advertise messages with the highest server preference value
SHOULD be preferred over all other Advertise messages. The client
MAY choose a less preferred server if that server has a better set
of advertised parameters, such as the available set of IAs, as
well as the set of other configuration options advertised.
* Within a group of Advertise messages with the same server
preference value, a client MAY select those servers whose
Advertise messages advertise information of interest to the
client.
Once a client has selected Advertise message(s), the client will
typically store information about each server, such as the server
preference value, addresses advertised, when the advertisement was
received, and so on.
In practice, this means that the client will maintain independent
per-IA state machines for each selected server.
If the client needs to select an alternate server in the case that a
chosen server does not respond, the client chooses the next server
according to the criteria given above.
The client MUST process any SOL_MAX_RT option (see Section 21.24) and
INF_MAX_RT option (see Section 21.25) present in an Advertise
message, even if the message contains a Status Code option (see
Section 21.13) indicating a failure, and the Advertise message will
be discarded by the client. A client SHOULD only update its
SOL_MAX_RT and INF_MAX_RT values if all received Advertise messages
that contained the corresponding option specified the same value;
otherwise, it should use the default value (see Section 7.6).
The client MUST ignore any Advertise message that contains no
addresses (IA Address options (see Section 21.6) encapsulated in
IA_NA options (see Section 21.4)) and no delegated prefixes (IA
Prefix options (see Section 21.22) encapsulated in IA_PD options (see
Section 21.21)), with the exception that the client:
* MUST process an included SOL_MAX_RT option and
* MUST process an included INF_MAX_RT option.
A client can record in an activity log or display to the user any
associated status message(s).
The client ignoring an Advertise message MUST NOT restart the Solicit
retransmission timer.
18.2.10. Receipt of Reply Messages
Upon the receipt of a valid Reply message in response to a Solicit
with a Rapid Commit option (see Section 21.14), Request, Confirm,
Renew, Rebind, or Information-request message, the client extracts
the top-level Status Code option (see Section 21.13) if present.
The client MUST process any SOL_MAX_RT option (see Section 21.24) and
INF_MAX_RT option (see Section 21.25) present in a Reply message,
even if the message contains a Status Code option indicating a
failure.
If the client receives a Reply message with a status code of
UnspecFail, the server is indicating that it was unable to process
the client's message due to an unspecified failure condition. If the
client retransmits the original message to the same server to retry
the desired operation, the client MUST limit the rate at which it
retransmits the message and limit the duration of the time during
which it retransmits the message (see Section 14.1).
Otherwise (no status code or another status code), the client
processes the Reply as described below based on the original message
for which the Reply was received.
The client MAY choose to report any status code or message from the
Status Code option in the Reply message.
The topic of revoking previously assigned options is discussed in
Section 18.2.10.5.
When a client receives a requested option that has an updated value
from what was previously received, the client SHOULD make use of that
updated value as soon as possible for its configuration information.
18.2.10.1. Reply for Solicit (with Rapid Commit), Request, Renew, or
Rebind
If the client receives a NotOnLink status from the server in response
to a Solicit (with a Rapid Commit option; see Section 21.14) or a
Request, the client can either reissue the message without specifying
any addresses or restart the DHCP server discovery process (see
Section 18 or Section 18.2.13).
If the Reply was received in response to a Solicit (with a Rapid
Commit option), Request, Renew, or Rebind message, the client updates
the information it has recorded about IAs from the IA options
contained in the Reply message:
* Calculate T1 and T2 times (based on T1 and T2 values sent in the
message and the message reception time), if appropriate for the IA
type.
* Add any new leases in the IA option to the IA as recorded by the
client.
* Update lifetimes for any leases in the IA option that the client
already has recorded in the IA.
* Discard any leases from the IA, as recorded by the client, that
have a valid lifetime of 0 in the IA Address or IA Prefix option.
* Leave unchanged any information about leases the client has
recorded in the IA but that were not included in the IA from the
server.
If the client can operate with the addresses and/or prefixes obtained
from the server:
* The client uses the addresses, delegated prefixes, and other
information from any IAs that do not contain a Status Code option
with the NoAddrsAvail or NoPrefixAvail status code. The client
MAY include the IAs for which it received the NoAddrsAvail or
NoPrefixAvail status code, with no addresses or prefixes, in
subsequent Renew and Rebind messages sent to the server, to retry
obtaining the addresses or prefixes for these IAs.
* The client MUST perform duplicate address detection as per
Section 5.4 of [RFC4862], which does list some exceptions, on each
of the received addresses in any IAs on which it has not performed
duplicate address detection during processing of any of the
previous Reply messages from the server. The client performs the
duplicate address detection before using the received addresses
for any traffic. If any of the addresses are found to be in use
on the link, the client sends a Decline message to the server for
those addresses as described in Section 18.2.8.
* For each assigned address that does not have any associated
reachability information (see the definition of "on-link" in
Section 2.1 of [RFC4861]), in order to avoid the problems
described in [RFC4943], the client MUST NOT assume that any
addresses are reachable on-link as a result of receiving an IA
Address option (see Section 21.6). Addresses obtained from an IA
Address option MUST NOT be used to form an implicit prefix with a
length other than 128.
* For each delegated prefix, the client assigns a subnet to each of
the links to which the associated interfaces are attached.
When a client subnets a delegated prefix, it must assign
additional bits to the prefix to generate unique, longer prefixes.
For example, if the client in Figure 1 were delegated
2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and
2001:db8:0:2::/64 for assignment to the two links in the
subscriber network. If the client were delegated 2001:db8:0::/48
and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and
2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and
2001:db8:5:2::/64 for assignment to the other link.
If the client uses a delegated prefix to configure addresses on
interfaces on itself or other nodes behind it, the preferred and
valid lifetimes of those addresses MUST be no longer than the
remaining preferred and valid lifetimes, respectively, for the
delegated prefix at any time. In particular, if the delegated
prefix or a prefix derived from it is advertised for stateless
address autoconfiguration [RFC4862], the advertised preferred and
valid lifetimes MUST NOT exceed the corresponding remaining
lifetimes of the delegated prefix.
Management of the specific configuration information is detailed in
the definition of each option in Section 21.
If the Reply message contains any IAs but the client finds no usable
addresses and/or delegated prefixes in any of these IAs, the client
may either try another server (perhaps restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.
When the client receives a Reply message in response to a Renew or
Rebind message, the client:
* Sends a Request message to the server that responded if any of the
IAs in the Reply message contain the NoBinding status code. The
client places IA options in this message for all IAs. The client
continues to use other bindings for which the server did not
return an error.
* Sends a Renew/Rebind if any of the IAs are not in the Reply
message, but as this likely indicates that the server that
responded does not support that IA type, sending immediately is
unlikely to produce a different result. Therefore, the client
MUST rate-limit its transmissions (see Section 14.1) and MAY just
wait for the normal retransmission time (as if the Reply message
had not been received). The client continues to use other
bindings for which the server did return information.
* Otherwise accepts the information in the IA.
18.2.10.2. Reply for Release and Decline
When the client receives a valid Reply message in response to a
Release message, the client considers the Release event completed,
regardless of the Status Code option (see Section 21.13) returned by
the server.
When the client receives a valid Reply message in response to a
Decline message, the client considers the Decline event completed,
regardless of the Status Code option(s) returned by the server.
18.2.10.3. Reply for Confirm
If the client receives any Reply messages that indicate a status of
Success (explicit or implicit), the client can use the addresses in
the IA and ignore any messages that indicate a NotOnLink status.
When the client only receives one or more Reply messages with the
NotOnLink status in response to a Confirm message, the client
performs DHCP server discovery as described in Section 18.
18.2.10.4. Reply for Information-request
Refer to Section 21.23 for details on how the Information Refresh
Time option (whether or not present in the Reply) should be handled
by the client.
18.2.10.5. Revoking Previously Provided Options
When a client receives a Reply for a Renew, Rebind, or Information-
Request that does not include a requested configuration option that
it previously received in a Reply, the client SHOULD stop using the
previously received configuration information. In other words, the
client should behave as if it never received this configuration
option and return to the relevant default state. If there is no
viable way to stop using the received configuration information, the
values received/configured from the option MAY persist if there are
no other sources for that data and they have no external impact. For
example, a client that previously received a Client FQDN option (see
[RFC4704]) and used it to set up its hostname is allowed to continue
using it if there is no reasonable way for a node to unset its
hostname and it has no external impact. As a counterexample, a
client that previously received an NTP server address from the DHCP
server and does not receive it anymore MUST stop using the configured
NTP server address. The client SHOULD be open to other sources of
the same configuration information. This behavior does not apply to
any IA options; their processing is described in Section 18.2.10.1.
18.2.11. Receipt of Reconfigure Messages
A client receives Reconfigure messages sent to UDP port 546 on
interfaces for which it has acquired configuration information
through DHCP. These messages may be sent at any time. Since the
results of a reconfiguration event may affect application-layer
programs, the client SHOULD log these events and MAY notify these
programs of the change through an implementation-specific interface.
The message MUST be dropped if it doesn't pass the validation, as
explained in Section 16.11, particularly in cases where the
authentication is missing or fails.
Upon receipt of a valid Reconfigure message, the client responds with
a Renew message, a Rebind message, or an Information-request message
as indicated by the Reconfigure Message option (see Section 21.19).
The client ignores the "transaction-id" field in the received
Reconfigure message. While the transaction is in progress, the
client discards any Reconfigure messages it receives.
The Reconfigure message acts as a trigger that signals the client to
complete a successful message exchange. Once the client has received
a Reconfigure, the client proceeds with the message exchange
(retransmitting the Renew, Rebind, or Information-request message if
necessary); the client MUST ignore any additional Reconfigure
messages until the exchange is complete.
Duplicate messages will be ignored because the client will begin the
exchange after the receipt of the first Reconfigure. Retransmitted
messages will either (1) trigger the exchange (if the first
Reconfigure was not received by the client) or (2) be ignored. The
server MAY discontinue retransmission of Reconfigure messages to the
client once the server receives the Renew, Rebind, or Information-
request message from the client.
It might be possible for a duplicate or retransmitted Reconfigure to
be sufficiently delayed (and delivered out of order) that it arrives
at the client after the exchange (initiated by the original
Reconfigure) has been completed. In this case, the client would
initiate a redundant exchange. The likelihood of delayed and out-of-
order delivery is small enough to be ignored. The consequence of the
redundant exchange is inefficiency rather than incorrect operation.
18.2.12. Refreshing Configuration Information
Whenever a client may have moved to a new link, the prefixes/
addresses assigned to the interfaces on that link may no longer be
appropriate for the link to which the client is attached. Examples
of times when a client may have moved to a new link include the
following:
* The client reboots (and has stable storage and persistent DHCP
state).
* The client is reconnected to a link on which it has obtained
leases.
* The client returns from sleep mode.
* The client changes access points (e.g., if using Wi-Fi
technology).
* The client's network interface indicates a disconnection event
followed by a connection event.
Specific algorithms for detecting network attachment changes are out
of scope for this document. Two possible mechanisms for detecting
situations where refreshing configuration information may be needed
are defined in [RFC6059] and [RFC4957].
When the client detects that it may have moved to a new link and it
has obtained addresses and no delegated prefixes from a server, the
client SHOULD initiate a Confirm/Reply message exchange. The client
MUST include any IAs assigned to the interface that may have moved to
a new link, along with the addresses associated with those IAs, in
its Confirm message. Any responding servers will indicate whether
those addresses are appropriate for the link to which the client is
attached with the status in the Reply message it returns to the
client.
If the client has any valid delegated prefixes obtained from the DHCP
server, the client MUST initiate a Rebind/Reply message exchange as
described in Section 18.2.5, with the exception that the
retransmission parameters should be set as for the Confirm message
(see Section 18.2.3). The client includes IA_NAs and IA_PDs, along
with the associated leases, in its Rebind message.
If the client has only obtained network information using
Information-request/Reply message exchanges, the client MUST initiate
an Information-request/Reply message exchange as described in
Section 18.2.6.
If the client has not detected having moved to a new link but has
detected a significant change regarding the prefixes available on the
link, the client SHOULD initiate one of the Renew/Reply, Confirm/
Reply, or Information-request/Reply exchanges. A change is
considered significant when one or more on-link prefixes are added
and/or one or more existing on-link prefixes are deprecated. The
reason for this is that such a significant change may indicate a
configuration change at the server. However, a client MUST rate-
limit such initiation attempts to avoid flooding a server with
requests when there are link issues (for example, only doing one of
these at most every 30 seconds).
The above selection of an exchange to initiate depends on the
client's current state:
* If the client has any valid delegated prefixes obtained from the
server, it sends Renew (as if the T1 time expired) as described in
Section 18.2.4.
* Else, if the client obtained an address(es) from the server, it
sends Confirm as described in Section 18.2.3.
* Else, if only network information was obtained from the server, it
sends an Information-request as described in Section 18.2.6.
18.2.13. Restarting Server Discovery Process
Whenever a client restarts the DHCP server discovery process or
selects an alternate server as described in Section 18.2.9, the
client SHOULD stop using any addresses and delegated prefixes for
which it has bindings (see Section 18.2.7) and, if possible, any
other configuration information it previously received. The client
SHOULD also try to obtain new bindings and other configuration
information from a new server for the same interface. This
facilitates the client using a single state machine for all bindings.
18.3. Server Behavior
For this discussion, the server is assumed to have been configured in
an implementation-specific manner with configurations of interest to
clients.
A server sends an Advertise message in response to each valid Solicit
message it receives to announce the availability of the server to the
client.
In most cases, the server will send a Reply in response to Request,
Confirm, Renew, Rebind, Decline, Release, and Information-request
messages sent by a client. The server will also send a Reply in
response to a Solicit with a Rapid Commit option (see Section 21.14)
when the server is configured to respond with committed lease
assignments.
These Advertise and Reply messages MUST always contain the Server
Identifier option (see Section 21.3) containing the server's DUID and
the Client Identifier option (see Section 21.2) from the client
message if one was present.
In most response messages, the server includes options containing
configuration information for the client. The server must be aware
of the recommendations on message sizes and the use of fragmentation
as discussed in Section 5 of [RFC8200]. If the client included an
Option Request option (see Section 21.7) in its message, the server
includes options in the response message containing configuration
parameters for all of the options identified in the Option Request
option that the server has been configured to return to the client.
The server MAY return additional options to the client if it has been
configured to do so.
Any message sent from a client may arrive at the server encapsulated
in one or more Relay-forward messages. The server MUST use the
received message to construct the proper Relay-reply message to allow
the response to the received message to be relayed through the same
relay agents (in reverse order) as the original client message; see
Section 19.3 for more details. The server may also need to record
this information with each client in case it is needed to send a
Reconfigure message at a later time, unless the server has been
configured with addresses that can be used to send Reconfigure
messages directly to the client (see Section 18.3.11). Note that
servers that support leasequery [RFC5007] also need to record this
information.
By sending Reconfigure messages, the server MAY initiate a
configuration exchange to cause DHCP clients to obtain new addresses,
prefixes, and other configuration information. For example, an
administrator may use a server-initiated configuration exchange when
links in the DHCP domain are to be renumbered or when other
configuration options are updated, perhaps because servers are moved,
added, or removed.
When a client receives a Reconfigure message from the server, the
client initiates sending a Renew, Rebind, or Information-request
message as indicated by msg-type in the Reconfigure Message option
(see Section 21.19). The server sends IAs and/or other configuration
information to the client in a Reply message. The server MAY include
options containing the IAs and new values for other configuration
parameters in the Reply message, even if those IAs and parameters
were not requested in the client's message.
18.3.1. Receipt of Solicit Messages
The server determines the information about the client and its
location as described in Section 13 and checks its administrative
policy about responding to the client. If the server is not
permitted to respond to the client, the server discards the Solicit
message. For example, if the administrative policy for the server is
that it may only respond to a client that is willing to accept a
Reconfigure message, if the client does not include a Reconfigure
Accept option (see Section 21.20) in the Solicit message, the server
discards the Solicit message.
If (1) the server is permitted to respond to the client, (2) the
client has not included a Rapid Commit option (see Section 21.14) in
the Solicit message, or (3) the server has not been configured to
respond with committed assignments of leases and other resources, the
server sends an Advertise message to the client as described in
Section 18.3.9.
If the client has included a Rapid Commit option in the Solicit
message and the server has been configured to respond with committed
assignments of leases and other resources, the server responds to the
Solicit with a Reply message. The server produces the Reply message
as though it had received a Request message as described in
Section 18.3.2. The server transmits the Reply message as described
in Section 18.3.10. The server MUST commit the assignment of any
addresses and delegated prefixes or other configuration information
before sending a Reply message to a client. In this case, the server
includes a Rapid Commit option in the Reply message to indicate that
the Reply is in response to a Solicit message.
DISCUSSION:
* When using the Solicit/Reply message exchange, the server commits
the assignment of any leases before sending the Reply message.
The client can assume that it has been assigned the leases in the
Reply message and does not need to send a Request message for
those leases.
* Typically, servers that are configured to use the Solicit/Reply
message exchange will be deployed so that only one server will
respond to a Solicit message. If more than one server responds,
the client will only use the leases from one of the servers, while
the leases from the other servers will be committed to the client
but not used by the client.
18.3.2. Receipt of Request Messages
When the server receives a valid Request message, the server creates
the bindings for that client according to the server's policy and
configuration information and records the IAs and other information
requested by the client.
The server constructs a Reply message by setting the "msg-type" field
to REPLY and copying the transaction ID from the Request message into
the "transaction-id" field.
The server MUST include in the Reply message a Server Identifier
option (see Section 21.3) containing the server's DUID and the Client
Identifier option (see Section 21.2) from the Request message.
The server examines all IAs in the message from the client.
For each IA_NA option (see Section 21.4) in the Request message, the
server checks if the prefixes of included addresses are appropriate
for the link to which the client is connected. If any of the
prefixes of the included addresses are not appropriate for the link
to which the client is connected, the server MUST return the IA to
the client with a Status Code option (see Section 21.13) with the
value NotOnLink. If the server does not send the NotOnLink status
code but it cannot assign any IP addresses to an IA, the server MUST
return the IA option in the Reply message with no addresses in the IA
and a Status Code option containing status code NoAddrsAvail in the
IA.
For any IA_PD option (see Section 21.21) in the Request message to
which the server cannot assign any delegated prefixes, the server
MUST return the IA_PD option in the Reply message with no prefixes in
the IA_PD and with a Status Code option containing status code
NoPrefixAvail in the IA_PD.
The server MAY assign different addresses and/or delegated prefixes
to an IA than those included within the IA of the client's Request
message.
For all IAs to which the server can assign addresses or delegated
prefixes, the server includes the IAs with addresses (for IA_NAs),
prefixes (for IA_PDs), and other configuration parameters and records
the IA as a new client binding. The server MUST NOT include any
addresses or delegated prefixes in the IA that the server does not
assign to the client.
The T1/T2 times set in each applicable IA option for a Reply MUST be
the same values across all IAs. The server MUST determine the T1/T2
times across all of the applicable client's bindings in the Reply.
This facilitates the client being able to renew all of the bindings
at the same time.
The server SHOULD include a Reconfigure Accept option (see
Section 21.20) if the server policy enables the reconfigure mechanism
and the client supports it. Currently, sending this option in a
Reply is technically redundant, as the use of the reconfiguration
mechanism requires authentication; at present, the only defined
mechanism is RKAP (see Section 20.4), and the presence of the
reconfigure key signals support for the acceptance of Reconfigure
messages. However, there may be better security mechanisms defined
in the future that would cause RKAP to not be used anymore.
The server includes other options containing configuration
information to be returned to the client as described in
Section 18.3.
If the server finds that the client has included an IA in the Request
message for which the server already has a binding that associates
the IA with the client, the server sends a Reply message with
existing bindings, possibly with updated lifetimes. The server may
update the bindings according to its local policies, but the server
SHOULD generate the response again and not simply retransmit
previously sent information, even if the "transaction-id" field value
matches a previous transmission. The server MUST NOT cache its
responses.
DISCUSSION:
* Cached replies are bad because lifetimes need to be updated
(either decrease the timers by the amount of time elapsed since
the original transmission or keep the lifetime values and update
the lease information in the server's database). Also, if the
message uses any security protection (such as the Replay Detection
Method (RDM), as described in Section 20.3), its value must be
updated. Additionally, any digests must be updated. Given all of
the above, caching replies is far more complex than simply sending
the same buffer as before, and it is easy to miss some of those
steps.
18.3.3. Receipt of Confirm Messages
When the server receives a Confirm message, the server determines
whether the addresses in the Confirm message are appropriate for the
link to which the client is attached. If all of the addresses in the
Confirm message pass this test, the server returns a status of
Success. If any of the addresses do not pass this test, the server
returns a status of NotOnLink. If the server is unable to perform
this test (for example, the server does not have information about
prefixes on the link to which the client is connected) or there were
no addresses in any of the IAs sent by the client, the server MUST
NOT send a Reply to the client.
The server ignores the T1 and T2 fields in the IA options and the
preferred-lifetime and valid-lifetime fields in the IA Address
options (see Section 21.6).
The server constructs a Reply message by setting the "msg-type" field
to REPLY and copying the transaction ID from the Confirm message into
the "transaction-id" field.
The server MUST include in the Reply message a Server Identifier
option (see Section 21.3) containing the server's DUID and the Client
Identifier option (see Section 21.2) from the Confirm message. The
server includes a Status Code option (see Section 21.13) indicating
the status of the Confirm message.
18.3.4. Receipt of Renew Messages
For each IA in the Renew message from a client, the server locates
the client's binding and verifies that the information in the IA from
the client matches the information stored for that client.
If the server finds the client entry for the IA, the server sends the
IA back to the client with new lifetimes and, if applicable, T1/T2
times. If the server is unable to extend the lifetimes of an address
or delegated prefix in the IA, the server MAY choose not to include
the IA Address option (see Section 21.6) for that address or IA
Prefix option (see Section 21.22) for that delegated prefix. If the
server chooses to include the IA Address or IA Prefix option for such
an address or delegated prefix, the server SHOULD set T1 and T2
values to the valid lifetime for the IA option unless the server also
includes other addresses or delegated prefixes that the server is
able to extend for the IA. Setting T1 and T2 to values equal to the
valid lifetime informs the client that the leases associated with
said IA will not be extended, so there is no point in trying. Also,
it avoids generating unnecessary traffic as the remaining lifetime
approaches 0.
The server may choose to change the list of addresses or delegated
prefixes and the lifetimes in IAs that are returned to the client.
If the server finds that any of the addresses in the IA are not
appropriate for the link to which the client is attached, the server
returns the address to the client with lifetimes of 0.
If the server finds that any of the delegated prefixes in the IA are
not appropriate for the link to which the client is attached, the
server returns the delegated prefix to the client with lifetimes of
0.
For each IA for which the server cannot find a client entry, the
server has the following choices, depending on the server's policy
and configuration information:
* If the server is configured to create new bindings as a result of
processing Renew messages, the server SHOULD create a binding and
return the IA with assigned addresses or delegated prefixes with
lifetimes and, if applicable, T1/T2 times and other information
requested by the client. If the client included the IA Prefix
option within the IA_PD option (see Section 21.21) with a zero
value in the "IPv6-prefix" field and a non-zero value in the
"prefix-length" field, the server MAY use the "prefix-length"
value as a hint for the length of the prefixes to be assigned (see
[RFC8168] for further details on prefix-length hints).
* If the server is configured to create new bindings as a result of
processing Renew messages but the server will not assign any
leases to an IA, the server returns the IA option containing a
Status Code option (see Section 21.13) with the NoAddrsAvail or
NoPrefixAvail status code and a status message for a user.
* If the server does not support creation of new bindings for the
client sending a Renew message or if this behavior is disabled
according to the server's policy or configuration information, the
server returns the IA option containing a Status Code option with
the NoBinding status code and a status message for a user.
The server constructs a Reply message by setting the "msg-type" field
to REPLY and copying the transaction ID from the Renew message into
the "transaction-id" field.
The server MUST include in the Reply message a Server Identifier
option (see Section 21.3) containing the server's DUID and the Client
Identifier option (see Section 21.2) from the Renew message.
The server includes other options containing configuration
information to be returned to the client as described in
Section 18.3.
The server MAY include options containing the IAs and values for
other configuration parameters, even if those parameters were not
requested in the Renew message.
The T1/T2 values set in each applicable IA option for a Reply MUST be
the same across all IAs. The server MUST determine the T1/T2 values
across all of the applicable client's bindings in the Reply. This
facilitates the client being able to renew all of the bindings at the
same time.
18.3.5. Receipt of Rebind Messages
When the server receives a Rebind message that contains an IA option
from a client, it locates the client's binding and verifies that the
information in the IA from the client matches the information stored
for that client.
If the server finds the client entry for the IA and the server
determines that the addresses or delegated prefixes in the IA are
appropriate for the link to which the client's interface is attached
according to the server's explicit configuration information, the
server SHOULD send the IA back to the client with new lifetimes and,
if applicable, T1/T2 values. If the server is unable to extend the
lifetimes of an address in the IA, the server MAY choose not to
include the IA Address option (see Section 21.6) for this address.
If the server is unable to extend the lifetimes of a delegated prefix
in the IA, the server MAY choose not to include the IA Prefix option
(see Section 21.22) for this prefix.
If the server finds that the client entry for the IA and any of the
addresses or delegated prefixes are no longer appropriate for the
link to which the client's interface is attached according to the
server's explicit configuration information, the server returns those
addresses or delegated prefixes to the client with lifetimes of 0.
If the server cannot find a client entry for the IA, the server
checks if the IA contains addresses (for IA_NAs) or delegated
prefixes (for IA_PDs). The server checks if the addresses and
delegated prefixes are appropriate for the link to which the client's
interface is attached according to the server's explicit
configuration information. For any address that is not appropriate
for the link to which the client's interface is attached, the server
MAY include the IA Address option with lifetimes of 0. For any
delegated prefix that is not appropriate for the link to which the
client's interface is attached, the server MAY include the IA Prefix
option with lifetimes of 0. The Reply with lifetimes of 0
constitutes an explicit notification to the client that the specific
addresses and delegated prefixes are no longer valid and MUST NOT be
used by the client. If the server chooses to not include any IAs
containing IA Address or IA Prefix options with lifetimes of 0 and
the server does not include any other IAs with leases and/or status
codes, the server does not send a Reply message. In this situation,
the server discards the Rebind message.
Otherwise, for each IA for which the server cannot find a client
entry, the server has the following choices, depending on the
server's policy and configuration information:
* If the server is configured to create new bindings as a result of
processing Rebind messages (also see the note below about the
Rapid Commit option (Section 21.14)), the server SHOULD create a
binding and return the IA with allocated leases with lifetimes
and, if applicable, T1/T2 values and other information requested
by the client. The server MUST NOT return any addresses or
delegated prefixes in the IA that the server does not assign to
the client.
* If the server is configured to create new bindings as a result of
processing Rebind messages but the server will not assign any
leases to an IA, the server returns the IA option containing a
Status Code option (see Section 21.13) with the NoAddrsAvail or
NoPrefixAvail status code and a status message for a user.
* If the server does not support creation of new bindings for the
client sending a Rebind message or if this behavior is disabled
according to the server's policy or configuration information, the
server returns the IA option containing a Status Code option with
the NoBinding status code and a status message for a user.
When the server creates new bindings for the IA, it is possible that
other servers also create bindings as a result of receiving the same
Rebind message; see the "DISCUSSION" text in Section 21.14.
Therefore, the server SHOULD only create new bindings during
processing of a Rebind message if the server is configured to respond
with a Reply message to a Solicit message containing the Rapid Commit
option.
The server constructs a Reply message by setting the "msg-type" field
to REPLY and copying the transaction ID from the Rebind message into
the "transaction-id" field.
The server MUST include in the Reply message a Server Identifier
option (see Section 21.3) containing the server's DUID and the Client
Identifier option (see Section 21.2) from the Rebind message.
The server includes other options containing configuration
information to be returned to the client as described in
Section 18.3.
The server MAY include options containing the IAs and values for
other configuration parameters, even if those IAs and parameters were
not requested in the Rebind message.
The T1 or T2 values set in each applicable IA option for a Reply MUST
be the same values across all IAs. The server MUST determine the T1
or T2 values across all of the applicable client's bindings in the
Reply. This facilitates the client being able to renew all of the
bindings at the same time.
18.3.6. Receipt of Information-request Messages
When the server receives an Information-request message, the client
is requesting configuration information that does not include the
assignment of any leases. The server determines all configuration
parameters appropriate to the client, based on the server
configuration policies known to the server.
The server constructs a Reply message by setting the "msg-type" field
to REPLY and copying the transaction ID from the Information-request
message into the "transaction-id" field.
The server MUST include a Server Identifier option (see Section 21.3)
containing the server's DUID in the Reply message. If the client
included a Client Identifier option (see Section 21.2) in the
Information-request message, the server copies that option to the
Reply message.
The server includes options containing configuration information to
be returned to the client as described in Section 18.3. The server
MAY include additional options that were not requested by the client
in the Information-request message.
If the Information-request message received from the client did not
include a Client Identifier option, the server SHOULD respond with a
Reply message containing any configuration parameters that are not
determined by the client's identity. If the server chooses not to
respond, the client may continue to retransmit the Information-
request message indefinitely.
18.3.7. Receipt of Release Messages
The server constructs a Reply message by setting the "msg-type" field
to REPLY and copying the transaction ID from the Release message into
the "transaction-id" field.
Upon the receipt of a valid Release message, the server examines the
IAs and the leases in the IAs for validity. If the IAs in the
message are in a binding for the client and the leases in the IAs
have been assigned by the server to those IAs, the server deletes the
leases from the IAs and makes the leases available for assignment to
other clients. The server ignores leases not assigned to the IAs,
although it may choose to log an error.
After all the leases have been processed, the server generates a
Reply message and includes a Status Code option (see Section 21.13)
with the value Success, a Server Identifier option (see Section 21.3)
with the server's DUID, and a Client Identifier option (see
Section 21.2) with the client's DUID. For each IA in the Release
message for which the server has no binding information, the server
adds an IA option using the IAID from the Release message and
includes a Status Code option with the value NoBinding in the IA
option. No other options are included in the IA option.
A server may choose to retain a record of assigned leases and IAs
after the lifetimes on the leases have expired to allow the server to
reassign the previously assigned leases to a client.
18.3.8. Receipt of Decline Messages
Upon the receipt of a valid Decline message, the server examines the
IAs and the addresses in the IAs for validity. If the IAs in the
message are in a binding for the client and the addresses in the IAs
have been assigned by the server to those IAs, the server deletes the
addresses from the IAs. The server ignores addresses not assigned to
the IAs (though it may choose to log an error if it finds such
addresses).
The client has found any addresses in the Decline messages to be
already in use on its link. Therefore, the server SHOULD mark the
addresses declined by the client so that those addresses are not
assigned to other clients and MAY choose to make a notification that
addresses were declined. Local policy on the server determines when
the addresses identified in a Decline message may be made available
for assignment.
After all the addresses have been processed, the server generates a
Reply message by setting the "msg-type" field to REPLY and copying
the transaction ID from the Decline message into the "transaction-id"
field. The server includes a Status Code option (see Section 21.13)
with the value Success, a Server Identifier option (see Section 21.3)
with the server's DUID, and a Client Identifier option (see
Section 21.2) with the client's DUID. For each IA in the Decline
message for which the server has no binding information, the server
adds an IA option using the IAID from the Decline message and
includes a Status Code option with the value NoBinding in the IA
option. No other options are included in the IA option.
18.3.9. Creation of Advertise Messages
The server sets the "msg-type" field to ADVERTISE and copies the
contents of the "transaction-id" field from the Solicit message
received from the client to the Advertise message. The server
includes its server identifier in a Server Identifier option (see
Section 21.3) and copies the Client Identifier option (see
Section 21.2) from the Solicit message into the Advertise message.
The server MAY add a Preference option (see Section 21.8) to carry
the preference value for the Advertise message. The server
implementation SHOULD allow the setting of a server preference value
by the administrator. The server preference value MUST default to 0
unless otherwise configured by the server administrator.
The server includes a Reconfigure Accept option (see Section 21.20)
if the server wants to indicate that it supports the Reconfigure
mechanism. This information may be used by the client during the
server selection process.
The server includes the options the server will return to the client
in a subsequent Reply message. The information in these options may
be used by the client in the selection of a server if the client
receives more than one Advertise message. The server MUST include
options in the Advertise message containing configuration parameters
for all of the options identified in the Option Request option (see
Section 21.7) in the Solicit message that the server has been
configured to return to the client. If the Option Request option
includes a container option, the server MUST include all the options
that are eligible to be encapsulated in the container. 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]. In this case, special processing is required by
the server. The server MAY return additional options to the client
if it has been configured to do so.
The server MUST include IA options in the Advertise message
containing any addresses and/or delegated prefixes that would be
assigned to IAs contained in the Solicit message from the client. If
the client has included addresses in the IA Address options (see
Section 21.6) in the Solicit message, the server MAY use those
addresses as hints about the addresses that the client would like to
receive. If the client has included IA Prefix options (see
Section 21.22), the server MAY use the prefix contained in the
"IPv6-prefix" field and/or the prefix length contained in the
"prefix-length" field as hints about the prefixes the client would
like to receive. If the server is not going to assign an address or
delegated prefix received as a hint in the Solicit message, the
server MUST NOT include this address or delegated prefix in the
Advertise message.
If the server will not assign any addresses to an IA_NA in subsequent
Request messages from the client, the server MUST include the IA
option in the Advertise message with no addresses in that IA and a
Status Code option (see Section 21.13) encapsulated in the IA option
containing status code NoAddrsAvail.
If the server will not assign any prefixes to an IA_PD in subsequent
Request messages from the client, the server MUST include the IA_PD
option (see Section 21.21) in the Advertise message with no prefixes
in the IA_PD option and a Status Code option encapsulated in the
IA_PD containing status code NoPrefixAvail.
Transmission of Advertise messages is described in the next section.
18.3.10. Transmission of Advertise and Reply Messages
If the original message was received directly by the server, the
server unicasts the Advertise or Reply message directly to the client
using the address in the source address field from the IP datagram in
which the original message was received. The Advertise or Reply
message MUST be unicast through the interface on which the original
message was received.
If the original message was received in a Relay-forward message, the
server constructs a Relay-reply message with the Reply message in the
payload of a Relay Message option (see Section 21.10). If the Relay-
forward messages included an Interface-Id option (see Section 21.18),
the server copies that option to the Relay-reply message. The server
unicasts the Relay-reply message directly to the relay agent using
the address in the source address field from the IP datagram in which
the Relay-forward message was received. See Section 19.3 for more
details on the construction of Relay-reply messages.
18.3.11. Creation and Transmission of Reconfigure Messages
The server sets the "msg-type" field to RECONFIGURE and sets the
"transaction-id" field to 0. The server includes a Server Identifier
option (see Section 21.3) containing its DUID and a Client Identifier
option (see Section 21.2) containing the client's DUID in the
Reconfigure message.
Because of the risk of denial-of-service (DoS) attacks against DHCP
clients, the use of a security mechanism is mandated in Reconfigure
messages. The server MUST use DHCP authentication in the Reconfigure
message (see Section 20.4).
The server MUST include a Reconfigure Message option (see
Section 21.19) to select whether the client responds with a Renew
message, a Rebind message, or an Information-request message.
The server MUST NOT include any other options in the Reconfigure
message, except as specifically allowed in the definition of
individual options.
A server sends each Reconfigure message to a single DHCP client,
using an IPv6 unicast address of sufficient scope belonging to the
DHCP client. If the server does not have an address to which it can
send the Reconfigure message directly to the client, the server uses
a Relay-reply message (as described in Section 19.3) to send the
Reconfigure message to a relay agent that will relay the message to
the client. The server may obtain the address of the client (and the
appropriate relay agent, if required) through the information the
server has about clients that have been in contact with the server
(see Section 18.3) or through some external agent.
To reconfigure more than one client, the server unicasts a separate
message to each client. The server may initiate the reconfiguration
of multiple clients concurrently; for example, a server may send a
Reconfigure message to additional clients while previous
reconfiguration message exchanges are still in progress.
The Reconfigure message causes the client to initiate a Renew/Reply,
Rebind/Reply, or Information-request/Reply message exchange with the
server. The server interprets the receipt of a Renew, Rebind, or
Information-request message (whichever was specified in the original
Reconfigure message) from the client as satisfying the Reconfigure
message request.
When transmitting the Reconfigure message, the server sets the
retransmission time (RT) to REC_TIMEOUT. If the server does not
receive a Renew, Rebind, or Information-request message from the
client before the RT elapses, the server retransmits the Reconfigure
message, doubles the RT value, and waits again. The server continues
this process until REC_MAX_RC unsuccessful attempts have been made,
at which point the server SHOULD abort the reconfigure process for
that client.
Default and initial values for REC_TIMEOUT and REC_MAX_RC are
documented in Section 7.6.