Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
RFC 4361

Network Working Group                                           T. Lemon
Request for Comments: 4361                                       Nominum
Updates: 2131, 2132, 3315                                 B. Sommerfield
Category: Standards Track                               Sun Microsystems
                                                           February 2006

                  Node-specific Client Identifiers for
       Dynamic Host Configuration Protocol Version Four (DHCPv4)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies the format that is to be used for encoding
   Dynamic Host Configuration Protocol Version Four (DHCPv4) client
   identifiers, so that those identifiers will be interchangeable with
   identifiers used in the DHCPv6 protocol.  This document also
   addresses and corrects some problems in RFC 2131 and RFC 2132 with
   respect to the handling of DHCP client identifiers.

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Applicability ...................................................2
   4. Problem Statement ...............................................3
      4.1. Client identities are ephemeral. ...........................3
      4.2. Clients can accidentally present multiple identities. ......3
      4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible. ...4
      4.4. RFC 2131 does not require the use of a client identifier. ..4
   5. Requirements ....................................................4
   6. Implementation ..................................................6
      6.1. DHCPv4 Client Behavior .....................................6
      6.2. DHCPv6 Client Behavior .....................................7
      6.3. DHCPv4 Server Behavior .....................................7
      6.4. Changes from RFC 2131 ......................................8
      6.5. Changes from RFC 2132 ......................................9

Lemon & Sommerfield         Standards Track                     [Page 1]
RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

   7. Notes on DHCP Clients in Multi-stage Network Booting ............9
   8. Security Considerations ........................................10
   9. References .....................................................10
      9.1. Normative References ......................................10
      9.2. Informative References ....................................10

1.  Introduction

   This document specifies the way in which Dynamic Host Configuration
   Protocol Version 4 [RFC2131] clients should identify themselves.
   DHCPv4 client implementations that conform to this specification use
   a DHCP Unique Identifier (DUID) as specified in Dynamic Host
   Configuration Protocol for IPv6 (DHCPv6) [RFC3315].  The DUID is
   encapsulated in a DHCPv4 client identifier option, as described in
   "DHCP Options and BOOTP Vendor Extensions" [RFC2132].  The behaviour
   described here supersedes the behavior specified in RFC2131 and
   RFC2132.

   The reason for making this change is that as we make the transition
   from IPv4 to IPv6, there will be network devices that must use both
   DHCPv4 and DHCPv6.  Users of these devices will have a smoother
   network experience if the devices identify themselves consistently,
   regardless of the version of DHCP they are using at any given moment.
   Most obviously, DNS updates made by the DHCP server on behalf of the
   client will be handled more correctly.  This change also addresses
   certain limitations in the functioning of RFC 2131/2132-style DHCP
   client identifiers.

   This document first describes the problem to be solved.  It then
   states the new technique that is to be used to solve the problem.
   Finally, it describes the specific changes that one would have to
   make to RFC 2131 and RFC 2132 in order for those documents not to
   contradict what is described in this document.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].