Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
RFC 4361
Document | Type |
RFC - Proposed Standard
(February 2006; Errata)
Updated by RFC 5494
|
|
---|---|---|---|
Authors | Ted Lemon , Bill Sommerfeld | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4361 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Margaret Cullen | ||
Send notices to | rdroms@cisco.com, venaas@uninett.no |
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]. 3. Applicability This document updates RFC 2131 and RFC 2132. This document also specifies behavior that is required of DHCPv4 and DHCPv6 clients that are intended to operate in a dual-stack configuration. Finally, this document recommends behavior for host configurations where more thanShow full document text