On Thu, Jan 24, 2008 at 05:04:24PM +0100,
Shane Kerr <Shane_Kerr at isc.org> wrote
a message of 67 lines which said:
> In DHCPv6 there is no place in the packet for the hardware
> address. Perhaps we should warn on the case. :(
IMHO, yes, you really should. That's quite painful when an option is
silently ignored.
And the hardware address is in the packet, both in the Ethernet header
(I assume you decided not to use it, because it is not easy to
retrieve it in a portable way, it does not work with relays, etc) and
in the DUID (after all, Wireshark can extract the hardware address
from a "Link-layer Address Plus Time" DUID).
Reading RFC 3315, it seems there is another way to have the hardware
address, the "Link-layer Address" DUID. As you mention, there is no
option to set this option in dhclient.
Also, RFC 3315 does not explain the rationale behind these client
identifiers and why the "Link-layer Address Plus Time"? Is it to
ensure real unicity?
> That client-id looks suspicious:
OK, I changed it using what I've found in /var/db/dhclient6.leases
where the client id is stored with the right syntax:
host lilith {
host-identifier option dhcp6.client-id 0:1:0:1:47:96:21:f7:0:19:b9:e4:25:f9;
fixed-address6 2001:DB8:DEAD:BABE::2;
}
And it works! I get my fixed address. Many thanks. But it is quite
inconvenient. With v4, when I add a new machine, I just have to look
at the dhcpd log file, I find the hardware address, I put it in
dhcpd.conf and it works. Now, I need to look a file on the DHCP client
:-( I wonder if the IETF considered this issue (the RFC 3315 does not
seem to discuss it). (tcpdump is another possible solution, see later)
> The time is clearly wrong - the time is supposed to be based on
> seconds since the year 2000 not 1970. A bug in our client that I'll
> fix presently!
Yes, because I confirm the bug:
lilith:~/tmp/dhcp-4.0.0 % more /var/db/dhclient6.leases
...
starts 1201021494;
lilith:~/tmp/dhcp-4.0.0 % date
Fri Jan 25 12:11:04 CET 2008
> Maybe you can try tcpdump instead (it also reports DUID if
> sufficiently verbose)?
Yes, with -vvv, although the DUID is displayed in a different syntax,
so it is less convenient:
12:14:39.114478 IP6 (hlim 64, next-header UDP (17) payload length: 88) fe80::219:b9ff:fee4:25f9.546 > ff02::1:2.547: dhcp6 confirm (xid=2d984 (client ID hwaddr/time type 1 time 1201021431 0019b9e425f9) (option request DNS DNS name)[|dhcp6ext])