[Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Mon, 2013-02-11 at 15:34 -0500, Gene Czarcinski wrote:
> On 02/10/2013 09:09 PM, Dan Williams wrote:
> > On Sat, 2013-02-09 at 11:01 -0500, Gene Czarcinski wrote:
> <snip>
> >> 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.
> Oops, you are correct.  The standard does say one DUID per device and 
> the same DUID for every network interface on that device.
> 
> I have not tried this but what happens when you have more than on 
> network interface and they are all connect to the same network and all 
> using DHCPv6.  If each is connected to a different network then things 
> should work correctly.
> 
> But, RFC3315 also says "per device" which to me means per hardware 
> device not per OS installation.  I am not sure how you do that but that 
> is my interpretation.  The only thing that comes close is duid-LL and 
> that has a problem when there are multiple network interfaces.  BTW, 
> this whole business with client-id is because the client-id did differ 
> between a Fedora 17 and a Fedora 18 installation which caused some 
> things to stop working.

Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to
dhcleint, which appears to generate a default DUID itself; but the
NetworkManager code will honor that existing DUID if it finds it in the
interface+connection specific lease file [1].  If NM does *not*, please
let me know and we'll fix that bug.

Some things say "device" and others say "DHCP client", and it's not
particularly clear what is what.  I interpreted "device" to mean a
machine, not a specific network interface.  Eg "for example, a device's
DUID should not change as a result of a change in the device's network
hardware" would indicate that the device is the *machine*, not a network
interface.

> Now, quoting a bit from RFC6355: "DHCP UUIDs should be persistent across 
> system restarts, system reconfiguration events,system software and 
> operating system upgrades or reinstallation as well as be easily 
> available to any part of the boot process that requires access to the 
> DHCP UUID."

Right, now we're on to DUID-UUID standards, which only apply if you're
going to use a DHCP-DUID.  They wouldn't apply if you chose a DUID-LL or
LLT, but as I've tried to point out, I think the LL/LLT standards simply
contravene RFC 3315 when used on anything more than an embedded closed
system.  On a laptop/desktop/server with expansion slots, multiple
adapters, and swappable interfaces, LL/LLT simply cannot fulfil the
requirements of RFC 3315 in my reading.

> And: "Implementations of this specification using DUID-UUID must select 
> a UUID that is persistent across system restart and reconfiguration 
> events and that is available to all DHCP protocol agents that may need 
> to identify themselves. For instance, a UUID that is part of the system 
> firmware, or managed by the system firmware, satisfies this requirement."
> 
> That implies to me that basing it on /etc/machine-id does not meet the 
> standard.  Unfortunately, it is not clear to me that there currently 
> exists anything that would.

Can you describe how you reach that conclusion?  Given the description
in 'man machine-id' I would say that's *exactly* what a DUID-UUID is.
The machine-id should not change across reboots, is created at install
time, is persistent, and should not change as a result of hardware
changes.

> Now that I understand how to override things, I can live with how they work.
> 
> BTW, I notice that DHCP_CLIENT_ID is support for DHCPv4, why not having 
> a DHCPv6 version?  Yes, it would be NM specific but so what.

Well, the Client Identifier is used to carry the DUID (see RFC 3315
section 22.2).  So this would be a convenience instead of writing the
DUID to the lease file, I suppose.  Given we'd still have to support
reading the DUID from the existing lease files, I'm not sure this is
much of a win.

> Note to Simon:  You might want to capture some of this in the dnsmasq 
> documentation (man page).
> >
> >> 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.
> Something appears to be not working.  This is with the 0.9.7.997 rpm 
> with no local patches (Yes, I did build it myself because I started 
> before the rpms were available in updates-testing).  I stop NM, delete 
> the /var/lib/NetworkManager/dhclient6-<whatever>.lease file and reboot.  
> After reboot, the IPv6 client-id sure looks like a duid-LLT with the 
> first four bytes being 0:1:0:1 and the last six being the MAC.

I'll do some tests here and see what's going on.

Dan

[1]
eg /var/lib/dhclient/dhclient6-cc98bcbe-ef64-4db7-9b46-b12ca02172e6-wlan12.lease