[Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Mon, 2013-02-11 at 15:06 -0600, Dan Williams wrote:
> 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.

See my reply to your other mail about this; I see what you're saying
now, and I think we can push for having whatever generates machine-id
(often systemd) pull that information from firmware/hardware rather than
generating it randomly.

Dan

> > 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
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss