12. Management of Temporary Addresses
A client may request the assignment of temporary addresses (see RFC
3041 [12] for the definition of temporary addresses). DHCPv6
handling of address assignment is no different for temporary
addresses. DHCPv6 says nothing about details of temporary addresses
like lifetimes, how clients use temporary addresses, rules for
generating successive temporary addresses, etc.
Clients ask for temporary addresses and servers assign them.
Temporary addresses are carried in the Identity Association for
Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA
option contains at most one temporary address for each of the
prefixes on the link to which the client is attached.
The IAID number space for the IA_TA option IAID number space is
separate from the IA_NA option IAID number space.
The server MAY update the DNS for a temporary address, as described
in section 4 of RFC3041.
13. Transmission of Messages by a Client
Unless otherwise specified in this document, or in a document that
describes how IPv6 is carried over a specific type of link (for link
types that do not support multicast), a client sends DHCP messages to
the All_DHCP_Relay_Agents_and_Servers.
A client uses multicast to reach all servers or an individual server.
An individual server is indicated by specifying that server's DUID in
a Server Identifier option (see section 22.3) in the client's message
(all servers will receive this message but only the indicated server
will respond). All servers are indicated by not supplying this
option.
A client may send some messages directly to a server using unicast,
as described in section 22.12.
14. Reliability of Client Initiated Message Exchanges
DHCP clients are responsible for reliable delivery of messages in the
client-initiated message exchanges described in sections 17 and 18.
If a DHCP client fails to receive an expected response from a server,
the client must retransmit its message. This section describes the
retransmission strategy to be used by clients in client-initiated
message exchanges.
Note that the procedure described in this section is slightly
modified when used with the Solicit message. The modified procedure
is described in section 17.1.2.
The client begins the message exchange by transmitting a message to
the server. The message exchange terminates when either the client
successfully receives the appropriate response or responses from a
server or servers, or when the message exchange is considered to have
failed according to the retransmission mechanism described below.
The client retransmission behavior is controlled and described by the
following variables:
RT Retransmission timeout
IRT Initial retransmission time
MRC Maximum retransmission count
MRT Maximum retransmission time
MRD Maximum retransmission duration
RAND Randomization factor
With each message transmission or retransmission, the client sets RT
according to the rules given below. If RT expires before the message
exchange terminates, the client recomputes RT and retransmits the
message.
Each of the computations of a new RT include a randomization factor
(RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to
minimize synchronization of messages transmitted by DHCP clients.
The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different
sequence of random numbers from each invocation of the DHCP client.
RT for the first message transmission is based on IRT:
RT = IRT + RAND*IRT
RT for each subsequent message transmission is based on the previous
value of RT:
RT = 2*RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0,
there is no upper limit on the value of RT. Otherwise:
if (RT > MRT)
RT = MRT + RAND*MRT
MRC specifies an upper bound on the number of times a client may
retransmit a message. Unless MRC is zero, the message exchange fails
once the client has transmitted the message MRC times.
MRD specifies an upper bound on the length of time a client may
retransmit a message. Unless MRD is zero, the message exchange fails
once MRD seconds have elapsed since the client first transmitted the
message.
If both MRC and MRD are non-zero, the message exchange fails whenever
either of the conditions specified in the previous two paragraphs are
met.
If both MRC and MRD are zero, the client continues to transmit the
message until it receives a response.
15. Message Validation
Clients and servers SHOULD discard any messages that contain options
that are not allowed to appear in the received message. For example,
an IA option is not allowed to appear in an Information-request
message. Clients and servers MAY choose to extract information from
such a message if the information is of use to the recipient.
A server MUST discard any Solicit, Confirm, Rebind or
Information-request messages it receives with a unicast destination
address.
Message validation based on DHCP authentication is discussed in
section 21.4.2.
If a server receives a message that contains options it should not
contain (such as an Information-request message with an IA option),
is missing options that it should contain, or is otherwise not valid,
it MAY send a Reply (or Advertise as appropriate) with a Server
Identifier option, a Client Identifier option if one was included in
the message and a Status Code option with status UnSpecFail.
15.1. Use of Transaction IDs
The "transaction-id" field holds a value used by clients and servers
to synchronize server responses to client messages. A client SHOULD
generate a random number that cannot easily be guessed or predicted
to use as the transaction ID for each new message it sends. Note
that if a client generates easily predictable transaction
identifiers, it may become more vulnerable to certain kinds of
attacks from off-path intruders. A client MUST leave the transaction
ID unchanged in retransmissions of a message.
15.2. Solicit Message
Clients MUST discard any received Solicit messages.
Servers MUST discard any Solicit messages that do not include a
Client Identifier option or that do include a Server Identifier
option.
15.3. Advertise Message
Clients MUST discard any received Advertise messages that meet any of
the following conditions:
- the message does not include a Server Identifier option.
- the message does not include a Client Identifier option.
- the contents of the Client Identifier option does not match the
client's DUID.
- the "transaction-id" field value does not match the value the
client used in its Solicit message.
Servers and relay agents MUST discard any received Advertise
messages.
15.4. Request Message
Clients MUST discard any received Request messages.
Servers MUST discard any received Request message that meet any of
the following conditions:
- the message does not include a Server Identifier option.
- the contents of the Server Identifier option do not match the
server's DUID.
- the message does not include a Client Identifier option.
15.5. Confirm Message
Clients MUST discard any received Confirm messages.
Servers MUST discard any received Confirm messages that do not
include a Client Identifier option or that do include a Server
Identifier option.
15.6. Renew Message
Clients MUST discard any received Renew messages.
Servers MUST discard any received Renew message that meets any of the
following conditions:
- the message does not include a Server Identifier option.
- the contents of the Server Identifier option does not match the
server's identifier.
- the message does not include a Client Identifier option.
15.7. Rebind Message
Clients MUST discard any received Rebind messages.
Servers MUST discard any received Rebind messages that do not include
a Client Identifier option or that do include a Server Identifier
option.
15.8. Decline Messages
Clients MUST discard any received Decline messages.
Servers MUST discard any received Decline message that meets any of
the following conditions:
- the message does not include a Server Identifier option.
- the contents of the Server Identifier option does not match the
server's identifier.
- the message does not include a Client Identifier option.
15.9. Release Message
Clients MUST discard any received Release messages.
Servers MUST discard any received Release message that meets any of
the following conditions:
- the message does not include a Server Identifier option.
- the contents of the Server Identifier option does not match the
server's identifier.
- the message does not include a Client Identifier option.
15.10. Reply Message
Clients MUST discard any received Reply message that meets any of the
following conditions:
- the message does not include a Server Identifier option.
- the "transaction-id" field in the message does not match the value
used in the original message.
If the client included a Client Identifier option in the original
message, the Reply message MUST include a Client Identifier option
and the contents of the Client Identifier option MUST match the DUID
of the client; OR, if the client did not include a Client Identifier
option in the original message, the Reply message MUST NOT include a
Client Identifier option.
Servers and relay agents MUST discard any received Reply messages.
15.11. Reconfigure Message
Servers and relay agents MUST discard any received Reconfigure
messages.
Clients MUST discard any Reconfigure messages that meets any of the
following conditions:
- the message was not unicast to the client.
- the message does not include a Server Identifier option.
- the message does not include a Client Identifier option that
contains the client's DUID.
- the message does not contain a Reconfigure Message option and the
msg-type must be a valid value.
- the message includes any IA options and the msg-type in the
Reconfigure Message option is INFORMATION-REQUEST.
- the message does not include DHCP authentication:
* the message does not contain an authentication option.
* the message does not pass the authentication validation
performed by the client.
15.12. Information-request Message
Clients MUST discard any received Information-request messages.
Servers MUST discard any received Information-request message that
meets any of the following conditions:
- The message includes a Server Identifier option and the DUID in
the option does not match the server's DUID.
- The message includes an IA option.
15.13. Relay-forward Message
Clients MUST discard any received Relay-forward messages.
15.14. Relay-reply Message
Clients and servers MUST discard any received Relay-reply messages.
16. Client Source Address and Interface Selection
When a client sends a DHCP message to the
All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message
through the interface for which configuration information is being
requested. However, the client MAY send the message through another
interface attached to the same link, if and only if the client is
certain the two interfaces are attached to the same link. The client
MUST use a link-local address assigned to the interface for which it
is requesting configuration information as the source address in the
header of the IP datagram.
When a client sends a DHCP message directly to a server using unicast
(after receiving the Server Unicast option from that server), the
source address in the header of the IP datagram MUST be an address
assigned to the interface for which the client is interested in
obtaining configuration and which is suitable for use by the server
in responding to the client.
17. DHCP Server Solicitation
This section describes how a client locates servers that will assign
addresses to IAs belonging to the client.
The client is responsible for creating IAs and requesting that a
server assign IPv6 addresses to the IA. The client first creates an
IA and assigns it an IAID. The client then transmits a Solicit
message containing an IA option describing the IA. Servers that can
assign addresses to the IA respond to the client with an Advertise
message. The client then initiates a configuration exchange as
described in section 18.
If the client will accept a Reply message with committed address
assignments and other resources in response to the Solicit message,
the client includes a Rapid Commit option (see section 22.14) in the
Solicit message.
17.1. Client Behavior
A client uses the Solicit message to discover DHCP servers configured
to assign addresses or return other configuration parameters on the
link to which the client is attached.
17.1.1. Creation 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 to identify itself
to the server. The client includes IA options for any IAs to which
it wants the server to assign addresses. The client MAY include
addresses in the IAs as a hint to the server about addresses for
which the client has a preference. The client MUST NOT include any
other options in the Solicit message, except as specifically allowed
in the definition of individual options.
The client uses IA_NA options to request the assignment of non-
temporary addresses and uses IA_TA options to request the assignment
of temporary addresses. Either IA_NA or IA_TA options, or a
combination of both, can be included in DHCP messages.
The client SHOULD include an Option Request option (see section 22.7)
to indicate the 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 22.20)
if the client is willing to accept Reconfigure messages from the
server.
17.1.2. Transmission of Solicit Messages
The first Solicit message from the client on the interface MUST be
delayed by a random amount of time between 0 and SOL_MAX_DELAY. In
the case of a Solicit message transmitted when DHCP is initiated by
IPv6 Neighbor Discovery, the delay gives the amount of time to wait
after IPv6 Neighbor Discovery causes the client to invoke the
stateful address autoconfiguration protocol (see section 5.5.3 of RFC
2462). This random delay desynchronizes clients which start at the
same time (for example, after a power outage).
The client transmits the message according to section 14, using the
following parameters:
IRT SOL_TIMEOUT
MRT SOL_MAX_RT
MRC 0
MRD 0
If the client has included a Rapid Commit option in its Solicit
message, the client terminates the waiting process as soon as a Reply
message with a Rapid Commit option is received.
If the client is waiting for an Advertise message, the mechanism in
section 14 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 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 Advertise messages for the first RT seconds,
unless it receives an Advertise message with a preference value of
255. The preference value is carried in the Preference option
(section 22.8). Any Advertise that does not include a Preference
option is considered to have a preference value of 0. If the client
receives an 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) by sending a
Request message to the server from which the Advertise message was
received. If the client receives an 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 an Advertise message, the client
SHOULD continue with a client-initiated message exchange by sending a
Request message.
If the client does not receive any Advertise messages before the
first RT has elapsed, it begins the retransmission mechanism
described in section 14. The client terminates the retransmission
process as soon as it receives any 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 to be 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.
17.1.3. Receipt of Advertise Messages
The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message to the
user.
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
are preferred over all other Advertise messages.
- 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. For example, the client may choose a server that returned
an advertisement with configuration options of interest to the
client.
- The client MAY choose a less-preferred server if that server has a
better set of advertised parameters, such as the available
addresses advertised in IAs.
Once a client has selected Advertise message(s), the client will
typically store information about each server, such as server
preference value, addresses advertised, when the advertisement was
received, and so on.
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.
17.1.4. Receipt of Reply Message
If the client includes a Rapid Commit option in the Solicit message,
it will expect a Reply message that includes a Rapid Commit option in
response. The client discards any Reply messages it receives that do
not include a Rapid Commit option. If the client receives a valid
Reply message that includes a Rapid Commit option, it processes the
message as described in section 18.1.8. If it does not receive such
a Reply message and does receive a valid Advertise message, the
client processes the Advertise message as described in section
17.1.3.
If the client subsequently receives a valid Reply message that
includes a Rapid Commit option, it either:
processes the Reply message as described in section 18.1.8, and
discards any Reply messages received in response to the Request
message, or
processes any Reply messages received in response to the Request
message and discards the Reply message that includes the Rapid
Commit option.
17.2. Server Behavior
A server sends an Advertise message in response to valid Solicit
messages it receives to announce the availability of the server to
the client.
17.2.1. Receipt of Solicit Messages
The server determines the information about the client and its
location as described in section 11 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 indicates with a Reconfigure
Accept option in the Solicit message that it will not accept a
Reconfigure message, the servers discard the Solicit message.
If the client has included a Rapid Commit option in the Solicit
message and the server has been configured to respond with committed
address assignments and other resources, the server responds to the
Solicit with a Reply message as described in section 17.2.3.
Otherwise, the server ignores the Rapid Commit option and processes
the remainder of the message as if no Rapid Commit option were
present.
17.2.2. Creation and Transmission 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 and
copies the Client Identifier from the Solicit message into the
Advertise message.
The server MAY add a Preference option 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 zero unless otherwise
configured by the server administrator.
The server includes a Reconfigure Accept option if the server wants
to require that the client accept Reconfigure messages.
The server includes 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. If the client has included
an Option Request option in the Solicit message, the server includes
options in the Advertise 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. The server must be aware of the recommendations on packet
sizes and the use of fragmentation in section 5 of RFC2460.
If the Solicit message from the client included one or more IA
options, the server MUST include IA options in the Advertise message
containing any addresses that would be assigned to IAs contained in
the Solicit message from the client. If the client has included
addresses in the IAs in the Solicit message, the server uses those
addresses as hints about the addresses the client would like to
receive.
If the server will not assign any addresses to any IAs in a
subsequent Request from the client, the server MUST send an Advertise
message to the client that includes only a Status Code option with
code NoAddrsAvail and a status message for the user, a Server
Identifier option with the server's DUID, and a Client Identifier
option with the client's DUID.
If the Solicit message was received directly by the server, the
server unicasts the Advertise message directly to the client using
the address in the source address field from the IP datagram in which
the Solicit message was received. The Advertise message MUST be
unicast on the link from which the Solicit message was received.
If the Solicit message was received in a Relay-forward message, the
server constructs a Relay-reply message with the Advertise message in
the payload of a "relay-message" option. If the Relay-forward
messages included an Interface-id option, 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.
17.2.3. Creation and Transmission of Reply Messages
The server MUST commit the assignment of any addresses or other
configuration information message before sending a Reply message to a
client in response to a Solicit message.
DISCUSSION:
When using the Solicit-Reply message exchange, the server commits
the assignment of any addresses before sending the Reply message.
The client can assume it has been assigned the addresses in the
Reply message and does not need to send a Request message for
those addresses.
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 addresses from one of the servers,
while the addresses from the other servers will be committed to
the client but not used by the client.
The server includes a Rapid Commit option in the Reply message to
indicate that the Reply is in response to a Solicit message.
The server includes a Reconfigure Accept option if the server wants
to require that the client accept Reconfigure messages.
The server produces the Reply message as though it had received a
Request message, as described in section 18.2.1. The server
transmits the Reply message as described in section 18.2.8.
18. DHCP Client-Initiated Configuration Exchange
A client initiates a message exchange with a server or servers to
acquire or update configuration information of interest. The client
may initiate the configuration exchange as part of the operating
system configuration process, when requested to do so by the
application layer, when required by Stateless Address
Autoconfiguration or as required to extend the lifetime of an address
(Renew and Rebind messages).
18.1. Client Behavior
A client uses Request, Renew, Rebind, Release and Decline messages
during the normal life cycle of addresses. It uses Confirm to
validate addresses when it may have moved to a new link. It uses
Information-Request messages when it needs configuration information
but no addresses.
If the client has a source address of sufficient scope that can be
used by the server as a return address, and the client has received a
Server Unicast option (section 22.12) from the server, the client
SHOULD unicast any Request, Renew, Release and Decline messages to
the server.
DISCUSSION:
Use of unicast may avoid delays due to the relaying of messages by
relay agents, as well as avoid overhead and duplicate responses by
servers due to the delivery of client messages to multiple
servers. Requiring the client to relay all DHCP messages through
a relay agent enables the inclusion of relay agent options in all
messages sent by the client. The server should enable the use of
unicast only when relay agent options will not be used.
18.1.1. Creation and Transmission of Request Messages
The client uses a Request message to populate IAs with addresses and
obtain other configuration information. The client includes one or
more IA options in the Request message. The server then returns
addresses and other information about the IAs to the client in IA
options in a Reply message.
The client generates a transaction ID and inserts this value in the
"transaction-id" field.
The client places the identifier of the destination server in a
Server Identifier option.
The client MUST include a Client Identifier option to identify itself
to the server. The client adds any other appropriate options,
including one or more IA options (if the client is requesting that
the server assign it some network addresses).
The client MUST include an Option Request option (see section 22.7)
to indicate the 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 includes a Reconfigure Accept option (see section 22.20)
indicating whether or not the client is willing to accept Reconfigure
messages from the server.
The client transmits the message according to section 14, 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:
- 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 17.
- Terminate the configuration process and report failure.
18.1.2. Creation and Transmission of Confirm Messages
Whenever a client may have moved to a new link, the prefixes from the
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:
o The client reboots.
o The client is physically connected to a wired connection.
o The client returns from sleep mode.
o The client using a wireless technology changes access points.
In any situation when a client may have moved to a new link, the
client MUST initiate a Confirm/Reply message exchange. The client
includes 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.
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 to identify itself
to the server. 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, and the preferred-lifetime and
valid-lifetime fields in the IA Address options 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 14, 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 14, the client SHOULD
continue to use any IP addresses, using the last known lifetimes for
those addresses, and SHOULD continue to use any other previously
obtained configuration parameters.
18.1.3. Creation and Transmission of Renew Messages
To extend the valid and preferred lifetimes for the addresses
associated with an IA, the client sends a Renew message to the server
from which the client obtained the addresses in the IA containing an
IA option for the IA. The client includes IA Address options in the
IA option for the addresses associated with the IA. The server
determines new lifetimes for the addresses in the IA according to the
administrative configuration of the server. The server may also add
new addresses to the IA. The server may remove addresses from the IA
by setting the preferred and valid lifetimes of those addresses to
zero.
The server controls the time at which the client contacts the server
to extend the lifetimes on assigned addresses through the T1 and T2
parameters assigned to an IA.
At time T1 for an IA, the client initiates a Renew/Reply message
exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned to
the IA in its Renew message.
If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no
T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind
message, respectively, at the client's discretion.
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 places the identifier of the destination server in a
Server Identifier option.
The client MUST include a Client Identifier option to identify itself
to the server. The client adds any appropriate options, including
one or more IA options. The client MUST include the list of
addresses the client currently has associated with the IAs in the
Renew message.
The client MUST include an Option Request option (see section 22.7)
to indicate the 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 14, using the
following parameters:
IRT REN_TIMEOUT
MRT REN_MAX_RT
MRC 0
MRD Remaining time until T2
The message exchange is terminated when time T2 is reached (see
section 18.1.4), at which time the client begins a Rebind message
exchange.
18.1.4. Creation and Transmission of Rebind Messages
At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded), the
client initiates a Rebind/Reply message exchange with any available
server. The client includes an IA option with all addresses
currently assigned to the IA in its Rebind message.
The client sets the "msg-type" field to REBIND. The client generates
a transaction ID and inserts this value in the "transaction-id"
field.
The client MUST include a Client Identifier option to identify itself
to the server. The client adds any appropriate options, including
one or more IA options. The client MUST include the list of
addresses the client currently has associated with the IAs in the
Rebind message.
The client MUST include an Option Request option (see section 22.7)
to indicate the 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 14, using the
following parameters:
IRT REB_TIMEOUT
MRT REB_MAX_RT
MRC 0
MRD Remaining time until valid lifetimes of all addresses have
expired
The message exchange is terminated when the valid lifetimes of all
the addresses assigned to the IA expire (see section 10), at which
time the client has several alternative actions to choose from; for
example:
- The client may choose to use a Solicit message to locate a new
DHCP server and send a Request for the expired IA to the new
server.
- The client may have other addresses in other IAs, so the client
may choose to discard the expired IA and use the addresses in the
other IAs.
18.1.5. Creation and Transmission of Information-request Messages
The client uses an Information-request message to obtain
configuration information without having addresses assigned to it.
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 to identify
itself to the server. 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 a Client
Identifier option if the Information-Request message will be
authenticated.
The client MUST include an Option Request option (see section 22.7)
to indicate the 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 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
14, using the following parameters:
IRT INF_TIMEOUT
MRT INF_MAX_RT
MRC 0
MRD 0
18.1.6. Creation and Transmission of Release Messages
To release one or more addresses, 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 places the identifier of the server that allocated the
address(es) in a Server Identifier option.
The client MUST include a Client Identifier option to identify itself
to the server. The client includes options containing the IAs for
the addresses it is releasing in the "options" field. The addresses
to be released MUST be included in the IAs. Any addresses for the
IAs the client wishes to continue to use MUST NOT be added to the
IAs.
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 14, using the
following parameters:
IRT REL_TIMEOUT
MRT 0
MRC REL_MAX_RC
MRD 0
The client MUST stop using all of the addresses being released as
soon as the client begins the Release message exchange process. If
addresses 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 addresses, each address
assigned to the IA will be reclaimed by the server when the valid
lifetime of that address expires.
18.1.7. 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 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 places the identifier of the server that allocated the
address(es) in a Server Identifier option.
The client MUST include a Client Identifier option to identify itself
to the server. 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 in 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 14, 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.
18.1.8. Receipt of Reply Messages
Upon the receipt of a valid Reply message in response to a Solicit
(with a Rapid Commit option), Request, Confirm, Renew, Rebind or
Information-request message, the client extracts the configuration
information contained in the Reply. The client MAY choose to report
any status code or message from the status code option in the Reply
message.
The client SHOULD perform duplicate address detection [17] on each of
the addresses in any IAs it receives in the Reply message before
using that address for traffic. If any of the addresses are found to
be in use on the link, the client sends a Decline message to the
server as described in section 18.1.7.
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:
- Record T1 and T2 times.
- Add any new addresses in the IA option to the IA as recorded by
the client.
- Update lifetimes for any addresses in the IA option that the
client already has recorded in the IA.
- Discard any addresses from the IA, as recorded by the client, that
have a valid lifetime of 0 in the IA Address option.
- Leave unchanged any information about addresses the client has
recorded in the IA but that were not included in the IA from the
server.
Management of the specific configuration information is detailed in
the definition of each option in section 22.
If the client receives a Reply message with a Status Code containing
UnspecFail, the server is indicating that it was unable to process
the 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.
When the client receives a Reply message with a Status Code option
with the value UseMulticast, the client records the receipt of the
message and sends subsequent messages to the server through the
interface on which the message was received using multicast. The
client resends the original message using multicast.
When the client receives a NotOnLink status from the server in
response to a Confirm message, the client performs DHCP server
solicitation, as described in section 17, and client-initiated
configuration as described in section 18. If the client receives any
Reply messages that do not indicate a NotOnLink status, the client
can use the addresses in the IA and ignore any messages that indicate
a NotOnLink status.
When the client receives a NotOnLink status from the server in
response to a Request, the client can either re-issue the Request
without specifying any addresses or restart the DHCP server discovery
process (see section 17).
The client examines the status code in each IA individually. If the
status code is NoAddrsAvail, the client has received no usable
addresses in the IA and may choose to try obtaining addresses for the
IA from another server. The client uses addresses and other
information from any IAs that do not contain a Status Code option
with the NoAddrsAvail code. If the client receives no addresses in
any of the IAs, it 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 examines each IA independently. For each
IA in the original Renew or Rebind message, the client:
- sends a Request message if the IA contained a Status Code option
with the NoBinding status (and does not send any additional
Renew/Rebind messages)
- sends a Renew/Rebind if the IA is not in the Reply message
- otherwise accepts the information in the IA
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(s) 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. Server Behavior
For this discussion, the Server is assumed to have been configured in
an implementation specific manner with configuration of interest to
clients.
In most instances, the server will send a Reply in response to a
client message. This Reply message MUST always contain the Server
Identifier option containing the server's DUID and the Client
Identifier option from the client message if one was present.
In most Reply messages, the server includes options containing
configuration information for the client. The server must be aware
of the recommendations on packet sizes and the use of fragmentation
in section 5 of RFC2460. If the client included an Option Request
option in its message, the server includes options in the Reply
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.
18.2.1. Receipt of Request Messages
When the server receives a Request message via unicast from a client
to which the server has not sent a unicast option, the server
discards the Request message and responds with a Reply message
containing a Status Code option with the value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier
option from the client message, and no other options.
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 a Server Identifier option containing the
server's DUID and the Client Identifier option from the Request
message in the Reply message.
If the server finds that the prefix on one or more IP addresses in
any IA in the message from the client is 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 with the value NotOnLink.
If the server cannot assign any addresses to an IA in the message
from the client, the server MUST include the IA in the Reply message
with no addresses in the IA and a Status Code option in the IA
containing status code NoAddrsAvail.
For any IAs to which the server can assign addresses, the server
includes the IA with addresses and other configuration parameters,
and records the IA as a new client binding.
The server includes a Reconfigure Accept option if the server wants