Re: [dhcwg] dhcpv6-24: use of anycast

> The only issue with this is that DHCP usually runs as an application
> and is therefore only able to access that information which the
> lower layers (via APIs) make available.

Understood.

> Determining whether multicast is supported or not is pretty standard
> from the socket API. However, determining that a particular
> interface is a specific media type may be difficult.

OK.

> Therefore, there is some value in providing a clear direction here
>  that is also relatively easy to implement.

Agreed.

> If all interface types provide multicast (either inherently or via
> some type of emulation), there is little need to ever use the
> anycast address and so what harm is there in specifying it.

The harm is that a) we may define something that isn't useful (which
may cause problems when deployed because some implementations choose
use the feature even if it doesn't work as intended). b) clients may
choose to send to anycast addresses, but if servers aren't configured
to deal with them, we don't get interoperability, so specifying that
clients MAY do something really implies (to me) that server SHOULD (or
maybe even MUST) be prepared to handle such packets from clients. If
the client  can't expect a server to handle something, there is little
point in clients implementing the feature either.

My general opinion: if its not clear something is useful, and it's not
obvious what the details should be, including the feature distracts
from the overall goal of getting the spec done. The more one can
remove, the fewer details that have to be gotten right. 

> What we probably should say is that the client MUST use the
> multicast address if the interface on which it is sending the
> message supports multicast. Otherwise, it may use the anycast
> address.

This is OK with me. Just so long as it's clear that the anycast usage
is only link-local and is only for reaching servers (and relay agents)
on the same link. This seems like a straightforward thing to get
right. 

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg