[Dnsmasq-discuss] DHCPv6 and MAC

[Gene Czarcinski]

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.

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."

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.

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.

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.

Gene