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) | |
| 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 than
Show full document text