Re: [dhcwg] I-D Action: draft-templin-duid-ipv6-01.txt

["Templin (US), Fred L" <[e-mail]>]

Bernie, your analysis would have to include RFC7401 and ‘draft-ietf-drip-rid’; the
authors of those certainly believe they are generating “valid IPv6 addresses” that
can be used as a permanent Identifier for the node. And, where there are two
such IPv6 address generation methods, many more may follow in the future.

Fred

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

Sorry as I said that would be it but I forgot to include (hit send too early) … a review of RFC7721 shows:

   +--------------+-------------+----------+-------------+-------------+
   | Mechanism(s) | Correlation | Location | Address     | Device      |
   |              |             | tracking | scanning    | exploits    |
   +--------------+-------------+----------+-------------+-------------+
   | IEEE         | For device  | For      | Possible    | Possible    |
   | identifier   | lifetime    | device   |             |             |
   |              |             | lifetime |             |             |
   |              |             |          |             |             |
   | Static       | For address | For      | Depends on  | Depends on  |
   | manual       | lifetime    | address  | generation  | generation  |
   |              |             | lifetime | mechanism   | mechanism   |
   |              |             |          |             |             |
   | Constant,    | For address | For      | No          | No          |
   | semantically | lifetime    | address  |             |             |
   | opaque       |             | lifetime |             |             |
   |              |             |          |             |             |
   | CGA          | For         | No       | No          | No          |
   |              | lifetime of |          |             |             |
   |              | (modifier   |          |             |             |
   |              | block +     |          |             |             |
   |              | public key) |          |             |             |
   |              |             |          |             |             |
   | Stable,      | Within      | No       | No          | No          |
   | semantically | single IPv6 |          |             |             |
   | opaque       | link        |          |             |             |
   |              |             |          |             |             |
   | Temporary    | For temp    | No       | No          | No          |
   |              | address     |          |             |             |
   |              | lifetime    |          |             |             |
   |              |             |          |             |             |
   | DHCPv6       | For lease   | No       | Depends on  | No          |
   |              | lifetime    |          | generation  |             |
   |              |             |          | mechanism   |             |
   +--------------+-------------+----------+-------------+-------------+

So it seems that only the first 3 are really “permanent”.

And, if one further looks at “Constant, Semantically opaque” (Section 4.3), there is a reference to RFC4941. But even that document says:

   7.  The node MUST perform duplicate address detection (DAD) on the
       generated temporary address.  If DAD indicates the address is
       already in use, the node MUST generate a new randomized interface
       identifier as described in Section 3.2<https://tools.ietf.org/html/rfc4941#section-3.2> above, and repeat the
       previous steps as appropriate up to TEMP_IDGEN_RETRIES times.  If
       after TEMP_IDGEN_RETRIES consecutive attempts no non-unique
       address was generated, the node MUST log a system error and MUST
       NOT attempt to generate temporary addresses for that interface.
       Note that DAD MUST be performed on every unicast address
       generated from this randomized interface identifier.

So, that removes that entry, so we are down the just the First 2 in that table.

And the first entry is handled by DUID-LL and DUID-LLT.

Thus we end up only with the 2nd which is a “static manual”. Though that of course assumes that someone is keeping track and has a “unique” prefix from which to allocate such an address – if we assume people are just randomly picking 128 bit values, I don’t think these would be unique (this also begs the first boot situation).

I admit that I haven’t looked at some of the other documents referenced in the draft and how well they offer “permanent” uniqueness.

Some may ask why this is important … the simple answer is that if you take a device that used the DUID-V6ADDR and move it and it says “oh sh*t, I need a new address”, and then move it back into the original location (perhaps over just a short period of time), it may well end up with a completely different DUID-V6ADDR when it moves back and hence the DHCP server now as two sets of potential leases. But again, I don’t know how you will manage the “life” of the DUID-V6ADDR in these cases. Note also that if the device is not at its original location, it cannot defend (such as in RFC4941) its use of an address.

So, Fred, you have more work to do to argue for your draft. I think this is really the core of the objection – we don’t believe these identifies are sufficiently unique for general purposes devices. And if you are hoping to use this in a specific network with specific device, then best to use DUID-EN with an appropriate enterprise-id.

-          Bernie

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

Do you say that in the draft? You don’t give the properties of the global address that can be used (other than a vague statement about uniqueness).

You do state:

   DUID-V6ADDR makes it possible for devices to use suitably-derived
   unique IPv6 addresses to identify themselves to DHCPv6 servers and/or
   other network nodes.

And, “but its use in control messages asserts that the address has been ensured unique through some unspecified means”? Is this permanently unique? And, how can this be defended if the device is moved elsewhere but still retains that address?

But never define what is “suitable-derived unique”? Nothing about “permanent” – address generated at time A may be unique, but can they stay unique when that device is offline?

And, you don’t describe how this interacts with the creation of this address and potentially having obtained leases prior to this (i.e., how does a host boot the first time when it does not yet have your “global address”).

Next, for ULA’s, you say that they are unique to a service domain – but don’t say what this means – how does a host know it is in a new service domain (and hence needs a new address)? What if it cannot tell because whatever it needs to communicate with requires a DHCP lease? This again can result in collisions or issues when the new address is used. If the device is out of the domain, how does it defend its prior use if it indeed was “permanent”. But your text implies it may not be “permanent” in this case?

> Which is why I proposed a single DUID-V6ADDR  type

By all means … if the address generated is (“permanently”) globally unique, then why would how it is generated matter? However, if different techniques at the same time, how accurate is the “globally unique”.


And, for your “ANYCAST” case, this has impact on DHCP operations as you’ll need to detail how this is designed to work? What about IAIDs? How would they be managed and are the leases obtain supposed to be used by all of the devices (how do they learn of this, how do they coordinate when the lease expires or if lease is released). There’s a lot that needs clarity here.

And again, when should this type be used over the other types? Are there cases it MUST be used. Are there cases it MUST NOT be used?


The other DUID types all use inputs that should remain FIXED for the life of the device (excepting administrator action). This type has cases where this is not the case, so either you need to REMOVE those or document what should happen when the DUID needs to change – what does it change to if there is no address available (i.e., consider the ULA case where the device moves out of that domain and into a new one which has no “global address”).


Anyway, I am going to stop debating these points at this time and may pick it up when you have a more complete draft that considers these (and likely other) aspects.


The DUID-UUID draft was much clearer because the properties of a UUID are defined elsewhere. Here you have the added issue as to how and when the “global address” is produced and whether it really is unique “forever”. UUID has almost a full 128 bits. Addresses generally have far fewer bits which can be used to generate “unique” values. And, when a node is down or disconnected, it cannot defend its use of the address (and it also seems the address may not even be used for “real” communication which further raises the question of how unique it can be).

You also don’t provide any clue as to whether this should be used by “all hosts” or hosts in specific environments (and what those might be). Should Android, Apple, Linux, and Microsoft devices use this?

Anyway, that’s it for me for a while on this topic … on to other things for a bit.

-          Bernie

From: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 15, 2021 5:52 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

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

The same is expected for IPv6 address generation methods that would use DUID-V6ADDR.

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

Which is why I proposed a single DUID-V6ADDR  type for all manners of generating IPv6
addresses. Otherwise, there would need to be DUID-HIT, DUID-HHIT, DUID-CGA, etc.,
i.e., one for each address generation method. The draft discusses in detail why that
would be a slippery slope we do not want to start down and makes the case for a
single DUID-V6ADDR.

Fred


From: Bernie Volz (volz) [mailto:[e-mail]]
Sent: Friday, January 15, 2021 2:32 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


EXT email: be mindful of links/attachments.




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]<mailto:[e-mail]>>
Sent: Friday, January 15, 2021 4:30 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, 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?