[dhcwg] IESG Discuss on draft-ietf-dhc-mac-assign

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

Hello:

Regarding your discuss issues ... I offer the following comments (inline with BV>):

Client SHOULD, server MUST ignore.  In a couple of places in the document (sections 6, 10.1, 10.2), it states that the client SHOULD set 0.  To allow the protocol to evolve in future, I believe that it would be better if the SHOULD is changed to a MUST.

BV> I believe I have correct these items in the latest version of the draft (08).

There doesn't appear to be any specification of how an OPTION_IA_LL should be handled if there are no IA_LL-options, or it contains an IA_LL-option that is not understood by the server.  The text does also not specify if IA_LL-options can contain multiple options, and if so how those are encoded (presumably as an array/list of option values), perhaps this is already covered by the DHCPv6 spec?  Similar comments also apply to the LLaddr-options field.

BV> RFC8415, I believe, also doesn't mention how IA_NA-options is to be handled if there are none. Technically there is no requirement to provide an LLADDR option (an empty IA_LL-option field is usually interpreted as a request for assignment of an (link-layer) address). For example, for RFC8415, an empty IA_NA-options or IA_PD-options means to assign addresses (usually 1 but it depends on the server's configuration - as there could be multiple prefixes active on the link to which the client is connected) or delegated prefixes (again, usually 1 but it depends on the server's configuration). If you feel it would add clarity, I can add text to clarify this. Perhaps adding the following paragraph in section 10.1:


   The IA_LL-options field typically contains one or more LLADDR

   options (see Section 10.2). If a client does not include a

   LLADDR option in a Solicit or Request message, the server MUST

   treat this as a request for a single address and that the

   client has no hint as to the address it would like.

9. Releasing Addresses

Once a block of addresses have been released, can they immediately be allocated to a different client?  Or should they avoid being reused straight away if possible?  Perhaps this consideration is already covered by DHCPv6, but it probably makes sense to say something about this, either in section 9, and/or maybe in the security considerations.

BV> This section refers the reader to Section 18.2.7 of [RFC8415]. That text states " The client MUST stop using all of the leases being released before the client begins the Release message exchange process". But this does create an interesting issue in case of the link-layer address as it is not clear how the client can transmit the message if the link-local address it is using is based on the to be released link-layer address. For the hypervisor case, this is not an issue because it is presumed that the hypervisor itself has its own link-layer address. It is an issue for a client. Perhaps we need to clarify this a bit with something like the following.

Note: If the client is releasing the link-layer address it is
using, it MUST stop using this address before sending the
Release message (as per [RFC8415]). In order to send the
Release message, the client MUST use another address (such as
what it used to initiate DHCPv6 to obtain the address).

BV> Regarding your point about reuse, I think this answers that - as the client MUST have stopped using the address, it is perfectly OK for the server to immediately reuse that address. I will however note that at least for DHCPv4 and DHCPv6 (v6 address/prefix delegation), server's often support a configuration parameter to delay reuse of an address (either if release or it has expired - for the expired case, this is more usual as clocks may not be synchronized).


  *   Bernie