> > DHCPv6 as defined in RFC 3315 does not offer client MAC address at all > > (thus making the job more difficult for a number of organizations). > > Yes it does… > > What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3) > is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what > this is intended to be. True, it includes an additional 16 bits of > > media type,
- I cannot a priori know which DUID type a particular client will use. Of the three DUID types in RFC 3315 section 9.1, type 1 and 3 include link layer address while type 2 does not. - As has already been pointed out, the same physical hardware may use different DUID types when booted with different operating systems. - The language in RFC 3315 is pretty explicit in saying that a server *must* treat the DUID as an opaque value - in other words, you are not allowed to "inspect" it in any way to find the presumed MAC address and take any action based on the MAC address. > > All I've seen so far indicates that this was a deliberate choice by > > the DHCPv6 designers, and in my opinion a very poor one. Fortunately > > we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and > > we're waiting for vendors to implement this. That solves one half of > > the problem. > > Yes and no. > > At the time RFC3315 was written, network cards changed independent of > motherboards on a regular basis and this fact was a source of great > consternation for DHCPv4 operators. Over time, that changed AFTER > RFC3315 was written, but if you read section 9.4, it seems pretty clear that > this change was anticipated by the authors and that DUID-LL was intended > for the situation we have today. I think understand the well-meant intentions of the RFC 3315 authors. However, my claim is that the actual end result for IPv6 leaves us in a *worse* situation than for IPv4. And one which, among others, makes it very difficult to correlate IPv4 and IPv6 leases (something which I have no need for today, but which I could easily see a need for in the future). Steinar Haug, Nethelp consulting, sth...@nethelp.no
