[Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Sat, 2013-02-09 at 11:01 -0500, Gene Czarcinski wrote:
> On 02/08/2013 05:11 PM, Dan Williams wrote:
> > 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.
> >
> Unfortunately, what you have done is not going to scratch my itch!
> 
> First, I would like a bit of clarification.  Is the DUID-UUID going to 
> be per system or per network interface?  By per system I mean that all 
> interfaces would have the same DUID-UUID.

Correct.  We're working off RFC-3315, which has sections stating that
"the DUID used by a client or server SHOULD NOT change over time if at
all possible; for example, a device's DUID should not change as a result
of a change in the device's network hardware." (section 9)

Which implies that even if you change a network interface, the DUID
should not change.  Which also implies one DUID *per machine*, not
per-interface.  It's also supposed to be globally unique, which means
you should not use the same DUID for multiple machines or VMs (section
9).

Even if we used a DUID-LL or LLT, RFC-3315 states that the DUID is
generated from "any one network interface that is connected to the DHCP
device at the time that the DUID is generated."  It doesn't say that the
DHCP client process must use a separate DUID for each interface it's run
on, though NM supports per-connection DUIDs.

That said, you're perfectly able to put whatever DUID you want to
in /etc/dhclient6.leases (or /var/lib/dhcp/dhclient6.leases
or /var/lib/dhclient/dhclient6.leases) and NM will use that instead of
generating a DUID-UUID.

> Now, what I want/need is the have a DUID which is predictable and fixed 
> for an interface on a hardware system.  The hardware system supports 
> multi-boot of different installations such as a Fedora 17 system and a 
> Fedora 18 system.  I have a firm, learned the hard way, rule never to 
> destroy a working systems ... all my installs are fresh installs into 
> different partition, LVs, or btrfs-subvolumes. I want to be able to boot 
> these system up and have them all use the same DUID.

Apparently that's against RFC-3315 section 9: "The motivation for having
more than one type of DUID is that the DUID must be globally unique..."

But again, you can override with dhclient6.leases.

> The reason for wanting this predictable, unchanging DUID is that I want 
> my dnsmasq server to assign this system a specific IPv6 address without 
> having to manually configure the system.  This specific IPv6 address is 
> used for routing IPv6 address of virtual guests running on that system.
> 
> I checked and /etc/machine-id differs on each installed system.  For me, 
> the DUID-UUID is no better than DUID-LLT.

That's what we've got for the standards, unfortunately.  But again,
you're free to override this on every machine
with /etc/dhclient6.leases.

> However, I suspect that there are situations where DUID-UUID is the 
> correct solution.

Yeah, we identified a few.

> Given these two different approaches/solutions, what I would like to see 
> is to optionally do either one (on a per interface basis).  If the value 
> of DUID-UUID is kept in the interface configuration file, then maybe 
> that could be extended so the DUID-LL could be specified (DUID-LLT is 
> the default for dhclient if nothing else is done).  How is dhclient 
> "told" to use a specific DUID-UUID value?

According to the standards, you're supposed to use one DUID *per
machine* and that DUID must be globally unique.  So what you're trying
to do here apparently contravenes the standards in a couple of ways.
But even so, you're certainly able to do what you want by specifying the
DUID in /etc/dhclient6.leases or connection-specific lease files by
putting this line in the file:

default-duid "<your escaped DUID>";

And NM will happily use it; since you're the administrator, we're not
forcing you to use DUID-UUID.

> I believe that the problem is we are trying to solve two 
> different/incompatible problems.
> 
> I need to look at the new code in NetworkManager to see what is being done.

The core bits for dhclient are in src/dhcp-manager/nm-dhcp-dhclient.c
and src/dhcp-manager/nm-dhcp-dhclient-utils.c, and if the
client-specific code doesn't give us a custom DUID (from leasefiles, or
whatever) then the generic code in src/dhcp-manager/nm-dhcp-client.c
will generate one off /etc/machine-id.

Dan