On Oct 12, 2009, at 5:42 AM, Jarrod Johnson wrote:
probably keep people who like the DUID moving with the hard drive happy: [...]
The reason why DUID is the way it is is not to make your life difficult, or because there is some conspiracy on the part of lovers of DUIDs that move with the hard drive. It is because your situation is unusual. The DUID is targeted at the vast majority of devices on the Internet, which are not managed the way you manage your devices. It's important that the IETF accommodate your needs if possible, and indeed the existing protocol does accommodate your needs, and there have been several extensions proposed that further accommodate your needs, which I will describe in a moment. But it's important to understand the context in which you are making this request. The context is that your situation is unusual - not typical.
You proposed changing the DUID so that it is tied to some hardware address configured on the device, or possibly to the hardware address of the interface that you are configuring. We didn't do it this way because this behavior makes it more difficult to keep track of the relationship between clients and their IP addresses, and between clients and their domain names. We also anticipated that similar problems would crop up in the future. The DUID-LLT DUID type, which is the one you are complaining about, also resolves a problem that cropped up fairly frequently where several devices would wind up, due to firmware bugs, with the same MAC address.
If we were to make the change that Chuck is proposing, which I think you were also advocating previously, it would break this functionality. It would break it for the people least able to identify the problem - end users of individual computers connected to the Internet. When a device behaves badly on your network, you (a skilled network administrator) are in a position to do something about it. When an end-user's device behaves badly, they are not. They call their ISP, and the guy they talk to probably hasn't a clue, and a lot of time is wasted before anybody with a clue talks to them, if anyone with a clue ever does. This is what DUID-LLT was designed to prevent.
This brings me to my next point, which is that in fact the DHCP protocol already supports DUIDs of the type you want - DUID-EN and DUID-LL. The reason your device doesn't support these address types is probably that you bought the wrong type of device, and that the vendor of your device's firmware did not read RFC4361, and that the hardware vendor provided no way for the software vendor to know that the device is eligible to use, e.g., DUID-LL.
The IETF is not in a position to do anything about this. Vendors don't typically listen to us. They implement the RFCs their customers look for on the feature list. Often they implement them badly or incompletely. If you want that to change, you have to talk to your vendors. You are the one with the money. Everybody has some degree of interest in doing things right, and but they also have lots of other priorities. Their highest priority is making sure that you buy as much of their product as possible. So if you want them to implement DUID-LL or DUID-EN (correctly, I hope), you need to talk to them about it. If you want them to implement RFC4361's recommendations, you need to talk to them. This is not the venue in which to solve your problem.
If you read RFC3315, there is no indication in it that DUID-EN is in any way less good than DUID-LLT. That's because DUID-EN is actually better than DUID-LLT. The reason DUID-EN isn't specifically recommended is that it requires effort on the part of both your hardware vendor and your software vendor to use it. If they can support it in compliance with the RFC, they should use it. If you want them to support it, don't talk to us. Talk to them.
Now, absent your ability to convince your vendors to implement DUID-EN correctly, which I admit may be problematic for you, what else can you do? As it happens, there are several drafts being worked on right now that solve aspects of your problem without requiring any changes to the way your DHCP client uses the DUID. These are the lightweight DHCP relay agent (LDRA) draft and the relay agent ID draft. The whole motivation behind these drafts is to help you to identify the physical port to which a particular device is connected. You could then propagate this information up into your device management system and clearly connect the (varying) DUID-LLT to the device's physical location. I would encourage you to read these drafts and comment on them.