9. DHCP Unique Identifier (DUID)

Each DHCP client and server has a DUID. DHCP servers use DUIDs to identify clients for the selection of configuration parameters and the association of IAs with clients. DHCP clients use DUIDs to identify servers in messages in which a server needs to be identified. For the representation of DUIDs in DHCP messages, see sections 22.2 and 22.3.

Clients and servers MUST treat DUIDs as opaque values and only compare DUIDs for equality. Clients and servers MUST NOT interpret DUIDs in any other way. Clients and servers MUST NOT restrict DUIDs to the types defined in this document, as other DUID types may be defined in the future.

DUIDs are carried in options because they may be variable length and are not required in all DHCP messages. DUIDs are designed to be unique across all DHCP clients and servers, and stable for any specific client or server -- that is, a DUID used by a client or server SHOULD NOT change over time if possible; for example, a device's DUID SHOULD NOT change as a result of a change in the device's network hardware.

The reason for having multiple types of DUIDs is that a DUID MUST be globally unique and MUST be easy to generate. The type of globally unique identifier that is easy to generate for any given device may vary considerably. In addition, some devices may not contain any persistent storage. It is impossible to preserve a generated DUID in such devices, so the DUID scheme must accommodate such devices.

9.1. DUID Contents

A DUID consists of a two-byte type code represented in network byte order, followed by a variable number of bytes that make up the actual identifier. The length of a DUID cannot exceed 128 bytes (excluding the type code). The following types are currently defined:

Link-layer address plus time
Vendor-assigned unique ID based on Enterprise Number
Link-layer address

The format of the variable fields for each of the above types of DUID is shown below.

9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]

This type of DUID consists of a two-byte type field containing the value 1, a two-byte hardware type code, a four-byte time value containing the time the DUID was generated, and the link-layer address of any one network interface connected to the DHCP device at the time the DUID was generated. The time value is the time that the DUID was generated, represented as seconds since midnight (UTC), January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by IANA, as described in RFC 826 [RFC 826]. Both time and hardware type are stored in network byte order. The link-layer address is stored in canonical form, as described in RFC 2464 [RFC 2464].

The following diagram illustrates the format of a DUID-LLT:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               1               |    hardware type (16 bits)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        time (32 bits)                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .             link-layer address (variable length)              .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The selection of the network interface can be completely arbitrary, as long as that interface provides a globally unique link-layer address for the link type, and the same DUID-LLT 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-LLT.

Clients and servers using this type of DUID MUST store the DUID-LLT in stable storage, and MUST continue to use this DUID-LLT even if the network interface used to generate the DUID-LLT is removed. Clients and servers that have no stable storage MUST NOT use this type of DUID.

Clients and servers using this DUID SHOULD attempt to configure time before generating the DUID if possible, and MUST use some time source (for example, a real-time clock) when generating the DUID, even if that time source cannot be configured before generating the DUID. Use of a time source makes it less likely that two identical DUID-LLTs will be generated if a network interface is removed from a client and then another client uses the same network interface to generate a DUID-LLT. Even if the clock is not configured before generating the DUID, a collision between two DUID-LLTs is very unlikely.

It is RECOMMENDED that all general-purpose computing devices (such as desktop computers and laptop computers) and devices that contain some form of writable non-volatile storage (such as printers, routers, etc.) use this DUID generation method.

Despite our best efforts, this algorithm for generating DUIDs may still result in client identifier collisions. DHCP clients that use this mechanism to generate DUID-LLTs MUST provide a management interface to replace an existing DUID-LLT with a newly generated DUID-LLT.

9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]

This form of DUID is assigned by a vendor to a device. It consists of a vendor's registered Private Enterprise Number as maintained by IANA [IANA], followed by a unique identifier assigned by the vendor. The following diagram summarizes the structure of a DUID-EN:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               2               |       enterprise-number       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   enterprise-number (contd)   |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    .                           identifier                          .
    .                       (variable length)                       .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The source of the identifier is determined by the vendor that defines it, but each identifier portion of each DUID-EN MUST be unique to the device that uses it, and MUST be assigned to the device at the time of device manufacture and stored in some form of non-volatile storage. The generated DUID SHOULD be recorded in non-erasable storage. The enterprise number is a vendor's registered Private Enterprise Number as maintained by IANA [IANA]. The enterprise number is stored as an unsigned 32-bit number.

An example of this type of DUID might look like this:

    +---+---+---+---+---+---+---+---+
    | 0 | 2 | 0 | 0 | 0 |  9| 12|192|
    +---+---+---+---+---+---+---+---+
    |132|221| 3 | 0 | 9 | 18|
    +---+---+---+---+---+---+

This example includes the two-byte type 2, enterprise number (9), followed by eight bytes of identifier data (0x0CC084D303000912).

9.4. DUID Based on Link-layer Address [DUID-LL]

This type of DUID consists of two bytes containing the DUID type 3, a two-byte network hardware type code, and the link-layer address of any one network interface that is permanently connected to the client or server device. For example, a host in which network interfaces are implemented in chips and are unlikely to be removed and used elsewhere can use DUID-LL. The hardware type MUST be a valid hardware type assigned by IANA, as described in RFC 826 [RFC 826]. The hardware type is stored in network byte order. The link-layer address is stored in canonical form, as described in RFC 2464 [RFC 2464]. The following diagram illustrates the format of a DUID-LL:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               3               |    hardware type (16 bits)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .             link-layer address (variable length)              .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The selection of the network interface can be completely arbitrary, as long as that interface provides a unique link-layer address and is permanently connected to the device that is generating the DUID-LL. The same DUID-LL 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.

It is RECOMMENDED that devices that have network interfaces with link-layer addresses that are permanently connected and that have no non-volatile, writable stable storage use DUID-LL. DHCP clients or servers that cannot determine whether a network interface is permanently connected to the device on which the DHCP client is running MUST NOT use DUID-LL.