[Dnsmasq-discuss] DHCPv6 and MAC

Gene Czarcinski gene at czarc.net
Fri Feb 8 16:34:21 GMT 2013


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

In both cases, things worked.

Gene



More information about the Dnsmasq-discuss mailing list