Subject: Definition of DUID

From: Ralph Droms <[email-masked]>
Date: Mon, 16 Jul 2001 20:30:12 -0400

Here's is text from Ted Lemon (thanks, Ted!) proposing a definition for the 
DUID.  Please take a look at this text and post comments to the mailing 
list as soon as possible so I can finish the -20 rev of the draft by this 
Friday's deadline.

- Ralph

=====

11. DHCP unique identifier (DUID)

    Each DHCP client has a DUID. DHCP servers use DUIDs to identify
    clients for the selection of configuration parameters and in
    the association of IAs with clients.  See section 18.2 for the
    representation of a DUID in a DHCP message.

    The DUID is carried in an option because it may be variable length
    and because it is not required in all DHCP options (e.g., messages
    sent by servers need not include a DUID).  The DUID must be unique
    across all DHCP clients, and it must also be consistent across uses
    of the same client - that is, a client's DUID SHOULD NOT change
    over time, or as a result of network hardware reconfiguration.

    The motivation for having more than one type of DUID is that the
    DUID must be globally unique, and must also be easy to generate.
    The sort of globally-unique identifier that is easy to generate for
    any given application can differ quite widely.   Also, some devices
    may not contain any persistent storage.   Retaining a generated
    DUID in such a device is not possible, so the DUID scheme must
    accomodate such devices.

11.1 DUID contents

    A DUID consists of a sixteen-bit type code represented in network
    byte order, followed by a variable number of bytes that make up the
    actual identifier.   The following types are currently defined:

	  1	Link-layer address plus time
	  2	Vendor-assigned unique ID
	  3	Link-layer address
	  4	IMSI
	  5	IMEI

    Although cell phone IMSI (International Mobile Subscriber
    Identifier) and IMEI (International Mobile Equipment Identity) can
    be used as unique identifiers, the mobile phone telephone number
    MUST NOT be used, because the mobile phone telephone number is not
    guaranteed to remain stable across the lifetime of the phone - it
    is possible to have two phones which have been programmed with the
    same telephone number.

    Formats for the variable field of the DUID for each of the above
    types are shown below.  New types may be defined in future
    standards, and must be allocated by the IANA.

11.1.1 DUID based on link-layer address plus time

    This type of DUID consists of four octets containing a time value,
    followed by a two octet network hardware type code, followed by
    link-layer address of any one network interface that is connected
    to the DHCP client device at the time that the DUID is generated.
    The time value is the time that the DUID is generated represented
    in seconds since January 1, 2000, modulo 2^32.  The hardware type
    MUST be a valid hardware type assigned by the IANA as described in
    the section on ARP in [23].  Both the time and the hardware type
    are stored in network byte order.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Time (32 bits)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Hardware type (16 bits)    |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     .                                                               .
     .             link-layer address (variable length)              .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The choice of network interface can be completely arbitrary, as
    long as that interface provides a unique link-layer address, and
    the same DUID should be used in configuring all network interfaces
    connected to the device, regardless of which interface's link-layer
    address was used to generate the DUID.

    DHCP clients using this type of DUID MUST store the DUID in stable
    storage, and MUST continue to use this DUID even if the network
    interface used to generate the DUID is removed.   DHCP clients that
    do not have any stable storage MUST NOT use this type of DUID.

    DHCP clients that use this DUID SHOULD attempt to configure the
    time prior to generating the DUID, if that is possible, and MUST
    use some sort of time source (e.g., a real-time clock) in
    generating the DUID, even if that time source is not configured by
    the user prior to generating the DUID.   The use of a time source
    makes it unlikely that if the network interface is removed from the
    client and another client then uses the same network interface to
    generate a DUID, that two identical DUIDs will be generated.   A
    DUID collision is very unlikely even if the clocks haven't been
    configured prior to generating the DUID.

    This method of DUID generation is recommended for all general
    purpose computing devices such as desktop computers and laptop
    computers, and also for devices such as printers, routers, and so
    on, that contain some form of writable non-volatile storage.

11.1.2 Vendor-assigned unique ID.

    The vendor-assigned unique ID consists of an eight-octet
    vendor-unique identifier, followed by the vendor's registered
    domain name.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        VUID (64 bits)                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                  domain name (variable length)                .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     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.
     The domain name is simply any domain name that has been legally
     registered by the vendor in the domain name system, stored in
     canonical form.   An example DUID of this type might look like
     this:

     +--+---+---+---+-+-+--+---+---+--+---+---+---+---+--+--+---+---+
     |12|192|132|221|3|9|18|101|120|97|109|112|108|101|46|99|111|109|
     +--+---+---+---+-+-+--+---+---+--+---+---+---+---+--+--+---+---+

     This is eight octets of VUID data, followed by "example.com"
     represented in ASCII.

11.1.3 Link-layer address

    This type of DUID consists of a two octet network hardware type
    code, followed by the link-layer address of any one network
    interface that is permanently connected to the DHCP client device.
    The time value is the time that the DUID is generated represented
    in seconds since January 1, 2000, modulo 2^32.  The hardware type
    MUST be a valid hardware type assigned by the IANA as described in
    the section on ARP in [23].  The hardware type is stored in network
    byte order.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Hardware type (16 bits)    |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     .                                                               .
     .             link-layer address (variable length)              .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The choice of network interface can be completely arbitrary, as
    long as that interface provides a unique link-layer address and is
    permanently attached to the device on which the DUID is being
    generated.  The same DUID should be used in configuring all network
    interfaces connected to the device, regardless of which interface's
    link-layer address was used to generate the DUID.

    This type of DUID is recommended for devices that have a
    permanently-connected network interface with a link-layer address
    and do not have nonvolatile, writable stable storage.   This type
    of DUID MUST NOT be used by DHCP clients that cannot tell whether
    or not a network interface is permanently attached to the device on
    which the DHCP client is running.

11.1.4 DUID based on IMEI and IMSI

    Because IMEI and IMSI are both globally-unique numbers, a DUID
    based on either one simply consists of the binary identifier,
    represented in its canonical form.

[Hayulp!   I have no idea what the format of these numbers is - can
anybody (nokia guys?) help to adjust this language?   Also, if we can
cleanly capture all the extant identifiers being used by the cell
phone industry here, that would be Really Nice [TM].   E.g., what
identifier is used in AMPS and CDMA?   Also, can anybody provide
references to be cited?]

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Tue, 17 Jul 2001 09:58:36 -0400

Ralph, Ted,
This looks great!  I have just one editorial comment...

Section 11.1.3 - paragraph 1 has a cut-and-paste about the time calculation,
but there is no time in the link-layer addresss DUID.

Greg

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Ralph Droms
> Sent: Monday, July 16, 2001 8:30 PM
> To: DHCPv6 discussion list
> Subject: Definition of DUID
>
>

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 17 Jul 2001 09:58:59 -0700

comments are inline

--Barr

>     in seconds since January 1, 2000, modulo 2^32.

...   the beginning of the epoch should be specified as starting at a
particular time of day, for example, midnight (00h00) UTC or midnight local
time -- I tend to favor UTC as the intent is to make the identifier globally
unique so it would (presumably) be of advantage to have the same start of
epoch.

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?

>                                                     The hardware type

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

>     on, that contain some form of writeable non-volatile storage.
>

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

      Is an 8-octet identifier sufficient as the number of networked devices
increases?

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

...   I think the following sentence should be struck from this section:

>     in seconds since January 1, 2000, modulo 2^32.

>                                                     The hardware type

...   Again, I think that an address length octet should be added to this
form, following the hardware type.

>     and do not have nonvolatile, write able stable storage.   This type

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jul 2001 13:28:43 -0700

> unique so it would (presumably) be of advantage to have the same start of

Oops.   Yes, we need both of these changes.

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

> length  octet immediately following the hardware type.

That's not necessary.   We already know how long the DUID is, because
it's an option.

> some other sort of "registered" identify, but I'm not sure what to propose

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.

>       Is an 8-octet identifier sufficient as the number of networked devices

There aren't that many atoms in the universe, so yes, I think this
will do.   :')

> addresses, or use some other identifier that is widely available such as

This is precisely what I am trying to avoid by using the domain name.

> >     in seconds since January 1, 2000, modulo 2^32.

You are right.

> form, following the hardware type.

See above.   :'}

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 17 Jul 2001 15:35:49 -0700

my responses are inline...

--Barr

> particular problem seems remote.   :')
...agreed, 68 years does seem long enough...  but I thought I should ask....

> That's not necessary.   We already know how long the DUID is, because
...oops!  forgot that!

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

> There aren't that many atoms in the universe, so yes, I think this
...so much for my knowledge of cosmology!

> 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 16:40:28 -0700

> ...agreed, 68 years does seem long enough...  but I thought I should ask....

It's actually 136 years.   :')

			       _MelloN_