RE: I-D Action: draft-templin-duid-ipv6-01.txt

["Bernie Volz (volz)" <[e-mail]>]

Yes, we could have done that. We could have just had DUID-EN and used that for all DUID types.

But the reason to standardize some types is their expected usage – the existing formats (except DUID-EN) are designed to be used by almost all devices and there are reasons specified for using one of the types over the other. Use DUID-LLT unless the link-layer is “locked” to device. DUID-UUID can be used if this is available on the hardware platform as it may require no persistent storage or resolves the issue when DUID-LLT has to be used by both a low-level boot loader (that doesn’t know where the OS stored the DUID-LLT). So, it is pretty clear which of these to use (DUID-EN if applicable, DUID-UUID if possible, DUID-LLT, or finally DUID-LL).

Some standards organization also require use of one type (such as Cable Modems should use DUID-LL).

DUID-EN was designed to allow vendors (or standards bodies for specific technologies) to define a different type for their purposes (not for standard operating systems like Linux to default to but nothing prevents them from being configured to use). The vendor is responsible for assuring the uniqueness and this was generally assumed to be something “burned” into hardware. So, using it was pretty clear.

If a specific application comes along where it needs a different identity for some reason but that is specific to that application, the DUID-EN was what is expected to be used.

When there is a broad benefit to the community at large, that’s when to consider a new DUID type (not DUID-EN).

So, the question that we need answer is when should something use DUID-new type over the other types.

You might say, well just use it if you have a “globally unique address”? But then the questions are:

  *   If this is a general purpose OS, and it boots via a boot loader that needs an address but there is no “global address”, what does it use?
  *   If it started to use an existing type before it got a “global address”, when should it start using the DUID-new type? It could be using active leases under the old DUID.
  *   Where will this global address be stored (persisted) so that it continues to be available “forever”?
  *   What happens if the global address is changed? Does the device keep using it since it is it’s DUID. But then what happens to a new device that gets that “old” global address – how does it know it MUST NOT use the DUID? The draft mentions nothing about what happens when the node / global address relation is ended for some reason (whether administratively done or as result of the “generation technique” where some input might change). As you state “The DUID-V6ADDR format makes no statement about the method used for generating the IPv6 address” but it also says nothing about how “permanent” that generated address must be and how changes to it are handled by a client that has been using it for a DUID-V6ADDR.
BTW: This is why DUID-LLT exists as the network card could be moved to a new device, but the time helps to differentiate the two DUIDs.

For the DUID-UUID it is clearly presumed that this is PERMANENTLY assigned value to the device.

Formatting the data is the easy part – yes put some bits here and there. But the usage is what is critical to define and do it in a way that creates no possible issues (or at least guidance about what the issues may be and how they could be resolved).

Those are some of the things you must properly motivate.

Once you do that and how well you do that should make deciding whether to move forward with DUID-new type or tell you to use DUID-EN as then many of these issues are NOT the responsibility of the IETF. For IETF standardized types, we want to make sure that how and when they are used is clear and that (to a reasonable ability) we prevent issues and possible collisions.

The earlier days of DHCPv6 were not easy as there were plenty of issues with DUIDs .. one operating system vendor’s host cloning failed to clear the DUID and so someone that cloned a bunch of hosts would end up with them all having the same DUID.

This is the reason why DUIDs are Standards Action as we need all of the issues thought through carefully and to give implementers guidance on when one type should be used over another.

Warning: I am not saying that my above questions are all there is.

Hope that helps as to why the bar for new DUID-types needs to be high.


  *   Bernie

From: Templin (US), Fred L <[e-mail]>
Sent: Friday, January 15, 2021 4:30 PM
To: Bernie Volz (volz) <[e-mail]>; Ted Lemon <[e-mail]>
Cc: Bob Hinden <[e-mail]>; dhcwg <[e-mail]>; IPv6 List <[e-mail]>; Dickson (US), Sean M <[e-mail]>
Subject: RE: I-D Action: draft-templin-duid-ipv6-01.txt

Bernie, using your logic UUIDs could also have gone into DUID-EN under some
arbitrary PEN code. But, they weren’t; they were *standardized* as DUID-UUID
which elevates them in standing as equals to all other forms of DUIDs. Nothing less
will suffice for DUIDs that would be based on IPv6 addresses that are specifically
generated as unique Identifiers for a node.

Fred

From: Bernie Volz (volz) [mailto:[e-mail]]
Sent: Friday, January 15, 2021 1:21 PM
To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>; Ted Lemon <[e-mail]<mailto:[e-mail]>>
Cc: Bob Hinden <[e-mail]<mailto:[e-mail]>>; dhcwg <[e-mail]<mailto:[e-mail]>>; IPv6 List <[e-mail]<mailto:[e-mail]>>; Dickson (US), Sean M <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] RE: I-D Action: draft-templin-duid-ipv6-01.txt

Also, I really have no idea what you mean by “under the care of an arbitrary DUID-EN PEN code”.

After all, this is just about a [unique] identifier isn’t it?

This isn’t putting anything “under the care of”. It is just the way it is communicating between DHCP client and servers and for the client (or perhaps server since it could use DUID-EN too) to identifier itself as a “different” device than another.


  *   Bernie

From: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 15, 2021 4:13 PM
To: Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>>; Ted Lemon <[e-mail]<mailto:[e-mail]>>
Cc: Bob Hinden <[e-mail]<mailto:[e-mail]>>; dhcwg <[e-mail]<mailto:[e-mail]>>; IPv6 List <[e-mail]<mailto:[e-mail]>>; Dickson (US), Sean M <[e-mail]<mailto:[e-mail]>>
Subject: RE: I-D Action: draft-templin-duid-ipv6-01.txt

Bernie, putting the entire global IPv6 unicast address space under the care of an
arbitrary DUID-EN PEN code would be like sending Biden to the inauguration on
a bicycle. You don’t transport VIPs to big events on vehicles made of tinker toys;
you give them a full-length limo and full escort.

Fred

From: Bernie Volz (volz) [mailto:[e-mail]]
Sent: Friday, January 15, 2021 1:05 PM
To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>; Ted Lemon <[e-mail]<mailto:[e-mail]>>
Cc: Bob Hinden <[e-mail]<mailto:[e-mail]>>; dhcwg <[e-mail]<mailto:[e-mail]>>; IPv6 List <[e-mail]<mailto:[e-mail]>>; Dickson (US), Sean M <[e-mail]<mailto:[e-mail]>>
Subject: RE: I-D Action: draft-templin-duid-ipv6-01.txt

That anyone can get a PEN code has no bearing on this – the DUID-EN is still standards track because YOUR PEN will be different than someone else’s and hence their format does not “collide” with yours because the Enterprise IDs are different.

This enterprise id has been very successfully used in the vendor class and vendor options (see RFC8415 sections 21.16 and 21.17). Cablelabs and other standards groups use these very heavily to provide for additional information that a vendor (or standards organization) needs to provide their devices. See for example https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=b74c68d8-b6af-45e6-81bf-936004d0273f.

> That, plus I don’t want to carry around the extra 4 bytes for a PEN code…

That’s life. There’s a lot of things I don’t want but have no choice over.


  *   Bernie

From: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 15, 2021 3:54 PM
To: Ted Lemon <[e-mail]<mailto:[e-mail]>>
Cc: Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>>; Bob Hinden <[e-mail]<mailto:[e-mail]>>; dhcwg <[e-mail]<mailto:[e-mail]>>; IPv6 List <[e-mail]<mailto:[e-mail]>>; Dickson (US), Sean M <[e-mail]<mailto:[e-mail]>>
Subject: Re: I-D Action: draft-templin-duid-ipv6-01.txt

Ted, the allocation policy for the Private Enterprise Number (PEN) code for users
of DUID-EN is not Standards Track; anyone and their brother can easily obtain a
PEN code by filling out a simple form:

https://pen.iana.org/pen/PenApplication.page

I did one for “LinkUp Networks”, but that is not in any way tied to a Standards
Track RFC. IANA did not even ask me any questions; they simply allocated the
code for free. So, as far as standards status goes, an arbitrary PEN code has no
standing while the global IPv6 unicast address space has full Internet standards
status according to RFCs 4291 and 8200. I would therefore see it as a major
DOWNREF to entrust the entire IPv6 address space to any random person
who decided to register a PEN code.

That, plus I don’t want to carry around the extra 4 bytes for a PEN code…

Fred

From: Ted Lemon [mailto:[e-mail]]
Sent: Friday, January 15, 2021 12:31 PM
To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>
Cc: Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>>; Bob Hinden <[e-mail]<mailto:[e-mail]>>; dhcwg <[e-mail]<mailto:[e-mail]>>; IPv6 List <[e-mail]<mailto:[e-mail]>>; Dickson (US), Sean M <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt

On Jan 15, 2021, at 3:25 PM, Templin (US), Fred L <[e-mail]<mailto:[e-mail]>> wrote:
using DUID-EN with some
arbitrary PEN code to encode the entire global IPv6 unicast address space would
IMHO be an unacceptable DOWNREF.

You said this before. I don’t understand what this means. DUID-EN is in a standards track RFC. How is this a DOWNREF? And why use an arbitrary enterprise number?