16. Message Validation
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
16. Message Validation
This section describes which options are valid in which kinds of
message types and explains what to do when a client or server
receives a message that contains known options that are invalid for
that message. For example, an IA option is not allowed to appear in
an Information-request message.
Clients and servers MAY choose to either (1) extract information from
such a message if the information is of use to the recipient or (2)
ignore such a message completely and just discard it.
If a server receives a message that it considers invalid, it MAY send
a Reply message (or Advertise message, as appropriate) with a Server
Identifier option (see Section 21.3), a Client Identifier option (see
Section 21.2) (if one was included in the message), and a Status Code
option (see Section 21.13) with status UnspecFail.
Clients, relay agents, and servers MUST NOT discard messages that
contain unknown options (or instances of vendor options with unknown
enterprise-number values). These options should be ignored as if
they were not present. This is critical to provide for future
extensions of DHCP.
A client or server MUST discard any received DHCP messages with an
unknown message type.
Clients SHOULD NOT accept multicast messages.
Servers SHOULD NOT accept unicast traffic from clients. The Server
Unicast option (see Section 21.12) and UseMulticast status code (see
Section 21.13) have been obsoleted; hence, clients should no longer
send messages to a server's unicast address nor receive the
UseMulticast status code. However, a server that previously
supported the Server Unicast option and is upgraded to not support it
MAY continue to receive unicast messages if it previously sent the
client the Server Unicast option. However, this causes no harm and
the client will eventually switch back to sending multicast messages
(such as after the lease's rebinding time is reached or the client is
rebooted).
Relay agents SHOULD NOT accept unicast messages from clients.
Note: The multicast/unicast rules mentioned above apply to the DHCP
messages within this document. Messages defined in other and future
documents may have different rules.
16.1. Use of Transaction IDs
The "transaction-id" field holds a value used by clients and servers
to correlate 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.
16.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.
16.3. Advertise Message
Clients MUST discard any received Advertise message that meets any of
the following conditions:
* the message does not include a Server Identifier option (see
Section 21.3).
* the message does not include a Client Identifier option (see
Section 21.2).
* the contents of the Client Identifier option do 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.
16.4. Request Message
Clients MUST discard any received Request messages.
Servers MUST discard any received Request message that meets any of
the following conditions:
* the message does not include a Server Identifier option (see
Section 21.3).
* the contents of the Server Identifier option do not match the
server's DUID.
* the message does not include a Client Identifier option (see
Section 21.2).
16.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 (see Section 21.2) or that do
include a Server Identifier option (see Section 21.3).
16.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 (see
Section 21.3).
* the contents of the Server Identifier option do not match the
server's identifier.
* the message does not include a Client Identifier option (see
Section 21.2).
16.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 (see Section 21.2) or that do include a
Server Identifier option (see Section 21.3).
16.8. Decline Message
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 (see
Section 21.3).
* the contents of the Server Identifier option do not match the
server's identifier.
* the message does not include a Client Identifier option (see
Section 21.2).
16.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 (see
Section 21.3).
* the contents of the Server Identifier option do not match the
server's identifier.
* the message does not include a Client Identifier option (see
Section 21.2).
16.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 (see
Section 21.3).
* 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 (see Section 21.2)
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. 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.
16.11. Reconfigure Message
Servers and relay agents MUST discard any received Reconfigure
messages.
Clients MUST discard any Reconfigure message that meets any of the
following conditions:
* the message was not unicast to the client.
* the message does not include a Server Identifier option (see
Section 21.3).
* the message does not include a Client Identifier option (see
Section 21.2) that contains the client's DUID.
* the message does not include a Reconfigure Message option (see
Section 21.19).
* the Reconfigure Message option msg-type is not a valid value.
* the message does not include authentication (such as RKAP; see
Section 20.4) or fails authentication validation.
16.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 (see
Section 21.3), and the DUID in the option does not match the
server's DUID.
* the message includes an IA option.
16.13. Relay-forward Message
Clients MUST discard any received Relay-forward messages.
16.14. Relay-reply Message
Clients and servers MUST discard any received Relay-reply messages.