Re: [dhcwg] [Technical Errata Reported] RFC8415 (6269)

["Bernie Volz (volz)" <[e-mail]>]

Hi:



It does look like the Information-Request is permitted to be unicast.



However, whether the Server Unicast is allowed in a Reconfigure itself is NOT specified. And, section 18.3.11 specifically states:



   The server MUST NOT include any other options in the Reconfigure

   message, except as specifically allowed in the definition of

   individual options.



And, the Server Unicast option text says nothing about this being allowed in a Reconfigure. (Perhaps there is text elsewhere that I missed.) So, I think Appendix B is correct (i.e., it does not allow a Server-Unicast option in a Reconfigure). Also, this would of course only apply to Renew and Information-Request (for a Reconfigure if it was allowed). Note: This does not prevent a previous exchange that provided the Server-Unicast from allowing the Renew or Information-Request triggered by a Reconfigure to be unicast by the client.





The following corrections are OK:



section 16:

"A server MUST discard any Solicit, Confirm, or Rebind messages it receives with a Layer 3 unicast destination address." (i.e., remove Information-Request)



section 18.2:

"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 (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, Decline, and Information-request messages to the server." (i.e., add Information-Request)



Note: Unicasting the Information-Request does create a condition where a client might fail to update its configuration if the target server is down. The reason the Request, Renew, Release, and Decline were allowed to use unicast was because these were targeted for a single server anyway and it optimized that communication (and reduced impact on other DHCPv6 servers that might receive and discard these packets because the Server Identifier did not match). I personally would have little issue if we decided the Information Request if it did not contain a Server Identifier option MUST NOT be unicast – the only time that the Server Identifier Option is explicitly included is in response to a Reconfigure. Again, this would be in my understanding of the spirit of when server unicast makes sense. So, if we go with that, the corrections would be:



section 16:

"A server MUST discard any Solicit, Confirm, Rebind, or Information-request (which does not contain a Server Identifier option (see Section 21.3)) messages it receives with a Layer 3 unicast destination address.



section 18.2:

"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 (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, Decline, and Information-request (only if it contains a Server Identifier option (see Section 21.3)) messages to the server."



I hope my suggested text makes it clear that this Server Identifier option only applies to Information-request.





While we could debate whether to allow Server Unicast option in a Reconfigure message itself, I think it best not to do this as it could be a security risk (though perhaps it is marginal if the attacker already knows the nonce). But that would be a change over the existing specification as best I can determine.



  *   Bernie



-----Original Message-----
From: RFC Errata System <[e-mail]>
Sent: Sunday, August 30, 2020 11:46 AM
To: [e-mail]; [e-mail]; Bernie Volz (volz) <[e-mail]>; Andrew Yourtchenko (ayourtch) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Eric Vyncke (evyncke) <[e-mail]>; Bernie Volz (volz) <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Technical Errata Reported] RFC8415 (6269)



The following errata report has been submitted for RFC8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".



--------------------------------------

You may review the report below and at:

https://www.rfc-editor.org/errata/eid6269



--------------------------------------

Type: Technical

Reported by: Felix Hamme <[e-mail]>



Section: GLOBAL



Original Text

-------------

section 16:

"A server MUST discard any Solicit, Confirm, Rebind, or Information-request messages it receives with a Layer 3 unicast destination address."



section 18.2:

"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 (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, and Decline messages to the server."





Appendix B does not permit a Server Unicast option in a Reconfigure message.



Corrected Text

--------------

section 16:

"A server MUST discard any Solicit, Confirm, or Rebind messages it receives with a Layer 3 unicast destination address."



section 18.2:

"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 (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, Decline, and Information-request messages to the server."



Appendix B permits a Server Unicast option in a Reconfigure message.



Notes

-----

Section 18.4 allows transmission of Information-request messages with a unicast destination address, if the client received a message with Server Unicast option. (See also https://mailarchive.ietf.org/arch/msg/dhcwg/x80cmfTN8fpRViiN_RHNXes-zVg/)



Instructions:

-------------

This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary.



--------------------------------------

RFC8415 (draft-ietf-dhc-rfc3315bis-13)

--------------------------------------

Title               : Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Publication Date    : November 2018

Author(s)           : T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, T. Winters

Category            : PROPOSED STANDARD

Source              : Dynamic Host Configuration

Area                : Internet

Stream              : IETF

Verifying Party     : IESG