[v6] Beginner with fixed-address6

chins chinmaya at gmail.com
Thu Feb 14 01:03:34 UTC 2008


host-identifier option dhcp6.client-id is not working for me.
any clues on what to look for?

my usage is ..
host host-ipv6-test {
    host-identifier option dhcp6.client-id
00:01:00:01:47:b3:86:d0:xx:xx:xx:xx:xx:xx;
    option dhcp6.name-servers fc00:0:1::26;
}




On Jan 25, 2008 3:06 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:

> 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-id0: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])
>
>


-- 
chinmaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20080213/38330a33/attachment.html>


More information about the dhcp-users mailing list