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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Hi Ian, Bernie,

I agree with Bernie. I think his proposal of text is fine. I don't think we
need to add anything in slap-quadrant, but let me know if you think
otherwise. I'm submitting a new version (-06) with the latest comments
discussed. Let me know if you think something else needs to be changed.

Thanks,

Carlos

On Fri, Mar 13, 2020 at 5:47 PM Bernie Volz (volz) <[e-mail]> wrote:

> 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
>
>
>