Subject: RE: Definition of DUID

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 17 Jul 2001 16:11:02 -0500

FYI - Forgot to add that the GSM document also defines the IMEI. It to is 15 digits:
    6 digits for TAC (Type Approval Code, determined by a "central body").
    2 digits for FAC (Final Assmbly Code, identifies place of manufacture/final assembly)
    6 digits for SNR (Serial Number, unique within a TAC + FAC)
    1 digit for a spare

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

Ted, Ralph, et al: 

This does look great! Thanks Ted. 

Regarding Barr's comment regarding a length field for the link-layer address, I don't see why we need this. Sure, there may be many link-layer addresses that are not fixed length, but the option's length field will tell you what the length of the link-layer address is (after subtracting the other octets since they are fixed). So, why add an extra octet to all of the packets that isn't needed.

Regarding Barr's comments on a 64-bit time, we could do this but again I think 32-bits is enough insurance. There are likely some privacy issues about knowing that exact time a DUID was created that someone would complain about? Having it be modulo 2^32 is fine since all we're trying to prevent is a collision in cases where a NIC card is moved between systems and both may use the MAC address to generate the DUID. Having a 64-bit time won't buy much, especially if maintained in seconds. The upper 32-bits will be stable over long periods and I suspect that most NICs won't last the 100 or so years covered by 32 bits.

Regarding IMEI, see http://www.buyncell.com/gsminfo/imei.shtml <http://www.buyncell.com/gsminfo/imei.shtml>  and http://home.swipnet.se/OsbyMikro/imeie.htm <http://home.swipnet.se/OsbyMikro/imeie.htm>  for some details. I'm sure that this is also specified in some GSM documentation but haven't been able to locate it.

Regarding IMSI, see GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification", European Telecommunications Standards Institute, April 1997". You can download documents from www.etsi.org (you need to register). Some of the basics are:

        IMSI consists of numerical characters (0 thru 9) only. 
        The overall number of digits shall not exceed 15. 
        There are 3 parts of the number: 
                MCC (3 digits)          - Mobile Country Code 
                MNC (2 digits)          - Mobile Network Code (GSM PLMN within country) 
                MSIN (remaining digits) - Mobile Subscriber Identification Number 

We probably would want to store these in an more efficient encoding than 15 bytes (perhaps BCD encoded, 4-bits per digit though that does make it difficult to represent an odd number of digits).

Hope that helps! 

- Bernie

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 17 Jul 2001 15:37:33 -0500

Ted, Ralph, et al:

Regarding IMEI, see http://www.buyncell.com/gsminfo/imei.shtml and http://home.swipnet.se/OsbyMikro/imeie.htm for some details. I'm sure that this is also specified in some GSM documentation but haven't been able to locate it.

Hope that helps!

- Bernie

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 17 Jul 2001 17:11:31 -0700

RE: Definition of DUID
I'm sending this to the mailing list twice, in the hopes that one of the forms will be completely readable by all recipients....

--Barr

-----Original Message-----
From: Barr Hibbs [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 17:10
To: [email-masked]
Subject: RE: Definition of DUID 

Bernie--

we'll probably just have to live with old, out-of-date domain names, but other than vanity issues (suppose IBM changed it's name to Ascentia, for example) there is probably no harm at all in allowing existing equipment to continue using an obsolete [but still, presumably, unique!] registered name.

Domain name length and encoding *are* an issue, however.  While there is a decided tendency for businesses to choose compact names, as you indicated, there are a few with larger names (nortelnetworks.com, for instance), and some for whom the preferred name coding might *not* be NVT-ASCII (東芝 -- Toshiba, is an example) when IDNs are finally supported.

As far as second and third-level names are concerned, perhaps the description of this item option ought to strongly discourage use of anything but the base domain name?

Your idea about encoding the SNMP Enterprise ID as ASCII digits prefixed by the "@" character is quite a good suggestion.  I would argue that a vendor who would be supplying a DHCPv6 client is highly likely to also supply an SNMP agent or sub-agent, and Enterprise IDs are nicely compact.

--Barr

  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).

---

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

Yeh, let's go with 256. It definitely is longer than we'll likely ever want, but it's also long enough that it should handle just about anything that comes along.

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 9:48 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.

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.

> 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.

That's fine by me.

			       _MelloN_