Re: [dhcwg] 3315bis question: Changing default DUID to DUID-LL?

[Simon Hobson <[e-mail]>]

Ted Lemon <[e-mail]> wrote:

>> This problem was also recently brought to my attention (dhcpcd uses DUID-LLT
>> by default) by some people integrating NetBSD (where dhcpcd is the default
>> client) into SmartOS as a VM.
>> SmartOS filters DHCPv4 requests to ensure that the ClientID matches predictable
>> values, and DUID-LLT is not this.
>> I don't know off hand if they filter DHCPv6 in the same way.
>> 
> Of course, the idea that there are "predictable values" for the DHCP client identifier based on the link-layer address is totally mistaken, and in violation of the specification.

But meanwhile, in the real world, many many people have workflows that require them to be able to identify equipment before it's plugged in. In this sense, it can be argued that the specification is in violation of real world needs.
Though in this case, I'd agree that the implementation is wrong.

>> In the same way that DUID-LLT is not predictable or known before booting the
>> host, neither is DUID-LL.
>> Consider the host with virtual or hot plugged interfaces. Some hosts also
>> randomise their MAC address each boot.

IMO, a device which has no persistent storage, and which uses a random MAC is not manageable by any system that relies on being able to identify a client - without using device class specific tools (like all those devices that can only be managed by the vendor's proprietary, and usually Windows only, programs) !
Virtual devices are another class - but do you have any example of such a device that has no persistent storage ?

Are we in danger of sacrificing functionality for many in pursuit of unattainable perfection ? There will always be corner cases, but the requirement for a "single homed device, with known MAC address, and a workflow already setup to capture that MAC address" is (going by the discussions here) very real - and would be serviced by using DUID-LL as default.

>> I think that changing the default to DUID-LL just makes it worse for multi-
>> homed users.

Does it ? Assuming the device has persistent storage then once it's generated a DUID it'll keep that. So there is really no change in terms of functionality - only a very very very small chance of a clash if MAC addresses aren't unique.
I strongly suspect that devices using virtual NICs (eg virtual hosts) aren't using DUID-LL[T] and so the change would not affect them.


> Also, consider this text from RFC3315 Section 9.
> 
>>    Clients and servers MUST treat DUIDs as opaque values and MUST only
>>    compare DUIDs for equality.  Clients and servers MUST NOT in any
>>    other way interpret DUIDs.

> Of course, that's the text I was talking about clarifying.   The point of that text was to make sure that the entire DUID was used as a client identifier, not a subset of it.   But it's totally fine to look in the DUID to see what the link-layer address is, as long as you don't use _just the link-layer address_ as a DUID.

I don't think clarifying is the right word. I cannot see any *reasonable* interpretation of that text other than "this is an opaque blob and you can only use it as an exact match to some other opaque blob". As a DUID-LL (and more so, DUID-LLT) is not the same thing as a MAC address, this text very clearly and explicitly prohibits matching the MAC address with the contents of the DUID.
For "clarify", I think you mean "significantly change" :-)


> Is there really any need for that, though?   Once you're on the network, the DHCP server knows the link between your IP address an DUID, so registering the device is a simple matter of querying the DHCP server for the DUID and matching that to the source IP address of the HTTP login (or whatever).

While that may work for some classes of device - eg a "computer" with a browser where the user lands in a captive portal until they've registered their device* - I don't think that's a valid statement for the general case. I strongly suspect the use case driving this is something like :
User/department/whoever gets a new printer. When it gets added to the network, network services need to ensure it goes to a sensible IP address and that relevant systems know about it so it can be used.
In the IPv4 world, as long as it's MAC is known (usually printed on the box, or at least on the device), that can be configured into DHCP to give it a known address, and from there it can be configured etc.
If it uses a predictable DUID (eg DUID-LL and the MAC address is known) then much the same process applies for IPv6 - and not much change to long established workflows are needed to support IPv6. If the DUID is not predictable then "some other means" is needed to find the device - using systems (DHCP server) that by design do not capture any known attribute of the device.

So the problem is easily stated. In a system where you have no knowledge of the IP address, and no knowledge of the DHCP identifier, how do you find and configure the new device ?
I suspect the answer comes back to : find out it's MAC address (the workflow captured it for the IPv4 config), then query a local device on the network for it's neighbour cache, and find the IP address from that, and only then can we query the DHCP server to find out it's DUID. That's a massive change to the workflow.


BTW - I have first hand experience of the problem in assuming that devices can be "registered" by using a portal or similar. A few years ago we (at work) were involved in something or other (I vaguely recall is was some sort of "design and build" project day for local schools) hosted at a local hotel. I wasn't involved in any pre-event stuff, but someone else had been told by the hotel that "yes we have wireless internet available".
Only problem was that access to it was by tickets and registering the device in a captive portal. This meant that we couldn't connect a printer to the network, and all printing ended up being by sneakernet. In hindsight there were probably other issues, but the key thing is that the system was designed on the assumption that every device needing to use the network was of a certain class - and that meant it didn't work for other classes of equipment.

* These are also really really annoying in that there's a gap between my laptop having "a connection" and getting past the captive portal. During this period, various bits of software (eg email clients) start spewing out security warnings as secure connections fail due to being redirected to the portal which (of course) lacks the right security certificates.