11. DHCP Unique Identifier (DUID)
This section preserves the RFC text for DHCPv6, including message exchanges, relay behavior, DUIDs, IA_NA, IA_TA, IA_PD, DHCP options, RKAP authentication, IANA registries, normative requirements, and appendix option-appearance matrices.
Original RFC Text
11. 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 in
the association of IAs with clients. DHCP clients use DUIDs to
identify a server in messages where a server needs to be identified.
See Sections 21.2 and 21.3 for details regarding the representation
of a DUID in a DHCP message.
Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers SHOULD NOT in any
other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the types defined in this document, as additional DUID types
may be defined in the future. It should be noted that an attempt to
parse a DUID to obtain a client's link-layer address is unreliable,
as there is no guarantee that the client is still using the same
link-layer address as when it generated its DUID. Also, such an
attempt will be more and more unreliable as more clients adopt
privacy measures such as those defined in [RFC7844]. If this
capability is required, it is recommended to rely on the Client Link-
Layer Address option instead [RFC6939].
The DUID is carried in an option because it may be variable in length
and because it is not required in all DHCP messages. The DUID is
designed to be unique across all DHCP clients and servers, and stable
for any specific client or server. That is, the DUID used by a
client or server SHOULD NOT change over time if at all possible; for
example, a device's DUID should not change as a result of a change in
the device's network hardware or changes to virtual interfaces (e.g.,
logical PPP (over Ethernet) interfaces that may come and go in
Customer Premises Equipment routers). The client may change its DUID
as specified in [RFC7844].
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
device 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 accommodate such devices.
11.1. DUID Contents
A DUID consists of a 2-octet type code represented in network byte
order, followed by a variable number of octets that make up the
actual identifier. The length of the DUID (not including the type
code) is at least 1 octet and at most 128 octets. The following
types are currently defined:
+======+======================================================+
| Type | Description |
+======+======================================================+
| 1 | Link-layer address plus time |
+------+------------------------------------------------------+
| 2 | Vendor-assigned unique ID based on Enterprise Number |
+------+------------------------------------------------------+
| 3 | Link-layer address |
+------+------------------------------------------------------+
| 4 | Universally Unique Identifier (UUID) [RFC6355] |
+------+------------------------------------------------------+
Table 2: DUID Types
Formats for the variable field of the DUID for the first three of the
above types are shown below. The fourth type, DUID-UUID [RFC6355],
can be used in situations where there is a UUID stored in a device's
firmware settings.
11.2. DUID Based on Link-Layer Address Plus Time (DUID-LLT)
This type of DUID consists of a 2-octet type field containing the
value 1, a 2-octet hardware type code, and 4 octets containing a time
value, followed by the link-layer address of any one network
interface that is connected to the DHCP device at the time that the
DUID is generated. The time value is the time that the DUID is
generated, represented in seconds since midnight (UTC), January 1,
2000, modulo 2^32. The hardware type MUST be a valid hardware type
assigned by IANA; see [IANA-HARDWARE-TYPES]. Both the time and the
hardware type are stored in network byte order. For Ethernet
hardware types, the link-layer address is stored in canonical form,
as described in [RFC2464].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (1) | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DUID-LLT Format
The choice of network interface can be completely arbitrary, as long
as that interface provides a globally unique link-layer address for
the link type; 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 do not have any stable storage MUST NOT use this
type of DUID.
Clients and servers 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 (for example, a real-time clock) in
generating the DUID, even if that time source could not be configured
prior to generating the DUID. The use of a time source makes it
unlikely that two identical DUID-LLTs will be generated if the
network interface is removed from the client and another client then
uses the same network interface to generate a DUID-LLT. A collision
between two DUID-LLTs is very unlikely even if the clocks have not
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.
It is possible that this algorithm for generating a DUID could result
in a client identifier collision. A DHCP client that generates a
DUID-LLT using this mechanism MUST provide an administrative
interface that replaces the existing DUID with a newly generated
DUID-LLT.
11.3. DUID Assigned by Vendor Based on Enterprise Number (DUID-EN)
The vendor assigns this form of DUID to the device. This DUID
consists of the 4-octet vendor's registered Private Enterprise Number
as maintained by IANA [IANA-PEN] 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (2) | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DUID-EN Format
The source of the identifier is left up to the vendor defining it,
but each identifier part of each DUID-EN MUST be unique to the device
that is using it, and MUST be assigned to the device no later than at
the first usage and stored in some form of non-volatile storage.
This typically means being assigned during the manufacturing process
in the case of physical devices or, in the case of virtual machines,
when the image is created or booted for the first time. The
generated DUID SHOULD be recorded in non-erasable storage. The
enterprise-number is the vendor's registered Private Enterprise
Number as maintained by IANA [IANA-PEN]. The enterprise-number is
stored as an unsigned 32-bit number.
An example DUID of this type might look like this:
+---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 0 |126|217| 12|192|
+---+---+---+---+---+---+---+---+
|132|211| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+
Figure 6: DUID-EN Example
This example includes the 2-octet type of 2 and the Enterprise Number
(32473) (from [RFC5612]), followed by 8 octets of identifier data
(0x0CC084D303000912).
11.4. DUID Based on Link-Layer Address (DUID-LL)
This type of DUID consists of 2 octets containing a DUID type of 3
and a 2-octet network hardware type code, followed by the link-layer
address of any one network interface that is permanently connected to
the client or server device. For example, a node that has a network
interface implemented in a chip that is unlikely to be removed and
used elsewhere could use a DUID-LL. The hardware type MUST be a
valid hardware type assigned by IANA; see [IANA-HARDWARE-TYPES]. The
hardware type is stored in network byte order. The link-layer
address is stored in canonical form, as described in [RFC2464]. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (3) | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DUID-LL Format
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-LL is being
generated. 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.
A DUID-LL is recommended for devices that have a permanently
connected network interface with a link-layer address and do not have
nonvolatile, writable stable storage. A DUID-LL SHOULD NOT be used
by DHCP clients or servers that cannot tell whether or not a network
interface is permanently attached to the device on which the DHCP
client is running.
11.5. DUID Based on Universally Unique Identifier (DUID-UUID)
This type of DUID consists of 16 octets containing a 128-bit UUID.
[RFC6355] details when to use this type and how to pick an
appropriate source of the UUID.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (4) | UUID (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: DUID-UUID Format