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

Hi Glen,

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. 

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.

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.

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.

Tim

On 12 Jul 2012, at 21:23, Eustace, Glen wrote:

> As one of these IT departments, I thought that some empirical data might be useful.
> 
> We have now got ISC dhcpd running on our main campus and I have just completed adding native IPv6 to the majority of networks.  We do NOT yet have DUIDs stored in our databases but do have the MAC address for the primary NIC for all University owned equipment.
> 
> I have the  hardware-ethernet included in each host declaration for both IPv4 and IPv6.  Using the ISC fudge of deconstructing the type 1 DUID, we have 1224 matches out of 1693 active leases.  Whilst not perfect, it is actually better than I expected and for us does add value.
> 
> I have not yet attempted to determine why we failed to match the remaining leases, could be a number of reasons
> Private equipment for which we do not have a MAC in the DB
> The DUID generated used a MAC we don't have in the DB
> The MAC we have is wrong.
> etc
> -- 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Glen Eustace, Infrastructure Development Engineer (BC/DR)
> Information Technology Service, Massey University PN460
> Tennent Drive, Palmerston North, New Zealand
> Ph: +64-6-3569099 x 81005, Fax: +64-6-3505607, Mob: +64-27-4500321
> 
> From: "Ted com>" <Ted.Lemon@nominum.com>
> Date: Thu, 12 Jul 2012 19:49:59 +0000
> To: Andre Kostur <akostur@incognito.com>
> Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>, Marc Perea <marccp@srttel.com>
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt
> 
> On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote:
>> Ok, if we're restricting to ISP environments, why not mandate in such
>> environments that they should be using the Remote ID (RFC 4649) to
>> specify the downstream "client".  Note that in DOCSIS environments,
>> this is already happening.  (Just not in RFC 4649 form... but in an
>> enterprise-specific option 17).
> 
> It's my understanding that the main motivator for this draft is use in corporate IT departments that inventory machines by MAC address.   I guess it would also be useful for ISPs, but that's certainly not the use case that I've heard mentioned most.
> 
> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg