draft-ietf-dhc-dhcpv6-13.txt   draft-ietf-dhc-dhcpv6-14.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 C. Perkins
Obsoletes: draft-ietf-dhc-dhcpv6-12.txt Sun Microsystems Obsoletes: draft-ietf-dhc-dhcpv6-13.txt Sun Microsystems Laboratories
28 June 1998 25 February 1999
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-13.txt draft-ietf-dhc-dhcpv6-14.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 should be submitted to the dhcp-v6@bucknell.edu mailing Comments 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. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
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
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."
To view the entire list of current Internet-Drafts, please check The list of current Internet-Drafts can be accessed at:
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern http://www.ietf.org/ietf/1id-abstracts.txt
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCPv6) enables DHCP The Dynamic Host Configuration Protocol (DHCPv6) enables DHCP
servers to pass configuration information, via extensions, to IPv6 servers to pass configuration information, via extensions, to IPv6
nodes. It offers the capability of automatic allocation of reusable nodes. It offers the capability of automatic allocation of reusable
network addresses and additional configuration flexibility. This network addresses and additional configuration flexibility. This
protocol is a stateful counterpart to the IPv6 Stateless Address protocol is a stateful counterpart to the IPv6 Stateless Address
Autoconfiguration protocol, and can be used separately or together Autoconfiguration protocol, and can be used separately or together
with the latter to obtain configuration information. with the latter to obtain configuration information.
skipping to change at page 1, line 63 skipping to change at page 1, line 67
2. Terminology and Definitions 2 2. Terminology and Definitions 2
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3 2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3
2.3. Specification Language . . . . . . . . . . . . . . . . . 4 2.3. Specification Language . . . . . . . . . . . . . . . . . 4
2.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Design Model 4 3. Protocol Design Model 4
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 5 3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Request/Response Processing Model . . . . . . . . . . . . 6 3.3. Request/Response Processing Model . . . . . . . . . . . . 7
4. DHCP Message Formats and Field Definitions 7 4. DHCP Message Formats and Field Definitions 8
4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8
4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9 4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9
4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10 4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10
4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12
4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13 4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13
4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 15
5. DHCP Client Considerations 15 5. DHCP Client Considerations 16
5.1. Verifying Resource Allocations After Restarts . . . . . . 15 5.1. Verifying Resource Allocations After Restarts . . . . . . 16
5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16 5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16
5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 16 5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 17
5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 17 5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 18
5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 19 5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 20
5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 19 5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 20
5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 20 5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 21
5.8. Interaction with Stateless Address Autoconfiguration . . 21 5.8. Interaction with Stateless Address Autoconfiguration . . 22
6. DHCP Server Considerations 21 6. DHCP Server Considerations 23
6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 22 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 23
6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 22 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 24
6.3. DHCP Request and Reply Message Processing . . . . . . . . 23 6.3. DHCP Request and Reply Message Processing . . . . . . . . 24
6.3.1. Processing for Extensions to DHCP Request and Reply 6.3.1. Processing for Extensions to DHCP Request and Reply
Messages . . . . . . . . . . . . . . . . . 24 Messages . . . . . . . . . . . . . . . . . 25
6.3.2. Client Requests to Deallocate Unknown Resources . 24 6.3.2. Client Requests to Deallocate Unknown Resources . 26
6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 25 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 26
6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 26 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 27
6.6. Client-Resource timeouts . . . . . . . . . . . . . . . . 26 6.6. Client-Resource timeouts . . . . . . . . . . . . . . . . 28
7. DHCP Relay Considerations 26 7. DHCP Relay Considerations 28
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 27 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 28
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 27 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 29
7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 28 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 30
8. Retransmission and Configuration Variables 28 8. Retransmission and Configuration Variables 30
9. Security Considerations 31 9. Security Considerations 33
10. Year 2000 considerations 32 10. Year 2000 considerations 33
11. IANA Considerations 32 11. IANA Considerations 34
12. Acknowledgements 32 12. Acknowledgements 34
A. Changes for this revision 33 A. Changes for this revision 34
B. Related Protocol Specifications 33 B. Related Protocol Specifications 35
C. Comparison between DHCPv4 and DHCPv6 34 C. Comparison between DHCPv4 and DHCPv6 37
D. Full Copyright Statement 37 D. Full Copyright Statement 40
Chair's Address 40 Chair's Address 43
Author's Address 40 Author's Address 43
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol (DHCPv6, or in this The Dynamic Host Configuration Protocol (DHCPv6, or in this
document usually DHCP) provides configuration parameters to Internet document usually DHCP) provides configuration parameters to Internet
nodes. DHCP consists of a protocol for delivering node-specific nodes. DHCP consists of a protocol for delivering node-specific
configuration parameters from a DHCP server to a client, and configuration parameters from a DHCP server to a client, and
extensions for allocation of network addresses and other related extensions for allocation of network addresses and other related
parameters to IPv6 [6] nodes. parameters to IPv6 [7] nodes.
DHCP uses a client-server model, where designated DHCP servers DHCP uses a client-server model, where designated DHCP servers
automatically allocate network addresses and deliver configuration automatically allocate network addresses and deliver configuration
parameters to dynamically configurable clients. Throughout the parameters to dynamically configurable clients. Throughout the
remainder of this document, the term "server" refers to a node remainder of this document, the term "server" refers to a node
providing initialization parameters by way of the DHCP protocol, providing initialization parameters by way of the DHCP protocol,
and the term "client" refers to a node requesting initialization and the term "client" refers to a node requesting initialization
parameters from a DHCP server. parameters from a DHCP server.
DHCPv6 uses Request and Reply messages to support a client/server DHCPv6 uses Request and Reply messages to support a client/server
processing model whereby both client and server are assured that processing model whereby both client and server are assured that
requested configuration parameters have been received and accepted requested configuration parameters have been received and accepted
by the client. DHCP supports optional configuration parameters and by the client. DHCP supports optional configuration parameters and
processing for nodes through extensions described in its companion processing for nodes through extensions described in its companion
document ``Extensions for the Dynamic Host Configuration Protocol for document ``Extensions for the Dynamic Host Configuration Protocol for
IPv6'' [13]. IPv6'' [15].
The IPv6 Addressing Architecture [8] and IPv6 Stateless Address The IPv6 Addressing Architecture [9] and IPv6 Stateless Address
Autoconfiguration [17] specifications provide new features not Autoconfiguration [20] specifications provide new features not
available in IP version 4 (IPv4) [16], which are used to simplify available in IP version 4 (IPv4) [18], which are used to simplify
and generalize the operation of DHCP clients. This document is and generalize the operation of DHCP clients. This document is
intended to complement those specifications for clients attached to intended to complement those specifications for clients attached to
the kinds of Internet media for which those specifications apply. In the kinds of Internet media for which those specifications apply. In
particular, the specification in this document does not necessarily particular, the specification in this document does not necessarily
apply to nodes which do not enjoy a bidirectional link to the apply to nodes which do not enjoy a bidirectional link to the
Internet. Internet.
Section 2 provides definitions for terminology used throughout Section 2 provides definitions for terminology used throughout
this document. Section 3 provides an overview of the protocol this document. Section 3 provides an overview of the protocol
design model that guided the design choices in the specification; design model that guided the design choices in the specification;
skipping to change at page 2, line 7 skipping to change at page 2, line 7
how clients, servers, and relays respectively interact. The timeout how clients, servers, and relays respectively interact. The timeout
and retransmission guidelines as well as configuration variables for and retransmission guidelines as well as configuration variables for
DHCP protocol operations are discussed in Section 8. Appendix B DHCP protocol operations are discussed in Section 8. Appendix B
summarizes related work in IPv6 that will provide helpful context; summarizes related work in IPv6 that will provide helpful context;
it is not part of this specification, but included for informational it is not part of this specification, but included for informational
purposes. Appendix C discusses the differences between DHCPv4 and purposes. Appendix C discusses the differences between DHCPv4 and
DHCPv6. DHCPv6.
2. Terminology and Definitions 2. Terminology and Definitions
Relevant terminology from the IPv6 Protocol [6], IPv6 Addressing Relevant terminology from the IPv6 Protocol [7], IPv6 Addressing
Architecture [8], and IPv6 Stateless Address Autoconfiguration [17] Architecture [9], and IPv6 Stateless Address Autoconfiguration [20]
is given, followed by DHCPv6 terminology. is given, followed by DHCPv6 terminology.
2.1. IPv6 Terminology 2.1. IPv6 Terminology
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
skipping to change at page 3, line 22 skipping to change at page 3, line 22
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. DHCPv6 Terminology 2.2. DHCPv6 Terminology
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) containing the data
which a DHCP server maintains for each of its clients which a DHCP server maintains for each of its clients
(see Section 6). (see Section 6).
resource-server association resource-server association
An association between a resource and a DHCP server, An association between a resource and a DHCP server,
maintained by the client which received that resource maintained by the client which received that resource
from that DHCP server. from that DHCP server.
configuration parameter configuration parameter
Any parameter that can be used by a node to configure Any parameter that can be used by a node to configure
its network subsystem and enable communication on a its network subsystem and enable communication on a
link or internetwork. link or internetwork.
DHCP agent (or agent)
Either a DHCP server or a DHCP relay.
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.
DHCP server (or server)
A server is a node that responds to requests from
clients, and may or may not be on the same link as as
the client.
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. messages between clients and servers, and is on the
same link as a client.
DHCP server (or server) DHCP agent (or agent)
A server is a node that responds to requests from Either a DHCP server on the same link as a client, or a
clients DHCP relay.
transaction-ID transaction-ID
A monotonically increasing unsigned integer used to An unsigned integer to match responses with replies
match a response to a pending message. initiated either by a client or server. Clients MUST
use integers from 1 to 1000, and servers use integers
greater than 1000 for transaction-ID's.
2.3. Specification Language 2.3. Specification Language
In this document, the words MUST, MUST NOT, SHOULD, SHOULD NOT, and In this document, the words MUST, MUST NOT, SHOULD, SHOULD NOT, and
MAY are used to signify the requirements of the specification, in MAY are used to signify the requirements of the specification, in
accordance with RFC 2119 [2]. accordance with RFC 2119 [2].
2.4. Error Values 2.4. Error Values
This specification document uses symbolic names for the errors known This specification document uses symbolic names for the errors known
skipping to change at page 4, line 46 skipping to change at page 5, line 5
This section is provided for implementors to understand the DHCPv6 This section is provided for implementors to understand the DHCPv6
protocol design model from an architectural perspective. Goals and protocol design model from an architectural perspective. Goals and
conceptual models are presented in this section. conceptual models are presented in this section.
3.1. Design Goals 3.1. Design Goals
The following list gives general design goals for this DHCP The following list gives general design goals for this DHCP
specification. specification.
- DHCP should be a mechanism rather than a policy. DHCP MUST allow - DHCP should be a mechanism rather than a policy. DHCP must allow
local system administrators control over configuration parameters local system administrators control over configuration parameters
where desired; e.g., local system administrators should be able where desired; e.g., local system administrators should be able
to enforce local policies concerning allocation and access to to enforce local policies concerning allocation and access to
local resources where desired. local resources where desired.
- DHCP MUST NOT require manual configuration of DHCP clients, - DHCP must not require manual configuration of DHCP clients,
except as dictated by security requirements. Each node should be except as dictated by security requirements. Each node should be
able to obtain appropriate local configuration parameters without able to obtain appropriate local configuration parameters without
user intervention. user intervention.
- DHCP MUST NOT require a server on each link. To allow for scale - DHCP must not require a server on each link. To allow for scale
and economy, DHCP MUST work across DHCP relays. and economy, DHCP must work across DHCP relays.
- In some installations, clients on certain subnets can be served - In some installations, clients on certain subnets can be served
by more than one DHCP server, improving reliability and/or by more than one DHCP server, improving reliability and/or
performance. Therefore, a DHCP client MUST be prepared to performance. Therefore, a DHCP client must be prepared to
receive multiple (possibly different) responses to a DHCP Solicit receive multiple (possibly different) responses to a DHCP Solicit
message. message.
- DHCP MUST coexist with statically configured, non-participating - DHCP must coexist with statically configured, non-participating
nodes and with existing network protocol implementations. nodes and with existing network protocol implementations.
- DHCPv6 MUST be compatible with IPv6 Stateless Address - DHCPv6 must be compatible with IPv6 Stateless Address
Autoconfiguration [17]. Autoconfiguration [20].
- A DHCPv6 Client implementation MAY be started in the absence of - A DHCPv6 Client implementation may be started in the absence of
any IPv6 routers on the client's link. any IPv6 routers on the client's link.
- DHCP architecture MUST support automated renumbering of IP - DHCP architecture must support automated renumbering of IP
addresses [3]. addresses [3].
- DHCP servers SHOULD be able to support Dynamic Updates to - DHCP servers should be able to support Dynamic Updates to
DNS [20]. DNS [22].
- DHCP servers MUST be able to support multiple IPv6 addresses for - DHCP servers must be able to support multiple IPv6 addresses for
each client. each client.
On the other hand, a DHCP server to server protocol is NOT part of On the other hand, a DHCP server to server protocol is NOT part of
this specification. Furthermore, it is NOT a design goal of DHCP to this specification. Furthermore, it is NOT a design goal of DHCP to
specify how a server configuration parameter database is maintained specify how a server configuration parameter database is maintained
or determined. Methods for configuring DHCP servers are outside the or determined. Methods for configuring DHCP servers are outside the
scope of this document. scope of this document.
3.2. DHCP Messages 3.2. DHCP Messages
Each DHCP message contains a type, which defines its function within Each DHCP message contains a type, which defines its function within
the protocol. Formats for the messages are found in section 4. the protocol. Formats for the messages are found in section 4, with
Processing details for these DHCP messages are specified in an initial description and discussion. Processing details for these
Sections 5, 6, and 7. The message types are as follows: DHCP messages are specified in Sections 5, 6, and 7. The message
types are as follows:
01 DHCP Solicit 01 DHCP Solicit
The DHCP Solicit message is an IP multicast message sent by a The DHCP Solicit message is an IP multicast message sent by a
client to one or more agents, or forwarded by a relay to one or client to one or more agents, or forwarded by a relay to one or
more servers. more servers.
02 DHCP Advertise 02 DHCP Advertise
The DHCP Advertise is an IP unicast message sent by a DHCP The DHCP Advertise is an IP unicast message sent by a DHCP
skipping to change at page 6, line 25 skipping to change at page 6, line 28
03 DHCP Request 03 DHCP Request
The DHCP Request is an IP unicast message sent by a client to a The DHCP Request is an IP unicast message sent by a client to a
server to request configuration parameters on a network. server to request configuration parameters on a network.
04 DHCP Reply 04 DHCP Reply
The DHCP Reply is an IP unicast message sent by a server in The DHCP Reply is an IP unicast message sent by a server in
response to a client's DHCP Request, or by the relay that response to a client's DHCP Request, or by the relay that
relayed that client's DHCP Request. Extensions [13] to the relayed that client's DHCP Request. Extensions [15] to the
DHCP Reply describe the resources that the server has committed DHCP Reply describe the resources that the server has committed
and allocated to this client, and may contain other information and allocated to this client, and may contain other information
for use by this client. for use by this client.
05 DHCP Release 05 DHCP Release
The DHCP Release is an IP unicast message sent by a client to The DHCP Release is an IP unicast message sent by a client to
inform the server that the client is releasing resources. inform the server that the client is releasing resources.
06 DHCP Reconfigure 06 DHCP Reconfigure
The DHCP Reconfigure is an IP unicast or multicast message sent The DHCP Reconfigure is an IP unicast or multicast message sent
by a server to inform one or more clients that the server has by a server to inform one or more clients that the server has
new configuration information of importance to the client. new configuration information of importance to the client.
Each client is expected to initiate a new Request/Reply Each client is expected to initiate a new DHCP Request in
transaction. response to the Reconfiure message.
DHCP message types not defined here (msg-types 0 and 7-255) are DHCP message types not defined here (msg-types 0 and 7-255) are
reserved and SHOULD be silently ignored. reserved and SHOULD be silently ignored.
3.3. Request/Response Processing Model 3.3. Request/Response Processing Model
The request/response processing for DHCPv6 is transaction based and The request/response processing for DHCPv6 is transaction based and
uses a set of best-effort messages to complete the transaction. uses a set of best-effort messages to complete the transaction.
To find a server, a client sends a DHCP Solicit from the interface To find a server, a client sends a DHCP Solicit from the interface
skipping to change at page 7, line 17 skipping to change at page 7, line 25
then unicasts a DHCP Reply, possibly via a relay. At this point in 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 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 received. To provide a method of recovery if either the client or
server does not receive its messages, the client retransmits each server does not receive its messages, the client retransmits each
DHCP Request message until it elicits the corresponding DHCP Reply, DHCP Request message until it elicits the corresponding DHCP Reply,
or until it can be reasonably certain that the desired DHCP server or until it can be reasonably certain that the desired DHCP server
is unavailable, or it determines that it does not want a response is unavailable, or it determines that it does not want a response
(i.e., it MAY abort the transaction). The timeout and retransmission (i.e., it MAY abort the transaction). The timeout and retransmission
guidelines and configuration variables are discussed in Section 8. guidelines and configuration variables are discussed in Section 8.
DHCP uses UDP [15] to communicate between clients and servers. UDP DHCP uses UDP [17] to communicate between clients and servers. UDP
is not reliable, but the DHCP retransmission scheme just described is not reliable, but the DHCP retransmission scheme just described
provides reliability between clients and servers. The following provides reliability between clients and servers. The following
well-known multicast addresses are used by DHCP agents and clients: well-known multicast addresses are used by DHCP agents and clients:
FF02:0:0:0:0:0:1:2 FF02:0:0:0:0:0:1:2
All DHCP Agents (servers and relays) MUST join the All DHCP Agents (servers and relays) MUST join the
link-local All-DHCP-Agents multicast group at the address link-local All-DHCP-Agents multicast group at the address
FF02:0:0:0:0:0:1:2. FF02:0:0:0:0:0:1:2.
FF05:0:0:0:0:0:1:3 FF05:0:0:0:0:0:1:3
skipping to change at page 7, line 43 skipping to change at page 7, line 51
All DHCP relays MUST join the site-local All-DHCP-Relays All DHCP relays MUST join the site-local All-DHCP-Relays
multicast group at the address FF05:0:0:0:0:0:1:4. 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 A DHCP server or agent MUST transmit all messages to DHCP clients on
UDP port 546. A DHCP client MUST transmit all messages to a DHCP UDP port 546. A DHCP client MUST transmit all messages to a DHCP
agent over UDP using port 547. A DHCP server MUST transmit all agent over UDP using port 547. A DHCP server MUST transmit all
messages to DHCP relays over UDP on port 546. The source port for messages to DHCP relays over UDP on port 546. The source port for
DHCP messages is arbitrary. DHCP messages is arbitrary.
For the proper operation of the DHCP protocol to operate within a For the proper operation of the DHCP protocol to operate within a
network where one or more firewalls [4] are used, DHCP transactions network where one or more firewallsare used, DHCP transactions sent
sent to the IP addresses of DHCP servers at UDP destination ports 546 to the IP addresses of DHCP servers at UDP destination ports 546 and
and 547 will need to be permitted. 547 will need to be permitted.
4. DHCP Message Formats and Field Definitions 4. DHCP Message Formats and Field Definitions
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.
4.1. DHCP Solicit Message Format 4.1. DHCP Solicit Message Format
A client transmits a DHCP Solicit message over the interface to be A client transmits a DHCP Solicit message over the interface to be
configured, to obtain one or more server addresses. configured, to obtain one or more server addresses. Unless otherwise
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 |C| reserved | prefix-size | | msg-type = 1 |C| reserved | prefix-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
msg-type 1 | (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 resources associated with
the client. the client. If set, the client SHOULD provide a saved
agent-address to locate the clients binding by a
server.
prefix-size A nonzero prefix-size is the number of leftmost bits prefix-size A nonzero prefix-size is the number of leftmost bits
of the agent's IPv6 address which make up the routing of the agent's IPv6 address which make up the routing
prefix. prefix. The prefix-size field is set by the DHCP relay
if the relay receives the solicitation and forwards it
to one or more DHCP Servers.
reserved 0 reserved 0
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 from
which the client issued the DHCP Request message which the client issued the DHCP Request message
relay-address relay-address
If nonzero, the IP address of the interface on which Set by the client to be zero. If received by a DHCP
the relay received the client's DHCP Solicit message relay, set by the relay to the IP address of the
interface on which the relay received the client's DHCP
Solicit message
saved agent-address
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 SHOULD send a DHCP Solicit message to the All-DHCP-Agents
multicast group (see section 3.3), setting the relay-address to multicast group (see section 3.3), setting the relay-address to
zero. Any relay receiving the solicitation MUST forward it to the zero. Any relay receiving the solicitation MUST forward it to the
All-DHCP-Servers multicast group. In that case, the relay MUST copy 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 a non-link-local address of its interface from which the client's
solicitation was received into the relay-address field. Servers solicitation was received into the relay-address field. Servers
receiving the solicitation then send their advertisements to the receiving the solicitation then send their advertisements to the
prospective client. prospective client.
4.2. DHCP Advertise Message Format 4.2. DHCP Advertise Message Format
A DHCP agent sends a DHCP Advertise message to inform a prospective A DHCP agent sends a DHCP Advertise message to inform a prospective
client about the IP address of a server to which a DHCP Request client about the IP address of a server to which a DHCP Request
message may be sent. When the client and server are on different message may be sent. When the client and server are on different
links, the server sends the advertisement back through the relay links, the server sends the advertisement back through the relay
whence the solicitation came. whence the solicitation came. The value of all fields in the DHCP
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 |S| reserved | preference | | msg-type = 2 |S| reserved | preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent-address | | agent-address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address | | server-address |
| (16 octets, if present) | | (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ... | extensions (variable number and length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 2
S If set, the server-address is present. S If set, the server-address is present.
reserved 0 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 (see Section 5.3).
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 DHCP Request message
agent-address agent-address
The IP address of a DHCP Agent interface on the same The IP address of a DHCP Agent interface on the same
link as the client. link as the client.
skipping to change at page 9, line 50 skipping to change at page 10, line 18
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 DHCP Request message
agent-address agent-address
The IP address of a DHCP Agent interface on the same The IP address of a DHCP Agent interface on the same
link as the client. link as the client.
server-address server-address
If present, the IP address of the DHCP server If present, the IP address of the DHCP server
extensions See [13]. extensions See [15].
Suppose that a server on the same link as a client issues the Suppose that a server on the same link as a client issues the
DHCP Advertise in response to a DHCP Solicit message sent to the DHCP Advertise in response to a DHCP Solicit message sent to the
All-DHCP-Agents multicast address. Then the agent-address will be an 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 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 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 of the server-address in the DHCP Advertise message. See section 5.3
for information about how clients handle the preference field. for information about how clients handle the preference field.
The server MUST copy the client's link-local address into the The server MUST copy the client's link-local address into the
skipping to change at page 10, line 24 skipping to change at page 10, line 42
Moreover, the agent-address of any DHCP Advertise message sent by a Moreover, the agent-address of any DHCP Advertise message sent by a
relay MUST NOT be a link-local address. In situations where there relay MUST NOT be a link-local address. In situations where there
are no routers sending Router Advertisements, then a DHCP server MUST are no routers sending Router Advertisements, then a DHCP server MUST
be configured on the same link as prospective clients. The DHCPv6 be configured on the same link as prospective clients. The DHCPv6
protocol design does not apply to situations where the client is protocol design does not apply to situations where the client is
unable to route messages to a server not on the same link. unable to route messages to a server not on the same link.
4.3. DHCP Request Message Format 4.3. DHCP Request Message Format
In order to request configuration parameters from a server, a client In order to request configuration parameters from a server, a client
sends a DHCP Request message, and MAY append extensions [13]. If sends a DHCP Request message, and MAY append extensions [15]. If
the client does not know any server address, it MUST first obtain the client does not know any server address, it MUST first obtain
one by multicasting a DHCP Solicit message (see Section 4.1). one by multicasting a DHCP Solicit message (see Section 4.1).
Typically, when a client reboots, it does not have a valid IP address Typically, when a client reboots, it does not have a valid IP address
of sufficient scope for the server to communicate with the client. of sufficient scope for the server to communicate with the client.
In such cases, the client MUST NOT send the message directly to In such cases, the client MUST NOT send the message directly to
the server because the server could not return any response to the the server because the server could not return any response to the
client; the client MUST send the message to the local relay and client; the client MUST send the message to the local relay and
insert the relay-address as the agent-address in the message header. insert the relay-address as the agent-address in the message header.
Otherwise, the client MAY omit the server-address in the DHCP Request Otherwise, the client MAY omit the server-address in the DHCP Request
message; in this case, the client MUST clear the S-bit and send the message; in this case, the client MUST clear the S-bit and send the
message directly to the server, using the server's address as the IP message directly to the server, using the server's address as the IP
destination address in the IP header. destination address in the IP header. In either case, 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 |C|S|R| rsvd | transaction-ID | | msg-type = 3 |C|S|R| rsvd | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent-address | | agent-address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address | | server-address |
| (16 octets, if present) | | (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 3
C If set, the client requests the server to remove all C If set, the client requests the server to remove all
resources associated with the client binding, except resources associated with the client binding, except
those resources provided as extensions. those resources provided as extensions.
S If set, the server-address is present S If set, the server-address is present
R If set, the client has rebooted and requests that all R If set, the client has rebooted and requests that all
of its previous transaction-IDs be expunged and made of its previous transaction-IDs be expunged and made
available for re-use. available for re-use.
rsvd 0 rsvd 0
transaction-ID transaction-ID
A monotonically increasing unsigned integer used to A unsigned integer identifier used to identify this
identify this Request, and copied into the Reply. Request.
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 from
which the client issued the DHCP Request message which the client issued the DHCP Request message
agent-address agent-address
The IP address of an agent's interface, copied from a The IP address of an agent's interface, copied from a
DHCP Advertisement message. DHCP Advertisement message.
server-address server-address
If present, the IP address of the server which should If present, the IP address of the server which should
receive the client's DHCP Request message. receive the client's DHCP Request message.
extensions See [13]. extensions See [15].
When the client sets the `C' bit and adds extensions, the server When the client sets the `C' bit and adds extensions, the server
is expected to deallocate all other resources not listed in the is expected to deallocate all other resources not listed in the
extension. The resources explicitly requested in extensions to the extension. The resources explicitly requested in extensions to the
Request message SHOULD be reallocated by the server to the client, Request message SHOULD be reallocated by the server to the client,
assuming the client is still authorized to receive them. assuming the client is still authorized to receive them.
The transaction-ID is selected by the client to be greater than or
equal to 1024, unless the DHCP Request is sent in response to a
Reconfigure msg (see section 4.6). In that case, the transaction-ID
is copied from the transaction-ID in the Reconfigure message.
4.4. DHCP Reply Message Format 4.4. DHCP Reply Message Format
The server sends one DHCP Reply message in response to every DHCP The server sends one DHCP Reply message in response to every DHCP
Request or DHCP Release received. If the request comes with the `S' Request or DHCP Release received. If the request comes with the `S'
bit set, the client could not directly send the Request to the server bit set, the client could not directly send the Request to the server
and had to use a neighboring relay agent. In that case, the server and had to use a neighboring relay agent. In that case, the server
sends back the DHCP Reply with the `L' bit set, and the DHCP Reply is sends back the DHCP Reply with the `L' bit set, and the DHCP Reply
addressed to the agent-address found in the DHCP Request message. If is addressed to the agent-address found in the DHCP Request message.
the `L' bit is set, then the client's link-local address will also be ALl the fields in the DHCP Reply message are set by the DHCP server.
present.
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 |L| status | transaction-ID | | msg-type = 4 |L| status | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets, if present) | | (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 4
L If set, the client's link-local address is present L If set, the client's link-local address is present
status One of the following decimal values: status One of the following decimal values:
0 Success 0 Success
16 Failure, reason unspecified 16 Failure, reason unspecified
17 Authentication failed or nonexistent 17 Authentication failed or nonexistent
18 Poorly formed Request or Release 18 Poorly formed Request or Release
19 Resources unavailable 19 Resources unavailable
20 Client record unavailable 20 Client record unavailable
21 Invalid client IP address in Release 21 Invalid client IP address in Release
23 Relay cannot find Server Address 23 Relay cannot find Server Address
skipping to change at page 12, line 50 skipping to change at page 13, line 17
16 Failure, reason unspecified 16 Failure, reason unspecified
17 Authentication failed or nonexistent 17 Authentication failed or nonexistent
18 Poorly formed Request or Release 18 Poorly formed Request or Release
19 Resources unavailable 19 Resources unavailable
20 Client record unavailable 20 Client record unavailable
21 Invalid client IP address in Release 21 Invalid client IP address in Release
23 Relay cannot find Server Address 23 Relay cannot find Server Address
64 Server unreachable (ICMP error) 64 Server unreachable (ICMP error)
transaction-ID transaction-ID
A monotonically increasing unsigned integer used to An unsigned integer identifier used to identify this
identify this Reply, and copied from the client's Reply, and copied from the client's Request.
Request.
client's link-local address client's link-local address
If present, the IP address of the client interface If present, the IP address of the client interface
which issued the corresponding DHCP Request message. which issued the corresponding DHCP Request message.
extensions extensions
See [13]. See [15].
If the `L' bit is set, and thus the link-local address is present in If the `L' bit is set, the client's link-local address is present
the Reply message, the Reply is sent by the server to the relay's in the Reply message. Then the Reply is sent by the server to the
address which was specified as the agent-address in the DHCP Request relay's address which was specified as the agent-address in the DHCP
message, and the relay uses the link-local address to deliver the Request message, and the relay uses the link-local address to deliver
Reply message to the client. the Reply message to the client. The transaction-ID in the DHCP
Reply is copied by the server from the client Request message.
4.5. DHCP Release Message Format 4.5. DHCP Release Message Format
The DHCP Release message is sent without the assistance of any DHCP The DHCP Release message is sent without the assistance of any DHCP
relay. When a client sends a Release message, it is assumed to have relay. When a client sends a Release message, it is assumed to
a valid IP address with sufficient scope to allow access to the have a valid IP address with sufficient scope to allow access to
target server. If parameters are specified in the extensions, only the target server. If parameters are specified in the extensions,
those parameters are released. The DHCP server acknowledges the only those parameters are released. The values of all fields
Release message by sending a DHCP Reply (Sections 4.4, 6.3). 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 |D| reserved | transaction-ID | | msg-type = 1 |D| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent-address | | agent-address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-address | | client-address |
| (16 octets, if present) | | (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 4 skipping to change at page 14, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 5 msg-type 5
D If the `D' flag is set, the client instructs the server D If the `D' flag is set, the client instructs the server
to send the DHCP Reply directly back to the client, to send the DHCP Reply directly back to the client,
instead of using the given agent-address and link-local instead of using the given agent-address and link-local
address to relay the Reply message. address to relay the Reply message.
reserved 0 reserved 0
transaction-ID transaction-ID
A monotonically increasing unsigned integer used to A unsigned integer identifier used to identify this
identify this Release, and copied into the Reply. Release, and copied into the Reply.
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 from
which the the client issued the DHCP Release message which the the client issued the DHCP Release message
agent-address agent-address
The IP address of the agent interface to which the The IP address of the agent interface for the IP
client issued a previous DHCP Request message address to be released.
client-address client-address
The IP address of the client interface from which The IP address of the client interface from which
the the client issued the DHCP Release message. The the the client issued the DHCP Release message. The
client-address field is present whenever the `D' bit is client-address field is present whenever the `D' bit is
set, even if it is equal to the link-local address. set, even if it is equal to the link-local address.
extensions See [13] extensions See [15]
It is an error (status code ``InvalidSource'' (see Section 2.4)) to It is an error (status code ``InvalidSource'' (see Section 2.4)) to
include within the DHCP Release message both the `D' bit and an IP include within the DHCP Release message both the `D' bit and an IP
address extension which has the IP address used as the client-address address extension which has the IP address used as the client-address
field of the DHCP Release message header. field of the DHCP Release message header.
4.6. DHCP Reconfigure Message Format 4.6. DHCP Reconfigure Message Format
DHCP Reconfigure messages can only be sent to clients which have DHCP Reconfigure messages can only be sent to clients which have
established an IP address which routes to the link at which they are established an IP address which routes to the link at which they are
reachable, hence the DHCP Reconfigure message is sent without the reachable, hence the DHCP Reconfigure message is sent without the
assistance of any DHCP relay. When a server sends a Reconfigure assistance of any DHCP relay. When a server sends a Reconfigure
message, the receivers are assumed to have a valid IP address with message, the receivers are assumed to have a valid IP address with
sufficient scope to be accessible by the server. Only the parameters sufficient scope to be accessible by the server. Only the parameters
which are specified in the extensions to the Reconfigure message need which are specified in the extensions to the Reconfigure message need
be requested again by the client. A Reconfigure message can either be requested again by the client. A Reconfigure message can either
be unicast or multicast by the server. be unicast or multicast by the server. The client will extract the
extensions provided by the server and send a DHCP Request message to
the server using those extensions (see section 5.7).
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 |N| reserved | transaction-ID | | msg-type = 6 |N| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address | | server-address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 6
N The `N' flag indicates that the client should not N The `N' flag indicates that the client should not
expect a DHCP Reply in response to the DHCP Request expect a DHCP Reply in response to the DHCP Request
it sends as a result of the DHCP Reconfigure message. it sends as a result of the DHCP Reconfigure message.
reserved 0 reserved 0
transaction-ID transaction-ID
A monotonically increasing unsigned integer used to A unsigned integer identifier used to identify this
identify this Reconfigure message, and copied into Reconfigure, to by copied into the following DHCP
the client's Request. Request message that will be transmitted by the
client.
server-address server-address
The IP address of the DHCP server issuing the DHCP The IP address of the DHCP server issuing the DHCP
Reconfigure message. Reconfigure message.
extensions See [13] extensions See [15]
5. DHCP Client Considerations 5. DHCP Client Considerations
A node which is not a DHCP agent MUST silently discard any DHCP A node which is not a DHCP agent MUST silently discard any DHCP
Solicit, DHCP Request, or DHCP Release message it receives. Solicit, DHCP Request, or DHCP Release message it receives.
5.1. Verifying Resource Allocations After Restarts 5.1. Verifying Resource Allocations After Restarts
A client MAY retain its configured parameters and resources across A client MAY retain its configured parameters and resources across
client system reboots and program restarts. However, in these client system reboots and program restarts. Any client wishing
circumstances the client MUST also formulate a DHCP Request message to use this feature MUST also maintain state for the address of
to verify that its configured parameters and resources are still its DHCP agent address. When the client restarts, the client MUST
valid. This Request message MUST have the `C' bit set, to clean up also formulate a DHCP Request message to verify that its configured
stale client binding information at the server which may no longer be parameters and resources are still valid. This Request message MUST
in use by the client; stale information is that which the client does have the `C' bit set, to clean up stale client binding information
not include in extensions to such request messages. 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 If the server does not respond to the DHCP Request message after
REQUEST_MSG_MIN_RETRANS (see section 8), the client may still REQUEST_MSG_MIN_RETRANS (see section 8), the client may still
use any resources whose lifetimes have not yet expired. In such use any resources whose lifetimes have not yet expired. In such
cases, however, the client MUST begin to search for another server cases, however, the client MUST begin to search for another server
by multicasting a DHCP Solicit message with the `C' bit set (see by multicasting a DHCP Solicit message with the `C' bit set (see
section 5.2). The client SHOULD log a DHCP System Error. section 5.2). The client SHOULD log a DHCP System Error.
This also handles the case wherein a client restarts on a new This also handles the case wherein a client restarts on a new
network, where its IP address is no longer valid. In this situation, 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 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 is no longer needed, the client MUST release its old IP address by
issuing a DHCP Release message with the appropriate extension if it issuing a DHCP Release message with the appropriate extension if it
can communicate with its previous server. can communicate with its previous server.
A mobile client (that is not stationary on a network) SHOULD keep its
agent-address, and possibly the relevant server address, along with
all resource-server associations [15] on non-volatile storage. This
will allow the client to release resources with the DHCP Solicit or
Release messages if it enters a different network location before
releasing its resources.
5.2. Sending DHCP Solicit Messages 5.2. Sending DHCP Solicit Messages
A client MUST have the address of a server to send a Request message. A client MUST have the address of a server to send a Request message.
The client SHOULD locate a DHCP server by multicasting a DHCP Solicit The client SHOULD locate a DHCP server by multicasting a DHCP Solicit
message to the All-DHCP-Agents link-local multicast address (see message to the All-DHCP-Agents link-local multicast address (see
Section 3.3), setting the Hop Limit == 1. If there are no DHCP 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 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 present if solicitations sent from a client's link-local address are
to be handled. to be handled.
When sending a DHCP Solicit message, a client MUST set the Relay When sending a DHCP Solicit message, a client MUST set the Relay
Address field to 16 octets of zeros, and zero the prefix-size field. Address field to 16 octets of zeros, and zero the prefix-size field.
If a client reboots and does not have a valid IP address, it MUST set If a client reboots and does not have a valid IP address, it SHOULD
the `C' bit in the DHCP Solicit message it sends when restarting. By set the `C' bit in the DHCP Solicit message it sends when restarting.
setting the `C' bit in the solicitation, a client requests that all By setting the `C' bit in the solicitation, a client requests that
the DHCP servers that receive the solicitation should clean up their all the DHCP servers that receive the solicitation should clean up
client records that match its link-local address. their client records that match its link-local address.
If a client sends a DHCP Solicit message after it reboots, the If a client sends a DHCP Solicit message after it reboots, the
solicitation SHOULD be delayed after reception of the first Router solicitation SHOULD be delayed after reception of the first Router
Advertisement [11] message, by at least some random amount of time Advertisement [14] message (see section 5.8), by at least some random
between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see section 8). amount of time between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see
This delay is intended to help stagger requests to DHCP servers (and section 8). This delay is intended to help stagger requests to
avoid link-layer collisions) after a power outage causes many nodes DHCP servers (and avoid link-layer collisions) after a power outage
to reboot all at once. Each subsequent DHCP Solicit message that is causes many nodes to reboot all at once. Each subsequent DHCP
issued before receiving an advertisement MUST be delayed by twice the Solicit message that is issued before receiving an advertisement
amount by which the previous DHCP Solicit message was delayed, plus MUST be delayed by twice the amount by which the previous DHCP
a small random delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY Solicit message was delayed, plus a small random delay between
seconds. MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds.
5.3. Receiving DHCP Advertise Messages 5.3. Receiving DHCP Advertise Messages
After a client has received a DHCP Advertise message, it has the After a client has received a DHCP Advertise message, it has the
address of a server for subsequent DHCP Request messages. If the `S' address of a server for subsequent DHCP Request messages. If the `S'
bit is zero, the DHCP Advertise message was transmitted by a server bit is zero, the DHCP Advertise message was transmitted by a server
on the same link as the client, and the client uses the agent-address 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 as the server's address; otherwise, the server's IP address is
located in the server-address field. If the server-address is a located in the server-address field. If the server-address is a
multicast address, the advertisement MUST be silently discarded. multicast address, the advertisement MUST be silently discarded.
skipping to change at page 17, line 16 skipping to change at page 18, line 7
to 255 (see Section 4.2), the client MUST wait CLIENT_ADV_WAIT to 255 (see Section 4.2), the client MUST wait CLIENT_ADV_WAIT
seconds after issuing the DHCP Solicit message in order to receive seconds after issuing the DHCP Solicit message in order to receive
the Advertisement with the highest preference. After waiting for the Advertisement with the highest preference. After waiting for
that period of time, a client MUST select the highest preference that period of time, a client MUST select the highest preference
server as the target of its DHCP request. If a client receives an 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 advertisement with a preference of 255, it does not have to wait for
any more advertisements. any more advertisements.
If a client sends a DHCP Request to a highly preferred server but If a client sends a DHCP Request to a highly preferred server but
fails to receive a DHCP reply from that server after following the fails to receive a DHCP reply from that server after following the
retransmission algorithm in section 8, the client SHOULD then try to retransmission algorithm in section 8, the client MUST then try to
send a DHCP Request to a less preferred server. send a DHCP Request to a less preferred server.
A client is free to cache the result of any DHCP Advertisement it A client is free to cache the result of any DHCP Advertisement it
hears. This is purely a potential performance enhancement, because receives. This is purely a potential performance enhancement,
the results might change over time. A client may not get a DHCP because the results might change over time. A client may not get
Reply if it uses a cached server-address, and in that case SHOULD a DHCP Reply if it uses a cached server-address, and in that case
multicast another DHCP Solicit message. SHOULD multicast another DHCP Solicit message.
5.4. Sending DHCP Request Messages 5.4. Sending DHCP Request Messages
A client obtains configuration information from a server by sending A client obtains configuration information from a server by sending
a DHCP Request message. The client MUST know the server's address a DHCP Request message. The client MUST know the server's address
before sending the Request message, and the client MUST have acquired before sending the Request message, and the client MUST have acquired
a (possibly identical) DHCP agent address. If the client and server a (possibly identical) DHCP agent address. If the client and server
are on the same link, the agent-address used by the client MUST be 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 the same as the DHCP server's address. A DHCP Request message MUST
NOT be sent to any multicast address, since otherwise multiple DHCP NOT be sent to any multicast address, since otherwise multiple DHCP
agents would possibly allocate resources to the client in response servers would possibly allocate resources to the client in response
to the same Request, and the client would have no way to know which 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 servers had made the allocations, if any packets were lost due to
collisions, etc. collisions, etc.
If the DHCP server is off-link, and the client has no valid IP If the DHCP server is off-link, and the client has no valid IP
address of sufficient scope, then the client MUST include the address of sufficient scope, then the client MUST include the
server-address and set the `S' bit in the DHCP Request message. In 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 this case, the IP destination address in the IP header will be a DHCP
relay address. relay address.
skipping to change at page 18, line 12 skipping to change at page 18, line 52
previous resources, configuration information, and bindings previous resources, configuration information, and bindings
associated with its agent-address and link-local address, it associated with its agent-address and link-local address, it
sets the `C' bit in the DHCP Request. A client MAY send in sets the `C' bit in the DHCP Request. A client MAY send in
such a Request even when it is no longer attached to the link on such a Request even when it is no longer attached to the link on
which the relay-address is attached. The `C' bit allows better which the relay-address is attached. The `C' bit allows better
reclamation of available resources when a client lost records for reclamation of available resources when a client lost records for
its resource-server associations and might not otherwise be able to its resource-server associations and might not otherwise be able to
release the associated resources. release the associated resources.
When a client reboots and loses its previous state, the server When a client reboots and loses its previous state, the server
should no longer keep track of the transaction IDs associated with should no longer keep track of the the XID-TIMEOUT binding cache of
that previous state. In order to inform the server that the client transaction IDs (see section 6) associated with that previous state.
no longer wishes any association to be maintained between used In order to inform the server that the client no longer wishes
transaction-IDs and previous transactions, the client SHOULD set the any association to be maintained between used transaction-IDs and
`R' bit in its DHCP Request. previous transactions, the client SHOULD set the `R' bit in its DHCP
Request.
In any case, after choosing a transaction-ID which is numerically In any case, after choosing a transaction-ID which is numerically
greater than its last recorded transaction-ID, and filling in the greater than its last recorded transaction-ID, and filling in the
appropriate fields of the DHCP Request message, the client MAY append appropriate fields of the DHCP Request message, the client MAY append
various DHCP Extensions to the message. These extensions denote various DHCP Extensions to the message. These extensions denote
specific requests by the client; for example, a client may request specific requests by the client; for example, a client may request
a particular IP address, or request that the server send an update 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 containing the client's new IP address to a Domain Name Server. When
all desired extensions have been applied, the client sends the DHCP all desired extensions have been applied, the client sends the DHCP
Request to the appropriate agent. Request to the appropriate agent.
skipping to change at page 19, line 6 skipping to change at page 19, line 45
retransmit according to the rules in Section 8. If (after following retransmit according to the rules in Section 8. If (after following
those rules) the client has not received a Reply message, it SHOULD 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 start over again by multicasting a new DHCP Solicit message to find a
different server. different server.
If the client receives an ICMP error message in response to such a If the client receives an ICMP error message in response to such a
DHCP Request, it likewise SHOULD start over again by multicasting a DHCP Request, it likewise SHOULD start over again by multicasting a
new DHCP Solicit message, to find a different server. new DHCP Solicit message, to find a different server.
If the client transmits a DHCP Request in response to a DHCP If the client transmits a DHCP Request in response to a DHCP
Reconfigure message (see Section 5.7) with the `N' bit not set, Reconfigure message, further processing is as specified in
the client can continue to operate with its existing configuration Section 5.7. The client can continue to operate with its existing
information and resources until it receives the corresponding DHCP configuration information and resources until it receives the
Reply from the server. The same retransmission rules apply as for corresponding DHCP Reply from the server. The same retransmission
any other DHCP Request message from the client. When the `N' bit is rules apply as for any other DHCP Request message from the client.
set, a DHCP Request sent in response to a DHCP Reconfigure message When the `N' bit is set, a DHCP Request sent in response to a DHCP
will not elicit a DHCP Reply message from the server. Reconfigure message will not elicit a DHCP Reply message from the
server.
5.5. Receiving DHCP Reply Messages 5.5. Receiving DHCP Reply Messages
When a client receives a DHCP Reply message, it MUST check whether When a client receives a DHCP Reply message, it MUST check whether
the transaction-ID in the Reply message matches the transaction-ID the transaction-ID in the Reply message matches the transaction-ID
of a pending DHCP Request message. If no match is found, the Reply of a pending DHCP Request message. If no match is found, the Reply
message MUST be silently discarded. message MUST be silently discarded.
If the Reply message is acceptable, the client processes each If the Reply message is acceptable, the client processes each
Extension [13], extracting the relevant configuration information Extension [15], extracting the relevant configuration information
and parameters for its network operation. The client can determine and parameters for its network operation. The client can determine
when all extensions in the Reply have been processed by using the UDP when all extensions in the Reply have been processed by using the UDP
Length field of the Reply. Some extensions in the Reply may have Length field of the Reply. Some extensions in the Reply may have
status codes, which indicate to the client the reason for failure status codes, which indicate to the client the reason for failure
when the server was unable to honor the request. If the server is 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, unable to honor the request in an extension included by the client,
that extension may simply be omitted from the Reply. The server MAY that extension may simply be omitted from the Reply. The server MAY
also provide the client with configuration parameters the client did also provide the client with configuration parameters the client did
not specifically request. not specifically request.
Some configuration information extracted from the extensions to the Some configuration information extracted from the extensions to the
DHCP Reply message MUST remain associated with the server that sent DHCP Reply message MUST remain associated with the server that sent
the message. The particular extensions that require this extra the message. The particular extensions that require this extra
measure of association with the server are indicated in the DHCP measure of association with the server are indicated in the DHCP
Extensions document [13]. These "resource-server" associations are Extensions document [15]. These "resource-server" associations are
used when sending DHCP Release messages. used when sending DHCP Release messages.
5.6. Sending DHCP Release Messages 5.6. Sending DHCP Release Messages
If a client wishes to ask the server to release all information and If a client wishes to ask the server to release all information and
resources relevant to the client, the client SHOULD send a DHCP resources relevant to the client, the client SHOULD send a DHCP
Release message without any extensions; this is preferable to sending Release message without any extensions; this is preferable to sending
a DHCP Request message with the `C' bit set and no extensions. If a a DHCP Request message with the `C' bit set and no extensions. If a
client wishes to retain some of its network configuration parameters, client wishes to retain some of its network configuration parameters,
but determines that others are no longer needed, it SHOULD enable but determines that others are no longer needed, it SHOULD enable
the server to release allocated resources which are no longer in the server to release allocated resources which are no longer in
use by sending a DHCP Release message to the server, and including use by sending a DHCP Release message to the server, and including
extensions to identify the unneeded items. The client consults its extensions to identify the unneeded items. The client consults its
list of resource-server associations in order to determine which list of resource-server associations in order to determine which
server should receive the desired Release message. 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 Suppose a client wishes to release resources which were granted to
it at another IP address. Further, suppose that the client has an it at another IP address. Further, suppose that the client has an
IP address that will still be valid after the server performs the IP address that will still be valid after the server performs the
operations requested in the extensions to the DHCP Release message, operations requested in the extensions to the DHCP Release message,
and which has sufficient scope to be reachable from the server. In 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 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 Release message (see section 4.5). This instructs the server to
send the DHCP Reply directly back to the client at the latter valid send the DHCP Reply directly back to the client at the latter valid
IP address, instead of performing the default processing of sending IP address, instead of performing the default processing of sending
the DHCP Reply back through the agent-address included in the DHCP the DHCP Reply back through the agent-address included in the DHCP
Release. Release.
5.7. Receiving DHCP Reconfigure Messages 5.7. Receiving DHCP Reconfigure Messages
Each client implementation MUST support listening at UDP port 546 Each client implementation MUST support listening at UDP port 546 to
to receive possible DHCP Reconfigure messages; in cases where the receive possible DHCP Reconfigure messages; in cases where the client
client knows that no Reconfigure message will ever be issued, the knows that no Reconfigure message will ever be issued, the client MAY
client MAY be configured to avoid executing this supported feature. 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 In some cases, the IP address at which the client listens will be a
multicast address sent to the client by the server in an extension 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 to an earlier DHCP Reply message. If the client does not listen for
DHCP Reconfigure messages, it is possible that the client will not DHCP Reconfigure messages, it is possible that the client will not
receive notification that its server has deallocated the client's receive notification that its server has deallocated the client's
IP address and/or other resources allocated to the client. See IP address and/or other resources allocated to the client. See
discussion in 6.5. The client MAY receive a prefix update for one discussion in 6.5. The client MAY receive a prefix update for one
or more of their addresses and then MUST use that prefix for those or more of their addresses and then MUST use that prefix for those
addresses. addresses.
If a client receives a DHCP Reconfigure message, it is a request for If a client receives a DHCP Reconfigure message, it is a request for
the client to initiate a new DHCP Request/Reply transaction with the the client to send a new DHCP Request to the server which sent the
server which sent the Reconfigure message. The server sending the Reconfigure message. Unless the `N' bit is set, the client MUST
Reconfigure message MAY be different than the server which sent a await a DHCP Reply with a matching transaction-ID, retransmitting
DHCP Reply message containing the original configuration information. (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 can be retransmitted by the server with the Reconfigure messages MAY be retransmitted by the server with the same
same transaction-ID. When a client receives such a retransmitted transaction-ID.
Reconfigure message within XID_TIMEOUT of the last received
Reconfigure message with the same transaction-ID, the client MUST When a client receives a retransmitted unicast Reconfigure message
reformulate exactly the same DHCP Request message and retransmit the within XID_TIMEOUT of the last received Reconfigure message with the
request message to the server again. In this way, the server can same transaction-ID, the client MUST reformulate exactly the same
make use of the retransmission algorithm to ensure that all affected DHCP Request message and retransmit the request message to the server
clients have received the Reconfigure message. 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
within XID_TIMEOUT of the last received Reconfigure message with
the same transaction-ID, the client MUST not resend the the Request
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 For each Extension which is present in the Reconfigure message, the
client MUST append a matching Extension to its Request message, which client MUST append a matching Extension to its Request message, which
it formulates to send to the server specified in the server-address it formulates to send to the server specified in the server-address
field of the message. The client also copies a transaction-ID from field of the message. The client also copies a transaction-ID from
the Reconfigure message into the Request message. If the `N' bit is the Reconfigure message into the Request message. Processing for the
not set, processing from then on is the same as specified above in Request is the same as specified in Section 5.4, except:
Section 5.4.
- the client retransmits as stated above in this section
- the client never needs a Relay to send the Request to the DHCP
Server
- the client MUST NOT set the `S' or `R' bits
- if the `N' Bit is set, the client will not get a Reply from the
server
- if the client receives an ICMP error message it should abort the
Reconfigure transaction and log an error message. The client
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 Resources held by the client which are not identified by Extensions
in the server's Reconfigure message are not affected. in the server's Reconfigure message are not affected.
If a client has recently sent a DHCP Request to the server from which
it subsequently received the DHCP Reconfigure message, the client
SHOULD silently discard the Reconfigure message until the server
sends the DHCP Reply message with the same transaction-ID as the
client's DHCP Request message.
A server may ask its client to join a multicast group for the A server may ask its client to join a multicast group for the
purpose of receiving DHCP Reconfigure messages. When a Reconfigure purpose of receiving DHCP Reconfigure messages. When a Reconfigure
message is delivered to the client by way of the selected multicast message is delivered to the client by way of the selected multicast
address, the client MUST delay its further response for a random address, the client MUST delay its further response for a random
amount of time uniformly distributed within the interval between amount of time uniformly distributed within the interval between
RECONF_MMSG_MIN_RESP and RECONF_MMSG_MAX_RESP seconds (see RECONF_MMSG_MIN_RESP and RECONF_MMSG_MAX_RESP seconds (see
section 8). This will minimize the likelihood that the server will section 8). This will minimize the likelihood that the server will
be flooded with DHCP Request messages. be flooded with DHCP Request messages.
5.8. Interaction with Stateless Address Autoconfiguration 5.8. Interaction with Stateless Address Autoconfiguration
Please refer to the Stateless Address Autoconfiguration Please refer to the Stateless Address Autoconfiguration Protocol
Protocol specification [17] and its follow-on, Stateless Address specification [20] for details regarding the actions taken by clients
Autoconfiguration version 2 [18] for details regarding the actions upon receiving Router Advertisements with changing values for the `M'
taken by clients upon receiving Router Advertisements with changing and `O' bits.
values for the `M' and `O' bits.
6. DHCP Server Considerations 6. DHCP Server Considerations
A node which is not a client or relay MUST ignore any DHCP Advertise, A node which is not a client or relay MUST ignore any DHCP Advertise,
DHCP Reply, or DHCP Reconfigure message it receives. DHCP Reply, or DHCP Reconfigure message it receives.
A server maintains a collection of client records, called A server maintains a collection of client records, called
``bindings''. Each binding is uniquely identifiable by the ordered ``bindings''. Each binding is uniquely identifiable by the ordered
pair <link-local address, agent-address prefix>, since the link-local pair <link-local address, agent-address>, since the link-local
address is guaranteed to be unique [17] on the link identified address is guaranteed to be unique [20] on the link identified by the
by the agent-address and prefix. An implementation MUST support agent-address and prefix. An implementation MUST support bindings
bindings consisting of at least a client's link-local address, consisting of at least a client's link-local address, agent-address,
agent-address prefix, preferred lifetime and valid lifetime [17] for preferred lifetime and valid lifetime [20] for each client address.
each client address. A server MAY, at the discretion of the network
administrator, be configured so that client bindings are identified A server MAY, at the discretion of the network administrator, be
by the client's MAC address, without need to use the additional configured so that client bindings are identified by the client's
information supplied by the agent-address. A client binding may be link-local address, without need to use the additional information
used to store any other information, resources, and configuration supplied by the agent-address.
data which will be associated with the client. A server MUST retain
its clients' bindings across server reboots, and, whenever possible, A client binding may be used to store any other information,
a client should be assigned the same configuration parameters resources, and configuration data which will be associated with the
despite server system reboots and DHCP server program restarts. A client. A server MUST retain its clients' bindings across server
server MUST support fixed or permanent allocation of configuration reboots, and, whenever possible, a client should be assigned the
parameters to specific clients. 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 In addition to the client binding a server must maintain an
XID_TIMEOUT binding cache to determine if a previous transaction-ID XID_TIMEOUT binding cache to determine if a previous transaction-ID
is being retransmitted by a client. An implementation of an is being retransmitted by a client. An implementation of an
XID_TIMEOUT binding cache MUST support at least a tuple consisting of XID_TIMEOUT binding cache MUST support at least a tuple consisting of
the client's link-local address, agent-address prefix, IPv6 address, the client's link-local address, agent-address prefix, IPv6 address,
and XID_TIMEOUT value when the cache entry can be deleted (see and XID_TIMEOUT value when the cache entry can be deleted (see
Section 8). Section 8).
6.1. Receiving DHCP Solicit Messages 6.1. Receiving DHCP Solicit Messages
skipping to change at page 22, line 33 skipping to change at page 24, line 6
If the DHCP Solicit message was received at the All-DHCP-Servers If the DHCP Solicit message was received at the All-DHCP-Servers
multicast address, the server MUST check to make sure that the multicast address, the server MUST check to make sure that the
relay-address is present, and is not a link-local address. If the 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, relay-address is not present, or if it is a link-local address,
the server MUST silently discard the packet. Note that if the the server MUST silently discard the packet. Note that if the
client sends a DHCP Solicit message from a link-local address, the client sends a DHCP Solicit message from a link-local address, the
multicast destination will be the All-DHCP-Agents address, not the multicast destination will be the All-DHCP-Agents address, not the
All-DHCP-Servers address. All-DHCP-Servers address.
When the `C' bit is set in the solicitation, the server deallocates When the `C' bit is set in the solicitation, the server deallocates
all resources that match its link-local address. The server MUST all resources that match the link-local address and saved
take the relay-address and use the prefix-size to locate the client agent-address in the solicitation message, if a binding for the
binding. 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 As an optimization, a server processing a Solicit message from relays
MAY check the prefix of the IP source address in the IP header to MAY check the prefix of the IP source address in the IP header to
determine whether the server has received the Solicit from multiple determine whether the server has received the Solicit from multiple
relays on the same link. The prefix-size field in the solicitation relays on the same link. The prefix-size field in the solicitation
enables the server to ascertain when two relay addresses belong to enables the server to ascertain when two relay addresses belong to
the same link. the same link.
6.2. Sending DHCP Advertise Messages 6.2. Sending DHCP Advertise Messages
skipping to change at page 23, line 13 skipping to change at page 24, line 34
the server SHOULD delay the transmission of its advertisement the server SHOULD delay the transmission of its advertisement
for a random amount of time between SERVER_MIN_ADV_DELAY and for a random amount of time between SERVER_MIN_ADV_DELAY and
SERVER_MAX_ADV_DELAY (see section 8). SERVER_MAX_ADV_DELAY (see section 8).
If the relay-address is nonzero, the server MUST copy it into the If the relay-address is nonzero, the server MUST copy it into the
agent-address field of the advertisement message, and send the agent-address field of the advertisement message, and send the
advertisement to the relay-address. Otherwise, the server MUST advertisement to the relay-address. Otherwise, the server MUST
send the advertisement to the client's link-local address. An IP send the advertisement to the client's link-local address. An IP
address of the interface on which the server received the Solicit address of the interface on which the server received the Solicit
message MUST appear in the server-address field of the corresponding message MUST appear in the server-address field of the corresponding
advertisement. advertisement, and the 'S' bit MUST be set.
The server MAY append extensions to the Advertisement, in order to The server MAY append extensions to the Advertisement, in order to
offer the soliciting node the best possible information about the offer the soliciting node the best possible information about the
available services and resources. available services and resources.
6.3. DHCP Request and Reply Message Processing 6.3. DHCP Request and Reply Message Processing
DHCP server MUST check to ensure that the client's link-local address DHCP server MUST check to ensure that the client's link-local address
field of the Request message contains a link-local address. If not, field of the Request message contains a link-local address. If not,
the message MUST be silently discarded. If the `S' bit is set, the the message MUST be silently discarded. If the `S' bit is set, the
skipping to change at page 23, line 41 skipping to change at page 25, line 14
and send a DHCP Reply with any resources allocated to the new and send a DHCP Reply with any resources allocated to the new
binding. Otherwise, if the server cannot create a new binding, binding. Otherwise, if the server cannot create a new binding,
it SHOULD return a DHCP Reply with a status of ``NoBinding'' (see it SHOULD return a DHCP Reply with a status of ``NoBinding'' (see
Section 2.4). If the client is updating its resources but the Section 2.4). If the client is updating its resources but the
database is temporarily unavailable, the server SHOULD return a DHCP database is temporarily unavailable, the server SHOULD return a DHCP
Reply with a status of ``Unavail'' (see Section 2.4). Reply with a status of ``Unavail'' (see Section 2.4).
While processing the Request, the server MUST first determine whether While processing the Request, the server MUST first determine whether
or not the Request is a retransmission of an earlier DHCP Request or not the Request is a retransmission of an earlier DHCP Request
from the same client. This is done by comparing the transaction-ID from the same client. This is done by comparing the transaction-ID
to all those transaction-IDs received from the same client during the to all those transaction-IDs in the XID_TIMEOUT binding cache
previous XID_TIMEOUT seconds. If the transaction-ID is the same as received from the same client during the previous XID_TIMEOUT
one received during that time, the server MUST take the same action seconds. If the transaction-ID is the same as one received during
(e.g., retransmit the same DHCP Reply to the client) as it did after that time, the server MUST take the same action (e.g., retransmit
processing the previous DHCP Request with the same transaction-ID. 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 Otherwise, if the server has no record of a message from the client
with the same transaction-ID, the server identifies and allocates with the same transaction-ID, the server identifies and allocates
all the relevant information, resources, and configuration data that all the relevant information, resources, and configuration data that
is associated with the client. Then it sends that information to is associated with the client. Then it sends that information to
its client by constructing a DHCP Reply message and including the its client by constructing a DHCP Reply message and including the
client's information in DHCP Extensions to the Reply message. The client's information in DHCP Extensions to the Reply message. The
DHCP Reply message uses the same transaction-ID as found in the DHCP Reply message uses the same transaction-ID as found in the
received DHCP Request message. Note that the reply message MAY received DHCP Request message. Note that the reply message MAY
contain information not specifically requested by the client. contain information not specifically requested by the client.
If the DHCP Request message has the `S' bit set in the message If the DHCP Request message has the `S' bit set in the message
header, the server MUST send the corresponding DHCP Reply message to header, the server MUST send the corresponding DHCP Reply message to
the agent-address found in the Request (see section 7.2). Otherwise, the agent-address found in the Request (see section 7.2). Otherwise,
the server SHOULD send the corresponding DHCP Reply message to the the server SHOULD send the corresponding DHCP Reply message to the
IP source address in the IP header received from the client Request IP source address in the IP header received from the client Request
message. message.
6.3.1. Processing for Extensions to DHCP Request and Reply Messages 6.3.1. Processing for Extensions to DHCP Request and Reply Messages
The DHCP Request may contain extensions [13], which are interpreted The DHCP Request may contain extensions [15], which are interpreted
(by default) as advisory information from the client about its (by default) as advisory information from the client about its
configuration preferences. For instance, if the IP Address Extension configuration preferences. For instance, if the IP Address Extension
is present, the server SHOULD attempt to allocate or extend the is present, the server SHOULD attempt to allocate or extend the
lifetime of the address indicated by the extension. Some extensions lifetime of the address indicated by the extension. Some extensions
may be marked by the client as required. may be marked by the client as required.
The server may accept some extensions for successful processing and The server may accept some extensions for successful processing and
allocation, while still rejecting others, or it may reject various allocation, while still rejecting others, or it may reject various
extensions for different reasons, and set the status appropriately extensions for different reasons, and set the status appropriately
for those extensions which return status to the client. The server for those extensions which return status to the client. The server
skipping to change at page 26, line 7 skipping to change at page 27, line 28
by the server, a matching Extension is appended to the DHCP Reply by the server, a matching Extension is appended to the DHCP Reply
message. For extensions in the DHCP Release message which cannot be message. For extensions in the DHCP Release message which cannot be
successfully processed by the server, a DHCP Reply message containing successfully processed by the server, a DHCP Reply message containing
extensions with the appropriate status MUST be returned by the extensions with the appropriate status MUST be returned by the
server. If the Release message contains no extensions, the server server. If the Release message contains no extensions, the server
does not include any extensions in the corresponding DHCP Reply does not include any extensions in the corresponding DHCP Reply
message to the client. message to the client.
6.5. Sending DHCP Reconfigure Messages 6.5. Sending DHCP Reconfigure Messages
If a server needs to change the configuration associated with any of If a server needs to change the configuration associated with any
its clients, it constructs a DHCP Reconfigure message and sends it to of its clients, it constructs a DHCP Reconfigure message (possibly
each such client. The Reconfigure MAY be sent to a multicast address including relevant extensions) and sends it to each such client. The
chosen by the server and previously sent to each such client in an Reconfigure MAY be sent to a multicast address chosen by the server,
extension to a previous DHCP Reply message. which was previously sent to each such client in an extension to a
previous DHCP Reply message.
It may happen that a client does not send a DHCP Request message It may happen that a client does not send a DHCP Request message
after the DHCP Reconfigure message has been issued and retransmitted after the DHCP Reconfigure message has been issued and retransmitted
RECONF_MSG_MIN_RETRANS times, according to the algorithm specified RECONF_MSG_MIN_RETRANS times, according to the algorithm specified
in Section 8. This can happen when the client is not listening for in Section 8. This can happen when the client is not listening for
the Reconfigure message, possibly because the client is a mobile the Reconfigure message, possibly because the client is a mobile
node disconnected from the network, or because the client node node disconnected from the network, or because the client node
has sustained a power outage or operating system crash. In such has sustained a power outage or operating system crash. In such
cases, the server SHOULD reserve any resources issued to the client cases, the server SHOULD reserve any resources issued to the client
until the client responds at some future time, until the resource until the client responds at some future time, until the resource
skipping to change at page 28, line 25 skipping to change at page 29, line 49
in the server-address field of the received DHCP Request message. in the server-address field of the received DHCP Request message.
All of the fields of DHCP Request message transmitted by the relay All of the fields of DHCP Request message transmitted by the relay
are copied over unchanged from the DHCP Request received from the are copied over unchanged from the DHCP Request received from the
client. Only the fields in the IP header will differ 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 packet received from the client. All relays MUST send DHCP Request
messages using the source IP address from the interface where the messages using the source IP address from the interface where the
DHCP request was received. If the Relay receives an ICMP error, 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 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 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 ``ICMPError'' (see Section 2.4), along with the DHCP Relay ICMP Error
extension [13]. extension [15].
7.3. DHCP Reply Message Processing 7.3. DHCP Reply Message Processing
When the relay receives a DHCP Reply, it MUST check that the message When the relay receives a DHCP Reply, it MUST check that the message
has the `L' bit set. It MUST check that the client's link-local has the `L' bit set. It MUST check that the client's link-local
address field contains a link-local address. If either check fails, address field contains a link-local address. If either check fails,
the packet MUST be silently discarded. If both checks are satisfied, the packet MUST be silently discarded. If both checks are satisfied,
the relay MUST send a DHCP Reply message to the link-local address the relay MUST send a DHCP Reply message to the link-local address
listed in the received Reply message. Only the fields in the IP listed in the received Reply message. Only the fields in the IP
header will differ from the packet received from the server, not the header will differ from the packet received from the server, not the
skipping to change at page 29, line 16 skipping to change at page 30, line 40
a Reconfigure message from the server, the client assumes that the a Reconfigure message from the server, the client assumes that the
DHCP server has received the Request. The server MUST retransmit DHCP server has received the Request. The server MUST retransmit
the identical DHCP Reconfigure to the client a reasonable number the identical DHCP Reconfigure to the client a reasonable number
of times to try to elicit the Request message from the client. of times to try to elicit the Request message from the client.
If no corresponding DHCP Request is received by the server after If no corresponding DHCP Request is received by the server after
REQUEST_MSG_MIN_RETRANS retransmissions, the server MAY erase or REQUEST_MSG_MIN_RETRANS retransmissions, the server MAY erase or
deallocate information as needed from the client's binding, but see deallocate information as needed from the client's binding, but see
section 6.5. section 6.5.
Retransmissions occur using the following configuration variables Retransmissions occur using the following configuration variables
for a DHCP implementation. Note that the retransmission algorithm for a DHCP implementation. These configuration variables MUST be
does not use exponential backoff techniques. These configuration configurable by a client or server:
variables MUST be configurable by a client or server:
CLIENT_ADV_WAIT CLIENT_ADV_WAIT
The minimum amount of time a client waits to receive DHCP The minimum amount of time a client waits to receive DHCP
Advertisements after transmitting a DHCP Solicit to the Advertisements after transmitting a DHCP Solicit to the
All-DHCP Agents multicast address (see section 5.3). All-DHCP Agents multicast address (see section 5.3).
Default: 2 seconds Default: 2 seconds
DEFAULT_SOLICIT_HOPCOUNT DEFAULT_SOLICIT_HOPCOUNT
The default hop-count used in the IP header by DHCP relays when The default hop-count used in the IP header by DHCP relays when
sending DHCP Solicit messages on behalf of a client. sending DHCP Solicit messages on behalf of a client.
Default: 4 Default: 4
SERVER_MIN_ADV_DELAY SERVER_MIN_ADV_DELAY
The minimum amount of time a server waits to transmit a The minimum amount of time a server waits to transmit a
skipping to change at page 30, line 4 skipping to change at page 31, line 26
Default: 100 milliseconds Default: 100 milliseconds
SERVER_MAX_ADV_DELAY SERVER_MAX_ADV_DELAY
The maximum amount of time a server waits to transmit a DHCP The maximum amount of time a server waits to transmit a DHCP
Advertisement after receiving a DHCP Solicit at the All-DHCP Advertisement after receiving a DHCP Solicit at the All-DHCP
Agents multicast address. Agents multicast address.
Default: 1 second Default: 1 second
REPLY_MSG_TIMEOUT REPLY_MSG_TIMEOUT
The time in seconds that a client waits to receive a server's The time in seconds that a client waits to receive a server's
DHCP Reply before retransmitting a DHCP Request. DHCP Reply before retransmitting a DHCP Request. The
client MUST multiply REPLY_MSG_TIMEOUT by a factor of 2 in
an exponential manner for each time it retransmits until
REQUEST_MSG_MIN_RETRANS (below) is attained. A client MAY be
configured to attempt 2 retransmissions before beginning the
exponential backoff retransmission in the previous sentence.
Default: 2 seconds. Default: 2 seconds.
REQUEST_MSG_MIN_RETRANS REQUEST_MSG_MIN_RETRANS
The minimum number of DHCP Request transmissions that a client The minimum number of DHCP Request transmissions that a client
should retransmit, before aborting the request. should retransmit, before aborting the request.
Default: 10 retransmissions. Default: 10 retransmissions.
skipping to change at page 30, line 48 skipping to change at page 32, line 27
Default: 2 seconds. Default: 2 seconds.
RECONF_MMSG_MAX_RESP RECONF_MMSG_MAX_RESP
The maximum amount of time before a client MUST respond to a The maximum amount of time before a client MUST respond to a
DHCP Reconfigure message sent to a multicast address. DHCP Reconfigure message sent to a multicast address.
Default: 10 seconds. Default: 10 seconds.
RECONF_MULTICAST_REQUEST_WAIT
The time a client should wait before retransmitting a Request
message in reponse to a retransmitted multicast Reconfigure
message.
Default: 120 seconds
MIN_SOLICIT_DELAY MIN_SOLICIT_DELAY
The minimum amount of time a prospective client is required to The minimum amount of time a prospective client is required to
wait, after determining from a Router Advertisement message wait, after determining from a Router Advertisement message
that the client should perform stateful address configuration, that the client should perform stateful address configuration,
before sending a DHCP Solicit to a server. before sending a DHCP Solicit to a server.
Default: 1 second Default: 1 second
MAX_SOLICIT_DELAY MAX_SOLICIT_DELAY
skipping to change at page 31, line 48 skipping to change at page 33, line 34
wish to only accept DHCP Reconfigure messages that are certain to wish to only accept DHCP Reconfigure 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 DHCP relay is involved, so that the DHCP message
MUST have the relay's address in the IP destination address field, MUST have the relay's address in the IP destination address field,
even though the client aims to deliver the message to the server. even though the client aims to deliver the message to the server.
The DHCP Client-Server Authentication Extension [13] is intended to The DHCP Client-Server Authentication Extension [15] is intended to
be used in these circumstances. be 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.
10. Year 2000 considerations 10. Year 2000 considerations
skipping to change at page 32, line 32 skipping to change at page 34, line 20
Section 3.3 specifies the use of several multicast groups, with Section 3.3 specifies the use of several multicast groups, with
multicast addresses FF02:0:0:0:0:0:1:2, FF05:0:0:0:0:0:1:3, and 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. 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 be
returned with the DHCP Reply message (see section 4.4). The nonzero returned with the DHCP Reply message (see section 4.4). The nonzero
values for these status codes which are currently specified are shown values for these status codes which are currently specified are shown
in section 2.4. in section 2.4.
There is a DHCPv6 extension [13] which allows clients and servers to There is a DHCPv6 extension [15] 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 defines in section 8. 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 [12].
skipping to change at page 33, line 13 skipping to change at page 34, line 48
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. Changes for this revision A. Changes for this revision
- Changed the preference field to be 8 bits and always present - Fixed grammatical and clarity problems.
- Eliminated the `P' bit from the DHCP Advertise message - Added saved agent-address field to the solicit message and
altered and enhanced references to the C bit use.
- Noted that relays SHOULD be able to determine which interface - Removed all references of agent-address prefix as it is implied
receives a message by the agent-address and can be used as such by implementors.
Should this be here? - 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 B. Related Protocol Specifications
Related work in IPv6 that would best serve an implementor to study Related work in IPv6 that would best serve an implementor to study
is the IPv6 Specification [6], the IPv6 Addressing Architecture [8], is the IPv6 Specification [7], the IPv6 Addressing Architecture [9],
IPv6 Stateless Address Autoconfiguration [17], IPv6 Neighbor IPv6 Stateless Address Autoconfiguration [20], IPv6 Neighbor
Discovery Processing [11], and Dynamic Updates to DNS [20]. These Discovery Processing [14], and Dynamic Updates to DNS [22]. These
specifications enable DHCP to build upon the IPv6 work to provide specifications enable DHCP to build upon the IPv6 work to provide
both robust stateful autoconfiguration and autoregistration of DNS both robust stateful autoconfiguration and autoregistration of DNS
Host Names. Host Names.
The IPv6 Specification provides the base architecture and design of The IPv6 Specification provides the base architecture and design of
IPv6. A key point for DHCP implementors to understand is that IPv6 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 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 or greater (in IPv4 the requirement is 68 octets). This means that
a UDP packet of 536 octets will always pass through an internet 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 (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 options prior to the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a 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 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] 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 to determine the size of the packet that will traverse a network
path. It is implementation dependent how this is accomplished in path. It is implementation dependent how this is accomplished in
DHCP. Path MTU Discovery for IPv6 is supported for both UDP and TCP 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 and can cause end-to-end fragmentation when the PMTU changes for a
destination. destination.
The IPv6 Addressing Architecture specification [8] defines the The IPv6 Addressing Architecture specification [9] defines the
address scope that can be used in an IPv6 implementation, and the address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required, and nodes can create link-local addresses for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin its link-local address and a well-known multicast address to begin
communications to discover neighbors on the link. For instance, a communications to discover neighbors on the link. For instance, a
client can send a DHCP Solicit and locate a server or relay. client can send a DHCP Solicit and locate a server or relay.
IPv6 Stateless Address Autoconfiguration [17] (Addrconf) specifies IPv6 Stateless Address Autoconfiguration [20] (Addrconf) specifies
procedures by which a node may autoconfigure addresses based on procedures by which a node may autoconfigure addresses based on
router advertisements [11], and the use of a valid lifetime to router advertisements [14], and the use of a valid lifetime to
support renumbering of addresses on the Internet. In addition the support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with Addrconf is a design stateful autoconfiguration. Compatibility with Addrconf is a design
requirement of DHCP (see Section 3.1). requirement of DHCP (see Section 3.1).
IPv6 Neighbor Discovery [11] is the node discovery protocol in IPv6 IPv6 Neighbor Discovery [14] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [14]. To understand which replaces and enhances functions of ARP [16]. To understand
IPv6 and Addrconf it is strongly recommended that implementors IPv6 and Addrconf it is strongly recommended that implementors
understand IPv6 Neighbor Discovery. understand IPv6 Neighbor Discovery.
Dynamic Updates to DNS [20] is a specification that supports the Dynamic Updates to DNS [22] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use 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 the dynamic updates to DNS to integrate addresses and name space to
not only support autoconfiguration, but also autoregistration in not only support autoconfiguration, but also autoregistration in
IPv6. The security model to be used with DHCPv6 should conform as IPv6. The security model to be used with DHCPv6 should conform as
closely as possible to the authentication model outlined in [9]. closely as possible to the authentication model outlined in [10].
C. Comparison between DHCPv4 and DHCPv6 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 [7, 1] and DHCPv6. a model and architecture comparison between DHCPv4 [8, 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.
skipping to change at page 35, line 23 skipping to change at page 37, line 43
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 Many 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 [19]. the Service Location protocol [21].
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
skipping to change at page 37, line 44 skipping to change at page 39, line 46
[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. RFC 2132, March 1997.
[2] S. Bradner. Key Words for Use in RFCs to Indicate Requirement [2] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997. Levels. RFC 2119, March 1997.
[3] S. Bradner and A. Mankin. The Recommendation for the IP Next [3] S. Bradner and A. Mankin. The Recommendation for the IP Next
Generation Protocol. RFC 1752, January 1995. Generation Protocol. RFC 1752, January 1995.
[4] William R. Cheswick and Steven Bellovin. Firewalls and Internet [4] A. Conta and S. Deering. Internet Control Message Protocol
Security. Addison-Wesley, Reading, Massachusetts, 1994. (ISBN:
0-201-63357-4).
[5] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885,
December 1995. December 1995.
[5] A. Conta and S. Deering. RFC 2463: Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
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. RFC 1883, December 1995.
[7] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March [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. 1997.
[8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. [9] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
RFC 1884, December 1995. RFC 2373, July 1998.
[9] Stephen Kent and Randall Atkinson. IP Authentication Header. [10] S. Kent and R. Atkinson. RFC 2402: IP authentication header,
draft-ietf-ipsec-auth-header-06.txt, May 1998. (work in November 1998. Status: PROPOSED STANDARD.
progress).
[10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP [11] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP
version 6. RFC 1981, August 1996. version 6. RFC 1981, August 1996.
[11] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for [12] T. Narten and H. Alvestrand. RFC 2434: Guidelines for writing
an IANA considerations section in RFCs, October 1998. Status:
BEST CURRENT PRACTICE.
[13] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP version 6 (IPv6). RFC 1970, August 1996. IP version 6 (IPv6). RFC 1970, August 1996.
[12] Thomas Narten and Harald Tveit Alvestrand. Guidelines [14] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor
for Writing an IANA Considerations Section in RFCs. discovery for IP Version 6 (IPv6), December 1998. Obsoletes
draft-iesg-iana-considerations-04.txt, May 1998. (work in RFC1970 [13]. Status: DRAFT STANDARD.
progress).
[13] C. Perkins. Extensions for the Dynamic Host Configuration [15] C. Perkins. Extensions for the Dynamic Host Configuration
Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-11.txt, June 1998. Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-11.txt, February
(work in progress). 1999. (work in progress).
[14] David C. Plummer. An Ethernet Address Resolution Protocol: [16] David C. Plummer. An Ethernet Address Resolution Protocol:
Or Converting Network Protocol Addresses to 48.bit Ethernet Or Converting Network Protocol Addresses to 48.bit Ethernet
Addresses for Transmission on Ethernet Hardware. RFC 826, Addresses for Transmission on Ethernet Hardware. RFC 826,
November 1982. November 1982.
[15] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [17] J. B. Postel. User Datagram Protocol. RFC 768, August 1980.
[16] J. B. Postel, Editor. Internet Protocol. RFC 791, September [18] J. B. Postel, Editor. Internet Protocol. RFC 791, September
1981. 1981.
[17] S. Thomson and T. Narten. IPv6 Stateless Address [19] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. RFC 1971, August 1996. Autoconfiguration. RFC 1971, August 1996.
[18] S. Thomson and T. Narten. IPv6 Address Autoconfiguration. [20] S. Thomson and T. Narten. RFC 2462: IPv6 stateless address
draft-ietf-ipngwg-addrconf-v2-00.txt, November 1997. (work in autoconfiguration, December 1998. Obsoletes RFC1971 [19].
progress). Status: DRAFT STANDARD.
[19] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [21] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. RFC 2165, July 1997. Location Protocol. RFC 2165, July 1997.
[20] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates [22] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
in the Domain Name System (DNS). RFC 2136, April 1997. in the Domain Name System (DNS). RFC 2136, 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: (717) 524-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 Perkins Jim Bound Charles E. Perkins
Compaq Computer Corporation Technology Development Compaq Computer Corporation Sun Microsystems Laboratories
110 Spitbrook Road, ZKO3-3/U14 Sun Microsystems, Inc. 110 Spitbrook Road, ZKO3-3/U14 15 Network Circle
Nashua, NH 03062 901 San Antonio Rd. Nashua, NH 03062 Menlo Park, CA 94025
Palo Alto, CA 94303 USA USA
Phone: +1-603-884-0400 +1-650-786-6464
Fax: +1-650-786-6445 Phone: +1-603-884-0400 Phone: +1 650 786-6464
E-mail: bound@zk3.dec.com charles.perkins@sun.com EMail: bound@zk3.dec.com EMail: cperkins@eng.sun.com
Fax: +1 650 786-6445
 End of changes. 

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