On Fri, 2013-02-08 at 11:34 -0500, Gene Czarcinski wrote: > On 02/08/2013 10:39 AM, Gene Czarcinski wrote: > > On 02/08/2013 10:17 AM, Simon Kelley wrote: > >> On 07/02/13 21:27, Gene Czarcinski wrote: > >>> On 02/07/2013 04:22 PM, Gene Czarcinski wrote: > >>>> I was googling around and found this: > >>>>> Looks like I got it working. I must admit that I was going off of > >>>>> information back when IPv6 and DHCPv6 first came out. > >>>>> > >>>>> So it was my impression that in my DHCP server configuration I had to > >>>>> use the old style of: > >>>>> host-identifier option dhcp6.client-id > >>>>> 00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4; > >>>>> fixed-address6 FD35:4776:6804:1::1; > >>>>> > >>>>> Turns out there is now compatibility with the IPv4 style of setting > >>>>> fixed ip addresses where a clientid / duid isn't required and I was > >>>>> able to set it up as: > >>>>> hardware ethernet 00:0C:29:37:12:85; > >>>>> fixed-address6 FD35:4776:6804:2:1::1; > >>>>> > >>>>> I remember trying the previous a long time ago when hardware ethernet > >>>>> wasn't allowed to be used with IPv6 but it appears that has now > >>>>> changed. > >>>>> > >>>>> All is well now and things are finally back on track. > >>>>> > >>>> at: https://bbs.archlinux.org/viewtopic.php?id=139567 > >>>> > >>>> The quoted text is comment #5 > >>>> > >>>> The writer claims to be using dhclient and dhcpd. > >>>> > >>>> The problems described are the same ones which trouble me. Has > >>>> something changed with the DHCPv6 standard or did the folks at isc.org > >>>> just want something that worked? > >>>> > >>>> > >>> I should have waited because I found what might be a slightly different > >>> solution to the problem here: > >>> http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/ > >>>> *Surprise #2: You can no longer simply use the MAC address of an > >>>> interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in > >>>> which the MAC address of the client interface is included in a DHCP > >>>> request, DHCPv6 uses a DHCP Unique Identifier > >>>> <http://tools.ietf.org/html/rfc3315#section-9>, or DUID, to uniquely > >>>> identify the client. By default, the DUID is synthesized from the MAC > >>>> address of an arbitrary interface on the host plus the system time at > >>>> the moment the DUID is generated. The same DUID is then used > >>>> regardless of which interface a DHCPv6 message originates from. > >>>> > >>>> The DUID normally persists across reboots, but if it’s deleted on the > >>>> client, e.g., when a new operating system is installed, the DUID is > >>>> automatically regenerated with a new time, and the server will no > >>>> longer recognize it. RFC 3315 <http://tools.ietf.org/html/rfc3315> > >>>> prohibits using a portion of the DUID as an identifier (it must be > >>>> treated as opaque), so DHCPv6 servers can’t be told to “just look at > >>>> the MAC address part” of the DUID. > >>>> > >>>> Fortunately for those wishing to use old-style MAC addresses, there’s > >>>> an alternative DUID type that let you do this. The DUID described > >>>> above is a “Type 1” DUID, and is referred to as a “Link-Layer plus > >>>> Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type > >>>> 1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs > >>>> <http://tools.ietf.org/html/rfc3315#section-9.4> (DUID-LLs), which is > >>>> simply the MAC address prepended with two identifiers (the sequence > >>>> “00:03:00:01”). Moreover, these can be configured on a per-interface > >>>> basis in the ISC DHCP client.^3 > >>>> <http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3> > >>>> Problem solved. > >>>> > >>> Now I just need to figure out how to get dhclient to use DUID-LL rather > >>> than DUID-LLT. > >>> > >> Sadly, it ain't that easy. a DUID-LL is _generated_ using _a_ mac > >> address, but if the machine has more than one interface, the client can > >> use any of them, and use the same DUID for all the interfaces. Then if > >> the MAC address is changed for any reason, the client will likely > >> continue to use the existing DUID, not make a new one. > >> > >> > >> Essentially, the MAC address is used just to ensure that the DUID is > >> unique, not to make ide ntifying interfaces/machines easy. That wasn't > >> considered necessary by the definers if IPv6. > >> > > It is better than DUID-LLT. > > > > I only have one NIC which works so that may not be a problem. Plus, > > with NetworkManager, I believe it may still work OK since NM has a > > separate dhclient instance for each interface it manages ... and > > separate DHCPv4 and DHCPv6 instances too. Each interface will have a > > different MAC. > > > > But, this is a good point and I will try to test what happens. > > > Seems to work as I expected it to. The test was of a qemu-kvm/libvirt > virtual system with two NICs and the updated NetworkManager installed. > > 1. Each NIC on a different network but the -D LL specified ... client-ID > matches the NIC > > 2. Both NICs on the same network and with -D LL specified ... client-ID > matches the respective NIC
We just updated NetworkManager to generate a *stable* DUID-UUID hashed off /etc/machine-id, which is generated once at system install/clone time, and stays the same thereafter. Thus we avoid the whole issue of what MAC address to generate the DUID from (which is a problem with DUID-LL and DUID-LLT), especially if the machine has multiple network interfaces. We also preserve the ability to clone a system and not have to remember to wipe some cached DUID from somewhere, since the DUID isn't saved but is always regenerated from /etc/machine-id or from administrator overrides. NM will use the administrator supplied DUID if it's found in the default lease file locations for dhclient, which are /etc/dhclient6.leases, /var/lib/dhcp/dhclient6.leases, /var/lib/dhclient/dhcp6.leases, or the interface/connection specific leasefile. Dan _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
