Re: [dhcwg] Questions regarding draft-ietf-dhc-mac-assign and draft-ietf-dhc-slap-quadrant

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

Hi Ian:

See inline below (BV>).

- Bernie

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Friday, March 13, 2020 11:48 AM
To: [e-mail]
Cc: dhcwg <[e-mail]>
Subject: Questions regarding draft-ietf-dhc-mac-assign and draft-ietf-dhc-slap-quadrant

Hi,

This question has come up in the review of draft-ieft-dhc-slap-quadrant, but I’ll raise it here as I think it’s relevant to both drafts, and the expected behaviour is not mentioned anywhere:

If a client request for an IA_LL is unsuccessful, what is the expected behaviour? Does it just continue using its existing L2 address, and configure whatever L3 addresses it has received, or should it keep retrying until it gets a response to the IA_LL?

BV> This is really up to the client. I think the specification should be silent on this issue. This also goes back to what Advertisement's the client will "accept". I suspect that early clients that use this capability will likely continue with their temporary assignment as it may be that no server is available yet that supports this feature? In other cases, there may be new classes of devices that will only accept Advisements that include the requested assignment(s).

----

For draft-ietf-dhc-mac-assign, another point that isn’t mentioned is the configuration of a new L2 address received in an IA_LL in regards to L3 addressing through SLAAC, IA_NA, link local, etc. E.g.: 

* While the client is attempting DHCP configuration, it may also be doing SLAAC. If this is successful, then it may have already responded to other hosts ND requests with its temporary MAC address.

* If the client gets an IA_NA alongside the IA_LL and configures it before the IA_LL, the same could happen.

In both cases, the newly configured L2 address will result in other hosts existing ND entries being invalid as soon as an IA_LL is received and configured on the interfaces.

I think this be fixed by adding the requirement that, when a new L2 address (or block)  is received, the client sends out an unsolicited neighbor advertisement as per RFC4861 sec 7.6.2 for every address configured on an interface which the new L2 address is being configured.

BV> Yes, this is would be expected. I think this was just assumed to be standard practice whenever changing mac-addresses. (The section is 7.2.6 - typo above). The text in that document already makes it clear that this is expected behavior:

7.2.6.  Sending Unsolicited Neighbor Advertisements

   In some cases, a node may be able to determine that its link-layer
   address has changed (e.g., hot-swap of an interface card) and may
   wish to inform its neighbors of the new link-layer address quickly.
   In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT
   unsolicited Neighbor Advertisement messages to the all-nodes
   multicast address.  These advertisements MUST be separated by at
   least RetransTimer seconds.

BV> Certainly when the node changes it address, it would be able to determine this? But, I guess adding a reminder for client implementers cannot hurt. How about adding to the end of Section 7 of mac-assign:

   A client that changes its link-layer address on an interface SHOULD
   follow the recommendations in Section 7.2.6 of [RFC4861] to inform
   its neighbors of the new link-layer address quickly.



Thanks,
Ian