Subject: RE: Definition of DUID

From: "Thirumalesh Bhat" <[email-masked]>
Date: Tue, 17 Jul 2001 18:06:17 -0700

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]] 
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 18:47:48 -0700

> hard coded domain name built it.

This is a seperate issue.   The domain name in the VUID DUID type is
not expected to be the domain name of the user, but of the vendor.
So it doesn't say anything about the identity of the user or the DHCP
client other than perhaps who implemented it.

> DUIDs. I think 256 octets is a reasonable upper bound.

That's fine by me.

			       _MelloN_