draft-ietf-dhc-dhcpv6-14.txt   draft-ietf-dhc-dhcpv6-15.txt 
Internet Engineering Task Force J. Bound Internet Engineering Task Force J. Bound
INTERNET DRAFT Compaq Computer Corp. INTERNET DRAFT Compaq Computer Corp.
DHC Working Group C. Perkins DHC Working Group M. Carney
Obsoletes: draft-ietf-dhc-dhcpv6-13.txt Sun Microsystems Laboratories Obsoletes: draft-ietf-dhc-dhcpv6-14.txt Sun Microsystems, Inc
25 February 1999 C. Perkins
Nokia Research Center
5 May 2000
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-14.txt draft-ietf-dhc-dhcpv6-15.txt
Status of This Memo Status of This Memo
This document is a submission by the Dynamic Host Configuration This document is a submission by the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Working Group of the Internet Engineering Task Force (IETF). Comments
Comments should be submitted to the dhcp-v6@bucknell.edu mailing should be submitted to the dhcp-v6@bucknell.edu mailing list.
list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 33 skipping to change at page 1, line 32
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at: The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCPv6) enables DHCP The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables
servers to pass configuration information, via extensions, to IPv6 DHCP servers to pass configuration parameters using extensions to
nodes. It offers the capability of automatic allocation of reusable IPv6 nodes. It offers the capability of automatic allocation of
network addresses and additional configuration flexibility. This reusable network addresses and additional configuration flexibility.
protocol is a stateful counterpart to the IPv6 Stateless Address This protocol is a stateful counterpart to ``IPv6 Stateless Address
Autoconfiguration protocol, and can be used separately or together Autoconfiguration'' [15], and can be used separately or concurrently
with the latter to obtain configuration information. with the latter to obtain configuration parameters.
Contents Contents
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Terminology and Definitions 2 2. Terminology 2
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3 2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3
2.3. Specification Language . . . . . . . . . . . . . . . . . 4
2.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Design Model 4 3. DHCP Constants 5
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 5
3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 5 3.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Request/Response Processing Model . . . . . . . . . . . . 7 3.3. DHCP message types . . . . . . . . . . . . . . . . . . . 6
3.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Generic Error Values . . . . . . . . . . . . . . 8
3.4.2. Server-specific Error Values . . . . . . . . . . 8
3.5. Configuration Variables . . . . . . . . . . . . . . . . . 8
4. DHCP Message Formats and Field Definitions 8 4. Requirements 9
4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8
4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9
4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10
4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12
4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13
4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 15
5. DHCP Client Considerations 16 5. Background 9
5.1. Verifying Resource Allocations After Restarts . . . . . . 16
5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16
5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 17
5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 18
5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 20
5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 20
5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 21
5.8. Interaction with Stateless Address Autoconfiguration . . 22
6. DHCP Server Considerations 23 6. Design Goals 11
6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 23
6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 24
6.3. DHCP Request and Reply Message Processing . . . . . . . . 24
6.3.1. Processing for Extensions to DHCP Request and Reply
Messages . . . . . . . . . . . . . . . . . 25
6.3.2. Client Requests to Deallocate Unknown Resources . 26
6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 26
6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 27
6.6. Client-Resource timeouts . . . . . . . . . . . . . . . . 28
7. DHCP Relay Considerations 28 7. Non-Goals 11
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 28
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 29
7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 30
8. Retransmission and Configuration Variables 30 8. Overview 12
8.1. How does a node know to use DHCP? . . . . . . . . . . . . 12
8.2. How does a client find out about DHCP agents? . . . . . . 12
8.3. What if the client and server(s) are on different links? 12
8.4. How does a client request configuration parameters from
servers? . . . . . . . . . . . . . . . . . . . . . . . 13
8.5. What are releasable resources, and when are they used? . 13
8.6. Can a client release its releasable resources before the lease
expires? . . . . . . . . . . . . . . . . . . . . . . . 14
8.7. What if the client determines its releasable resource is
already being used by another client? . . . . . . . . 14
8.8. How are clients notified of server configuration changes? 14
9. Security Considerations 33 9. Message Formats 15
9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 15
9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 16
9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 18
9.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 19
9.5. DHCP Release Message Format . . . . . . . . . . . . . . . 20
9.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 22
9.7. DHCP Reconfigure-reply Message Format . . . . . . . . . . 23
9.8. DHCP Reconfigure-init Message Format . . . . . . . . . . 24
10. Year 2000 considerations 33 10. DHCP Server Solicitation and Subnet Prefix Discovery 25
10.1. Solicit Message Validation . . . . . . . . . . . . . . . 25
10.2. Advertise Message Validation . . . . . . . . . . . . . . 25
10.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26
10.3.1. Creation and sending of the Solicit message . . . 26
10.3.2. Time out and retransmission of Solicit Messages . 27
10.3.3. Receipt of Advertise messages . . . . . . . . . . 27
10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 28
10.4.1. Relaying of Solicit messages . . . . . . . . . . 28
10.4.2. Relaying of Advertise messages . . . . . . . . . 28
10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28
10.5.1. Receipt of Solicit messages . . . . . . . . . . . 28
10.5.2. Creation and sending of Advertise messages . . . 29
11. IANA Considerations 34 11. DHCP Client-Initiated Configuration Exchange 29
11.1. Request Message Validation . . . . . . . . . . . . . . . 29
11.2. Reply Message Validation . . . . . . . . . . . . . . . . 30
11.3. Release Message Validation . . . . . . . . . . . . . . . 31
11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31
11.4.1. Creation and sending of Request messages . . . . 32
11.4.2. Time out and retransmission of Request Messages . 33
11.4.3. Receipt of Reply message in response to a Request 33
11.4.4. Creation and sending of Release messages . . . . 33
11.4.5. Time out and retransmission of Release Messages . 34
11.4.6. Receipt of Reply message in response to a Release 35
11.5. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 35
11.5.1. Relaying of Request or Release messages . . . . . 35
11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35
11.6.1. Receipt of Request messages . . . . . . . . . . . 35
11.6.2. Receipt of Release messages . . . . . . . . . . . 36
11.6.3. Creation and sending of Reply messages . . . . . 36
12. Acknowledgements 34 12. DHCP Server-Initiated Configuration Exchange 37
12.1. Reconfigure Message Validation . . . . . . . . . . . . . 37
12.2. Reconfigure-reply Message Validation . . . . . . . . . . 38
12.3. Reconfigure-init Message Validation . . . . . . . . . . . 38
12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 38
12.4.1. Creation and sending of Reconfigure messages . . 39
12.4.2. Time out and retransmission of Reconfigure
messages . . . . . . . . . . . . . . . . . 40
12.4.3. Receipt of Reconfigure-reply messages . . . . . . 40
12.4.4. Creation and sending of Reconfigure-init messages 40
12.4.5. Time out and retransmission of Reconfigure-init
messages . . . . . . . . . . . . . . . . . 41
12.4.6. Receipt of Request messages . . . . . . . . . . . 41
12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 41
12.5.1. Receipt of Reconfigure messages . . . . . . . . . 42
12.5.2. Creation and sending of Reconfigure-reply messages 42
12.5.3. Receipt of Reconfigure-init messages . . . . . . 43
12.5.4. Creation and sending of Request messages . . . . 43
12.5.5. Time out and retransmission of Request messages . 43
12.5.6. Receipt of Reply messages . . . . . . . . . . . . 43
A. Changes for this revision 34 13. Using DHCP for network renumbering 43
13.1. Passive Renumbering . . . . . . . . . . . . . . . . . . . 44
13.2. Active Renumbering . . . . . . . . . . . . . . . . . . . 44
B. Related Protocol Specifications 35 14. DHCP Client Implementator Notes 44
14.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 45
14.2. Advertise Message and Configuration Parameter Caching . . 45
14.3. Time out and retransmission variables . . . . . . . . . . 45
14.4. Server Preference . . . . . . . . . . . . . . . . . . . . 45
C. Comparison between DHCPv4 and DHCPv6 37 15. DHCP Server Implementator Notes 46
15.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 46
15.2. Reconfigure Considerations . . . . . . . . . . . . . . . 46
15.3. Server Preference . . . . . . . . . . . . . . . . . . . . 46
15.4. Request Message Transaction-ID Cache . . . . . . . . . . 47
D. Full Copyright Statement 40 16. DHCP Relay Implementator Notes 47
Chair's Address 43 17. Open Issues for Working Group Discussion 47
17.1. Trade-offs: Optional fields in DHCP messages . . . . . . 47
17.2. Use DHCPv4 authentication or the current DHCPv6 method? . 48
17.3. The Reconfigure Message and Subnet Prefix Extensions . . 48
17.4. ``R'' bit in Request message not needed? . . . . . . . . 48
Author's Address 43 18. Security Considerations 48
1. Introduction 19. Year 2000 considerations 49
The Dynamic Host Configuration Protocol (DHCPv6, or in this 20. IANA Considerations 49
document usually DHCP) provides configuration parameters to Internet
nodes. DHCP consists of a protocol for delivering node-specific
configuration parameters from a DHCP server to a client, and
extensions for allocation of network addresses and other related
parameters to IPv6 [7] nodes.
DHCP uses a client-server model, where designated DHCP servers 21. Acknowledgements 50
automatically allocate network addresses and deliver configuration
parameters to dynamically configurable clients. Throughout the
remainder of this document, the term "server" refers to a node
providing initialization parameters by way of the DHCP protocol,
and the term "client" refers to a node requesting initialization
parameters from a DHCP server.
DHCPv6 uses Request and Reply messages to support a client/server A. Comparison between DHCPv4 and DHCPv6 50
processing model whereby both client and server are assured that
requested configuration parameters have been received and accepted
by the client. DHCP supports optional configuration parameters and
processing for nodes through extensions described in its companion
document ``Extensions for the Dynamic Host Configuration Protocol for
IPv6'' [15].
The IPv6 Addressing Architecture [9] and IPv6 Stateless Address B. Full Copyright Statement 52
Autoconfiguration [20] specifications provide new features not
available in IP version 4 (IPv4) [18], which are used to simplify
and generalize the operation of DHCP clients. This document is
intended to complement those specifications for clients attached to
the kinds of Internet media for which those specifications apply. In
particular, the specification in this document does not necessarily
apply to nodes which do not enjoy a bidirectional link to the
Internet.
Section 2 provides definitions for terminology used throughout Chair's Address 55
this document. Section 3 provides an overview of the protocol
design model that guided the design choices in the specification;
section 3.2 briefly describes the protocol messages and their
semantics. Section 4 provides the message formats and field
definitions used for each message. Sections 5, 6, and 7 specify
how clients, servers, and relays respectively interact. The timeout
and retransmission guidelines as well as configuration variables for
DHCP protocol operations are discussed in Section 8. Appendix B
summarizes related work in IPv6 that will provide helpful context;
it is not part of this specification, but included for informational
purposes. Appendix C discusses the differences between DHCPv4 and
DHCPv6.
2. Terminology and Definitions Author's Address 55
Relevant terminology from the IPv6 Protocol [7], IPv6 Addressing 1. Introduction
Architecture [9], and IPv6 Stateless Address Autoconfiguration [20]
is given, followed by DHCPv6 terminology. This document describes DHCP for IPv6 (DHCP), a UDP [14] client /
server protocol designed to reduce the cost of management of IPv6
nodes in environments where network managers require more control
over the allocation of network resources more varied than that
offered by ``IPv6 Stateless Autoconfiguration'' [15]. The DHCP is a
stateful counterpart to stateless autoconfiguration. Note that both
stateful and stateless autoconfiguration can be used concurrently in
the same environment, leveraging the strengths of both mechanisms
in order to reduce the cost of ownership and management of network
nodes.
The DHCP reduces the cost of ownership by centralizing the management
of network resources such as IP addresses, routing information, OS
installation information, directory service information, and other
such information on a few DHCP servers, rather than distributing such
information in local configuration files among each network node.
The DHCP is designed to be easily extended to carry new configuration
parameters through the addition of new DHCP ``extensions'' defined to
carry this information. See this document's companion specification,
``Extensions for the Dynamic Host Configuration Protocol for
IPv6'' [2] for specifications of existing extensions as well as
information on the process by which an interested party might specify
new extensions.
Those readers familiar with DHCP for IPv4 [7] will find DHCP for IPv6
provides a superset of features, and benefits from the additional
features of IPv6 and freedom from BOOTP [5]-backward compatibility
constraints. For more information about the differences between DHCP
for IPv6 and DHCP for IPv4, see Appendix A.
This document is organized as follows. Section 2 defines terminology
used throughout this document. Section 3 defines constant values
used by DHCP. Section 4 briefly discusses requirement levels.
Section 5 points the reader to helpful background specifications
covering related IPv6 protocols. Section 6 discusses the design
goals that influenced DHCP. Section 7 identifies some of the
non-goals of this specification. Section 8 gives a high level
overview of DHCP, its message types, and identifies DHCP functional
entities (client, relay, server). Section 9 describes in detail the
format of each DHCP message type. Section 10 discusses DHCP server
solicitation and subnet prefix discovery. Section 11 discusses DHCP
client-initiated configuration information exchange. Section 12
discusses DHCP server-initiated configuration information exchange.
Section 13 describes how DHCP can be used to renumber networks.
Section 14 presents helpful notes for DHCP client implementators.
Section 15 presents helpful notes for DHCP server implementors.
Section 16 presents helpful notes for DHCP relay implementors.
Section 18 discusses security considerations for DHCP.
2. Terminology
2.1. IPv6 Terminology 2.1. IPv6 Terminology
IPv6 terminology relevant to this specification from the IPv6
Protocol [6], IPv6 Addressing Architecture [8], and IPv6 Stateless
Address Autoconfiguration [15] is included below.
address An IP layer identifier for an interface or a set of address An IP layer identifier for an interface or a set of
interfaces. interfaces.
unicast address unicast address
An identifier for a single interface. A packet sent An identifier for a single interface. A packet sent
to a unicast address is delivered to the interface to a unicast address is delivered to the interface
identified by that address. identified by that address.
multicast address multicast address
An identifier for a set of interfaces (typically An identifier for a set of interfaces (typically
skipping to change at page 2, line 40 skipping to change at page 2, line 42
IPv6 are used only in contexts where it is necessary to IPv6 are used only in contexts where it is necessary to
avoid ambiguity. avoid ambiguity.
interface interface
A node's attachment to a link. A node's attachment to a link.
link A communication facility or medium over which nodes link A communication facility or medium over which nodes
can communicate at the link layer, i.e., the layer can communicate at the link layer, i.e., the layer
immediately below IP. Examples are Ethernet (simple or immediately below IP. Examples are Ethernet (simple or
bridged); Token Ring; PPP links, X.25, Frame Relay, or bridged); Token Ring; PPP links, X.25, Frame Relay, or
ATM networks; and internet (or higher) layer "tunnels", ATM networks; and Internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself. such as tunnels over IPv4 or IPv6 itself.
link-layer identifier link-layer identifier
a link-layer identifier for an interface. Examples a link-layer identifier for an interface. Examples
include IEEE 802 addresses for Ethernet or Token Ring include IEEE 802 addresses for Ethernet or Token Ring
network interfaces, and E.164 addresses for ISDN links. network interfaces, and E.164 addresses for ISDN links.
link-local address link-local address
An IP address having link-only scope, indicated by An IP address having link-only scope, indicated by
having the routing prefix (FE80::0000/64), that can be having the subnet prefix (FE80::0000/64), that can be
used to reach neighboring nodes attached to the same used to reach neighboring nodes attached to the same
link. Every interface has a link-local address. link. Every interface has a link-local address.
message A unit of data carried in a packet, exchanged between message A unit of data carried in a packet, exchanged between
DHCP agents and clients. DHCP agents and clients.
neighbor A node attached to the same link. neighbor A node attached to the same link.
node A device that implements IP. node A device that implements IP.
packet An IP header plus payload. packet An IP header plus payload.
prefix A bit string that consists of some number of initial prefix A bit string that consists of some number of initial
bits of an address. bits of an address.
router A node that forwards IP packets not explicitly router A node that forwards IP packets not explicitly
addressed to itself. addressed to itself.
2.2. DHCP Terminology
2.2. DHCPv6 Terminology Terminology specific to DHCP can be found below.
abort status
A status value returned to the application that has
invoked a DHCP client operation, indicating anything
other than success.
agent address agent address
The address of a neighboring DHCP Agent on the same The address of a neighboring DHCP Agent on the same
link as the DHCP client. link as the DHCP client.
binding A binding (or, client binding) containing the data binding A binding (or, client binding) is a group of server
which a DHCP server maintains for each of its clients data records indexed by <client's link-local address,
(see Section 6). subnet prefix> containing the releasable resource data
which a DHCP server has assigned to a client.
resource-server association Note that the transaction-ID from the Request message
An association between a resource and a DHCP server, that produced the assignment of the releasable resource
maintained by the client which received that resource is also stored in the server data record including the
from that DHCP server. releasable resource identifier.
DHCP Dynamic Host Configuration Protocol for IPv6. The
terms DHCPv4 and DHCPv6 are used only in contexts where
it is necessary to avoid ambiguity.
configuration parameter configuration parameter
Any parameter that can be used by a node to configure An element of the configuration information set on the
its network subsystem and enable communication on a server and delivered to the client using DHCP. Such
link or internetwork. parameters may be used to carry information to be used
by a node to configure its network subsystem and enable
communication on a link or internetwork, for example.
DHCP client (or client) DHCP client (or client)
A node that initiates requests on a link to obtain A node that initiates requests on a link to obtain
configuration parameters. configuration parameters from one or more DHCP servers.
DHCP domain
A chunk of network topology managed by DHCP and
operated by a single administrative entity.
DHCP server (or server) DHCP server (or server)
A server is a node that responds to requests from A server is a node that responds to requests from
clients, and may or may not be on the same link as as clients, and may or may not be on the same link as the
the client. client(s).
DHCP relay (or relay) DHCP relay (or relay)
A node that acts as an intermediary to deliver DHCP A node that acts as an intermediary to deliver DHCP
messages between clients and servers, and is on the messages between clients and servers, and is on the
same link as a client. same link as a client.
DHCP agent (or agent) DHCP agent (or agent)
Either a DHCP server on the same link as a client, or a Either a DHCP server on the same link as a client, or a
DHCP relay. DHCP relay.
Releasable resource
Any configuration resource allocated by a server for
a finite period of time. As of this writing, the
only example of such a resource is the IP address.
Releasable resources are carried in extensions
allocated out of the 1--8192 range.
solicit-ID
An unsigned integer generated by the client and
inserted into its DHCP Solicit messages, and echoed
back to the client by the server in its resultant DHCP
Advertise message(s). The client uses the solicit-ID
to match received Advertise messages to Solicit
messages it has generated.
transaction-ID transaction-ID
An unsigned integer to match responses with replies An unsigned integer to match responses with replies
initiated either by a client or server. Clients MUST initiated either by a client or server. Servers
use integers from 1 to 1000, and servers use integers allocate their transaction-IDs from the range of
greater than 1000 for transaction-ID's. 0--1023, and clients allocate their transaction-IDs
from the range of 1024--65535. Limiting clients and
servers to different ranges prevents transaction-ID
collisions (e.g. client and server happen to use the
same transaction-ID for unrelated transactions (e.g.
client Request, server Reconfigure-init).
3. DHCP Constants
2.3. Specification Language This section describes various program and networking constants used
by DHCP.
3.1. Multicast Addresses
In this document, the words MUST, MUST NOT, SHOULD, SHOULD NOT, and The DHCP makes use of the following multicast addresses:
MAY are used to signify the requirements of the specification, in
accordance with RFC 2119 [2].
2.4. Error Values All DHCP Agents address: FF02::1:2
This link-local multicast address is used by clients to
communicate with the on-link agent(s) when they do not
know those agents' link-local address(es). All agents
(servers and relays) are members of this multicast
group.
This specification document uses symbolic names for the errors known All DHCP Servers address: FF05::1:3
to DHCP clients and servers, as used for instance in the status field This site-local multicast address is used by clients or
of the DHCP Reply message (see section 4.4). The symbolic names have relays to communicate with server(s), either because
the actual values listed below: they want to send messages to all servers or because
they do not know the server(s) unicast address(es).
Note that in order for a client to use this address,
it must have an address of sufficient scope to be
reachable by the server(s). All servers within the
site are members of this multicast group.
3.2. UDP ports
Error Name ErrorID The DHCP uses the following destination UDP [14] port numbers. While
================================ source ports MAY be arbitrary, client implementations SHOULD permit
PoorlyFormed 18 their specification through a local configuration parameter to
Unavail 19 facilitate the use of DHCP through firewalls.
NoBinding 20
InvalidSource 21
NoServer 23
ICMPError 64
3. Protocol Design Model 546 Client port. Used by agents to send messages to
clients. Also used by servers to send messages to
relays.
This section is provided for implementors to understand the DHCPv6 547 Agent port. Used by clients to send messages to
protocol design model from an architectural perspective. Goals and agents. Also used by relays to send messages to
conceptual models are presented in this section. servers.
3.3. DHCP message types
3.1. Design Goals The DHCP defines the following message types. More detail on these
message types can be found in Section 9. Message types 0 and 9--255
are reserved and MUST be silently ignored.
The following list gives general design goals for this DHCP 01 DHCP Solicit
specification.
- DHCP should be a mechanism rather than a policy. DHCP must allow The DHCP Solicit (or Solicit) message is used by clients to
local system administrators control over configuration parameters locate servers and (optionally) learn about the subnet prefixes
where desired; e.g., local system administrators should be able on the client's link for networks that are managed by DHCP.
to enforce local policies concerning allocation and access to This message is multicast using the All-DHCP-Agents address.
local resources where desired. Relay(s) forward Solicits as necessary to off-link servers.
- DHCP must not require manual configuration of DHCP clients, Section 9.1 contains more details about the Solicit message.
except as dictated by security requirements. Each node should be
able to obtain appropriate local configuration parameters without
user intervention.
- DHCP must not require a server on each link. To allow for scale 02 DHCP Advertise
and economy, DHCP must work across DHCP relays.
- In some installations, clients on certain subnets can be served The DHCP Advertise (or Advertise) message is used by servers
by more than one DHCP server, improving reliability and/or responding to Solicits. This message is unicast to the
performance. Therefore, a DHCP client must be prepared to client's link-local address (if the server and client are
receive multiple (possibly different) responses to a DHCP Solicit on the same link) or unicast to the relay through which the
Solicit was sent for final delivery to the client.
Section 9.2 contains more details about the Advertise message.
03 DHCP Request
The DHCP Request (or Request) message is used by clients to
request configuration parameters from servers. This message
is unicast to the server if the client has an address with
sufficient scope to be reachable by the server, otherwise it
is unicast to the on-link relay through which the Advertise
message was relayed.
Section 9.3 contains more details about the Request message.
04 DHCP Reply
The DHCP Reply (or Reply) message is used by servers responding
to Request and Release messages. In the case of responding to
a Request message, the Reply contains configuration parameters
destined for the client. This message is unicast to the client
if the client has an address of sufficient scope that is
reachable by the server. Otherwise, it is unicast to the relay
through which the Request or Release message was sent for final
delivery to the client.
Section 9.4 contains more details about the Reply message.
05 DHCP Release
The DHCP Release (or Release) message is used by clients to
return one or more instances of releasable resources (e.g. IP
addresses) to servers. This message is unicast to the server
if the client will have an address of sufficient scope after
the Release operation to receive a Reply message. Otherwise,
the Release message is sent through the relay. The server will
acknowledge the receipt of the Release message by sending the
client a Reply message.
Section 9.5 contains more details about the Release message.
06 DHCP Reconfigure
The DHCP Reconfigure (or Reconfigure) message is sent by
servers to client(s). It contains new or updated configuration
parameters for use by the client(s). This message may be
unicast or multicast to the client(s).
Section 9.6 contains more details about the Reconfigure
message. message.
- DHCP must coexist with statically configured, non-participating 07 DHCP Reconfigure-reply
nodes and with existing network protocol implementations.
- DHCPv6 must be compatible with IPv6 Stateless Address The DHCP Reconfigure-reply (or Reconfigure-reply) message is
Autoconfiguration [20]. unicast by client(s) to the server to acknowledge the receipt
of a Reconfigure message.
- A DHCPv6 Client implementation may be started in the absence of Section 9.7 contains more details about the Reconfigure-reply
any IPv6 routers on the client's link. message.
- DHCP architecture must support automated renumbering of IP 08 DHCP Reconfigure-init
addresses [3].
- DHCP servers should be able to support Dynamic Updates to The DHCP Reconfigure-init (or Reconfigure-init) message is set
DNS [22]. by server(s) to inform client(s) that the server(s) has new or
updated configuration parameters, and that the client(s) are
to initiate a Request/Reply transaction with the server(s) in
order to receive the updated information.
- DHCP servers must be able to support multiple IPv6 addresses for Section 9.8 contains more details about the Reconfigure-init
each client. message.
On the other hand, a DHCP server to server protocol is NOT part of 3.4. Error Values
this specification. Furthermore, it is NOT a design goal of DHCP to
specify how a server configuration parameter database is maintained
or determined. Methods for configuring DHCP servers are outside the
scope of this document.
3.2. DHCP Messages This section describes error values exchanged between DHCP
implementations.
3.4.1. Generic Error Values
Each DHCP message contains a type, which defines its function within The following symbolic names are used between client and server
the protocol. Formats for the messages are found in section 4, with implementations to convey error conditions. The following table
an initial description and discussion. Processing details for these contains the actual numeric values for each name. Note that the
DHCP messages are specified in Sections 5, 6, and 7. The message numeric values do not start at 1, nor are they consecutive. The
types are as follows: errors are organized in logical groups.
01 DHCP Solicit _______________________________________________________________
|_Error_Name___|Error_ID_|Description__________________________|
|_Success______|00_______|Success______________________________|
|_UnspecFail___|16_______|Failure,_reason_unspecified__________|
|_AuthFailed___|17_______|Authentication_failed_or_nonexistent_|
|_PoorlyFormed_|18_______|Poorly_formed_message________________|
|_Unavail______|19_______|Resources_unavailable________________|
The DHCP Solicit message is an IP multicast message sent by a 3.4.2. Server-specific Error Values
client to one or more agents, or forwarded by a relay to one or
more servers.
02 DHCP Advertise The following symbolic names are used by server implementations to
convey error conditions to clients. The following table contains the
actual numeric values for each name.
_______________________________________________________________
|_Error_Name____|Error_ID_|Description_________________________|
|_NoBinding_____|20_______|Client_record_(binding)_unavailable_|
|_InvalidSource_|21_______|Invalid_Client_IP_address___________|
|_NoServer______|23_______|Relay_cannot_find_Server_Address____|
|_ICMPError_____|64_______|Server_unreachable_(ICMP_error)_____|
The DHCP Advertise is an IP unicast message sent by a DHCP 3.5. Configuration Variables
Agent in response to a client's DHCP Solicit message.
03 DHCP Request This section presents a table of client and server configuration
variables and the default or initial values for these variables. The
client-specific variables MAY be configured on the server and MAY be
delivered to the client through the ``DHCP Retransmission Parameter
Extension''carried in a Reply message. This extension is documented
in the ``extensions document'' [2].
The DHCP Request is an IP unicast message sent by a client to a ______________________________________________________________
server to request configuration parameters on a network. |_Parameter__________|Default_|Description____________________|
|_MIN_SOL_DELAY______|1_______|MIN_(secs)_to_delay_1st_mesg___|
|_MAX_SOL_DELAY______|5_______|MAX_(secs)_to_delay_1st_mesg___|
|_ADV_MSG_TIMEOUT____|500_____|SOL_Retrans_timer_(msecs)______|
|_ADV_MSG_MAX________|30______|MAX_timer_value_(secs)_________|
|_SOL_MAX_ATTEMPTS___|-1______|MAX_attempts_(-1_=_infinite)___|
|_REP_MSG_TIMEOUT____|250_____|REQ_Retrans_timer_(msecs)______|
|_REQ_MSG_ATTEMPTS___|10______|MAX_Request_attempts___________|
|_REL_MSG_ATTEMPTS___|5_______|MAX_Release_attempts___________|
|_RECREP_MSG_TIMEOUT_|2000____|Retrans_timer_(msecs)__________|
|_REC_MSG_ATTEMPTS___|10______|Reconfigure_attempts___________|
|_REC_REP_MIN________|5_______|Minimum_pause_interval_(secs)__|
|_REC_REP_MAX________|7200____|Maximum_pause_interval_(secs)__|
|_REC_THRESHOLD______|100_____|%_of_required_clients__________|
|_SRVR_PREF_WAIT_____|2_______|Advertise_Collect_timer_(secs)_|
04 DHCP Reply 4. Requirements
The DHCP Reply is an IP unicast message sent by a server in The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
response to a client's DHCP Request, or by the relay that SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
relayed that client's DHCP Request. Extensions [15] to the document, are to be interpreted as described in [3].
DHCP Reply describe the resources that the server has committed
and allocated to this client, and may contain other information
for use by this client.
05 DHCP Release This document also makes use of internal conceptual variables
to describe protocol behavior and external variables that an
implementation must allow system administrators to change. The
specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demostrate
protocol behavior. An implementation is not required to have them in
the exact form described here, so long as its external behavior is
consistent with that described in this document.
5. Background
The DHCP Release is an IP unicast message sent by a client to Related work in IPv6 that would best serve an implementor to study
inform the server that the client is releasing resources. is the IPv6 Specification [6], the IPv6 Addressing Architecture [8],
IPv6 Stateless Address Autoconfiguration [15], IPv6 Neighbor
Discovery Processing [12], and Dynamic Updates to DNS [17]. These
specifications enable DHCP to build upon the IPv6 work to provide
both robust stateful autoconfiguration and autoregistration of DNS
Host Names.
06 DHCP Reconfigure The IPv6 Specification provides the base architecture and design of
IPv6. A key point for DHCP implementors to understand is that IPv6
requires that every link in the Internet have an MTU of 1280 octets
or greater (in IPv4 the requirement is 68 octets). This means that
a UDP packet of 536 octets will always pass through an internetwork
(less 40 octets for the IPv6 header), as long as there are no IP
options prior to the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a
packet greater than 1500 octets it can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [10]
to determine the size of the packet that will traverse a network
path.
The DHCP Reconfigure is an IP unicast or multicast message sent DHCP clients use Path MTU discovery when they have an address of
by a server to inform one or more clients that the server has sufficient scope to reach the DHCP server. If a DHCP client does not
new configuration information of importance to the client. have such an address, that client MUST fragment its packets if the
Each client is expected to initiate a new DHCP Request in resultant message size is greater than the minimum 1280 octets.
response to the Reconfiure message.
DHCP message types not defined here (msg-types 0 and 7-255) are Path MTU Discovery for IPv6 is supported for both UDP and TCP and
reserved and SHOULD be silently ignored. can cause end-to-end fragmentation when the PMTU changes for a
destination.
3.3. Request/Response Processing Model The IPv6 Addressing Architecture specification [8] defines the
address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin
communications to discover neighbors on the link. For instance, a
client can send a Solicit message and locate a server or relay.
The request/response processing for DHCPv6 is transaction based and IPv6 Stateless Address Autoconfiguration [15] (Addrconf) specifies
uses a set of best-effort messages to complete the transaction. procedures by which a node may autoconfigure addresses based on
router advertisements [12], and the use of a valid lifetime to
support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. The DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with addrconf is a design
requirement of DHCP (see Section 6).
To find a server, a client sends a DHCP Solicit from the interface IPv6 Neighbor Discovery [12] is the node discovery protocol in IPv6
which it wishes to configure. The client then awaits a DHCP which replaces and enhances functions of ARP [13]. To understand
Advertise message containing an IP address of a DHCP server. IPv6 and Addrconf it is strongly recommended that implementors
Transactions are started by a client with a DHCP Request, which may understand IPv6 Neighbor Discovery.
be issued after the client knows the server's address. The server
then unicasts a DHCP Reply, possibly via a relay. At this point in
the flow all data has been transmitted and is presumed to have been
received. To provide a method of recovery if either the client or
server does not receive its messages, the client retransmits each
DHCP Request message until it elicits the corresponding DHCP Reply,
or until it can be reasonably certain that the desired DHCP server
is unavailable, or it determines that it does not want a response
(i.e., it MAY abort the transaction). The timeout and retransmission
guidelines and configuration variables are discussed in Section 8.
DHCP uses UDP [17] to communicate between clients and servers. UDP Dynamic Updates to DNS [17] is a specification that supports the
is not reliable, but the DHCP retransmission scheme just described dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
provides reliability between clients and servers. The following the dynamic updates to DNS to integrate addresses and name space
well-known multicast addresses are used by DHCP agents and clients: to not only support autoconfiguration, but also autoregistration
in IPv6. The security model to be used with DHCPv6 should conform
as closely as possible to the authentication model outlined in
RFC2402 [9].
FF02:0:0:0:0:0:1:2 6. Design Goals
All DHCP Agents (servers and relays) MUST join the
link-local All-DHCP-Agents multicast group at the address
FF02:0:0:0:0:0:1:2.
FF05:0:0:0:0:0:1:3 - DHCP is a mechanism rather than a policy. Network administrators
All DHCP servers MUST join the site-local set their administrative policies through the configuration
All-DHCP-Servers multicast group at the address parameters they place upon the DHCP servers in the DHCP domain
FF05:0:0:0:0:0:1:3. they're managing. DHCP is simply used to deliver parameters
according to that policy to each of the DHCP clients within the
domain.
FF05:0:0:0:0:0:1:4 - DHCP is compatible with IPv6 stateless autoconf [15].
All DHCP relays MUST join the site-local All-DHCP-Relays
multicast group at the address FF05:0:0:0:0:0:1:4.
A DHCP server or agent MUST transmit all messages to DHCP clients on - DHCP does not require manual configuration of network parameters
UDP port 546. A DHCP client MUST transmit all messages to a DHCP on DHCP clients, except in cases where such configuration is
agent over UDP using port 547. A DHCP server MUST transmit all needed for security reasons. A node configuring itself using
messages to DHCP relays over UDP on port 546. The source port for DHCP should require no user intervention.
DHCP messages is arbitrary.
For the proper operation of the DHCP protocol to operate within a - DHCP does not require a server on each link. To allow for scale
network where one or more firewallsare used, DHCP transactions sent and economy, DHCP must work across DHCP relays.
to the IP addresses of DHCP servers at UDP destination ports 546 and
547 will need to be permitted.
4. DHCP Message Formats and Field Definitions - DHCP coexists with statically configured, non-participating nodes
and with existing network protocol implementations.
- DHCP clients can operate on a link without IPv6 routers present.
- DHCP will provide the ability to renumber network(s) when
required by network administrators [4].
- A DHCP client can make multiple, different requests for
configuration parameters when necessary from one or more DHCP
servers at any time. DHCP will provide enough information
to enable a DHCP server to keep track of a DHCP client's
configuration state.
- DHCP will contain the appropriate time out and retransmission
mechanisms to efficiently operate in environments with high
latency and low bandwidth characteristics.
7. Non-Goals
This specification explicitly does not cover the following:
- Specification of a DHCP server to server protocol.
- How a DHCP server stores its DHCP data.
- How to manage a DHCP domain or DHCP server.
- How a DHCP relay is configured or what sort of information it may
log.
8. Overview
This section provides a general overview of the interaction
between the functional entities of DHCP. The overview is organized
as a series of questions and answers. Details of DHCP such
as message formats and retransmissions are left to sections 9,
10, 11, 12, 14, 15, and 16.
8.1. How does a node know to use DHCP?
An unconfigured node determines that it is to use DHCP for
configuration of an interface by detecting the presence (or absence)
of routers on the link. If router(s) are present, the node examines
router advertisements to determine if DHCP should be used to
configure the interface. If there are no routers present, then
the node MUST use DHCP to configure the interface. Detail on
this process can be found in neighbor discovery [12] and stateless
autoconfiguration [15].
8.2. How does a client find out about DHCP agents?
The client forms a Solicit message, and multicasts it to the
FF02::1:2(All DHCP Agents) address. Server(s) receiving the Solicit
respond with Advertise message(s). If requested in the client's
Solicit message, the Advertise message(s) can include one or more
subnet prefix extensions [2], informing the client of subnet prefixes
for the networks(s) managed by the server(s) on the client's link.
Now that the client knows the IP address(es) of agents(s) on the
link, it can request configuration parameters from servers.
8.3. What if the client and server(s) are on different links?
Use of DHCP in such environments requires one or more DHCP relays
be set up on the client's link, because a client may only have a
link-local address. Relays pick up the Solicit and Request messages
from the client and forward them to some set of servers within the
DHCP domain. A relay will include one of its own addresses (of
sufficient scope) of the interface on the same link as the client.
The relay also includes the subnet prefix length of that address
in the client's messages. Servers receiving the forwarded traffic
use this information to aid in selecting configuration parameters
appropriate to the client's link. The servers also use the relay's
address as the destination to forward client-destined messages
for final delivery by the relay. Relays forward client messages
to servers using some combination of the FF05::1:3(All Servers)
site-local multicast address, some other (perhaps a combination)
of site-local multicast addresses set up within the DHCP domain to
include the servers in that domain, or a list of unicast addresses
for servers. The network administrator makes relay configuration
decisions based upon the topological requirements (scope) of the
DHCP domain they are managing. Note that if the DHCP domain spans
more than the site-local scope, then the relays MUST be configured
with global addresses for the client's link so as to be reachable by
servers outside the relays' site-local environment.
8.4. How does a client request configuration parameters from servers?
To request configuration parameters, the client forms a Request
message, and sends it to the server either directly (client has an
address of sufficient scope) or indirectly (through the on-link
relay). The client MAY include a Extension Request Extension [2]
along with other extensions to request specific information from the
server. Note that the client MAY form multiple Request messages
and send each of them to different servers to request potentially
different information (perhaps based upon what was advertised) in
order to satisfy its needs. As a client's needs may change over time
(perhaps based upon an application's requirements), the client may
form additional Request messages to request additional information as
it is needed.
The server(s) respond with Reply messages containing the requested
configuration parameters, which can include status information
regarding the information requested by the client. The Reply MAY
also include additional information, such as a reconfiguration event
multicast group for the client to join to monitor reconfiguration
events, as described in section 8.8.
The receipt of a Reply from a server concludes the basic
request/reply transaction of the protocol.
8.5. What are releasable resources, and when are they used?
A releasable resource is configuration information leased to a client
by a server for some finite period of time. When negotiating for a
releasable resource, the client and server agree upon a finite period
of time the client may use the resource. The client MAY request a
renewal of the lease on the resource at any time. The length of time
of the lease (and whether it is renewable) are server-based policy
tunables. The client MUST stop using the resource when the lease on
the resource expires. The server MUST NOT reallocate an assigned
resource before either its lease expires or the client releases the
resource.
See the ``extensions document'' [2] for more information about
releasable resources.
8.6. Can a client release its releasable resources before the lease
expires?
A client forms a Release message, including extensions carrying the
resource(s) to be released. The client sends the Release to the
server which leased the resource(s) to the client initially. If that
server cannot be reached after a certain number of attempts (see
section 3.5), the client can abandon the Release attempt. In this
case, the resource(s) will be reclaimed by the server(s) when the
client's lease(s) expire.
8.7. What if the client determines its releasable resource is already
being used by another client?
If the client determines through a releasable resource-specific
manner that the resource it was assigned by the server is already
in use by another client, the client will form a Release message,
including the extension carrying the in-use resource. The
extension's status field MUST be set to the extension-specific value
reflecting the ``in use'' status of the resource.
For example, if the releasable resource is an IP address, the client
uses Duplicate Address Detection (DAD) to verify that the IP address
is not in use. If the client determines that the IP address is
already in use, it forms a Release message including the IP address
extension containing the appropriate status value and sends it to the
server. See the ``extensions document''for details on the IP address
extension. [2].
8.8. How are clients notified of server configuration changes?
There are two possibilities. Either the clients discover the new
information when they revisit the server(s) to request additional
configuration information / renew the lease on a releasable resource,
or through a server-initiated event known as a reconfigure event.
The reconfiguration feature of DHCP offers network administrators
the opportunity to update configuration information on DHCP clients
whenever necessary. If the information to be updated is not
client-specific, the server will form a Reconfigure message and add
the new or changed configuration information to it. The Reconfigure
may be unicast or multicast (to a preassigned multicast address for
this purpose) to one or more client(s) to which the new or updated
information needs to be directed. The client(s) will acknowledge the
receipt of the Reconfigure message by forming a Reconfigure-reply
message and unicasting it to the server. If the configuration
information change is different for each client (e.g. a change in
subnet prefix, perhaps, which would affect the IP address releasable
resource(s)), the server will form a Reconfigure-init message and
unicast / multicast as needed to the client(s). A Reconfigure-init
is a trigger which will cause the client(s) to initiate a standard
Request/Reply exchange with the server in order to acquire the new or
updated resources.
9. Message Formats
All reserved fields in a message MUST be transmitted as zeroes and All reserved fields in a message MUST be transmitted as zeroes and
ignored by the receiver of the message. ignored by the receiver of the message.
9.1. DHCP Solicit Message Format
4.1. DHCP Solicit Message Format A client multicasts a DHCP Solicit message to the FF02::1:2(All DHCP
agents) address over the interface to be configured to locate one or
more servers which are configured to provide configuration parameters
to nodes on the client's link.
A client transmits a DHCP Solicit message over the interface to be Unless otherwise noted, the value of all fields are set by the
configured, to obtain one or more server addresses. Unless otherwise client.
noted, the value of all fields are set by the client.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 1 |C| reserved | prefix-size | | msg-type = 1 |C|P| reserved | prefix-len | solicit-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay-address | | relay-address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| saved agent-address |
| (if present, 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C If set, the client requests that all servers receiving C If set, the client requests that all servers receiving
the message deallocate the resources associated with the message deallocate the releasable resources (e.g.
the client. If set, the client SHOULD provide a saved IP addresses) associated with the client's binding.
agent-address to locate the clients binding by a
server.
prefix-size A nonzero prefix-size is the number of leftmost bits P If set, the client requests that all servers receiving
of the agent's IPv6 address which make up the routing the message SHOULD return a list of subnet prefix
prefix. The prefix-size field is set by the DHCP relay extensions identifying the networks on the client's
if the relay receives the solicitation and forwards it link that the server(s) are configured to manage.
to one or more DHCP Servers.
reserved 0 reserved 0
prefix-len
An unsigned 7 bit number (0-127) non-zero prefix-len is
the number of leftmost bits of the agent's IPv6 address
which make up the subnet prefix. The prefix-len field
is set by the relay if the relay receives the Solicit
message and forwards it to one or more servers.
solicit-ID
An unsigned 9 bit number (0-511) generated by the
client used to identify this Solicit message.
client's link-local address client's link-local address
The IP link-local address of the client interface from The IP link-local address of the client interface
which the client issued the DHCP Request message through which the client will issue the Solicit
message.
relay-address relay-address
Set by the client to be zero. If received by a DHCP Set by the client to be zero. If received by a relay,
relay, set by the relay to the IP address of the set by the relay to the site-local IP address of the
interface on which the relay received the client's DHCP interface on which the relay received the client's
Solicit message Solicit message. Note that if the DHCP domain crosses
site boundaries, the relay MUST place a globally-scoped
saved agent-address address in this field.
If present, the IP address of an agent's interface
retained by the client from a previous DHCP
transaction.
A client SHOULD send a DHCP Solicit message to the All-DHCP-Agents A client MUST send the Solicit message to the All-DHCP-Agents
multicast group (see section 3.3), setting the relay-address to multicast group (see section 3.1), setting the relay-address to zero.
zero. Any relay receiving the solicitation MUST forward it to the 9.2. DHCP Advertise Message Format
All-DHCP-Servers multicast group. In that case, the relay MUST copy
a non-link-local address of its interface from which the client's
solicitation was received into the relay-address field. Servers
receiving the solicitation then send their advertisements to the
prospective client.
4.2. DHCP Advertise Message Format A server sends an Advertise message in response to a client's
Solicit message. The Advertise message notifies the client of the
server's IP address. If the server is so configured by the network
administrator and the client requests it through the ``P'' bit in
its Solicit message, the server SHOULD add a list of subnet prefix
extensions to the Advertise message to notify the client of the
networks it manages on the client's link.
A DHCP agent sends a DHCP Advertise message to inform a prospective When the client and server are on different links, the server sends
client about the IP address of a server to which a DHCP Request the Advertise message back through the relay whence the corresponding
message may be sent. When the client and server are on different Solicit came. The solicit-ID is copied from the client's Solicit
links, the server sends the advertisement back through the relay Message. The value of all fields in the Advertise message are filled
whence the solicitation came. The value of all fields in the DHCP in by the server and not changed in any way by any intervening relay.
Adverstise message are filled in by the DHCP Server and not changed
by any DHCP Relay.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 2 |S| reserved | preference | | msg-type = 2 | reserved | solicit-ID | preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent-address | | relay-address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address | | server-address |
| (16 octets, if present) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ... | extensions (variable number and length) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0
S If set, the server-address is present. solicit-ID An unsigned 9 bit number (0-511) used to identify
this Advertise message. Copied from the client's
Solicit message.
reserved 0
preference An octet (unsigned) indicating a server's willingness preference An octet (unsigned) indicating a server's willingness
to provide service to the client (see Section 5.3). to provide service to the client.
client's link-local address client's link-local address
The IP link-local address of the client interface The IP link-local address of the client interface
from which the client issued the DHCP Request message from which the client issued the Solicit message.
agent-address relay-address
The IP address of a DHCP Agent interface on the same The IP address of the relay interface on the same
link as the client. link as the client. Copied from the client's
Solicit. If the server is on the same link as the
client, then this field MUST be zero.
server-address server-address
If present, the IP address of the DHCP server The site-local IP address of the server. If the DHCP
domain crosses site boundaries, then this address
MUST be globally-scoped.
extensions See [15]. extensions See the ``extensions document'' for details [2].
Suppose that a server on the same link as a client issues the See Sections 14.4 and 15.3 for information about how clients and
DHCP Advertise in response to a DHCP Solicit message sent to the servers handle the preference field.
All-DHCP-Agents multicast address. Then the agent-address will be an
IP address of one of the server's interfaces on the same link as the
client, and the `S' bit will be set to zero, indicating the absence
of the server-address in the DHCP Advertise message. See section 5.3
for information about how clients handle the preference field.
The server MUST copy the client's link-local address into the 9.3. DHCP Request Message Format
advertisement which is sent in response to a DHCP Solicit. Both
server-address (if present) and agent-address of the DHCP Advertise
message MUST have sufficient scope to be reachable by the client.
Moreover, the agent-address of any DHCP Advertise message sent by a
relay MUST NOT be a link-local address. In situations where there
are no routers sending Router Advertisements, then a DHCP server MUST
be configured on the same link as prospective clients. The DHCPv6
protocol design does not apply to situations where the client is
unable to route messages to a server not on the same link.
4.3. DHCP Request Message Format A client sends a Request message to request configuration parameters
from a server. It MAY append appropriate extensions [2].
In order to request configuration parameters from a server, a client When a client reboots, it often does not have a valid IP address of
sends a DHCP Request message, and MAY append extensions [15]. If sufficient scope for the server to communicate with the client. In
the client does not know any server address, it MUST first obtain such cases, the client MUST NOT unicast the message to the server
one by multicasting a DHCP Solicit message (see Section 4.1). because the server could not return a response to the client. The
Typically, when a client reboots, it does not have a valid IP address client MUST send the message to the server indirectly, by using the
of sufficient scope for the server to communicate with the client. on-link relay. The client MUST fill in the relay address field with
In such cases, the client MUST NOT send the message directly to the on-link relay's IP address.
the server because the server could not return any response to the
client; the client MUST send the message to the local relay and
insert the relay-address as the agent-address in the message header.
Otherwise, the client MAY omit the server-address in the DHCP Request If the Request message is being formed in response to a
message; in this case, the client MUST clear the S-bit and send the Reconfigure-init message from the server, then the transaction ID
message directly to the server, using the server's address as the IP used must be copied from the Reconfigure-init.
destination address in the IP header. In either case, all fields in
the DHCP Request message are entered by the client. All fields in the DHCP Request message are entered by the client.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 3 |C|S|R| rsvd | transaction-ID | | msg-type = 3 |C|R| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent-address | | relay-address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address | | server-address |
| (16 octets, if present) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C If set, the client requests the server to remove
all releasable resources associated with the client
binding, except those releasable resources provided as
extensions.
C If set, the client requests the server to remove all R If set, the client has rebooted and requests that the
resources associated with the client binding, except server clear any transaction-ID cache entries for the
those resources provided as extensions. client.
S If set, the server-address is present
R If set, the client has rebooted and requests that all
of its previous transaction-IDs be expunged and made
available for re-use.
rsvd 0
reserved 0
transaction-ID transaction-ID
A unsigned integer identifier used to identify this An unsigned integer identifier used to identify this
Request. request.
client's link-local address client's link-local address
The IP link-local address of the client interface from The link-local address of the client interface from
which the client issued the DHCP Request message which the client will issue the Request message.
agent-address relay-address
The IP address of an agent's interface, copied from a The IP address of a relay's interface, copied from an
DHCP Advertisement message. Advertise message. If the server is on the same link
as the client, then this field MUST BE zero.
server-address server-address
If present, the IP address of the server which should The IP address of the server to which the the client's
receive the client's DHCP Request message. Request message is directed, copied from an Advertise
message.
extensions See [15]. extensions
See the ``extensions document'' [2].
When the client sets the `C' bit and adds extensions, the server A DHCP client selects the transaction-ID from the range of
is expected to deallocate all other resources not listed in the 1024--65535 used to identify its Request. In contrast, a
extension. The resources explicitly requested in extensions to the transaction-ID from the range of 0--1023is selected by a DHCP server
Request message SHOULD be reallocated by the server to the client, to identify a Reconfigure-init. In the latter case, the transaction
assuming the client is still authorized to receive them. ID from the Reconfigure-init is copied by the client into its Request
message.
The transaction-ID is selected by the client to be greater than or When the client sets the `C' bit and adds extensions documenting
equal to 1024, unless the DHCP Request is sent in response to a the releasable resources the client wishes to keep, the server is
Reconfigure msg (see section 4.6). In that case, the transaction-ID expected to deallocate all other releasable resources not listed.
is copied from the transaction-ID in the Reconfigure message. The server SHOULD examine the included extensions to check whether
the client is still authorized to use them.
9.4. DHCP Reply Message Format
4.4. DHCP Reply Message Format A server sends a Reply message in response to a client's Request
message or Release message.
The server sends one DHCP Reply message in response to every DHCP If a Request message is received which contains a non-zero relay
Request or DHCP Release received. If the request comes with the `S' address field, then the client could not unicast the Request message
bit set, the client could not directly send the Request to the server to the server and thus had to use a on-link relay. In that case, the
and had to use a neighboring relay agent. In that case, the server server unicasts the Reply message to the relay address found in the
sends back the DHCP Reply with the `L' bit set, and the DHCP Reply Request message.
is addressed to the agent-address found in the DHCP Request message.
ALl the fields in the DHCP Reply message are set by the DHCP server. If a Release message is received which contains a non-zero relay
address field, then the client will not have an IP address of
sufficient scope after the Release to receive the Reply message. In
this case, the server unicasts the Reply message to the relay address
found in the Release message.
All the fields in the DHCP Reply message are set by the DHCP server.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 4 |L| status | transaction-ID | | msg-type = 4 |R| status | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets, if present) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | relay-address (if present) |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R If set, the ``relay-address'' field is present.
L If set, the client's link-local address is present status
status One of the following decimal values: This 7-bit field contains one of the values in the
errors table in section 3.4.
0 Success
16 Failure, reason unspecified
17 Authentication failed or nonexistent
18 Poorly formed Request or Release
19 Resources unavailable
20 Client record unavailable
21 Invalid client IP address in Release
23 Relay cannot find Server Address
64 Server unreachable (ICMP error)
transaction-ID transaction-ID
An unsigned integer identifier used to identify this Copied from the client's Request or Release.
Reply, and copied from the client's Request.
client's link-local address client's link-local address
If present, the IP address of the client interface Copied from the client's Request or Release message.
which issued the corresponding DHCP Request message.
relay-address
The IP address of a relay's interface, copied from the
Request or Release message. If the server is on the
same link as the client, then the ``R'' bit is not set
and this field is not present.
extensions extensions
See [15]. See the ``extensions document'' [2].
9.5. DHCP Release Message Format
If the `L' bit is set, the client's link-local address is present A client sends a Release message to a server when it wishes to return
in the Reply message. Then the Reply is sent by the server to the one or more releasable resources to the server which allocated
relay's address which was specified as the agent-address in the DHCP them. This can occur either because the client no longer needs the
Request message, and the relay uses the link-local address to deliver resource(s) or the client has determined through a resource-specific
the Reply message to the client. The transaction-ID in the DHCP manner that the resource(s) are already in use by different
Reply is copied by the server from the client Request message. client(s). The client communicates the reason for the premature
release of the resource in the status field of the resource's
extension. See ``extensions document'' [2] for more details.
4.5. DHCP Release Message Format When a client sends a Release message, it needs to have a valid IP
address with sufficient scope to allow access by the target server.
If such an address is not available, a relay is used. Only those
releasable resources identified by extensions are released. If no
extensions are included in the Release message, then all releasable
resources associated with the client's binding are to be released.
The DHCP Release message is sent without the assistance of any DHCP The values of all fields of the Release message are set by the
relay. When a client sends a Release message, it is assumed to client. The DHCP server acknowledges the Release message by sending
have a valid IP address with sufficient scope to allow access to a Reply message.
the target server. If parameters are specified in the extensions,
only those parameters are released. The values of all fields
of the DHCP Release message are entered by the Client. The DHCP
server acknowledges the Release message by sending a DHCP Reply
(Sections 4.4, 6.3).
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 1 |D| reserved | transaction-ID | | msg-type = 5 |R| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent-address | | server-address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-address | | X-address |
| (16 octets, if present) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R If set, the ``X-address'' field contains the address of
msg-type 5 relay. If not set, the ``X-address'' field contains a
non-local scope client address.
D If the `D' flag is set, the client instructs the server
to send the DHCP Reply directly back to the client,
instead of using the given agent-address and link-local
address to relay the Reply message.
reserved 0 reserved 0
transaction-ID transaction-ID
A unsigned integer identifier used to identify this An unsigned integer identifier used to identify this
Release, and copied into the Reply. Release message.
client's link-local address client's link-local address
The IP link-local address of the client interface from The client's link-local address for the interface
which the the client issued the DHCP Release message from which the client issued the Release message (and
to which the releasable resources are bound at the
server).
agent-address server-address
The IP address of the agent interface for the IP The IP address of the server which allocated the
address to be released. resource.
client-address X-address
The IP address of the client interface from which If the ``R'' bit is set, the ``X-address'' field
the the client issued the DHCP Release message. The contains the IP address of the relay interface on the
client-address field is present whenever the `D' bit is same link as the client. If the ``R'' bit is not set,
set, even if it is equal to the link-local address. this field contains a non-link-local IP address of the
client interface from which the the client issued the
Release message.
extensions See [15] extensions See the ``extensions document'' [2].
It is an error (status code ``InvalidSource'' (see Section 2.4)) to A client selects the transaction-ID from the range of
include within the DHCP Release message both the `D' bit and an IP 1024--65535 used to identify the Release message.
address extension which has the IP address used as the client-address
field of the DHCP Release message header.
4.6. DHCP Reconfigure Message Format A client MUST NOT specify an IP address in the client-address field
that it is releasing in the extensions field.
9.6. DHCP Reconfigure Message Format
DHCP Reconfigure messages can only be sent to clients which have A server sends a Reconfigure message when it wishes to inform one or
established an IP address which routes to the link at which they are more clients of new or updated values for configuration parameters.
reachable, hence the DHCP Reconfigure message is sent without the The new configuration parameters are carried in the extensions
assistance of any DHCP relay. When a server sends a Reconfigure portion of the Reconfigure message. Note that a Reconfigure message
message, the receivers are assumed to have a valid IP address with MUST NOT carry releasable resource extensions.
sufficient scope to be accessible by the server. Only the parameters
which are specified in the extensions to the Reconfigure message need Reconfigure messages can ONLY be sent to clients which have
be requested again by the client. A Reconfigure message can either established an IP address of sufficient scope as to be directly
be unicast or multicast by the server. The client will extract the reachable by the server.
extensions provided by the server and send a DHCP Request message to
the server using those extensions (see section 5.7). Clients acknowledge Reconfigure messages with Reconfigure-reply
messages.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 6 |N| reserved | transaction-ID | | msg-type = 6 | reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address | | server-address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0
transaction-ID
An unsigned integer identifier in the range of
0--1023 chosen by the server to identify this
Reconfigure message.
N The `N' flag indicates that the client should not server-address
expect a DHCP Reply in response to the DHCP Request The IP address of the DHCP server issuing the
it sends as a result of the DHCP Reconfigure message. Reconfigure message. MUST be of sufficient scope to be
reachable by all clients.
extensions
See the ``extensions document'' [2].
9.7. DHCP Reconfigure-reply Message Format
A client sends a Reconfigure-reply message to acknowledge receipt of
a Reconfigure message from a server.
A Reconfigure-reply message can only be sent if the client has an IP
address of sufficient scope to contact the server. No interaction
with a relay is possible.
All fields in the DHCP Reconfigure-reply message are entered by the
client.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 7 |r| status | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r reserved (0)
status
This 7-bit field contains one of the values from the
errors table in section 3.4.
transaction-ID
An unsigned integer identifier copied from the server's
Reconfigure message.
client's link-local address
The client's link-local address for the interface from
which the client issued the Reconfigure-reply message.
server-address
Copied from the Reconfigure message.
9.8. DHCP Reconfigure-init Message Format
A server sends a Reconfigure-init message when it wishes to notify
one or more clients of new or updated values for configuration
parameters available on the server.
Reconfigure-init messages can ONLY be sent to clients which have
established an IP address of sufficient scope as to be directly
reachable by the server.
A ``Reconfigure-init'' serves as a trigger which will cause the
clients to initiate a Request/Reply exchange with the server in order
to receive the new information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 8 | reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0 reserved 0
transaction-ID transaction-ID
A unsigned integer identifier used to identify this An unsigned integer identifier in the range of
Reconfigure, to by copied into the following DHCP 0--1023 chosen by the server to identify this
Request message that will be transmitted by the Reconfigure-init message.
client.
server-address server-address
The IP address of the DHCP server issuing the DHCP The IP address of the DHCP server issuing the
Reconfigure message. Reconfigure-init message. MUST be of sufficient scope
to be reachable by all clients.
extensions See [15] extensions SHOULD only include an ERE and/or authentication
extensions. No configuration information SHOULD be
included. See the ``extensions document'' [2] for more
information about extensions.
10. DHCP Server Solicitation and Subnet Prefix Discovery
5. DHCP Client Considerations This section describes how a client locates agents (relays and
servers) and how it can learn about the networks on its link that are
managed by these servers. The behavior of client, server, and relay
implementations is discussed, along with the messages they use.
10.1. Solicit Message Validation
A node which is not a DHCP agent MUST silently discard any DHCP Clients MUST silently discard any received Solicit messages.
Solicit, DHCP Request, or DHCP Release message it receives.
5.1. Verifying Resource Allocations After Restarts Agents MUST discard any received Solicit messages if the ``client's
link-local address'' field does not contain a valid link-local
address.
A client MAY retain its configured parameters and resources across Servers MUST discard each received Solicit message which meet the
client system reboots and program restarts. Any client wishing following criteria:
to use this feature MUST also maintain state for the address of
its DHCP agent address. When the client restarts, the client MUST
also formulate a DHCP Request message to verify that its configured
parameters and resources are still valid. This Request message MUST
have the `C' bit set, to clean up stale client binding information
at the server which may no longer be in use by the client; stale
information is that which the client does not include in extensions
to such request messages.
If the server does not respond to the DHCP Request message after o The ``relay-address'' field does not contain an address of
REQUEST_MSG_MIN_RETRANS (see section 8), the client may still sufficient scope that is reachable by the server.
use any resources whose lifetimes have not yet expired. In such
cases, however, the client MUST begin to search for another server
by multicasting a DHCP Solicit message with the `C' bit set (see
section 5.2). The client SHOULD log a DHCP System Error.
This also handles the case wherein a client restarts on a new o The ``relay-address'' field is non-zero, but prefix-len is zero.
network, where its IP address is no longer valid. In this situation,
when the client receives a new IP address and the old IP address
is no longer needed, the client MUST release its old IP address by
issuing a DHCP Release message with the appropriate extension if it
can communicate with its previous server.
A mobile client (that is not stationary on a network) SHOULD keep its An error message MAY be logged by the agent. The logging of
agent-address, and possibly the relevant server address, along with such messages SHOULD be controlled by an agent implementation
all resource-server associations [15] on non-volatile storage. This configuration flag.
will allow the client to release resources with the DHCP Solicit or 10.2. Advertise Message Validation
Release messages if it enters a different network location before
releasing its resources.
5.2. Sending DHCP Solicit Messages Servers MUST silently discard any received Advertise messages.
A client MUST have the address of a server to send a Request message. Clients MUST discard any Advertise messages that meet any of the
The client SHOULD locate a DHCP server by multicasting a DHCP Solicit following criteria:
message to the All-DHCP-Agents link-local multicast address (see
Section 3.3), setting the Hop Limit == 1. If there are no DHCP
servers on the same link as the node, then a DHCP relay MUST be
present if solicitations sent from a client's link-local address are
to be handled.
When sending a DHCP Solicit message, a client MUST set the Relay o The ``Solicit-ID'' field value does not match the value the
Address field to 16 octets of zeros, and zero the prefix-size field. client used in its Solicit message.
If a client reboots and does not have a valid IP address, it SHOULD o The ``client's link-local address'' field value does not match
set the `C' bit in the DHCP Solicit message it sends when restarting. the link-local address of the interface upon which the client
By setting the `C' bit in the solicitation, a client requests that sent the Solicit message.
all the DHCP servers that receive the solicitation should clean up
their client records that match its link-local address.
If a client sends a DHCP Solicit message after it reboots, the Relays MUST discard any Advertise messages that meet any of the
solicitation SHOULD be delayed after reception of the first Router following criteria:
Advertisement [14] message (see section 5.8), by at least some random
amount of time between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see
section 8). This delay is intended to help stagger requests to
DHCP servers (and avoid link-layer collisions) after a power outage
causes many nodes to reboot all at once. Each subsequent DHCP
Solicit message that is issued before receiving an advertisement
MUST be delayed by twice the amount by which the previous DHCP
Solicit message was delayed, plus a small random delay between
MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds.
5.3. Receiving DHCP Advertise Messages o The ``relay-address'' field does not contain the relay's address
on the same link as the client.
After a client has received a DHCP Advertise message, it has the o The ``client's link-local address'' field does not contain a
address of a server for subsequent DHCP Request messages. If the `S' valid link-local address.
bit is zero, the DHCP Advertise message was transmitted by a server 10.3. Client Behavior
on the same link as the client, and the client uses the agent-address
as the server's address; otherwise, the server's IP address is
located in the server-address field. If the server-address is a
multicast address, the advertisement MUST be silently discarded.
A server MAY append extensions to its advertisements; this might Clients use the Solicit message primarily to discover DHCP servers
allow the client to select the configuration that best meets its configured to serve networks on the link containing the client.
needs from among several prospective servers. Optionally, the client MAY set the ``P'' bit which has the effect
of requesting that the server return subnet prefix extensions
identifying the networks on the client's link the server is
configured to manage.
10.3.1. Creation and sending of the Solicit message
Unless a DHCP Advertisement is received with a preference equal When creating a Solicit message, the client SHOULD start out with
to 255 (see Section 4.2), the client MUST wait CLIENT_ADV_WAIT a buffer initialized with zeroed octets. The client sets the
seconds after issuing the DHCP Solicit message in order to receive ``msg-type'' field to 1, and places the link-local address of the
the Advertisement with the highest preference. After waiting for interface it wishes to configure in the link-local address field.
that period of time, a client MUST select the highest preference
server as the target of its DHCP request. If a client receives an
advertisement with a preference of 255, it does not have to wait for
any more advertisements.
If a client sends a DHCP Request to a highly preferred server but If the client is prepared to process multiple Advertise messages
fails to receive a DHCP reply from that server after following the in response to its Solicit message, the client will set the
retransmission algorithm in section 8, the client MUST then try to Solicit-ID field to 1. Every time the client initiates a new server
send a DHCP Request to a less preferred server. solicitation attempt (not a retransmission), the client increments
the Solicit-ID by one. If the 9-bit field rolls over to 0, then the
client sets the Solicit-ID to 1. A client which will only accept
the first Advertise message it receives leaves the Solicit-ID field
initialized to zero.
A client is free to cache the result of any DHCP Advertisement it The ``C'' bit of the Solicit message is set by the client when the
receives. This is purely a potential performance enhancement, client has no cached knowledge of previous DHCP configuration for the
because the results might change over time. A client may not get interface. Setting this bit requests that the server release any
a DHCP Reply if it uses a cached server-address, and in that case information assigned to the client for the networks on the client's
SHOULD multicast another DHCP Solicit message. link.
5.4. Sending DHCP Request Messages If the client desires to learn of the networks managed by DHCP on
the link its interface is attached to, it sets the ``P'' bit in the
Solicit message.
A client obtains configuration information from a server by sending The client transmits the Solicit message to the FF02::1:2 (All DHCP
a DHCP Request message. The client MUST know the server's address Agents) multicast address, destination port 547. The source port
before sending the Request message, and the client MUST have acquired selection can be arbitrary, although it SHOULD be possible using a
a (possibly identical) DHCP agent address. If the client and server client configuration facility to set a specific source port value.
are on the same link, the agent-address used by the client MUST be
the same as the DHCP server's address. A DHCP Request message MUST
NOT be sent to any multicast address, since otherwise multiple DHCP
servers would possibly allocate resources to the client in response
to the same Request, and the client would have no way to know which
servers had made the allocations, if any packets were lost due to
collisions, etc.
If the DHCP server is off-link, and the client has no valid IP 10.3.2. Time out and retransmission of Solicit Messages
address of sufficient scope, then the client MUST include the
server-address and set the `S' bit in the DHCP Request message. In
this case, the IP destination address in the IP header will be a DHCP
relay address.
Otherwise, if the client has a valid IP address of sufficient scope The client's first Solicit message on the interface MUST be delayed
and knows the IP address of a candidate server, it MUST send the by a random amount of time between the interval of MIN_SOL_DELAY and
Request message directly to the server without requiring the services MAX_SOL_DELAY. This random delay desynchronizes clients which start
of the local DHCP relay. at the same time (e.g., after a power outage).
If a client wishes to instruct a server to deallocate all unknown The client waits ADV_MSG_TIMEOUT, collecting Advertise messages.
previous resources, configuration information, and bindings If no Advertise messages are received, the client retransmits
associated with its agent-address and link-local address, it the Solicit, and doubles the ADV_MSG_TIMEOUT value. This process
sets the `C' bit in the DHCP Request. A client MAY send in continues until either one or more Advertise messages are received or
such a Request even when it is no longer attached to the link on ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value. Thereafter, Solicits
which the relay-address is attached. The `C' bit allows better are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
reclamation of available resources when a client lost records for made, at which time the client stops trying to DHCP configure the
its resource-server associations and might not otherwise be able to interface. An event external to DHCP is required to restart the DHCP
release the associated resources. configuration process.
When a client reboots and loses its previous state, the server Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
should no longer keep track of the the XID-TIMEOUT binding cache of ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 3.5.
transaction IDs (see section 6) associated with that previous state. 10.3.3. Receipt of Advertise messages
In order to inform the server that the client no longer wishes
any association to be maintained between used transaction-IDs and
previous transactions, the client SHOULD set the `R' bit in its DHCP
Request.
In any case, after choosing a transaction-ID which is numerically Upon receipt of one or more validated Advertise messages, the client
greater than its last recorded transaction-ID, and filling in the selects one or more Advertise messages based upon the following
appropriate fields of the DHCP Request message, the client MAY append criteria.
various DHCP Extensions to the message. These extensions denote
specific requests by the client; for example, a client may request
a particular IP address, or request that the server send an update
containing the client's new IP address to a Domain Name Server. When
all desired extensions have been applied, the client sends the DHCP
Request to the appropriate agent.
For each pending DHCP Request message, a client MUST maintain the - Those Advertise messages with the highest server preference
following information: value (see section 14.4) are preferred over all other Advertise
messages.
- The transaction-ID of the request message, - Within a group of Advertise messages with the same server
- The server-address, preference value, a client MAY select those servers whose
- The agent-address (which can be the same as the server-address), Advertise messages advertise information of interest to
- The time at which the next retransmission will be attempted, and the client. For example, one server may be advertising the
- All extensions appended to the request message. availability of IP addresses on networks which have an address
scope of interest to the client.
If a client does not receive a DHCP Reply message (Section 5.5) with Once a client has selected Advertise message(s), the client will
the same transaction-ID as a pending DHCP Request message within typically store information about each server, such as relay address
REPLY_MSG_TIMEOUT (see section 8) seconds, or if the received DHCP and prefix length, server preference value, networks advertised,
Reply message contains a DHCP Authentication extension which fails when the advertisement was received, and so on. Depending on the
to provide the correct authentication information, the client MUST requirements of the client's invoking user, the client MAY initiate a
retransmit the Request with the same transaction-ID and continue to configuration exchange with the server(s) immediately, or MAY defer
retransmit according to the rules in Section 8. If (after following this exchange until later.
those rules) the client has not received a Reply message, it SHOULD
start over again by multicasting a new DHCP Solicit message to find a
different server.
If the client receives an ICMP error message in response to such a 10.4. Relay Behavior
DHCP Request, it likewise SHOULD start over again by multicasting a
new DHCP Solicit message, to find a different server.
If the client transmits a DHCP Request in response to a DHCP For this discussion, the Relay is assumed to have been configured
Reconfigure message, further processing is as specified in with some list of server destination addresses, which may be unicast,
Section 5.7. The client can continue to operate with its existing the FF05::1:3 (All DHCP Servers) multicast address, or some other
configuration information and resources until it receives the multicast address selected by the network administrator.
corresponding DHCP Reply from the server. The same retransmission 10.4.1. Relaying of Solicit messages
rules apply as for any other DHCP Request message from the client.
When the `N' bit is set, a DHCP Request sent in response to a DHCP
Reconfigure message will not elicit a DHCP Reply message from the
server.
5.5. Receiving DHCP Reply Messages When a Relay receives a valid Solicit message, it places the IP
address of the interface upon which it received the Solicit message
in the ``relay-address'' field of the Solicit. The Relay also places
the number of bits of that make up the subnet prefix for this address
in the ``prefix-len'' field of the Solicit.
When a client receives a DHCP Reply message, it MUST check whether The Relay then forwards this Solicit to the list of server
the transaction-ID in the Reply message matches the transaction-ID destination addresses that it has been configured with.
of a pending DHCP Request message. If no match is found, the Reply 10.4.2. Relaying of Advertise messages
message MUST be silently discarded.
If the Reply message is acceptable, the client processes each When a Relay receives a valid Advertise message, it unicasts the
Extension [15], extracting the relevant configuration information message to the link-local address found in the ``client's link-local
and parameters for its network operation. The client can determine address'' field by way of the appropriate network interface.
when all extensions in the Reply have been processed by using the UDP 10.5. Server Behavior
Length field of the Reply. Some extensions in the Reply may have
status codes, which indicate to the client the reason for failure
when the server was unable to honor the request. If the server is
unable to honor the request in an extension included by the client,
that extension may simply be omitted from the Reply. The server MAY
also provide the client with configuration parameters the client did
not specifically request.
Some configuration information extracted from the extensions to the For this discussion, the Server is assumed to have been configured in
DHCP Reply message MUST remain associated with the server that sent an implementation specific manner. This configuration is assumed to
the message. The particular extensions that require this extra contain all network topology information for the DHCP domain, as well
measure of association with the server are indicated in the DHCP as any necessary authentication information.
Extensions document [15]. These "resource-server" associations are 10.5.1. Receipt of Solicit messages
used when sending DHCP Release messages.
5.6. Sending DHCP Release Messages Upon the receipt of a valid Solicit message, the server first
identifies the client's location within the DHCP domain. If the
``relay-address'' and / or ``prefix-len'' fields of the Solicit are
zeroed, then the client is attached to the same link as the server.
If these fields are non-zero, then the client exists on the same link
as the network identified by these two fields.
If a client wishes to ask the server to release all information and If administrative policy permits the server to respond to a client on
resources relevant to the client, the client SHOULD send a DHCP that link, the server will generate and send an Advertise message to
Release message without any extensions; this is preferable to sending the client.
a DHCP Request message with the `C' bit set and no extensions. If a
client wishes to retain some of its network configuration parameters,
but determines that others are no longer needed, it SHOULD enable
the server to release allocated resources which are no longer in
use by sending a DHCP Release message to the server, and including
extensions to identify the unneeded items. The client consults its
list of resource-server associations in order to determine which
server should receive the desired Release message. The Release
MUST be transmitted to the server that provided the configuration
parameters.
Suppose a client wishes to release resources which were granted to 10.5.2. Creation and sending of Advertise messages
it at another IP address. Further, suppose that the client has an
IP address that will still be valid after the server performs the
operations requested in the extensions to the DHCP Release message,
and which has sufficient scope to be reachable from the server. In
that case, and only then, the client MUST set the `D' bit in the DHCP
Release message (see section 4.5). This instructs the server to
send the DHCP Reply directly back to the client at the latter valid
IP address, instead of performing the default processing of sending
the DHCP Reply back through the agent-address included in the DHCP
Release.
5.7. Receiving DHCP Reconfigure Messages When creating an Advertise message, the server SHOULD start out
with a buffer initialized with zeroed octets. The server sets the
``msg-type'' field to 2 and copies the values of the following fields
from the client's Solicit to the Advertise message:
Each client implementation MUST support listening at UDP port 546 to o solicit-ID
receive possible DHCP Reconfigure messages; in cases where the client
knows that no Reconfigure message will ever be issued, the client MAY
be configured to avoid executing this supported feature. Any DHCP
Reconfigure message received with a transaction-ID greater than or
equal to 1024 MUST be silently discarded.
In some cases, the IP address at which the client listens will be a o client's link-local address
multicast address sent to the client by the server in an extension
to an earlier DHCP Reply message. If the client does not listen for o relay-address
DHCP Reconfigure messages, it is possible that the client will not
receive notification that its server has deallocated the client's The server places one of its IP addresses (determined through
IP address and/or other resources allocated to the client. See administrator setting) in the ``server-address'' field of the
discussion in 6.5. The client MAY receive a prefix update for one Advertise message. The server initializes the ``preference''
or more of their addresses and then MUST use that prefix for those field from its configuration information. See section 15.3 for a
description of server preference.
If the client requests subnet prefix extensions (by setting the ``P''
bit in its Solicit) and the server implements and is configured to
provide prefix extensions, the server will generate and insert a
subnet prefix extension for each network on the client's link it is
configured to manage.
If the ``relay-address'' field of the Advertise message is zero, then
the server unicasts the Advertise message directly to the client
using the ``client's link-local address'' field value as destination
address. If the ``relay-address'' field is non-zero, then the server
unicasts the Advertise message directly to the relay using the
``relay-address'' field value as the destination address.
11. DHCP Client-Initiated Configuration Exchange
A client initiates a configuration exchange with one or more servers
it has found through DHCP server solicitation whenever requested to
do so by the application layer in order to acquire configuration
information of interest.
11.1. Request Message Validation
Clients MUST silently discard any received Request messages.
Agents MUST discard any Request messages in which the ``client's
link-local address'' field does not contain a valid link-local
address.
Relays MUST discard any received Request messages in which the
``relay-address'' field value does not match any of the relay's
addresses. addresses.
If a client receives a DHCP Reconfigure message, it is a request for Servers MUST discard any received Request message which meets any of
the client to send a new DHCP Request to the server which sent the the following criteria:
Reconfigure message. Unless the `N' bit is set, the client MUST
await a DHCP Reply with a matching transaction-ID, retransmitting
(as specified in section 8) until the Reply is received. The server
sending the Reconfigure message MAY be different than the server
which sent a DHCP Reply message containing the original configuration
information.
Reconfigure messages MAY be retransmitted by the server with the same o The ``server-address'' field value does not match any of the
transaction-ID. server's addresses.
When a client receives a retransmitted unicast Reconfigure message o If the ``relay-address'' field is set, and that field's value
within XID_TIMEOUT of the last received Reconfigure message with the does not contain an address of sufficient scope as to be
same transaction-ID, the client MUST reformulate exactly the same reachable by the server.
DHCP Request message and retransmit the request message to the server
again. In this way, the server can make use of the retransmission
algorithm to ensure that a client has received the Reconfigure
message.
When a client receives a retransmitted multicast Reconfigure message o The ``extensions'' field contains an authentication extension,
within XID_TIMEOUT of the last received Reconfigure message with and the server cannot successfully authenticate the client.
the same transaction-ID, the client MUST not resend the the Request 11.2. Reply Message Validation
message if RECONF_MULTICAST_REQUEST_WAIT (see section 8) has not
expired. If RECONF_MULTICAST_REQUEST_WAIT has expired then the
client MUST reformulate exactly the same DHCP Request message and
retransmit the Request message to the server again, and then reset
RECONF_MULTICAST_REQUEST_WAIT to its default value or the value that
was provided from a retransmission extension [15] provided by the
server. In this way, the server can make use of the retransmission
algorithm to ensure that all affected clients have received the
multicast Reconfigure message.
For each Extension which is present in the Reconfigure message, the Servers MUST silently discard any received Reply messages.
client MUST append a matching Extension to its Request message, which
it formulates to send to the server specified in the server-address
field of the message. The client also copies a transaction-ID from
the Reconfigure message into the Request message. Processing for the
Request is the same as specified in Section 5.4, except:
- the client retransmits as stated above in this section Clients MUST discard any Reply message that meets any of the
following criteria:
- the client never needs a Relay to send the Request to the DHCP o The ``transaction-ID'' field value does not match the value the
Server client used in its Request or Release message.
- the client MUST NOT set the `S' or `R' bits o The ``client's link-local address'' field value does not match
the link-local address of the interface upon which the client
sent in its Request or Release message.
- if the `N' Bit is set, the client will not get a Reply from the o The Reply message contains an authentication extension, and the
server client's attempt to authenticate the message fails.
- if the client receives an ICMP error message it should abort the Relays MUST discard any Reply message that meets any of the following
Reconfigure transaction and log an error message. The client criteria:
MUST NOT transmit a DHCP Solicit message in order to rediscover
the IP address of the DHCP Server.
Resources held by the client which are not identified by Extensions o The ``R'' bit isn't set.
in the server's Reconfigure message are not affected.
A server may ask its client to join a multicast group for the o The ``relay-address'' field value does not contain the relay's
purpose of receiving DHCP Reconfigure messages. When a Reconfigure address on the same link as the client.
message is delivered to the client by way of the selected multicast
address, the client MUST delay its further response for a random
amount of time uniformly distributed within the interval between
RECONF_MMSG_MIN_RESP and RECONF_MMSG_MAX_RESP seconds (see
section 8). This will minimize the likelihood that the server will
be flooded with DHCP Request messages.
5.8. Interaction with Stateless Address Autoconfiguration o The ``client's link-local address'' field value does not contain
a valid link-local address.
Please refer to the Stateless Address Autoconfiguration Protocol 11.3. Release Message Validation
specification [20] for details regarding the actions taken by clients
upon receiving Router Advertisements with changing values for the `M'
and `O' bits.
6. DHCP Server Considerations Clients MUST silently discard any received Release messages.
A node which is not a client or relay MUST ignore any DHCP Advertise, Agents MUST discard any Release message that meets any of the
DHCP Reply, or DHCP Reconfigure message it receives. following criteria:
A server maintains a collection of client records, called o The ``transaction-ID'' field contains a value not in the
``bindings''. Each binding is uniquely identifiable by the ordered 1024--65535 range.
pair <link-local address, agent-address>, since the link-local
address is guaranteed to be unique [20] on the link identified by the
agent-address and prefix. An implementation MUST support bindings
consisting of at least a client's link-local address, agent-address,
preferred lifetime and valid lifetime [20] for each client address.
A server MAY, at the discretion of the network administrator, be o The ``client's link-local address'' field does not contain a
configured so that client bindings are identified by the client's valid link-local address.
link-local address, without need to use the additional information
supplied by the agent-address.
A client binding may be used to store any other information, Relays MUST discard any received Release message that meets any of
resources, and configuration data which will be associated with the the following criteria:
client. A server MUST retain its clients' bindings across server
reboots, and, whenever possible, a client should be assigned the
same configuration parameters despite server system reboots and DHCP
server program restarts. A server MUST support fixed or permanent
allocation of configuration parameters to specific clients.
In addition to the client binding a server must maintain an o The ``R'' bit is not set.
XID_TIMEOUT binding cache to determine if a previous transaction-ID
is being retransmitted by a client. An implementation of an
XID_TIMEOUT binding cache MUST support at least a tuple consisting of
the client's link-local address, agent-address prefix, IPv6 address,
and XID_TIMEOUT value when the cache entry can be deleted (see
Section 8).
6.1. Receiving DHCP Solicit Messages o The ``X-address'' field value does not match any of the relay's
addresses.
If the DHCP Solicit message was received at the All-DHCP-Servers Servers MUST discard any received Release message which meets any of
multicast address, the server MUST check to make sure that the the following criteria:
relay-address is present, and is not a link-local address. If the
relay-address is not present, or if it is a link-local address,
the server MUST silently discard the packet. Note that if the
client sends a DHCP Solicit message from a link-local address, the
multicast destination will be the All-DHCP-Agents address, not the
All-DHCP-Servers address.
When the `C' bit is set in the solicitation, the server deallocates o The ``X-address'' field does not contain an address of sufficient
all resources that match the link-local address and saved scope as to be reachable by the server.
agent-address in the solicitation message, if a binding for the
client can be found. If a client binding cannot be found the server
SHOULD continue to process the Solicit message.
As an optimization, a server processing a Solicit message from relays o The ``extensions'' field contains an authentication extension,
MAY check the prefix of the IP source address in the IP header to and the server cannot successfully authenticate the client.
determine whether the server has received the Solicit from multiple 11.4. Client Behavior
relays on the same link. The prefix-size field in the solicitation
enables the server to ascertain when two relay addresses belong to
the same link.
6.2. Sending DHCP Advertise Messages A client will generate one or more Request messages when prompted by
the application layer in order to acquire configuration information.
A client may initiate such an exchange automatically in order to
acquire the necessary network parameters to communicate with nodes
off-link. The client uses the server and relay address information
from previous Advertise message(s) for use in delivering Request
message(s). Note that a client may request configuration information
from one or more servers at any time.
Upon receiving and verifying the correctness of a DHCP Solicit A client uses the Release message in the management of releasable
message, a server constructs a DHCP Advertise message and transmits resources when:
it on the same link as the solicitation was received from. When the
solicitation is received at the All-DHCP-Servers multicast address,
the server SHOULD delay the transmission of its advertisement
for a random amount of time between SERVER_MIN_ADV_DELAY and
SERVER_MAX_ADV_DELAY (see section 8).
If the relay-address is nonzero, the server MUST copy it into the o The client has determined through a resource-specific manner
agent-address field of the advertisement message, and send the that the resource assigned by the server is already in use by a
advertisement to the relay-address. Otherwise, the server MUST different client.
send the advertisement to the client's link-local address. An IP
address of the interface on which the server received the Solicit
message MUST appear in the server-address field of the corresponding
advertisement, and the 'S' bit MUST be set.
The server MAY append extensions to the Advertisement, in order to o The client has been instructed to release the resource prior to
offer the soliciting node the best possible information about the the lease expiration time since it is no longer needed.
available services and resources. 11.4.1. Creation and sending of Request messages
6.3. DHCP Request and Reply Message Processing When creating a Request message, the client SHOULD start out with
a buffer initialized with zeroed octets. The client sets the
``msg-type'' field to 3, and places the link-local address of the
interface it wishes to associate with the configuration information
with in the ``client's link-local address'' field.
DHCP server MUST check to ensure that the client's link-local address Unless the Request message is created in response to a
field of the Request message contains a link-local address. If not, Reconfigure-init message, the client generates a transaction
the message MUST be silently discarded. If the `S' bit is set, the ID in the range of 1024--65535 and inserts this value in the
server MUST check that the server-address matches one of its own IP ``transaction-ID'' field.
addresses. If the server-address does not match, the Request message
MUST be silently discarded.
If the received agent-address and link-local address do not The client places the address of the destination server in the
correspond to any binding known to the server, then the server ``server-address'' field.
SHOULD create a new binding for the previously unknown client,
and send a DHCP Reply with any resources allocated to the new
binding. Otherwise, if the server cannot create a new binding,
it SHOULD return a DHCP Reply with a status of ``NoBinding'' (see
Section 2.4). If the client is updating its resources but the
database is temporarily unavailable, the server SHOULD return a DHCP
Reply with a status of ``Unavail'' (see Section 2.4).
While processing the Request, the server MUST first determine whether If the client is not on the same link as the destination
or not the Request is a retransmission of an earlier DHCP Request server, the client places the appropriate relay's address in the
from the same client. This is done by comparing the transaction-ID ``relay-address'' field.
to all those transaction-IDs in the XID_TIMEOUT binding cache
received from the same client during the previous XID_TIMEOUT
seconds. If the transaction-ID is the same as one received during
that time, the server MUST take the same action (e.g., retransmit
the same DHCP Reply to the client) as it did after processing the
previous DHCP Request with the same transaction-ID.
Otherwise, if the server has no record of a message from the client If the client is acquiring configuration information on the interface
with the same transaction-ID, the server identifies and allocates for the first time, the client SHOULD set the ``C'' bit in the
all the relevant information, resources, and configuration data that header. How the client determines if this is the first configuration
is associated with the client. Then it sends that information to attempt on the interface is implementation-specific. A client may
its client by constructing a DHCP Reply message and including the implement a cache of configuration information on a per-interface
client's information in DHCP Extensions to the Reply message. The basis; if that cache does not exist, that client would set the
DHCP Reply message uses the same transaction-ID as found in the ``C'' bit. Clients which do not implement caching of per-interface
received DHCP Request message. Note that the reply message MAY configuration information MUST always set the ``C'', and include
contain information not specifically requested by the client. any extensions carrying releasable resources received from earlier
configuration exchanges in the extensions field of the Request.
If the DHCP Request message has the `S' bit set in the message If the client has determined through an implementation-specific
header, the server MUST send the corresponding DHCP Reply message to manner that the client implementation itself has restarted, it MUST
the agent-address found in the Request (see section 7.2). Otherwise, set the ``R'' bit in the header. After the first successful exchange
the server SHOULD send the corresponding DHCP Reply message to the with the server, the client MUST NOT set the ``R'' bit in subsequent
IP source address in the IP header received from the client Request Request messages.
Client considerations for extensions are now considered (see the
``extensions document'', [2] for more details).
If the client already has an IP address of sufficient scope to
directly reach the server, then the client SHOULD unicast the Request
to the server. Otherwise, if the server is off-link, the client
unicasts the Request message to the appropriate relay.
11.4.2. Time out and retransmission of Request Messages
The client waits REP_MSG_TIMEOUT milliseconds, collecting
Reply messages. If no Reply messages are received, the client
retransmits the Request with the same transaction-ID, and doubles
the REP_MSG_TIMEOUT value, and waits again. The client continues
this process until a Reply is received or REQUEST_MSG_ATTEMPTS
unsuccessful attempts have been made, at which time the client MUST
abort the configuration attempt. The client SHOULD report the abort
status to the application layer.
Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
are documented in section 3.5.
11.4.3. Receipt of Reply message in response to a Request
Upon the receipt of a valid Reply message, the client extracts the
configuration information contained in the Reply. If the ``status''
field contains a non-zero value, the client reports the error status
to the application layer.
If the extensions field contains one or more ``Reconfigure Multicast
Address'' extensions (see ``extensions document'', ``Reconfigure
Multicast Address Extension'' section [2]), the client MUST join
these multicast groups, and MUST monitor the UDP 546 port for
Reconfigure or Reconfigure-init messages on the networks configured
by DHCP.
If the configuration information returned in the Reply contains
releasable resources, then the client MUST take over lease management
of the resource. A client MUST NOT request releasable resources
unless it is prepared to appropriately manage the resource lease.
11.4.4. Creation and sending of Release messages
When creating a Release message, the client SHOULD start out with
a buffer initialized with zeroed octets. The client sets the
``msg-type'' field to 5, and places the link-local address of the
interface the configuration information it wishes to release is
associated with in the ``client's link-local address'' field.
The client generates a transaction ID in the range of
1024--65535 and inserts this value in the ``transaction-ID''
field.
The client includes extensions containing the releasable resources it
is releasing in the ``extensions'' field. The appropriate ``status''
field in the extensions MUST be set to indicate the reason for the
release.
The client places the IP address of the server who allocated the
resource(s) in the ``server-address'' field.
If the client will have an appropriately scoped IP address after the
release transaction is completed, the client clears the ``R'' bit
and places this address in the ``X-address'' field. If the client
will not have an appropriately scoped IP address after the release
transaction is completed, the client sets the ``R'' bit and places
the address of the appropriate relay in the ``X-address'' field.
If the client is configured to use authentication, the client
generates the appropriate authentication extension, and adds this
extension to the ``extensions'' field. Note that the authentication
extension MUST be the last extension in the ``extensions''
field. See the ``extension document'' for more details about the
authentication extension [2].
If the ``R'' bit is set, then the client MUST unicast the Release
to the relay indicated in the ``X-address'' field. Otherwise, the
client unicasts the Release message directly to the server indicated
in the ``server-address'' field.
11.4.5. Time out and retransmission of Release Messages
The client waits REP_MSG_TIMEOUT milliseconds, collecting Reply
messages. If no Reply messages are received, the client retransmits
the Release, and doubles the REP_MSG_TIMEOUT value, and waits again.
The client continues this process until a Reply is received or
REL_MSG_ATTEMPTS unsuccessful attempts have been made, at which
time the client SHOULD abort the release attempt. The client
SHOULD return the abort status to the application, if an application
initiated the release.
Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented in section 3.5.
Note that if the client fails to release the resource, the resource
will be reclaimed by the server when the lease associated with it
expires.
11.4.6. Receipt of Reply message in response to a Release
Upon receipt of a valid Reply message, the client can consider the
Release event successful, and SHOULD return the successful status to
the application layer, if an application initiated the release.
11.5. Relay Behavior
11.5.1. Relaying of Request or Release messages
When a Relay receives a valid Request or Release message, it forwards
it to the IP address found in the ``server-address'' field of the
message. message.
11.6. Server Behavior
6.3.1. Processing for Extensions to DHCP Request and Reply Messages For this discussion, the Server is assumed to have been configured
in an implementation specific manner with configuration of interest
to clients. Such configuration information MAY contain releasable
resources such as IP addresses.
11.6.1. Receipt of Request messages
The DHCP Request may contain extensions [15], which are interpreted Upon the receipt of a valid Request message from a client the server
(by default) as advisory information from the client about its can respond to, (implementation-specific administrative policy
configuration preferences. For instance, if the IP Address Extension satisfied) the server scans the extensions field.
is present, the server SHOULD attempt to allocate or extend the
lifetime of the address indicated by the extension. Some extensions
may be marked by the client as required.
The server may accept some extensions for successful processing and If the client has set the ``C'' bit, the server MUST release all
allocation, while still rejecting others, or it may reject various releasable resources currently associated with the client's binding
extensions for different reasons, and set the status appropriately that do not appear in the ``extensions'' field.
for those extensions which return status to the client. The server
sends a single DHCP Reply message in response to each DHCP Request,
with the same transaction-ID as the Request.
Whenever it is able to, the server includes an extension in the If the client has set the ``R'' bit, the server MUST delete any
Reply message for every extension sent by the client in the Request transaction-ID cache entries it is maintaining for this client, if
message. If the client requests some extensions that cannot be the server implements such a cache.
supplied by the server, the server can simply fail to provide them,
not including them in the Reply. Other extensions can be rejected
by including them in the Reply with an appropriate status indicating
failure. The server can include extensions in the reply that were
not requested by the client.
6.3.2. Client Requests to Deallocate Unknown Resources Server considerations for extensions are now evaluated (see the
``extensions document'', [2] for more details).
When a client DHCP Request is received that has the `C' bit set, If the configuration information to be returned to the client
the server should check to find out whether the extensions listed includes releasable resources, the server checks if a binding
in the Request message match those which it has associated with the already exists for the client. If so, the server examines the
client's binding. Any resources which are not indicated by the data records within the binding to determine if the client's
client are presumed to be unknown by the client, and thus possible Request is a retransmission of an earlier Request or a new Request.
candidates for reallocation to satisfy requests from other clients. Releasable resource identifiers are stored within the binding with
The server MUST deallocate all resources associated with the client the transaction-ID used by the client to request the resource's
upon reception of a DHCP Request with the `C' bit set, except for assignment. If the transaction-ID's match, this is a retransmission
those which the server is willing to reallocate in response to the and the server simply return the contents of the client's binding
client's request. It may be more efficient to avoid deallocating any which satisfy its request. If the transaction-ID's do not match,
resources until after the list of extensions to the request has been the server records the additional resources it is assigning in the
inspected. existing binding with the new Request's transaction-ID.
6.4. Receiving DHCP Release Messages If the client does not have an existing binding, the server creates a
binding for the client and records the resources it is assigning in
this binding along with the transaction-ID from the client's Request.
If the server receives a DHCP Release Message, it MUST verify that The server then constructs a Reply message and sends it to the
the link-local address field of the message contains an address which client.
could be a valid link-local address (see Section 2.1). If not, the 11.6.2. Receipt of Release messages
message MUST be silently discarded.
In response to a DHCP Release Message with a valid client's Upon the receipt of a valid Release message, the server performs a
link-local address and agent-address, the server formulates a DHCP lookup to find the client's binding. If the binding is found, the
Reply message that will be sent back to the releasing client. When server examines the binding to see if the resource(s) identified by
the `D' flag is set, the server MUST send the DHCP Reply back to the client in the Release message's extensions field are in fact
the client using the client-address field of the Release message. assigned to the client. If they are, the server deletes these
Otherwise, if the `D' bit is not set, the server MUST send its DHCP resources from the client's binding, making them available to other
Reply message (with the `L' bit set) to the agent-address in the clients.
Release message, so that the relay agent can subsequently forward the
Reply back to the releasing client at the client's link-local address
indicated in the Reply message.
If the received agent-address and link-local address do not The server then generates a Reply message. If a binding was
correspond to any binding known to the server, then the server SHOULD found and the resources presented to the server were deleted from
return a DHCP Reply, indicating the error by setting the status code the client's binding, the server sets the ``status'' field to
to ``NoBinding'' (see Section 2.4). ``Success''. If no binding is found, the server sets the ``status''
field to ``NoBinding''(section 3.4).
11.6.3. Creation and sending of Reply messages
Otherwise, if the agent-address and link-local address indicate a When creating a Reply message, the server SHOULD start out with
binding known to the server, then the server continues processing the a buffer initialized with zeroed octets. The server sets the
Release message. If there are any extensions, the server releases ``msg-type'' field to 4 and copies the values of the following fields
the particular configuration items specified in the extensions. from the client's Request or Release to the Reply message:
If there are no extensions, the server releases all configuration
information in the client's binding.
After performing the operations indicated in the DHCP Release message o transaction-ID
and its extensions, the server formulates a DHCP Reply message,
copying the transaction-ID from the DHCP Release message. For
each Extension in the DHCP Release message successfully processed
by the server, a matching Extension is appended to the DHCP Reply
message. For extensions in the DHCP Release message which cannot be
successfully processed by the server, a DHCP Reply message containing
extensions with the appropriate status MUST be returned by the
server. If the Release message contains no extensions, the server
does not include any extensions in the corresponding DHCP Reply
message to the client.
6.5. Sending DHCP Reconfigure Messages o client's link-local address
If a server needs to change the configuration associated with any o If the client's message is a Request with a non-zero
of its clients, it constructs a DHCP Reconfigure message (possibly ``relay-address'' field value, the server sets the ``R'' bit in
including relevant extensions) and sends it to each such client. The the Reply and copies the ``relay-address'' field value from the
Reconfigure MAY be sent to a multicast address chosen by the server, Request to the Reply. If the client's message is a Release with
which was previously sent to each such client in an extension to a the ``R'' bit set, the server sets the ``R'' bit in the Reply and
previous DHCP Reply message. sets the ``relay-agent'' field to the contents of the Release's
X-address field.
It may happen that a client does not send a DHCP Request message The server sets the ``status'' field appropriately (see the table
after the DHCP Reconfigure message has been issued and retransmitted in section 3.4) based upon the results of processing the client's
RECONF_MSG_MIN_RETRANS times, according to the algorithm specified request.
in Section 8. This can happen when the client is not listening for
the Reconfigure message, possibly because the client is a mobile
node disconnected from the network, or because the client node
has sustained a power outage or operating system crash. In such
cases, the server SHOULD reserve any resources issued to the client
until the client responds at some future time, until the resource
allocation times out (see section 6.6), or until administrative
intervention causes the resources to be manually returned to use.
The server SHOULD also log a DHCP System Error.
If the server gets another DHCP Request from a client, with a If configured to do so, a server will include ``Reconfigure Multicast
transaction-ID which does not match that of the recently transmitted Address'' extensions (see ``extensions document'', ``Reconfigure
reconfigure message, the server SHOULD send a DHCP Reply to Multicast Address Extension'' [2]), in Reply messages sent in
the client, and wait for RECONF_MSG_RETRANS_INTERVAL, before response to a Request, informing the client of one or more multicast
retransmitting the DHCP Reconfigure again. groups it should join to facilitate the receipt of Reconfigure or
Reconfigure-init messages.
6.6. Client-Resource timeouts If the DHCP domain is using authentication, the server will generate
an authentication extension with the appropriate settings and add
that extension as the last extension in the ``extensions'' field of
the Reply message.
Some resources (for instance, a client's IP address) may only be If the ``relay-address'' field of the Reply message is zero, then the
allocated to a client for a particular length of time (for instance, server unicasts the Reply directly to the client using the ``client's
the valid lifetime of an IP address). If the client does not renew link-local address'' field value as destination address. If the
the resource allocation for such a resource, the server MAY make the ``relay-address'' field is non-zero, then the server unicasts the
resource available for allocation to another client. However, under Reply directly to the relay using the ``relay-address'' field value
administrative control, the server MAY reserve any resources issued as the destination address.
to the client until the client responds at some future time.
7. DHCP Relay Considerations If the server implements a transaction-ID cache, the server would add
an entry for the client to this cache.
12. DHCP Server-Initiated Configuration Exchange
The DHCP protocol is constructed so that a relay does not have A server initiates a configuration exchange on behalf of the
to maintain any state in order to mediate DHCP client/server administrator of the DHCP domain. An administrator may initiate such
interactions. an exchange when new networks are added to the domain or existing
networks are to be renumbered. Other examples include changes in
the location of directory servers, addition of new services such as
printing, and availability of new software (system or application).
12.1. Reconfigure Message Validation
The DHCP relay enables clients and servers to carry out DHCP protocol Agents MUST silently discard any received Reconfigure messages.
transactions. DHCP Solicit messages are issued by the relay when
initiated by prospective clients. By default, the relay locates
servers by use of multicasting solicitations to the All-DHCP-Servers
multicast group, but relays SHOULD allow this behavior to be
configurable. The relay MUST be able to determine which of its
interfaces received the client's solicitation message.
7.1. DHCP Solicit and DHCP Advertise Message Processing Clients MUST discard any Reconfigure message that meets any of the
following criteria:
Upon receiving a DHCP Solicit message from a prospective client, o The ``transaction-ID'' field value is not within
a relay, by default, forwards the message to servers at a site the 0--1023 range.
according to the following procedure:
- copying the prospective client's solicitation message fields into o The Reconfigure message contains an authentication extension, and
the appropriate fields of the outgoing solicitation, the client's attempt to authenticate the message fails.
- copying a non-link-local address of its interface from which the 12.2. Reconfigure-reply Message Validation
solicitation was received from the client into the relay-address
field, and
- setting the prefix-size field appropriately, Clients and Relays MUST silently discard any received
Reconfigure-reply messages.
- by default, setting the hop-count field in the IP header of Servers MUST discard any Reconfigure-reply message that meets any of
the solicitation to the value DEFAULT_SOLICIT_HOPCOUNT (see the following criteria:
section 8).
- setting the IP source address to be a site-local or global-scope o The ``transaction-ID'' field value is not that same value the
address belonging to the relay's interface on which the client's server used in its Reconfigure message.
original solicitation was received,
- finally, sending the resulting message to one or more servers. o The ``server-address'' field value does not match the value the
server placed in its Reconfigure message.
12.3. Reconfigure-init Message Validation
By default, the relay sends solicitations to the All-DHCP-Servers Agents MUST silently discard any received Reconfigure-init messages.
multicast address, FF05:0:0:0:0:0:1:3. However, the relay MAY be
configured with an alternate server address, or the FQDN of a server.
Methods for automatically updating such alternately configured server
addresses are not specified in this document.
When the relay receives a DHCP advertisement, it relays the Clients MUST discard any Reconfigure-init messages that meets any of
advertisement to the client at the client's link-local address by way the following criteria:
of the interface indicated in the agent's address field.
7.2. DHCP Request Message Processing o The ``transaction-ID'' field value is not within
the 0--1023 range.
When a relay receives a DHCP Request message, it SHOULD check that o The Reconfigure-init message contains an authentication
the IP source address in the IP header is a link-local address, extension, and the client's attempt to authenticate the message
that the link-local address matches the link-local address field in fails.
the Request message header, and that the agent-address field of the 12.4. Server Behavior
message matches an IP address associated with the interface from
which the DHCP Request message was received. If any of these checks
fail, the relay MUST silently discard the Request message.
The relay MUST check whether the `S' bit is set in the message For this discussion, the server is assumed to have a
header. If not, the packet is discarded, and the relay SHOULD implementation-specific interface by which an administrator
return a DHCP Reply message to the address contained in the client's may initiate a reconfiguration event with some set of clients.
link-local address field of the Request message, with status
``PoorlyFormed'' (see Section 2.4).
If the received request message is acceptable, the relay then There are two methods of initiating a reconfiguration event. Each
transmits the DHCP Request message to the address of the server found has its advantages:
in the server-address field of the received DHCP Request message.
All of the fields of DHCP Request message transmitted by the relay
are copied over unchanged from the DHCP Request received from the
client. Only the fields in the IP header will differ from the
packet received from the client. All relays MUST send DHCP Request
messages using the source IP address from the interface where the
DHCP request was received. If the Relay receives an ICMP error, the
Relay SHOULD return a DHCP Reply message to the client address (which
can be found in the payload of the ICMP message [5]), with status
``ICMPError'' (see Section 2.4), along with the DHCP Relay ICMP Error
extension [15].
7.3. DHCP Reply Message Processing Reconfigure with payload
This method uses the Reconfigure message. Items
to be changed are included as extensions in the
``extensions'' field. This method MUST NOT be used
to reconfigure releasable resources. Examples of
information which can be reconfigured using this
method are DNS domain and servers, NTP servers, other
name service parameters. The server generates and
sends the Reconfigure message; clients respond with
Reconfigure-reply messages.
When the relay receives a DHCP Reply, it MUST check that the message Reconfigure Trigger
has the `L' bit set. It MUST check that the client's link-local This method uses the Reconfigure-init message. When
address field contains a link-local address. If either check fails, a client receives a Reconfigure-init message, it
the packet MUST be silently discarded. If both checks are satisfied, initiates a Request/Reply exchange with the server.
the relay MUST send a DHCP Reply message to the link-local address Any kind of resource can be reconfigured using this
listed in the received Reply message. Only the fields in the IP method, including releasable resources. An example
header will differ from the packet received from the server, not the of an releasable resource is an IP address.
payload.
8. Retransmission and Configuration Variables A server can send Reconfigure and Reconfigure-init messages only to
those clients who have an address of sufficient scope to be reachable
by the server. Thus, those clients who have not requested an IP
address and are off-link cannot be reconfigured by the server.
When a client does not receive a DHCP Reply in response to a pending Before initiating a reconfigure process, the server SHOULD be
DHCP Request, the client MUST retransmit the identical DHCP Request, configured with a REC_THRESHOLD threshold value which represents
with the same transaction-ID, to the same server again until it can the percentage of clients successfully reconfigured before the
be reasonably sure that the server is unavailable and an alternative reconfigure process is considered a success. See section 3.5 for the
can be chosen. The DHCP server assumes that the client has received default setting of REC_THRESHOLD. Note that the server MUST be able
the configuration information included with the extensions to the to determine the set of clients that should receive the reconfigure,
DHCP Reply message, and it is up to the client to continue to try for in order to determine when the reconfigure process is complete.
a reasonable amount of time to complete the transaction. All the 12.4.1. Creation and sending of Reconfigure messages
actions specified for DHCP Request in this section hold also for DHCP
Release messages sent by the client.
Similarly, when a client sends a DHCP Request message in response to When creating a Reconfigure message, the server SHOULD start out
a Reconfigure message from the server, the client assumes that the with a buffer initialized with zeroed octets. The server sets the
DHCP server has received the Request. The server MUST retransmit ``msg-type'' field to 6. The server generates a transaction-ID
the identical DHCP Reconfigure to the client a reasonable number from the 0--1023 range and inserts it in the ``transaction-ID''
of times to try to elicit the Request message from the client. field. The server places its address (of appropriate scope) in the
If no corresponding DHCP Request is received by the server after ``server-address'' field.
REQUEST_MSG_MIN_RETRANS retransmissions, the server MAY erase or
deallocate information as needed from the client's binding, but see
section 6.5.
Retransmissions occur using the following configuration variables The server then generates extensions for the non-releasable resources
for a DHCP implementation. These configuration variables MUST be to be changed and places them in the ``extensions'' field.
configurable by a client or server:
CLIENT_ADV_WAIT If the DHCP domain is using authentication, the server will generate
an authentication extension with the appropriate settings and add
that extension as the last extension in the ``extensions'' field of
the Reconfigure message.
The minimum amount of time a client waits to receive DHCP The server multicasts the Reconfigure message to one or more
Advertisements after transmitting a DHCP Solicit to the Reconfigure Multicast Addresses previously sent as extensions to the
All-DHCP Agents multicast address (see section 5.3). clients. Note that a server MAY unicast Reconfigure message(s) to
specific clients by walking its list of bindings to determine the
unicast address(es) of the clients. Whether or not the Reconfigure
is multicast or unicast is an implementation detail.
Default: 2 seconds A server waits for Reconfigure-reply messages from clients confirming
DEFAULT_SOLICIT_HOPCOUNT that they have received the Reconfigure.
The default hop-count used in the IP header by DHCP relays when 12.4.2. Time out and retransmission of Reconfigure messages
sending DHCP Solicit messages on behalf of a client.
Default: 4 The server waits RECREP_MSG_TIMEOUT milliseconds, collecting
Reconfigure-reply messages. If all the expected Reconfigure-reply
messages are received, then the reconfigure process is successful.
If some or all of the expected Reconfigure-reply messages are not
received, then the server retransmits the Reconfigure, and doubles
the RECREP_MSG_TIMEOUT value, and waits again. The server continues
this process until all Reconfigure-reply messages are received or
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time
the server SHOULD abort the reconfigure process. The server SHOULD
log the result of the reconfigure process.
SERVER_MIN_ADV_DELAY Default and initial values for RECREP_MSG_TIMEOUT and
REC_MSG_ATTEMPTS are documented in section 3.5.
12.4.3. Receipt of Reconfigure-reply messages
The minimum amount of time a server waits to transmit a Upon receipt of a valid Reconfigure-reply message, the server
DHCP Advertisement after receiving a DHCP Solicit at the removes that client from the list of clients it is expecting a
All-DHCP-Servers or All-DHCP-Agents multicast address. Reconfigure-reply message from.
12.4.4. Creation and sending of Reconfigure-init messages
Default: 100 milliseconds When creating a Reconfigure-init message, the server SHOULD start
out with a buffer initialized with zeroed octets. The server sets
the ``msg-type'' field to 8. The server generates a transaction-ID
from the 0--1023 range and inserts it in the ``transaction-ID''
field. The server places its address (of appropriate scope) in the
``server-address'' field.
SERVER_MAX_ADV_DELAY The server MAY generate an ERE extension to inform the client of what
information has been changed or new information that has been added.
The maximum amount of time a server waits to transmit a DHCP If the DHCP domain is using authentication, the server will generate
Advertisement after receiving a DHCP Solicit at the All-DHCP an authentication extension with the appropriate settings and add
Agents multicast address. that extension as the last extension in the ``extensions'' field of
the Reconfigure-init message.
Default: 1 second Typically, the server will not provide more than an ERE and / or
Authentication extension, since it will provide the new configuration
information as part of the Request/Reply transaction triggered by the
Reconfigure-init message.
REPLY_MSG_TIMEOUT The server multicasts the Reconfigure-init message to one or more
Reconfigure Multicast Addresses previously sent as extensions
to the clients. Note that a server MAY unicast Reconfigure-init
message(s) to specific clients by walking its list of bindings to
determine the unicast address(es) of the clients. Whether or not the
Reconfigure-init is multicast or unicast is an implementation detail.
The time in seconds that a client waits to receive a server's A server waits for a Request message from each client confirming that
DHCP Reply before retransmitting a DHCP Request. The they have received the Reconfigure-init and are thus initiating a
client MUST multiply REPLY_MSG_TIMEOUT by a factor of 2 in Request/Reply transaction with the server. The server can determine
an exponential manner for each time it retransmits until that a Request message is in response to a Reconfigure-init because
REQUEST_MSG_MIN_RETRANS (below) is attained. A client MAY be the transaction-ID in the Request will be the same value as was used
configured to attempt 2 retransmissions before beginning the in the Reconfigure-init message.
exponential backoff retransmission in the previous sentence. 12.4.5. Time out and retransmission of Reconfigure-init messages
Default: 2 seconds. The server uses the same algorithm and configuration values for
sending Reconfigure-init messages as it does with Reconfigure
messages. See Section 12.4.2 for this algorithm.
12.4.6. Receipt of Request messages
REQUEST_MSG_MIN_RETRANS Upon receipt of a valid Request message with the same transaction-ID
as the Reconfigure-init messages it sent, the server removes that
client from the list of clients it is expecting to initiate a
Request/Reply transaction.
The minimum number of DHCP Request transmissions that a client The server generates and sends Reply message(s) to the client as
should retransmit, before aborting the request. described in section 11.6.3, including in the ``extension'' field
new values for configuration parameters. If the extensions include
releasable resources, the server will include two extensions for each
resource - one with the original values with the lease times set to
zero, and another with new values and lease times. Note that the
server can terminate the client's ability to use a resource simply by
including only the first extension value.
12.5. Client Behavior
Default: 10 retransmissions. A client MUST always monitor UDP port 546 for Reconfigure and
Reconfigure-init messages on interfaces upon which it has acquired
DHCP parameters. Since the results of a reconfiguration event may
affect application layer programs, the client SHOULD log these
events, and MAY notify these programs of the change through an
implementation-specific interface.
RECONF_MSG_MIN_RETRANS 12.5.1. Receipt of Reconfigure messages
The minimum number of DHCP Reconfigure messages that a Upon receipt of a valid Reconfigure message, the client extracts
server should retransmit, before assuming the the client is the configuration parameters contained in the ``extensions''
unavailable. field, and notifies the application layer that new values for these
parameters are available. The client then generates and sends a
Reconfigure-reply message to the server.
12.5.2. Creation and sending of Reconfigure-reply messages
Default: 10 retransmissions. When creating a Reconfigure-reply message, the client SHOULD start
out with a buffer initialized with zeroed octets. The client sets
the ``msg-type'' field to 7, and places the link-local address of
the interface upon which it received the Reconfigure message in
the ``client's link-local address'' field. The client copies the
values of the following fields from the Reconfigure message to the
Reconfigure-reply message:
RECONF_MSG_RETRANS_INTERVAL o transaction-ID
The least time in seconds that a server waits for a o server-address
client's DHCP Request before each retransmission of the DHCP
Reconfigure.
Default: 12 seconds. The client sets the ``status'' field appropriately (see the table
in section 3.4) based upon the results of processing the server's
reconfigure-reply.
RECONF_MMSG_MIN_RESP The client places the address of the destination server in the
``server-address'' field.
The minimum amount of time before a client can respond to a If the client is configured to use authentication, the client
DHCP Reconfigure message sent to a multicast address. generates the appropriate authentication extension, and adds this
extension to the ``extensions'' field. Note that the authentication
extension MUST be the last extension in the ``extensions'' field.
Default: 2 seconds. The client delays the sending of the Reconfigure-reply by some
random value selected in the range of REC_REP_MIN and REC_REP_MAX
seconds. This delay helps reduce the load on the server generated by
processing large numbers of Reconfigure-reply messages.
RECONF_MMSG_MAX_RESP Default and initial values for REC_REP_MIN and REC_REP_MAX are
documented in section 3.5.
The maximum amount of time before a client MUST respond to a The client unicasts the Reconfigure-reply to the address identified
DHCP Reconfigure message sent to a multicast address. in the ``server-address'' field. Sending the Reconfigure-reply
completes the reconfiguration process for the client.
Default: 10 seconds. 12.5.3. Receipt of Reconfigure-init messages
RECONF_MULTICAST_REQUEST_WAIT Upon receipt of a valid Reconfigure-init message, the client
initiates a Request/Reply transaction with the server.
12.5.4. Creation and sending of Request messages
The time a client should wait before retransmitting a Request When responding to a Reconfigure-init, the client creates and
message in reponse to a retransmitted multicast Reconfigure sends the Request message in exactly the same manner as outlined in
message. section 11.4.1 with the following differences:
Default: 120 seconds transaction-ID
The client copies the transaction-ID from the
Reconfigure-init message into the Request message.
MIN_SOLICIT_DELAY Pause before sending Request
The client pauses before sending the Request for
a random value within the range REC_REP_MIN and
REC_REP_MAX seconds, as outlined in section 12.5.2.
12.5.5. Time out and retransmission of Request messages
The minimum amount of time a prospective client is required to The client uses the same variables and retransmission algorithm as it
wait, after determining from a Router Advertisement message does with Request messages generated as part of a client-initiated
that the client should perform stateful address configuration, configuration exchange. See section 11.4.2 for details.
before sending a DHCP Solicit to a server. 12.5.6. Receipt of Reply messages
Default: 1 second Upon the receipt of a valid Reply message, the client extracts
the contents of the ``extension'' field, and sets (or resets)
configuration parameters appropriately. If the configuration
parameters changed were requested by the application layer, the
client notifies the application layer of the changes using an
implementation-specific interface. If the resources changed are
releasable, the client makes the appropriate adjustments to its
management of the leases of these resources.
13. Using DHCP for network renumbering
MAX_SOLICIT_DELAY An administrator can use DHCP to renumber links within her DHCP
domain through two techniques, passive renumbering and active
renumbering.
The maximum amount of time a prospective client is required to 13.1. Passive Renumbering
wait, after determining from a Router Advertisement message
that the client should perform stateful address configuration,
before sending a DHCP Solicit to a server.
Default: 5 seconds The administrator can configure her servers to return relatively
XID_TIMEOUT short preferred and valid lifetimes for the IP addresses she
makes available to clients. When she determines that she'd like
to renumber a network, she configures her servers through an
implementation-specific manner to disallow the extension of the IP
address lifetimes on the original network, and adds the new network
configuration data to the server's database.
The amount of time a DHCP server has to keep track of The clients on the original network will fail to acquire lifetime
client transaction-IDs in order to make sure that client extensions on their IP addresses, and will request and acquire
retransmissions using the same transaction-ID are idempotent. IP addresses from the new network when the valid lifetime of the
original IP addresses approaches expiration.
Default: 600 seconds When the lifetimes for all of the IP addresses on the original
network expire, the network can be considered renumbered.
13.2. Active Renumbering
9. Security Considerations The administrator can force the renumbering of networks in her DHCP
domain by using the reconfigure feature of DHCP. She instructs her
servers of the network renumbering through an implementation-specific
interface. The servers in the domain will generate Reconfigure-init
messages, which will cause the clients to initiate a Request/Reply
transaction with the server. The servers will include two IP address
extensions for each IP address being changed. The first will contain
the original IP address, with the preferred and valid lifetimes set
to zero. The second will contain the new IP address, with non-zero
preferred and valid lifetimes.
A server implementation MAY permit the administrator to set the
original IP address lifetimes to some small value greater than zero,
to allow applications running on the client to orderly transfer to
the new network over time.
14. DHCP Client Implementator Notes
This section provides helpful information for the client implementor
regarding their implementations. The text described here is not part
of the protocol, but rather a discussion of implementation features
we feel the implementor should consider during implementation.
14.1. Primary Interface
Since configuration parameters acquired through DHCP can be
interface-specific or more general, the client implementor SHOULD
provide a mechanism by which the client implementation can be
configured to specify which interface is the primary interface. The
client SHOULD always query the DHCP data associated with the primary
interface for non-interface specific configuration parameters. An
implementation MAY implement a list of interfaces which would be
scanned in order to satisfy the general request. In either case, the
first interface scanned is considered the primary interface.
By allowing the specification of a primary interface, the client
implementor identifies which interface is authoritative for
non-interface specific parameters, which prevents configuration
information ambiguity within the client implementation.
14.2. Advertise Message and Configuration Parameter Caching
If the hardware the client is running on permits it, the implementor
SHOULD provide a cache for Advertise messages and a cache of
configuration parameters received through DHCP. Providing these
caches prevents unnecessary DHCP traffic and the subsequent load
this generates on the servers. The implementor SHOULD provide a
configuration knob for setting the amount of time the cache(s) are
valid.
14.3. Time out and retransmission variables
Note that the client time out and retransmission variables outlined
in section 3.5 can be configured on the server and sent to the client
through the use of the ``DHCP Retransmission Parameter Extension'',
which is documented in the ``extensions document'' [2]. A client
implementation SHOULD be able to reset these variables using the
values from this extension.
14.4. Server Preference
A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
Solicit message to collect Advertise messages and compare their
preferences (see section 15.3), unless it receives an Advertise
message with a preference of 255. If the client receives an
Advertise message with a preference of 255, then the client MAY act
immediately on that Advertise without waiting for any more additional
Advertise messages.
15. DHCP Server Implementator Notes
This section provides helpful information for the server implementor.
15.1. Client Bindings
A server implementation can use the client's link-local address
and the subnet prefix specification from which the client sent its
Request message(s) as an index for finding configuration parameters
assigned to the client. While it isn't critical to keep track
of which clients were given information (resources) that isn't
releasable, it IS critical for the server to keep track of which
client it has assigned releasable resources. The server MUST
include the transaction-ID from the client's Request along with
the releasable resource identifier(s) within the binding. This is
done so that the server can detect whether a client Request is a
retransmission of an earlier Request or an entirely new Request.
The server should periodically scan its bindings for releasable
resources whose leases have expired. When the server finds expired
resource assignments, it MUST delete these assignments, thereby
making these resources available to other clients.
The client bindings MUST be stored in non-volatile storage.
The server implementation should provide policy knobs to control
whether or not the lease on a releasable resource is renewable, and
by how long.
15.2. Reconfigure Considerations
A server implementation MUST provide an interface to the
administrator for initiating reconfigure events.
A server implementation may provide a mechanism for allowing the
specification of how many clients comprise a reconfigure multicast
group. This enables the administrator to control the hit a server
takes when a reconfigure event occurs.
15.3. Server Preference
The server implementation SHOULD allow the setting of a server
preference value by the administrator. The server preference
variable is an unsigned single octet value (0--255), with the lowest
preference being 0 and the highest 255. Clients will choose higher
preference servers over those with lower preference values. If you
don't choose to implement this feature in your server, you MUST set
the server preference field to 0 in the Advertise messages generated
by your server.
15.4. Request Message Transaction-ID Cache
In order to improve performance, a server implementation MAY include
an in memory transaction-ID cache. This cache is indexed by client
binding and transaction-ID, and enables the server to quickly
determine whether a Request is a retransmission or a new Request
without the cost of a database lookup. If an implementor chooses to
implement this cache, then they SHOULD provide a configuration knob
to tune the lifetime of the cache entries.
16. DHCP Relay Implementator Notes
A relay implementation SHOULD allow the specification of a list of
destination addresses for Solicit messages. This list MAY contain
any mixture of unicast addresses and multicast addresses.
If a relay receives an ICMP message in response to a DHCP message it
has forwarded, it SHOULD log this event.
17. Open Issues for Working Group Discussion
This section contains some items for discussion by the working group.
17.1. Trade-offs: Optional fields in DHCP messages
You'll notice that the message formats have changed. In particular,
some of the optional fields are now required. This will increase the
size of DHCP messages in some cases, consuming network bandwidth and
memory on the DHCP client (an issue for small devices such as PDAs).
The changes were made for the following reasons:
o Fields that were used most of the time were made required.
o Some fields that were optional were either made required or added
to messages which previously didn't have them. This was done for
robustness reasons (receivers can validate that the message is
for them, and in the case of clients, know which interface the
message is intended for).
o Simplicity.
Please look at the messages as they are now defined, and let us know
your opinion.
17.2. Use DHCPv4 authentication or the current DHCPv6 method?
Now that the DHCPv4 authentication draft is in last call, should
we use the technique described in that document to provide
authentication for DHCPv6, or should we continue with the
authentication technique currently documented in the extensions
draft?
17.3. The Reconfigure Message and Subnet Prefix Extensions
The drafts currently specify that Releasable resources (such as an IP
address) can only be reconfigured using the Reconfigure-init trigger
message. This was done for simplicity (enables clients to perform
DAD on the new address and return the appropriate result to the
server) using the same mechanism as a standard Request/Reply/Release
exchange. This method also makes no assumptions about the
charactistics of the releasable resource.
However, for IP addresses with interface IDs, one could send out
two IP address extensions, one for the old prefix and one for the
new, and cause clients to change the prefix and thus renumber over
time. This scheme avoids the added DHCP Request traffic - clients
acknowledge with a Reconfigure-reply message.
17.4. ``R'' bit in Request message not needed?
Now that the transaction-ID is stored along with the releasable
resource identifier in a client's binding, the transaction-ID cache
becomes an optional feature of the DHCP server implementation, not a
requirement of the protocol. Should we do away with the ``R'' bit?
18. Security Considerations
Clients and servers often have to authenticate the messages they Clients and servers often have to authenticate the messages they
exchange. For instance, a server may wish to be certain that a DHCP exchange. For instance, a server may wish to be certain that a
Request originated from the client identified by the <link-local Request originated from the client identified by the <link-local
address, agent-address> fields included within the Request message address, subnet-prefix> fields included within the Request message
header. Conversely, it is quite often essential for a client to header. Conversely, it is quite often essential for a client to
be certain that the configuration parameters and addresses it has be certain that the configuration parameters and addresses it has
received were sent to it by an authoritative server. Similarly, a received were sent to it by an authoritative server. Similarly, a
server should only accept a DHCP Release message which seems to be server should only accept a Release message which seems to be from
from one of its clients, if it has some assurance that the client one of its clients, if it has some assurance that the client actually
actually did transmit the Release message. Again, a client might did transmit the Release message. Again, a client might wish to only
wish to only accept DHCP Reconfigure messages that are certain to accept Reconfigure or Reconfigure-init messages that are certain to
have originated from a server with authority to issue them. have originated from a server with authority to issue them.
The IPv6 Authentication Header can provide security for DHCPv6 The IPv6 Authentication Header can provide security for DHCPv6
messages when both endpoints have a suitable IP address. However, messages when both endpoints have a suitable IP address. However,
a client often has only a link-local address, and such an address a client often has only a link-local address, and such an address
is not sufficient for a server which is off-link. In those is not sufficient for a server which is off-link. In those
circumstances the DHCP relay is involved, so that the DHCP message circumstances the relay is involved, so that the DHCP message MUST
MUST have the relay's address in the IP destination address field, have the relay's address in the IP destination address field, even
even though the client aims to deliver the message to the server. though the client aims to deliver the message to the server. The
The DHCP Client-Server Authentication Extension [15] is intended to DHCP Client-Server Authentication Extension [2] is intended to be
be used in these circumstances. used in these circumstances.
Note that, if a client receives a DHCP message which fails Note that, if a client receives a DHCP message which fails
authentication, it should continue to wait for another message which authentication, it should continue to wait for another message which
might be correctly authenticated just as if the failed message had might be correctly authenticated just as if the failed message had
never arrived; however, receiving such failed messages SHOULD be never arrived; however, receiving such failed messages SHOULD be
logged. logged.
19. Year 2000 considerations
10. Year 2000 considerations
Since all times are relative to the current time of the transaction, Since all times are relative to the current time of the transaction,
there is no problem within the DHCPv6 protocol related to any there is no problem within the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the current year. hardcoded dates or two-digit representation of the current year.
20. IANA Considerations
11. IANA Considerations This document defines message types 1--8 to be received by UDP at
port numbers 546 and 547. Additional message types may be defined in
This document defines message types 1-7 to be received by UDP at port the future.
numbers 546 and 547. Additional message types may be defined in the
future.
Section 3.3 specifies the use of several multicast groups, with Section 3.1 lists several multicast addresses used by DHCP.
multicast addresses FF02:0:0:0:0:0:1:2, FF05:0:0:0:0:0:1:3, and
FF05:0:0:0:0:0:1:4.
This document also defines several status codes that are to be This document also defines several status codes that are to
returned with the DHCP Reply message (see section 4.4). The nonzero be returned with the Reply and Reconfigure-reply messages (see
values for these status codes which are currently specified are shown sections 9.4 and 9.7). The non-zero values for these status codes
in section 2.4. which are currently specified are shown in the table in section 3.4.
There is a DHCPv6 extension [15] which allows clients and servers to There is a DHCPv6 extension [2] which allows clients and servers to
exchange values for some of the timing and retransmission parameters exchange values for some of the timing and retransmission parameters
defines in section 8. Adding new parameters in the future would defined in section 3.5. Adding new parameters in the future would
require extending the values by which the parameters are indicated in require extending the values by which the parameters are indicated in
the DHCP extension. Since there needs to be a list kept, the default the DHCP extension. Since there needs to be a list kept, the default
values for each parameter should also be stored as part of the list. values for each parameter should also be stored as part of the list.
All of these protocol elements may be specified to assume new values All of these protocol elements may be specified to assume new values
at some point in the future. New values should be approved by the at some point in the future. New values should be approved by the
process of IETF Consensus [12]. process of IETF Consensus [11].
21. Acknowledgements
12. Acknowledgements
Thanks to the DHC Working Group for their time and input into the Thanks to the DHC Working Group for their time and input into the
specification. Ralph Droms and Thomas Narten have had a major specification. Ralph Droms and Thomas Narten have had a major
role in shaping the continued improvement of the protocol by their role in shaping the continued improvement of the protocol by their
careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald
Maguire, and Mike Carney for their studied review as part of the Maguire, and Mike Carney for their studied review as part of the
Last Call process. Thanks also for the consistent input, ideas, and Last Call process. Thanks also for the consistent input, ideas, and
review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.
Thanks to Steve Deering and Bob Hinden, who have consistently Thanks to Steve Deering and Bob Hinden, who have consistently
taken the time to discuss the more complex parts of the IPv6 taken the time to discuss the more complex parts of the IPv6
specifications. specifications.
A. Comparison between DHCPv4 and DHCPv6
A. Changes for this revision
- Fixed grammatical and clarity problems.
- Added saved agent-address field to the solicit message and
altered and enhanced references to the C bit use.
- Removed all references of agent-address prefix as it is implied
by the agent-address and can be used as such by implementors.
- Verified all binding dependencies use the link-local address and
agent-address.
- Added clients in what cases SHOULD retain specific addresses when
the client is not stationary.
- Updated DHCP terminology section and re-ordered.
- Put RFC 2119 terms in lower case, in section 3.1.
- Changed definition of transaction-ID and specified ranges for
client and server use.
- Added and fixed text to clarify use of Reconfigure message for
clients in all relevant sections.
- Added words in spec to differentiate format section from
processing section.
- Added retransmission algorithm for Reconfigure multicast messages
and new configuration parameter.
- Differentiated processing for requests by clients when received
from Reconfigure message.
- Added more words when binding cache is used for XID timeout.
- Added exponential backoff to client retransmissions.
- Updated the references section.
B. Related Protocol Specifications
Related work in IPv6 that would best serve an implementor to study
is the IPv6 Specification [7], the IPv6 Addressing Architecture [9],
IPv6 Stateless Address Autoconfiguration [20], IPv6 Neighbor
Discovery Processing [14], and Dynamic Updates to DNS [22]. These
specifications enable DHCP to build upon the IPv6 work to provide
both robust stateful autoconfiguration and autoregistration of DNS
Host Names.
The IPv6 Specification provides the base architecture and design of
IPv6. A key point for DHCP implementors to understand is that IPv6
requires that every link in the internet have an MTU of 1500 octets
or greater (in IPv4 the requirement is 68 octets). This means that
a UDP packet of 536 octets will always pass through an internet
(less 40 octets for the IPv6 header), as long as there are no IP
options prior to the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a
packet greater than 1500 octets it can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [11]
to determine the size of the packet that will traverse a network
path. It is implementation dependent how this is accomplished in
DHCP. Path MTU Discovery for IPv6 is supported for both UDP and TCP
and can cause end-to-end fragmentation when the PMTU changes for a
destination.
The IPv6 Addressing Architecture specification [9] defines the
address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin
communications to discover neighbors on the link. For instance, a
client can send a DHCP Solicit and locate a server or relay.
IPv6 Stateless Address Autoconfiguration [20] (Addrconf) specifies
procedures by which a node may autoconfigure addresses based on
router advertisements [14], and the use of a valid lifetime to
support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with Addrconf is a design
requirement of DHCP (see Section 3.1).
IPv6 Neighbor Discovery [14] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [16]. To understand
IPv6 and Addrconf it is strongly recommended that implementors
understand IPv6 Neighbor Discovery.
Dynamic Updates to DNS [22] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space to
not only support autoconfiguration, but also autoregistration in
IPv6. The security model to be used with DHCPv6 should conform as
closely as possible to the authentication model outlined in [10].
C. Comparison between DHCPv4 and DHCPv6
This appendix is provided for readers who will find it useful to see This appendix is provided for readers who will find it useful to see
a model and architecture comparison between DHCPv4 [8, 1] and DHCPv6. a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6.
There are three key reasons for the differences: There are three key reasons for the differences:
o IPv6 inherently supports a new model and architecture for o IPv6 inherently supports a new model and architecture for
communications and autoconfiguration of addresses. communications and autoconfiguration of addresses.
o DHCPv6 benefits from the new IPv6 features. o DHCPv6 benefits from the new IPv6 features.
o New features were added to support the expected evolution and o New features were added to support the expected evolution and
the existence of more complicated Internet network service the existence of more complicated Internet network service
requirements. requirements.
IPv6 Architecture/Model Changes: IPv6 Architecture/Model Changes:
o The link-local address permits a node to have an address o The link-local address permits a node to have an address
immediately when the node boots, which means all clients have a immediately when the node boots, which means all clients have a
source IP address at all times to locate a server or relay agent source IP address at all times to locate an on-link server or
on the local link. relay.
o The need for BOOTP compatibility and broadcast flags is removed. o The need for BOOTP compatibility and the broadcast flag have been
removed.
o Multicast and address scoping in IPv6 permit the design of o Multicast and address scoping in IPv6 permit the design of
discovery packets that would inherently define their range by the discovery packets that would inherently define their range by the
multicast address for the function required. multicast address for the function required.
o Stateful autoconfiguration has to coexist and integrate with o Stateful autoconfiguration has to coexist and integrate with
stateless autoconfiguration supporting Duplicate Address stateless autoconfiguration supporting Duplicate Address
Detection and the two IPv6 lifetimes, to facilitate the dynamic Detection and the two IPv6 lifetimes, to facilitate the dynamic
renumbering of addresses and the management of those addresses. renumbering of addresses and the management of those addresses.
o Multiple addresses per interface are inherently supported in o Multiple addresses per interface are inherently supported in
IPv6. IPv6.
o Many DHCPv4 options are unnecessary now because the configuration o Some DHCPv4 options are unnecessary now because the configuration
parameters are either obtained through IPv6 Neighbor Discovery or parameters are either obtained through IPv6 Neighbor Discovery or
the Service Location protocol [21]. the Service Location protocol [16].
DHCPv6 Architecture/Model Changes: DHCPv6 Architecture/Model Changes:
o The message type is the first byte in the packet. o The message type is the first byte in the packet.
o IPv6 Address allocations are now handled in a message extension o IPv6 Address allocations are now handled in a message extension
as opposed to the message header. as opposed to the message header.
o Client/Server bindings are now mandatory and take advantage of o Client/Server bindings are now mandatory and take advantage of
the client's link-local address to always permit communications the client's link-local address to always permit communications
either directly from an on-link server, or from a remote server either directly from an on-link server, or from a off-link server
through an on-link relay-agent. through an on-link relay.
o Servers are discovered by a client solicit, followed by a server o Servers are discovered by a client Solicit, followed by a server
or relay-agent advertisement. Advertise message
o The client will know if the server is on-link or off-link. o The client will know if the server is on-link or off-link.
o The on-link relay-agent locates remote server addresses from o The on-link relay may locate off-link server addresses from
system configuration or by the use of a site wide multicast system configuration or by the use of a site-wide multicast
packet. packet.
o ACKs and NAKs are not used. o ACKs and NAKs are not used.
o The server assumes the client receives its responses unless it o The server assumes the client receives its responses unless it
receives a retransmission of the same client request. This receives a retransmission of the same client request. This
permits recovery in the case where the network has faulted. permits recovery in the case where the network has faulted.
o Clients can issue multiple, unrelated DHCP Request messages to o Clients can issue multiple, unrelated Request messages to the
the same or different servers. same or different servers.
o The function of DHCPINFORM is inherent in the new packet design; o The function of DHCPINFORM is inherent in the new packet design;
a client can request configuration parameters other than IPv6 a client can request configuration parameters other than IPv6
addresses in the optional extension headers. addresses in the optional extension headers.
o Clients MUST listen to their UDP port for the new Reconfigure o Clients MUST listen to their UDP port for the new Reconfigure
message from servers. message from servers.
o New extensions have been defined. o New extensions have been defined.
skipping to change at page 38, line 48 skipping to change at page 52, line 21
o Address deprecation, for dynamic renumbering. o Address deprecation, for dynamic renumbering.
o Relays can be preconfigured with server addresses, or use of o Relays can be preconfigured with server addresses, or use of
multicast. multicast.
o Authentication o Authentication
o Clients can ask for multiple IP addresses. o Clients can ask for multiple IP addresses.
o Addresses allocated with too-long lifetimes can be reclaimed o Addresses can be reclaimed using the Reconfigure-init message.
using the Reconfigure message.
o Integration between stateless and stateful address o Integration between stateless and stateful address
autoconfiguration. autoconfiguration.
o Enabling relay-agents to locate remote servers for a link. o Enabling relays to locate off-link servers.
B. Full Copyright Statement
D. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose or other Internet organizations, except as needed for the purpose
skipping to change at page 39, line 34 skipping to change at page 53, line 6
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
References References
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 2132, March 1997. Extensions. Request for Comments (Draft Standard) 2132,
Internet Engineering Task Force, March 1997.
[2] S. Bradner. Key Words for Use in RFCs to Indicate Requirement [2] J. Bound, M. Carney, and C. Perkins. Extensions for the Dynamic
Levels. RFC 2119, March 1997. Host Configuration Protocol for IPv6.
draft-ietf-dhc-dhcpv6ext-12.txt, May 2000. (work in progress).
[3] S. Bradner and A. Mankin. The Recommendation for the IP Next [3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Generation Protocol. RFC 1752, January 1995. Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[4] A. Conta and S. Deering. Internet Control Message Protocol [4] S. Bradner and A. Mankin. The Recommendation for the IP Next
(ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, Generation Protocol. Request for Comments (Proposed Standard)
December 1995. 1752, Internet Engineering Task Force, January 1995.
[5] A. Conta and S. Deering. RFC 2463: Internet Control Message [5] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Comments 951, Internet Engineering Task Force, September 1985.
Specification, December 1998. Obsoletes RFC1885 [4]. Status:
DRAFT STANDARD.
[6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[7] S. Deering and R. Hinden. RFC 2460: Internet Protocol, Version
6 (IPv6) specification, December 1998. Obsoletes RFC1883 [6].
Status: DRAFT STANDARD.
[8] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March
1997.
[9] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
RFC 2373, July 1998.
[10] S. Kent and R. Atkinson. RFC 2402: IP authentication header,
November 1998. Status: PROPOSED STANDARD.
[11] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP
version 6. RFC 1981, August 1996.
[12] T. Narten and H. Alvestrand. RFC 2434: Guidelines for writing [7] R. Droms. Dynamic Host Configuration Protocol. Request for
an IANA considerations section in RFCs, October 1998. Status: Comments (Draft Standard) 2131, Internet Engineering Task Force,
BEST CURRENT PRACTICE. March 1997.
[13] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
IP version 6 (IPv6). RFC 1970, August 1996. Request for Comments (Proposed Standard) 2373, Internet
Engineering Task Force, July 1998.
[14] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor [9] S. Kent and R. Atkinson. IP Authentication Header. Request for
discovery for IP Version 6 (IPv6), December 1998. Obsoletes Comments (Proposed Standard) 2402, Internet Engineering Task
RFC1970 [13]. Status: DRAFT STANDARD. Force, November 1998.
[15] C. Perkins. Extensions for the Dynamic Host Configuration [10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for
Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-11.txt, February IP version 6. Request for Comments (Proposed Standard) 1981,
1999. (work in progress). Internet Engineering Task Force, August 1996.
[16] David C. Plummer. An Ethernet Address Resolution Protocol: [11] T. Narten and H. Alvestrand. Guidelines for Writing an IANA
Or Converting Network Protocol Addresses to 48.bit Ethernet Considerations Section in RFCs. Request for Comments (Best
Addresses for Transmission on Ethernet Hardware. RFC 826, Current Practice) 2434, Internet Engineering Task Force, October
November 1982. 1998.
[17] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [12] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998.
[18] J. B. Postel, Editor. Internet Protocol. RFC 791, September [13] D. C. Plummer. Ethernet Address Resolution Protocol: Or
1981. converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware. Request for Comments
(Standard) 826, Internet Engineering Task Force, November 1982.
[19] S. Thomson and T. Narten. IPv6 Stateless Address [14] J. Postel. User Datagram Protocol. Request for Comments
Autoconfiguration. RFC 1971, August 1996. (Standard) 768, Internet Engineering Task Force, August 1980.
[20] S. Thomson and T. Narten. RFC 2462: IPv6 stateless address [15] S. Thomson and T. Narten. IPv6 Stateless Address
autoconfiguration, December 1998. Obsoletes RFC1971 [19]. Autoconfiguration. Request for Comments (Draft Standard) 2462,
Status: DRAFT STANDARD. Internet Engineering Task Force, December 1998.
[21] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [16] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. RFC 2165, July 1997. Location Protocol. Request for Comments (Proposed Standard)
2165, Internet Engineering Task Force, June 1997.
[22] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates [17] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic
in the Domain Name System (DNS). RFC 2136, April 1997. Updates in the Domain Name System (DNS UPDATE). Request for
Comments (Proposed Standard) 2136, Internet Engineering Task
Force, April 1997.
Chair's Address Chair's Address
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (570) 577-1145
E-mail: droms@bucknell.edu E-mail: droms@bucknell.edu
Author's Address Author's Address
Questions about this memo can be directed to: Questions about this memo can be directed to:
Jim Bound Charles E. Perkins Jim Bound
Compaq Computer Corporation Sun Microsystems Laboratories Compaq Computer Corporation
110 Spitbrook Road, ZKO3-3/U14 15 Network Circle Mail Stop: ZK03-3/U14
Nashua, NH 03062 Menlo Park, CA 94025 110 Spitbrook Road
USA USA Nashua, NH 03062
USA
Phone: +1-603-884-0400
Email: bound@zk3.dec.com
Phone: +1-603-884-0400 Phone: +1 650 786-6464 Mike Carney
EMail: bound@zk3.dec.com EMail: cperkins@eng.sun.com Sun Microsystems, Inc
Fax: +1 650 786-6445 Mail Stop: UMPK17-202
901 San Antonio Road
Palo Alto, CA 94303-4900
USA
Phone: +1-650-786-4171
Email: mwc@eng.sun.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/