rfc9915v4.txt   rfc9915.txt 
skipping to change at line 528 skipping to change at line 528
lease lease
A contract by which the server grants the use of an address or A contract by which the server grants the use of an address or
delegated prefix to the client for a specified period of time. delegated prefix to the client for a specified period of time.
message message
A unit of data carried as the payload of a UDP datagram, exchanged A unit of data carried as the payload of a UDP datagram, exchanged
among DHCP servers, relay agents, and clients. among DHCP servers, relay agents, and clients.
Reconfigure key Reconfigure key
A key supplied to a client by a server. Used to provide security A key supplied to a client by a server. Used to provide security
for Reconfigure messages (see Section 7.3 for the list of for Reconfigure messages (see Section 20.4 for use cases for the
available message types). reconfigure key).
relaying relaying
A DHCP relay agent relays DHCP messages between DHCP participants. A DHCP relay agent relays DHCP messages between DHCP participants.
retransmission retransmission
Another attempt to send the same DHCP message by a client or Another attempt to send the same DHCP message by a client or
server, as a result of not receiving a valid response to the server, as a result of not receiving a valid response to the
previously sent messages. The retransmitted message is typically previously sent messages. The retransmitted message is typically
modified prior to sending, as required by the DHCP specifications. modified prior to sending, as required by the DHCP specifications.
In particular, the client updates the value of the Elapsed Time In particular, the client updates the value of the Elapsed Time
skipping to change at line 1898 skipping to change at line 1898
Relay agents SHOULD NOT accept unicast messages from clients. Relay agents SHOULD NOT accept unicast messages from clients.
Note: The multicast/unicast rules mentioned above apply to the DHCP Note: The multicast/unicast rules mentioned above apply to the DHCP
messages within this document. Messages defined in other and future messages within this document. Messages defined in other and future
documents may have different rules. documents may have different rules.
16.1. Use of Transaction IDs 16.1. Use of Transaction IDs
The "transaction-id" field holds a value used by clients and servers The "transaction-id" field holds a value used by clients and servers
to synchronize server responses to client messages. A client SHOULD to correlate server responses to client messages. A client SHOULD
generate a random number that cannot easily be guessed or predicted generate a random number that cannot easily be guessed or predicted
to use as the transaction ID for each new message it sends. Note to use as the transaction ID for each new message it sends. Note
that if a client generates easily predictable transaction that if a client generates easily predictable transaction
identifiers, it may become more vulnerable to certain kinds of identifiers, it may become more vulnerable to certain kinds of
attacks from off-path intruders. A client MUST leave the transaction attacks from off-path intruders. A client MUST leave the transaction
ID unchanged in retransmissions of a message. ID unchanged in retransmissions of a message.
16.2. Solicit Message 16.2. Solicit Message
Clients MUST discard any received Solicit messages. Clients MUST discard any received Solicit messages.
skipping to change at line 4065 skipping to change at line 4065
after the message processing is completed. One is a bulk leasequery after the message processing is completed. One is a bulk leasequery
mechanism that may ask for all addresses and/or prefixes that were mechanism that may ask for all addresses and/or prefixes that were
assigned via a specific relay. A second is for the reconfigure assigned via a specific relay. A second is for the reconfigure
mechanism. The server may choose to not send the Reconfigure message mechanism. The server may choose to not send the Reconfigure message
directly to the client but rather to send it via relays. This directly to the client but rather to send it via relays. This
particular behavior is considered an implementation detail and is out particular behavior is considered an implementation detail and is out
of scope for this document. of scope for this document.
20. Authentication of DHCP Messages 20. Authentication of DHCP Messages
This document introduces two security mechanisms for the This document defines two security mechanisms for the authentication
authentication of DHCP messages: (1) authentication (and encryption) of DHCP messages: (1) authentication (and encryption) of messages
of messages sent between servers and relay agents using IPsec and (2) sent between servers and relay agents using IPsec and (2) protection
protection against misconfiguration of a client caused by a against misconfiguration of a client caused by a Reconfigure message
Reconfigure message sent by a malicious DHCP server. sent by a malicious DHCP server.
20.1. Security of Messages Sent Between Servers and Relay Agents 20.1. Security of Messages Sent Between Servers and Relay Agents
Relay agents and servers that exchange messages can use IPsec as Relay agents and servers that exchange messages can use IPsec as
detailed in [RFC8213]. detailed in [RFC8213].
20.2. Summary of DHCP Authentication 20.2. Summary of DHCP Authentication
Authentication of DHCP messages is accomplished through the use of Authentication of DHCP messages is accomplished through the use of
the Authentication option (see Section 21.11). The authentication the Authentication option (see Section 21.11). The authentication
skipping to change at line 4528 skipping to change at line 4528
The client MUST discard any addresses for which the preferred The client MUST discard any addresses for which the preferred
lifetime is greater than the valid lifetime. lifetime is greater than the valid lifetime.
As per Section 7.7, if the valid lifetime of an address is As per Section 7.7, if the valid lifetime of an address is
0xffffffff, it is taken to mean "infinity" and should be used 0xffffffff, it is taken to mean "infinity" and should be used
carefully. carefully.
More than one IA Address option can appear in an IA_NA option. More than one IA Address option can appear in an IA_NA option.
The status of any operations involving this IA Address is indicated
in a Status Code option in the IAaddr-options field, as specified in
Section 21.13.
21.7. Option Request Option 21.7. Option Request Option
The Option Request option is used to identify a list of options in a The Option Request option is used to identify a list of options in a
message between a client and a server. The format of the Option message between a client and a server. The format of the Option
Request option is: Request option is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ORO | option-len | | OPTION_ORO | option-len |
skipping to change at line 4640 skipping to change at line 4636
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value | | pref-value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 18: Preference Option Format Figure 18: Preference Option Format
option-code: OPTION_PREFERENCE (7). option-code: OPTION_PREFERENCE (7).
option-len: 1. option-len: 1.
pref-value: The preference value for the server in this message. A pref-value: The preference value for the server in this message.
1-octet unsigned integer. Allowed values are from 0 (least) to 255 (most preferred).
Absence of option means preference 0. A 1-octet unsigned integer.
A server MAY include a Preference option in an Advertise message to A server MAY include a Preference option in an Advertise message to
control the selection of a server by the client. See Section 18.2.9 control the selection of a server by the client. See Section 18.2.9
for information regarding the use of the Preference option by the for information regarding the use of the Preference option by the
client and the interpretation of the Preference option data value. client and the interpretation of the Preference option data value.
21.9. Elapsed Time Option 21.9. Elapsed Time Option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at line 5672 skipping to change at line 5669
* In enterprise and factory networks, use of authentication per * In enterprise and factory networks, use of authentication per
[IEEE8802.1x] can prevent unknown or untrusted clients from [IEEE8802.1x] can prevent unknown or untrusted clients from
connecting to the network. However, this does not necessarily connecting to the network. However, this does not necessarily
assure that the connected client will be a good DHCP or network assure that the connected client will be a good DHCP or network
actor. actor.
* For wired networks where clients typically are connected to a * For wired networks where clients typically are connected to a
switch port, snooping DHCP multicast (or unicast) traffic becomes switch port, snooping DHCP multicast (or unicast) traffic becomes
difficult, as the switches limit the traffic delivered to a port. difficult, as the switches limit the traffic delivered to a port.
The client's DHCP multicast messages (with destination address The client's DHCP multicast messages (with destination address
fe02::1:2) are only forwarded to the DHCP server's (or relay's) ff02::1:2) are only forwarded to the DHCP server's (or relay's)
switch port -- not all ports. Also, the server's (or relay's) switch port -- not all ports. Also, the server's (or relay's)
unicast replies are only delivered to the target client's port -- unicast replies are only delivered to the target client's port --
not all ports. not all ports.
* In public networks (such as a Wi-Fi network in a coffee shop or * In public networks (such as a Wi-Fi network in a coffee shop or
airport), it is possible for others within radio range to snoop airport), it is possible for others within radio range to snoop
DHCP and other traffic. But in these environments, there is very DHCP and other traffic. But in these environments, there is very
little if anything that can be learned from the DHCP traffic little if anything that can be learned from the DHCP traffic
itself (either from client to server or from server to client) if itself (either from client to server or from server to client) if
the privacy considerations provided in Section 23 are followed. the privacy considerations provided in Section 23 are followed.
 End of changes. 6 change blocks. 
15 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.48.