[Dnsmasq-discuss] DHCPv6 and MAC

[Gene Czarcinski]

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.

Gene