Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

["Eustace, Glen" <[e-mail]>]

Hi Tim,

> Does that mean all your devices/OSes are by default using DUID-LL?  The spec says that the client
> must use *a* MAC address; it may not happen to pick the one corresponding to the interface that
> the query comes from.

No, the vast majority are DUID-LLT, there are some DUID-LLs.   The version of the ISC DHCPv6 code I am running deconstructs the DUID and attempts to match the MAC address with the host hardware-addres if a host DUID isn't specified in the config file, this is a hack but is proving useful as we do not have the DUIDs in our database yet still want to try to match the lease to the client primarily so that the forward DDNS uses the official name of the client.

> It would be very interesting to see other enterprises who are using DHCPv6 reporting what they see.
> And interesting to also note how often observed DUIDs change over time, e.g. from dual-boot systems.

I haven't had a chance to look at anything like this yet.

> The relay function seems useful to me. In a typical campus environment that we'd be interested in
> all requests would be forwarded by a relay, thus client support would not be essential in our environment.

Same here but for the hosts in the same network as the DHCP servers.

> It would seem very likely the proposed draft would be used by some enterprise admins to try to perform
> the same type of "accountability" that exists for DHCPv4 with DHCPv6.  That's a question that frequently
> crops up from new sites considering IPv6 deployment.

I think if is was up to me, I'd be pushing for SLAAC for the majority of our clients but it isn't and the security team wants 'accountability' just like they think they have with IPv4. So I have to do my best to get DHCPv6 doing something similar to DHCPv4.

Glen.