[HTML][HTML] Dynamic host configuration protocol for IPv6 (DHCPv6)

T Mrugalski, M Siodelski, B Volz, A Yourtchenko… - 2018 - rfc-editor.org
T Mrugalski, M Siodelski, B Volz, A Yourtchenko, M Richardson, S Jiang, T Lemon, T Winters
2018rfc-editor.org
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 …
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.
Mrugalski, et al. Standards Track [Page 76]
RFC 8415 DHCP for IPv6 November 2018
18.3. 2. Receipt of Request Messages
See Section 18.4 for details regarding the handling of Request
messages received via unicast.
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) and IA_TA option (see
Section 21.5) 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 and
IA_TAs), 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.
Mrugalski, et al. Standards Track [Page 77]
RFC 8415 DHCP for IPv6 November 2018
The T1/T2 times set in each applicable IA option for a Reply MUST be
rfc-editor.org
以上显示的是最相近的搜索结果。 查看全部搜索结果