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

[[e-mail]]

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?

----

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.

Thanks,
Ian