[Dibbler] Wrong hardware type in LL and LLT DUIDs
thomson at klub.com.pl
Sun Dec 5 20:14:02 CET 2010
On Wed, 13 Oct 2010 somebody known as Fred Zwarts wrote:
> I am rather new to Dibbler. I had a problem to use the Dibbler DHCP client for IPv6 on my Windows XP system.
> I could not find the problem when I searched through the archives, so I decided to bring it here in this mailing list.
> Our institute uses the ISC DHCP server. This has the option to match a client with an hardware Ethernet address.
> When a client uses an LLT or LL DUID, it extracts the MAC address from this DUID and tries to match it
> against the given Ethernet addresses for the registered clients.
> This did not work for my Dibbler client.
> The first problem was, that Dibbler did not base its DUID on the Ethernet adapter, but on the tunnel adapter,
> that is also installed when IPv6 is installed for Windows XP.
> After disabling the tunnel adapter, and removing the DUID file, Dibbler regenerated a DUID.
> This time it looked like a LLT DUID and I found the MAC address of the Ethernet adapter in the DUID.
> However, for the hardware type, Dibbler used 6, whereas for Ethernet the hardware type should 1.
> This caused again a failing match with the registration in the DHCP server.
> When I checked this on our Windows 7 and Linux systems, they all generated a DUID with hardware type 1.
> Is there an explanation why Dibbler used 6, both in LL and LLT DUIDs?
Not sure, if anyone responded to that, but here is the answer.
First, the bahavior you are describing is a violation of DHCPv6 protocol.
Client or servers are not supposed to interpret DUID in any way. Here's
part of Section 9 of RFC3315:
> Clients and servers MUST treat DUIDs as opaque values and MUST only
> compare DUIDs for equality. Clients and servers MUST NOT in any
> other way interpret DUIDs.
What you described is against the very idea of DUID. DUID is opaque value
that should be unique. That's it. Here's another part of the RFC 3315:
> Clients and servers MUST NOT restrict
> DUIDs to the types defined in this document, as additional DUID types
> may be defined in the future.
That is in fact true. There's draft about using UUID for generating unique
DUIDs. It is going to published as RFC soon.
Now, let's get back to Dibbler and its 6 value as HW type. Under Linux,
dibbler uses values returned by kernel using rtnl socket. See line 173 of
Port-linux/lowlevel-linux.c. On Windows systems, this is the value
returned by GetAdaptersAddresses() function in field IfType.
> Does it depend on other hardware in my PC?
No, that is HW type returned by the system. At least that's the idea.
I really don't like to hardcode the value in Dibbler. Dibbler may be used
on interfaces other than Ethernet.
Just for the reference, the values are specificied here:
Hope that helps.
Sorry for my late response. I returned from my round the world trip 3
weeks ago and I've been swamped with all the urgent things thatI have to
attend to since then. Preparing for defense of my Ph.D is one of them.
More information about the Dibbler