Subject: RE: Definition of DUID

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 17 Jul 2001 23:34:30 -0500

I think the domain name was supposed to be something burned into the system by the manufacturer (when they burned in the vendor ID). Or, the board (or software) knows the vendor of the NIC or whatever and can simply add the domain name. But, that is an assumption that might not always hold.
 
I suspect that the vendor ID type, while good in concept, won't be used much.
 
- Bernie
 
PS: For US vendors, we could even have them use their EIN (Employer Identification Number)? [Just kidding.]

-----Original Message-----
From: Thirumalesh Bhat [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 9:06 PM
To: DHCPv6 discussion list
Subject: RE: Definition of DUID 

As far as using domain names in a DUID goes - it can be used in a small subset of apps. I would expect a lot of the clients implementing DHCPv6 to obtain their domain name from a DHCP Server as opposed to using a hard coded domain name built it. Since we expect this way of figuring out the DUID is not very advisable as noted below - is this useful for any set of apps? If it is not useful for a specific set of clients - why not just scrub it from the spec?

I also second the idea of an upper limit for the DUID length. An option is two octets long and the DUID option length can potentially be 64K long. This is going to impact the server implementation. Either this will lead to implementations that will put self imposed restrictions on the length of the DUID or they should be ready to take care of 64K long DUIDs. I think 256 octets is a reasonable upper bound.

thx

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2001 4:18 PM
To: DHCPv6 discussion list
Subject: RE: Definition of DUID 

>...there doesn't seem to be a good answer to this one -- on the one hand, we 
>should encourage vendors to select as short an identifier string as possible 
>to identify the vendor, but not so long as to be burdensome.  Is there any 
>value to specifying the "domain name" part as an opaque, vendor-selected 
>octet string (permitting, for example, UTF-8) with the strong suggestion 
>that it be a (registered) trade-mark, domain name, or legal business name, 
>but without burdening either IANA or a domain registrar? 

While domain names could be long, I think they are a reasonable identifier. 
There could be issues if a domain name used as a vendor id is sold (since the 
new vendor might have no idea what vendor IDs were used previously). However, 
mergers and the like don't create problems since if a domain name is switched, 
the previously shipped devices will continue to use the old values (burned in 
prom). The combined corporation hopefully knows what values were assigned in 
the past. 

The only issue that concerns me with domain names is that its one thing is 
someone uses nominum.com, but what about subdomains or even internationalized 
domains. Given that some internationalized domain names might go 3 or 4 levels, 
each that could be up to 63 characters, the DUID could easily end up at 100s 
of bytes. 

I don't have a solution other than to discourage use of this DUID type or, if 
used, reasonable length domain names are used (dell.com, compaq.com, intel.com, 
toshiba.com, gateway.com, etc are luckily all fairly short names). 

Depending on what character set is used for the domain names, another option 
is to allow something like @<SNMP-Enterprise-ID> (since @ is an invalid domain 
name character) - the ID would be in ASCII. Other characters could be used for 
other identifiers (of course, we could simply define new DUID types as well). 

Anyway, I think the domain name is a decent solution. 

Do we want to indicate some maximum limit to the length of the DUID? I'd like 
there to be one. I had suggested 32 bytes a while ago, but that is too short 
considering the types. I would recommend we consider something like 128? Perhaps 
we make this servers MUST be able to support DUIDs up to 128 bytes (longer 
ones would be truncated under the assumption that the first 128 bytes is unique). 

I'm open for other suggested maximum lengths (64, 256). 

- Bernie Volz 

-----Original Message----- 
From: Barr Hibbs [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, July 17, 2001 6:36 PM 
To: DHCPv6 discussion list 
Subject: RE: Definition of DUID 

my responses are inline... 

--Barr 

> > Also, given that we can reasonably expect to be moving very 
> soon to 64-bit 
> > time values, is a four-octet value an appropriate choice? 
> 
> Yes.   I would say a two-octet value would be fine, frankly.   There's 
> no need to add an extra four bytes to the identifier, and keeping it 
> small is a virtue.   The time from the beginning to the end of the 
> epoch is long enough that the likelihood of a collision caused by this 
> particular problem seems remote.   :') 
> 
...agreed, 68 years does seem long enough...  but I thought I should ask.... 

> > ...   this assumes that the link-layer address lengths are 
> well-known, which 
> > I'm not quite sure is universally correct.  While most of us know that 
> > Ethernet addresses are 48-bits, how many of us know the length of every 
> > other hardware address?  I would propose generalizing this by adding a 
> > length  octet immediately following the hardware type. 
> 
> That's not necessary.   We already know how long the DUID is, because 
> it's an option. 
> 
...oops!  forgot that! 

> > ...   given that domain names are changed as frequently as corporate 
> > identity makeovers or marketing department changes of direction I'd like 
> > some other sort of "registered" identify, but I'm not sure what 
> to propose 
> > in place of domain name. 
> 
> That's just it.  We can't make the IANA do it.  Short of that, making 
> the domain registrars do it seems like the easiest thing.  I can 
> definitely conceive of this becoming a problem once in a while, but 
> it's a problem that the manufacturer will have some interest in 
> avoiding, so I'm not *too* worried about it. 
> 
...there doesn't seem to be a good answer to this one -- on the one hand, we 
should encourage vendors to select as short an identifier string as possible 
to identify the vendor, but not so long as to be burdensome.  Is there any 
value to specifying the "domain name" part as an opaque, vendor-selected 
octet string (permitting, for example, UTF-8) with the strong suggestion 
that it be a (registered) trade-mark, domain name, or legal business name, 
but without burdening either IANA or a domain registrar? 

> >       Is an 8-octet identifier sufficient as the number of 
> networked devices 
> > increases? 
> 
> There aren't that many atoms in the universe, so yes, I think this 
> will do.   :') 
> 
...so much for my knowledge of cosmology! 

> > ...   would the vendor ID include some numeric encoding of the vendor's 
> > identity, or is it intended that the domain name portion do 
> that, leaving 
> > VUID to be, essentially, an equipment serial number?  If the vendor's 
> > identity is encoded in the VUID then registration/assignment of 
> vendor IDs 
> > become a task for IANA, would we expand the IEEE codes as used 
> in Ethernet 
> > addresses, or use some other identifier that is widely available such as 
> > SIC/NMIC? 
> 
> This is precisely what I am trying to avoid by using the domain name. 
> 
...good point

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jul 2001 23:38:07 -0700

> Or, the board (or software) knows the vendor of the NIC or whatever
> and can simply add the domain name. But, that is an assumption that
> might not always hold.

This is not at all what is intended!   That's why there are special
DUID types for both possible uses of the link-layer address, with very
explicit MUSTs and MUST NOTs.   Based on what you've said, perhaps we
should add this:

     The structure of the VUID is left up to the vendor defining it,
     but each device containing such a VUID MUST be unique to each
     device that is using it, and MUST be assigned to the device at the
     time of manufacture and stored in some form of non-volatile
-    storage.  The VUID SHOULD be recorded in non-erasable storage.
+    storage.  The VUID MUST NOT be the link-layer of a network 
+    interface.   The VUID SHOULD be recorded in non-erasable storage.
     The domain name is simply any domain name that has been legally

			       _MelloN_

---

From: "Jerome Labussiere" <[email-masked]>
Date: Wed, 18 Jul 2001 11:00:58 +0200

Hello

What do you think of the solution defined in COPS
(http://www.ietf.org/rfc/rfc2748.txt section 2.2.11) ?

> Variable-length field. It is a NULL terminated ASCII string that is
>  also zero padded to a 32-bit word boundary (so the object length is a
>  multiple of 4 octets). The PEPID MUST contain an ASCII string that
>  uniquely identifies the PEP within the policy domain in a manner that
>  is persistent across PEP reboots. For example, it may be the PEP's
>  statically assigned IP address or DNS name. This identifier may
>  safely be used by a PDP as a handle for identifying the PEP in its
>  policy rules.

Maybe the DUID should not be globally-unique but simply unique within the
administrative domain (and configurable on the client)

As the format of the DUID was not defined, I tried this in a modest
implementation of rev-18 and it was very flexible and easy to implement. I
used NAI (ftp://ftp.isi.edu/in-notes/rfc2486.txt) to identify clients. If
the NAI "realm" is local, I used a LDAP repository, if not, it is possible
to send a request to an AAA infrastructure (using the realm to route the
request).

Actually, I think it is also possible to map authentification of DHCP
messages on identification/authentification of clients in a generic way.

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 18 Jul 2001 09:15:19 -0700

RE: Definition of DUIDBernie,

you may have been kidding, but what's important is that a unique number be
used to identify the vendor in this case, so the EIN isn't all that weird.
I'll have some suggested text to unify this later today.

--Barr

  PS: For US vendors, we could even have them use their EIN (Employer
Identification Number)? [Just kidding.]

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 18 Jul 2001 09:40:43 -0700

comments inline....

--Barr

> From: Jerome Labussiere
... nits first:  (1) we should not introduce new protocol elements that
continue to use (NVT-)ASCII -- either ISO10646 or UTF-8 will be required in
the [near] future, so let's not make more work for ourselves by
intentionally building in obsolescence;  (2) options carry a length code
precisely so that we never need to include a null terminator for a string,
so let's not even consider this sort of a change as I'm afraid it sets a
dangerous precedent;  (3) again, because the length of an option is known in
advance, padding any octet string to be a multiple of some unit is not a
good idea -- it arbitrarily increases the size of the protocol messages
without any clear benefit

...having said all of that, I definitely like the idea of reusing concepts
that have been previously developed, and will have more to say in a later
message

> administrative domain (and configurable on the client)
... one of the shortcomings of DHCPv4 is the lack of a globally unique
identifier:  without revisiting all of the discussion, I'll just state as an
article of faith that a globally-unique identifier *is* required for DUID.
I can imagine, however, that some sort of a "scope" indicator might be
included in the DUID *if and only if* the working group reaches a consensus
that the DUID does not *always* require global uniqueness:  "scope" would
then be either "local" or "global" according to the indicator carried
with(in) the DUID.  Again, I'll try to put this into a contribution in a
later message.

> to send a request to an AAA infrastructure (using the realm to route the
... HOORAY!!!  There is nothing like implementation experience to draw upon
when trying to decide how to design a protocol element....

> messages on identification/authentification of clients in a generic way.
... this may open up an entirely different discussion, however....

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2001 12:27:31 -0700

> to send a request to an AAA infrastructure (using the realm to route the

Where your proposed format falls down is not in the implementation,
but in the deployment.  Coming up with an ad-hoc identifier that is
unique within an administrative domain is difficult.  Coming up with
one that continues to be unique when you move to a new administrative
domain, or detecting that you have changed administrative domains and
therefore generating a new identifier for that domain is even more
difficult.   This is why none of the proposed formats for DUID attempt
to solve this problem.

> messages on identification/authentification of clients in a generic way.

That's certainly true.

			       _MelloN_