[Dnsmasq-discuss] DHCPv6 and MAC

Sat Feb 9 16:01:49 GMT 2013

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.

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.

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.

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

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?

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.

Gene