draft-ietf-dhc-dhcpv6-11.txt   draft-ietf-dhc-dhcpv6-12.txt 
Internet Engineering Task Force J. Bound Internet Engineering Task Force J. Bound
INTERNET DRAFT Digital Equipment Corp. INTERNET DRAFT Digital Equipment Corp.
DHC Working Group C. Perkins DHC Working Group C. Perkins
Obsoletes: draft-ietf-dhc-dhcpv6-11.txt Sun Microsystems Obsoletes: draft-ietf-dhc-dhcpv6-11.txt Sun Microsystems
21 November 1997 13 March 1998
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-11.txt draft-ietf-dhc-dhcpv6-12.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. 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 learn the current status of any Internet-Draft, please check To view the entire list of current Internet-Drafts, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCPv6) provides a framework The Dynamic Host Configuration Protocol (DHCPv6) provides a framework
for passing configuration information, via extensions, to IPv6 nodes. for passing configuration information, via extensions, to IPv6 nodes.
It offers the capability of automatic allocation of reusable network It offers the capability of automatic allocation of reusable network
addresses and additional configuration flexibility. This protocol addresses and additional configuration flexibility. This protocol
should be considered a stateful counterpart to the IPv6 Stateless should be considered a stateful counterpart to the IPv6 Stateless
Address Autoconfiguration protocol specification, and can be used Address Autoconfiguration protocol specification, and can be used
separately or together with the latter to obtain configuration separately or together with the latter to obtain configuration
skipping to change at page 1, line 60 skipping to change at page 1, line 62
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Terminology and Definitions 2 2. Terminology 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 . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Design Model 5 3. Protocol Design Model 5
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5
3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 6 3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Request/Response Processing Model . . . . . . . . . . . . 7 3.3. Request/Response Processing Model . . . . . . . . . . . . 7
4. DHCP Message Formats and Field Definitions 8 4. DHCP Message Formats and Field Definitions 9
4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 9
4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9 4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 10
4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 11 4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 11
4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 13
4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13 4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 14
4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 15 4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 16
5. DHCP Client Considerations 16 5. DHCP Client Considerations 16
5.1. Verifying Resource Allocations After Restarts . . . . . . 16 5.1. Verifying Resource Allocations After Restarts . . . . . . 17
5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16 5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 17
5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 17 5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 18
5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 18 5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 19
5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 20 5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 20
5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 20 5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 21
5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 21 5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 21
5.8. Interaction with Stateless Address Autoconfiguration . . 21 5.8. Interaction with Stateless Address Autoconfiguration . . 23
6. DHCP Server Considerations 22 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 . . . . . . . . . . . . . 23 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 . 25 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
7. DHCP Relay Considerations 26 6.6. Client-Resource timeouts . . . . . . . . . . . . . . . . 28
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 27
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 27
7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 28
8. Retransmission and Configuration Variables 28 7. DHCP Relay Considerations 28
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 28
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 29
7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 29
9. Security Considerations 31 8. Retransmission and Configuration Variables 30
10. Year 2000 considerations 32 9. Security Considerations 33
11. Acknowledgements 32 10. Year 2000 considerations 33
A. Related Work in IPv6 32 11. Acknowledgements 34
B. Comparison between DHCPv4 and DHCPv6 33 A. Changes for this revision 34
Chair's Address 39 B. Related Work in IPv6 35
Author's Address 39 C. Comparison between DHCPv4 and DHCPv6 36
Chair's Address 41
Author's Address 41
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 a configuration parameters from a DHCP server to a client, and a
mechanism for allocation of network addresses and other related mechanism for allocation of network addresses and other related
parameters to IPv6 [6] nodes. parameters to IPv6 [6] nodes.
DHCP is built on a client-server model, where designated DHCP servers DHCP is built on a client-server model, where designated DHCP servers
allocate network addresses and automatically deliver configuration allocate network addresses and automatically 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.
Since it is typically impractical to deploy a DHCP server on
each network on which DHCP clients are to be served, a DHCP relay
function is defined to assist clients in finding DHCP servers,
and in delivering packets for clients that do not have sufficient
address scope to complete a transaction with a DHCP server on another
network. Either a DHCP server or a DHCP relay is required to be
present on every network on which DHCP clients will need to be
served.
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'' [12]. IPv6'' [12]. DHCP only provides a mechanism, but does not provide
any policy with respect to parameter and resource assignments.
The IPv6 Addressing Architecture [8] and IPv6 Stateless Address The IPv6 Addressing Architecture [8] and IPv6 Stateless Address
Autoconfiguration [16] specifications provide new features not Autoconfiguration [16] specifications provide new features not
available in IP version 4 (IPv4) [15], which are used to simplify available in IP version 4 (IPv4) [15], 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 full duplex link to the Internet. apply to nodes which do not enjoy a broadcast link to the 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;
section 3.2 briefly describes the protocol messages and their section 3.2 briefly describes the protocol messages and their
semantics. Section 4 provides the message formats and field semantics. Section 4 provides the message formats and field
definitions used for each message. Sections 5, 6, and 7 specify definitions used for each message. Sections 5, 6, and 7 specify
how clients, servers, and relays interact. The timeout and how clients, servers, and relays interact. The timeout and
retransmission guidelines and configuration variables are discussed retransmission guidelines and configuration variables are discussed
in Section 8. Appendix A summarizes related work in IPv6 that will in Section 8. Appendix B summarizes related work in IPv6 that will
provide helpful context; it is not part of this specification, but provide helpful context; it is not part of this specification, but
included for informational purposes. Appendix B discusses the included for informational purposes. Appendix C discusses the
differences between DHCPv4 and DHCPv6. differences between DHCPv4 and DHCPv6.
2. Terminology and Definitions 2. Terminology and Definitions
Relevant terminology from the IPv6 Protocol [6], IPv6 Addressing Relevant terminology from the IPv6 Protocol [6], IPv6 Addressing
Architecture [8], and IPv6 Stateless Address Autoconfiguration [16] Architecture [8], and IPv6 Stateless Address Autoconfiguration [16]
will be provided, and then the DHCPv6 terminology. will be provided, and then the DHCPv6 terminology.
2.1. IPv6 Terminology 2.1. IPv6 Terminology
skipping to change at page 3, line 23 skipping to change at page 3, line 34
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 DHCP agent (server or relay).
link as the DHCP client.
binding A binding (or, client binding) in DHCP contains the binding A binding (or, client binding) in DHCP contains the
data which a DHCP server maintains for each of its data which a DHCP server maintains for each of its
clients (see Section 6). clients (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.
skipping to change at page 5, line 5 skipping to change at page 5, line 9
implementation which does include the option. implementation which does include the option.
silently discard silently discard
The implementation discards the packet without The implementation discards the packet without
further processing, and without indicating an error further processing, and without indicating an error
to the sender. The implementation SHOULD provide to the sender. The implementation SHOULD provide
the capability of logging the error, including the the capability of logging the error, including the
contents of the discarded packet, and SHOULD record contents of the discarded packet, and SHOULD record
the event in a statistics counter. the event in a statistics counter.
2.4. Error Values
This specification document uses symbolic names for the errors known
to DHCP clients and servers, as used for instance in the status field
of the DHCP Reply message (see section 4.4). The symbolic names have
the actual values listed below:
Message Name Value
UnspecFailure 16
BadAuth 17
Unavail 19
NoBinding 20
InvalidSource 21
NoServer 23
BadCharset 24
ICMPError 64
3. Protocol Design Model 3. Protocol Design Model
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.
skipping to change at page 5, line 50 skipping to change at page 6, line 28
- DHCPv6 MUST be compatible with IPv6 Stateless Address - DHCPv6 MUST be compatible with IPv6 Stateless Address
Autoconfiguration [16]. Autoconfiguration [16].
- 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 the requirements of automated - DHCP architecture MUST support the requirements of automated
renumbering of IP addresses [3]. renumbering of IP addresses [3].
- DHCP servers SHOULD be able to support Dynamic Updates to - DHCP servers SHOULD be able to support Dynamic Updates to
DNS [18]. DNS [19].
- 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.
- DHCP MUST work on network links that do not have routers, as long - DHCP MUST work on isolated network links, as long as a DHCP
as a DHCP server is present on the link. server is present on the link.
- A DHCP server to server protocol is NOT part of this - A DHCP server to server protocol is NOT part of this
specification. specification.
- It is NOT a design goal of DHCP to specify how a server - It is NOT a design goal of DHCP to specify how a server
configuration parameter database is maintained or determined. configuration parameter database is maintained or determined.
Methods for configuring DHCP servers are outside the scope of Methods for configuring DHCP servers are outside the scope of
this document. this document.
3.2. DHCP Messages 3.2. DHCP Messages
skipping to change at page 8, line 14 skipping to change at page 8, line 38
FF05:0:0:0:0:0:1:3 FF05:0:0:0:0:0:1:3
All DHCP servers MUST join the site-local All DHCP servers MUST join the site-local
All-DHCP-Servers multicast group at the address All-DHCP-Servers multicast group at the address
FF05:0:0:0:0:0:1:3. FF05:0:0:0:0:0:1:3.
FF05:0:0:0:0:0:1:4 FF05:0:0:0:0:0:1:4
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.
Note that All-DHCP-Relay is currently unused in this specification.
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 firewalls [4] are used, DHCP transactions
using UDP destination ports 546 and 547 will need to be permitted. using UDP destination ports 546 and 547 will need to be permitted.
skipping to change at page 8, line 41 skipping to change at page 9, line 22
A DHCP client transmits a DHCP Solicit message over the interface it A DHCP client transmits a DHCP Solicit message over the interface it
is trying to configure, to obtain one or more DHCP server addresses. is trying to configure, to obtain one or more DHCP server addresses.
In the event that there is no DHCP server on this link, such a In the event that there is no DHCP server on this link, such a
request MAY be forwarded by a DHCP relay attached to this link (if request MAY be forwarded by a DHCP relay attached to this link (if
such a relay exists) on behalf of a client to a DHCP server. such a relay exists) on behalf of a client to a DHCP server.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |C| reserved | | 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 1
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.
prefix size A nonzero prefix size is the number of leftmost bits
of the agent's IPv6 address which make up the routing
prefix.
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 If nonzero, the IP address of the interface on which
the relay received the client's DHCP Solicit message the relay received the client's DHCP Solicit message
To obtain a DHCP Agent address a DHCP client SHOULD send a DHCP To obtain a neighboring DHCP Agent address a DHCP client SHOULD send
Solicit message to the All-DHCP-Agents multicast address (see a DHCP Solicit message to the All-DHCP-Agents multicast address
section 3.3). Any DHCP Relay receiving the solicitation MUST forward (see section 3.3). Any DHCP Relay receiving the solicitation, that
it to the All-DHCP-Servers multicast address, to instruct DHCP does not have the address of a DHCP Server configured, MUST forward
the solicitation to the All-DHCP-Servers multicast address (see
Section 7). The solicitation is sent in order to instruct DHCP
servers to send their advertisements to the prospective client. servers to send their advertisements to the prospective client.
In that case, the relay MUST copy a non-link-local address of its When forwarding solicitations, the relay MUST copy a non-link-local
interface from which the client's solicitation was received into the address of its interface from which the client's solicitation was
relay address field. received into the relay address field.
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 DHCP Agent to which a DHCP Request client about the IP address of a DHCP Agent 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 DHCP Relay links, the server sends the advertisement back through the DHCP Relay
whence the solicitation came. whence the solicitation came.
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|P| reserved | | msg-type=2 |S|P| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server preference (if present) | | server 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 4 skipping to change at page 10, line 36
| 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.
P If set, the server preference is present. P If set, the server preference is valid.
reserved 0 reserved 0
server preference server preference
A 32-bit unsigned integer indicating a server's A 32-bit unsigned integer indicating a server's
willingness to provide service to the client. willingness 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.
server address server address
If present, the IP address of the DHCP server If present, the IP address of the DHCP server
extensions See [12]. extensions See [12].
Suppose that a DHCP server on the same link as a client issues the Suppose that a DHCP server on the same link as a client issues the
skipping to change at page 10, line 39 skipping to change at page 11, line 20
extensions See [12]. extensions See [12].
Suppose that a DHCP server on the same link as a client issues the Suppose that a DHCP 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. No server address will client, and the 'S' bit will be set to zero. No server address will
be present in the DHCP Advertise message. be present in the DHCP Advertise message.
If the 'P' bit is set, the server preference field is present. If If the `P' bit is set, the server preference field is valid. If the
the 'P' bit is not set, the server preference field is not present, `P' bit is not set, the server preference field is not valid, but
but implicitly has the value of 0xffffffff (in other words, the implicitly has the value of 0xffffffff (in other words, the highest
highest possible value). possible value).
The DHCP server MUST copy the client's link-local address into the The DHCP server MUST copy the client's link-local address into the
advertisement which is sent in response to a DHCP Solicit. Both advertisement which is sent in response to a DHCP Solicit. Both
agent address and server address (if present) of the DHCP Advertise agent address and server address (if present) of the DHCP Advertise
message MUST have sufficient scope to be reachable by the DHCP message MUST have sufficient scope to be reachable by the DHCP
client. Moreover, the Agent address of any DHCP Advertise message client. Moreover, the agent address of any DHCP Advertise message
sent by a DHCP relay MUST NOT be a link-local address. In situations sent by a DHCP relay MUST NOT be a link-local address. In situations
where there are no routers sending Router Advertisements, then a DHCP where there are no routers sending Router Advertisements, then a DHCP
server MUST be configured on the same link as prospective clients. server MUST be configured on the same link as prospective clients.
The DHCPv6 protocol design does not apply to situations where the The DHCPv6 protocol design does not apply to situations where the
client has no way to route messages to a server not on the same link. client has no way to route messages to a server not on the same link.
See section 5.3 for information about how clients handle the server See section 5.3 for information about how clients handle the server
preference field. preference field.
4.3. DHCP Request Message Format 4.3. DHCP Request Message Format
skipping to change at page 11, line 29 skipping to change at page 12, line 12
DHCP server because the server could not return any response to the DHCP server because the server could not return any response to the
client. Otherwise, the client MAY omit the server address in the client. Otherwise, the client MAY omit the server address in the
DHCP Request message; in this case, the client MUST clear the S-bit DHCP Request message; in this case, the client MUST clear the S-bit
in the DHCP Request message and send it directly to to the server, in the DHCP Request message and send it directly to to the server,
using the server address as the IP destination address in the IP using the server address as the IP destination address in the IP
header. header.
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|N| 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 resources associated with the client binding,
C If set, the client requests the server to remove all except those resources provided as extensions.
resources associated with the client binding, except
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
of its previous transaction IDs be expunged and made
available for re-use.
N If set, the client has begun operating in stateless R If set, the client has rebooted and requests that
address autoconfiguration. all of its previous transaction-IDs be expunged
and made available for re-use.
rsvd 0 rsvd 0
transaction-ID transaction-ID
A monotonically increasing unsigned integer used to A monotonically increasing unsigned integer used
identify this Request, and copied into the Reply. to identify this Request, 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
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 an agent's interface, copied from a The IP address of a neighboring agent's
DHCP Advertisement message. interface, copied from a DHCP Advertisement
message.
server address server address
If present, the IP address of the DHCP server which If present, the IP address of the DHCP server
should receive the client's DHCP Request message. which should receive the client's DHCP Request
message.
extensions See [12]. extensions See [12].
When the client sets the 'C' bit and adds extensions, the server
is expected to deallocate all other resources not listed in the
extension. The resources explicitly requested in extensions to the
Request message SHOULD be reallocated by the server to the client,
assuming the client is still authorized to receive them.
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 is
addressed to the agent address found in the DHCP Request message. If addressed to the agent address found in the DHCP Request message. If
the 'L' bit is set, then the client's link-local address will also be the 'L' bit is set, then the client's link-local address will also be
present. 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
skipping to change at page 13, line 46 skipping to change at page 14, line 31
message, and the relay uses the link-local address to deliver the message, and the relay uses the link-local address to deliver the
Reply message to the client. Reply message to the client.
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 have
a valid IP address with sufficient scope to allow access to the a valid IP address with sufficient scope to allow access to the
target server. If parameters are specified in the extensions, only target server. If parameters are specified in the extensions, only
those parameters are released. The DHCP server acknowledges the those parameters are released. The DHCP server acknowledges the
Release message by sending a DHCP Reply (Sections 4.4, 6.3). Release message by sending a DHCP Reply (Sections 4.4, 6.3). The
DHCP Client MUST wait for a DHCP Reply, and follow the retransmission
rules in section 8.
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=5 |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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 5
D If the 'D' ("Direct") flag is set, the client instructs D If the 'D' ("Direct") flag is set, the client instructs
the server to send the DHCP Reply directly back to the the server to send the DHCP Reply directly back to the
client, instead of using the given agent address and client, instead of using the given agent address and
link-local address to relay the Reply message. link-local address to relay the Reply message.
reserved 0 reserved 0
transaction-ID transaction-ID
A monotonically increasing unsigned integer used to A monotonically increasing unsigned integer used to
identify this Release, and copied into the Reply. identify this Release, and copied into the Reply.
skipping to change at page 15, line 5 skipping to change at page 15, line 39
extensions See [12] extensions See [12]
Suppose that the client has an IP address that will still be valid Suppose that the client has an IP address that will still be valid
after the server performs the operations requested in the extensions after the server performs the operations requested in the extensions
to the DHCP Release message, and which has sufficient scope to be to the DHCP Release message, and which has sufficient scope to be
reachable from the server. In that case, and only then, the client reachable from the server. In that case, and only then, the client
SHOULD set the 'D' flag. When the 'D' flag is set, the server MUST SHOULD set the 'D' flag. When the 'D' flag is set, the server MUST
send the DHCP Reply back to the client using the client address field send the DHCP Reply back to the client using the client address field
of the Release message. Otherwise, when the 'D' bit is not set, the of the Release message. Otherwise, when the 'D' bit is not set, the
server MUST send its DHCP Reply message to the agent address in the server MUST send its DHCP Reply message to the agent address in the
Release message, so that the relay agent can subsequently forward the Release message, so that the relay agent can subsequently forward
Reply back to the releasing client at the client's link-local address the Reply back to the releasing client at the client's link-local
indicated in the Reply message. Note that it is an error (status address indicated in the Reply message. Note that it is an error
code 21) to include within the DHCP Release message both the 'D' bit (status code ``InvalidSource'' (see Section 2.4)) to include within
and an IP address extension which has the IP address used as the the DHCP Release message both the 'D' bit and an IP address extension
client IP address field of the DHCP Release message header. If the which has the IP address used as the client IP address field of the
clients link-local address and agent address do not match a client DHCP Release message header. If the clients link-local address and
binding (see section 6) an error (status code 20) will be returned to agent address do not match a client binding (see section 6) an error
the client. (status code ``NoBinding'' (see Section 2.4)) will be returned to the
client.
4.6. DHCP Reconfigure Message Format 4.6. DHCP Reconfigure Message Format
Reconfigure messages can only be sent to clients which have 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 client to which it is sent is assumed to have a valid message, the client to which it is sent is assumed to have a valid
IP address with sufficient scope to be accessible by the server. IP address with sufficient scope to be accessible by the server.
Reconfigure messages can only be sent to clients which are reachable Only the parameters which are specified in the extensions to the
by the DHCP server. Hence, the DHCP Reconfigure message is sent Reconfigure message need be requested again by the client. A
without the assistance of any DHCP relay. Only the parameters which Reconfigure message can either be unicast or multicast by the server.
are specified in the extensions to the Reconfigure message need be
requested again by the client. A Reconfigure message can either be
unicast or multicast by the server.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |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 monotonically increasing unsigned integer used to
identify this Reconfigure message, and copied into identify this Reconfigure message, and copied into
the client's Request. the client's Request.
skipping to change at page 16, line 31 skipping to change at page 17, line 18
across client system reboots and DHCP client program restarts. across client system reboots and DHCP client program restarts.
However, in these circumstances a DHCP client MUST also formulate a However, in these circumstances a DHCP client MUST also formulate a
DHCP Request message to verify that its configured parameters and DHCP Request message to verify that its configured parameters and
resources are still valid. This Request message MUST have the 'C' resources are still valid. This Request message MUST have the 'C'
bit set, to clean up stale client binding information at the server bit set, to clean up stale client binding information at the server
which may no longer be in use by the client; stale information is 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 that which the client does not include in extensions to such request
messages. 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
REPLY_MSG_MIN_RETRANS (see section 8), the client may still use any REQUEST_MSG_MIN_RETRANS (see section 8), the client may still use
resources whose lifetimes have not yet expired. In such cases, any resources whose lifetimes have not yet expired. In such cases,
however, the client MUST begin to search for another server by however, the client MUST begin to search for another server by
multicasting a new DHCP Solicit message, again with the 'C' bit set. multicasting a new DHCP Solicit message, again with the 'C' bit set.
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.
skipping to change at page 17, line 17 skipping to change at page 17, line 50
which may be sent in response to the solicitation. which may be sent in response to the solicitation.
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. Address field to 16 octets of zeros.
If a DHCP client reboots and does not have a valid IP address, If a DHCP client reboots and does not have a valid IP address,
it MUST set the 'C' bit in the DHCP Solicit message it sends it MUST set the 'C' bit in the DHCP Solicit message it sends
when restarting. By setting the 'C' bit in the solicitation, a when restarting. By setting the 'C' bit in the solicitation, a
DHCP client requests that all the DHCP servers that receive the DHCP client requests that all the DHCP servers that receive the
solicitation should clean up their client records that match its solicitation should clean up their client records that match its
link-local address. The server MUST take the Relay Address Field and link-local address.
use it as the agent address prefix to locate the client binding (see
section 6.0 for server bindings).
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 [11] message, by at least some random amount of time
between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see section 8 between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see section 8).
seconds. This delay is intended to help stagger requests to DHCP This delay is intended to help stagger requests to DHCP servers (and
servers (and avoid link-layer collisions) after a power outage avoid link-layer collisions) after a power outage causes many nodes
causes many nodes to reboot all at once. Each subsequent DHCP to reboot all at once. Each subsequent DHCP Solicit message that is
Solicit message that is issued before receiving an advertisement issued before receiving an advertisement MUST be delayed by twice the
MUST be delayed by twice the amount by which the previous DHCP amount by which the previous DHCP Solicit message was delayed, plus
Solicit message was delayed, plus a small random delay between a small random delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY
MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds. seconds.
5.3. Receiving DHCP Advertise Messages 5.3. Receiving DHCP Advertise Messages
After a DHCP client has received a DHCP Advertise message, it has the After a DHCP client has received a DHCP Advertise message, it has the
address of a DHCP server for subsequent DHCP Request messages. If address of a DHCP server for subsequent DHCP Request messages. If
the 'S' bit is zero, the DHCP Advertise message was transmitted by the 'S' bit is zero, the DHCP Advertise message was transmitted by
a DHCP server on the same link as the client, and the client uses a DHCP server on the same link as the client, and the client uses
the Agent address as the address of a DHCP server; otherwise, the the agent address as the address of a DHCP server; otherwise, the
DHCP server address is located in the server address field. If the DHCP server address is located in the server address field. If the
server's address is shown as a Multicast address, the advertisement server's address is shown as a Multicast address, the advertisement
MUST be silently discarded. MUST be silently discarded.
A DHCP server MAY append extensions to its Advertisements; this might A DHCP server MAY append extensions to its Advertisements; this might
allow the DHCP client to select the configuration that best meets its allow the DHCP client to select the configuration that best meets its
needs from among several prospective servers. needs from among several prospective servers.
Unless a DHCP Advertisement is received with a "server preference" If a DHCP Advertisement is received with a "server preference"
field of 0xffffffff, a DHCP client must wait ADV_CLIENT_WAIT seconds field invalid (the 'P' bit is not set), or equal to 0xffffffff
after issuing the DHCP Solicit message in order to receive the (see Section 4.2), the DHCP client can use the information in
Advertisement with the highest preference. After waiting for that the DHCP Solicit message immediately without waitin for any more
period of time, a client MUST select the highest preference DHCP advertisements. Otherwise, the DHCP client MUST wait ADV_CLIENT_WAIT
server as the target of its DHCP request. If a DHCP client receives seconds after issuing the DHCP Solicit message in order to receive
an advertised preference of 0xffffffff, it does not have to wait for the Advertisement with the highest preference. After waiting for
any more advertisements. that period of time, a client MUST select the highest preference DHCP
server as the target of its DHCP request.
If a DHCP client sends a DHCP Request to a highly preferred DHCP If a DHCP client sends a DHCP Request to a more highly preferred
server but fails to receive a DHCP reply from that server after DHCP server but fails to receive a DHCP reply from that server after
following the retransmission algorithm in section 8, the client may following the retransmission algorithm in section 8, the client may
subsequently attempt to send a DHCP Request to a less preferred subsequently attempt to send a DHCP Request to a less preferred
server. server.
A DHCP client is free to cache the result of any DHCP Advertisement A DHCP client is free to cache the result of any DHCP Advertisement
it hears. However, it should be noted that this is purely a it hears. However, it should be noted that this is purely a
potential performance enhancement as the results need not be constant potential performance enhancement as the results need not be constant
over time, hence it may not get a response if it uses the address over time, hence it may not get a response if it uses the address
obtained from this message and may have to emit its own DHCP Solicit obtained from this message and may have to emit its own DHCP Solicit
message subsequently. message subsequently.
5.4. Sending DHCP Request Messages 5.4. Sending DHCP Request Messages
A DHCP client obtains configuration information from a DHCP server by A DHCP client obtains configuration information from a DHCP server by
sending a DHCP Request message. The client MUST know the server's sending a DHCP Request message. The client MUST know the server's
address before sending the Request message, and the client MUST address before sending the Request message, and the client MUST
have acquired a (possibly identical) DHCP agent address. If the have acquired a (possibly identical) DHCP agent address. If the
client and server are on the same link, the agent address used by the client and server are on the same link, the agent address used by
client MUST be the same as the DHCP server's address. A DHCP Request the client MUST be the same as the DHCP server's address. A DHCP
message MUST NOT be sent to any multicast address, since otherwise Request message MUST NOT be sent to any multicast address. Otherwise
multiple DHCP agents would possibly allocate resources to the client multiple DHCP servers would possibly allocate resources to the client
in response to the same Request, and the client would have no way to in response to the same Request, and the client would have no way to
know which servers had made the allocations, if any packets were lost know which servers had made the allocations, if any packets were lost
due to collisions, etc. due to 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 server address of sufficient scope, then the client MUST include the server
address in the appropriate field and set the 'S' bit in the DHCP address in the appropriate field and set the 'S' bit in the DHCP
Request message. In this case, the IP destination address in the IP Request message. In this case, the IP destination address in the IP
header will be a DHCP relay address. header will be a DHCP relay address.
skipping to change at page 19, line 21 skipping to change at page 20, line 8
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 DHCP client sends the all desired extensions have been applied, the DHCP client sends the
DHCP Request to the appropriate DHCP Agent. DHCP Request to the appropriate DHCP Agent.
For each pending DHCP Request message, a client MUST maintain the For each pending DHCP Request message, a client MUST maintain the
following information: following information:
- The transaction-ID of the request message, The transaction-ID of the request message,
- The server address, The server address,
- The agent address (which can be the same as the server address), The agent address (which can be the same as the server
- The time at which the next retransmission will be attempted, and address),
- All extensions appended to the request message. The time at which the next retransmission will be attempted,
and
All extensions appended to the request message.
If a client does not receive a DHCP Reply message (Section 5.5) with If a client does not receive a DHCP Reply message (Section 5.5) with
the same transaction-ID as a pending DHCP Request message within the same transaction-ID as a pending DHCP Request message within
REPLY_MSG_TIMEOUT (see section 8) seconds, or if the received DHCP REPLY_MSG_TIMEOUT (see section 8) seconds, or if the received DHCP
Reply message contains a DHCP Authentication extension which fails Reply message contains a DHCP Authentication extension which fails
to provide the correct authentication information, the client MUST to provide the correct authentication information, the client MUST
retransmit the Request with the same transaction-ID and continue to retransmit the Request with the same transaction-ID and continue to
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 never receives a Reply message, it naturally those rules) the client never receives a Reply message, it naturally
SHOULD start over again by sending a new DHCP Solicit message to find SHOULD start over again by sending a new DHCP Solicit message to find
skipping to change at page 21, line 38 skipping to change at page 22, line 26
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. If the 'N' bit is
not set, processing from then on is the same as specified above in not set, processing from then on is the same as specified above in
Section 5.4. Section 5.4.
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.
Note that a server may ask its client to join a multicast group If a client has recently sent a DHCP Request to the server from which
for the purpose of receiving DHCP Reconfigure messages. When a it subsequently received the DHCP Reconfigure message, the client
Reconfigure message is delivered to the client by way of the selected SHOULD silently discard the Reconfigure message until the server
multicast address, the client MUST delay its further response for sends the DHCP Reply message with the same transaction-ID as the
a random amount of time uniformly distributed within the interval client's DHCP Request message.
between RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds (see
section 8). This will minimize the likelihood that the server will
be flooded with DHCP Request messages.
5.8. Interaction with Stateless Address Autoconfiguration A server may ask its client to join a multicast group for the
purpose of receiving DHCP Reconfigure messages. When a Reconfigure
message is delivered to the client by way of the selected multicast
address, the client MUST delay its further response for a random
amount of time uniformly distributed within the interval between
RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds (see section 8).
This will minimize the likelihood that the server will be flooded
with DHCP Request messages.
If a client begins to receive Router Advertisements [11] with the 'M' Reconfigure messages can be retransmitted by the DHCP server with
bit no longer set (so that the link is no longer a "managed" link), the same transaction-ID. When a client receives such a retransmitted
then the client SHOULD send one or more DHCP Release messages to Reconfigure message within XID_TIMEOUT of the last received
deallocate the IP addresses it has received. The client sends the Reconfigure message with the same transaction-ID, the client MUST
DHCP Release messages to the servers recorded in the resource-server reformulate exactly the same DHCP Request message and retransmit the
associations maintained for the IP addresses. request message to the server again. In this way, the DHCP server
can make use of the retransmission algorithm to ensure that all
affected clients have received the Reconfigure message.
If a client is receiving Router Advertisements with the 'M' bit equal 5.8. Interaction with Stateless Address Autoconfiguration
to 0, then it is using IP addresses obtained by way of Stateless
Address Autoconfiguration [16]. In this case, if the client receives
a DHCP Reconfigure message, the client MUST return a DHCP Request
message to the DHCP server with the 'N' bit set.
Suppose a client, after using Stateless Address Autoconfiguration Please refer to the Stateless Address Autoconfiguration
to configure its stateless IP address, begins to receive Router Protocol specification [16] and its follow-on, Stateless Address
Advertisements with the 'M' bit set. Then the client MAY continue Autoconfiguration version 2 [17] for details regarding the actions
to use its existing IP addresses, but it MUST send a DHCP Solicit taken by DHCP clients upon receiving Router Advertisements with
message to discover a DHCP server. If the solicitation results in changing values for the 'M' and 'O' bits.
the receipt of of a DHCP Advertisement message from a DHCP server,
the client MUST subsequently transact a DHCP Request message with at
least one such DHCP server.
6. DHCP Server Considerations 6. DHCP Server Considerations
A node which is not a DHCP client or DHCP relay MUST ignore any DHCP A node which is not a DHCP client or DHCP relay MUST ignore any DHCP
Advertise, DHCP Reply, or DHCP Reconfigure message it receives. Advertise, 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 prefix>, since the link-local
address is guaranteed to be unique [16] on the link identified by the address is guaranteed to be unique [16] on the link identified by the
agent address. An implementation MUST support bindings consisting agent address. An implementation MUST support bindings consisting
of at least a client's link-local address, agent address prefix, of at least a client's link-local address, agent address prefix,
preferred lifetime and valid lifetime [16] for each client address, preferred lifetime and valid lifetime [16] for each client address.
and the transaction-ID. A client binding may be used to store any A server MAY, at the discretion of the network administrator, be
configured so that client bindings are identified by the client's
MAC address, without need to use the additional information supplied
by the relay address. A client binding may be used to store any
other information, resources, and configuration data which will be other information, resources, and configuration data which will be
associated with the client. A DHCP server MUST retain its clients' associated with the client. A DHCP server MUST retain its clients'
bindings across server reboots, and, whenever possible, a DHCP client bindings across server reboots, and, whenever possible, a DHCP client
should be assigned the same configuration parameters despite server should be assigned the same configuration parameters despite server
system reboots and DHCP server program restarts. A DHCP server MUST system reboots and DHCP server program restarts. A DHCP server MUST
support fixed or permanent allocation of configuration parameters to support fixed or permanent allocation of configuration parameters to
specific clients. specific clients.
In addition to the client binding a Server must maintain an
XID_TIMEOUT binding cache to determine if a previous transaction-ID
is being retransmitted by a client. An implementation of an
XID_TIMEOUT binding cache MUST support at least a tuple consisting of
the client's link-local address, agent address prefix, IPv6 address,
and XID_TIMEOUT value when the cache entry can be deleted (see
Section 8).
6.1. Receiving DHCP Solicit Messages 6.1. Receiving DHCP Solicit Messages
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 DHCP server MUST check to make sure that the multicast address, the DHCP server MUST check to make sure that the
relay address is present, and not a link-local address. If the relay address is present, and 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 DHCP server
deallocates all resources that match its link-local address. The
server MUST take the Relay Address Field and use it as the agent
address prefix to locate the client binding.
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. relays on the same link. The prefix size field in the solicitation
enables the server ascertain exactly when two agent IP addresses
belong to the same link.
6.2. Sending DHCP Advertise Messages 6.2. Sending DHCP Advertise Messages
Upon receiving and verifying the correctness of a DHCP Solicit Upon receiving and verifying the correctness of a DHCP Solicit
message, a server constructs a DHCP Advertise message and transmits message, a server constructs a DHCP Advertise message and transmits
it on the same link as the solicitation was received from. When it on the same link as the solicitation was received from. When
the solicitation is received at the DHCP Servers multicast address, the solicitation is received at the DHCP Servers multicast address,
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).
skipping to change at page 23, line 50 skipping to change at page 25, line 12
is set, the server MUST check that the server address matches the is set, the server MUST check that the server address matches the
destination IP address at which the Request message was received destination IP address at which the Request message was received
by the server. If the server address does not match, the Request by the server. If the server address does not match, the Request
message MUST be silently discarded. message MUST be silently discarded.
If the received agent address and link-local address do not If the received agent address and link-local address do not
correspond to any binding known to the server, then the server correspond to any binding known to the server, then the server
MAY create a new binding for the previously unknown client, and MAY create a new binding for the previously unknown client, and
send a DHCP Reply with any resources allocated to the new binding. send a DHCP Reply with any resources allocated to the new binding.
Otherwise, if the server cannot create a new binding, it SHOULD Otherwise, if the server cannot create a new binding, it SHOULD
return a DHCP Reply with a status of 20. If the client is updating return a DHCP Reply with a status of ``NoBinding'' (see Section 2.4).
its resources but the database is temporarily unavailable, the server If the client is updating its resources but the database is
SHOULD return a DHCP Reply with a status of 19. temporarily unavailable, the server SHOULD return a DHCP Reply with a
status of ``Unavail'' (see Section 2.4).
While processing the Request, the server MUST first determine whether 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 received from the same client during the
previous XID_TIMEOUT seconds. If the transaction-ID is the same as previous XID_TIMEOUT seconds. If the transaction-ID is the same as
one received during that time, the server MUST take the same action one received during that time, the server MUST take the same action
(e.g., retransmit the same DHCP Reply to the client) as it did after (e.g., retransmit the same DHCP Reply to the client) as it did after
processing the previous DHCP Request with the same transaction-ID. processing the previous DHCP Request with the same transaction-ID.
skipping to change at page 25, line 44 skipping to change at page 27, line 8
DHCP Reply message that will be sent back to the releasing client by DHCP Reply message that will be sent back to the releasing client by
way of the client's link-local address. A DHCP Reply message sent way of the client's link-local address. A DHCP Reply message sent
in response to a DHCP Release message MUST be sent to the client's in response to a DHCP Release message MUST be sent to the client's
link-local address via the agent address in the Release message link-local address via the agent address in the Release message
with the 'L' bit set in the Reply, unless the 'D' bit is set in the with the 'L' bit set in the Reply, unless the 'D' bit is set in the
Release message. Release message.
If the received agent address and link-local address do not If the received agent address and link-local address do not
correspond to any binding known to the server, then the server SHOULD correspond to any binding known to the server, then the server SHOULD
return a DHCP Reply, indicating the error by setting the status code return a DHCP Reply, indicating the error by setting the status code
to 20. to ``NoBinding'' (see Section 2.4).
Otherwise, if the agent address and link-local address indicate a Otherwise, if the agent address and link-local address indicate a
binding known to the server, then the server continues processing the binding known to the server, then the server continues processing the
Release message. If there are any extensions, the server releases Release message. If there are any extensions, the server releases
the particular configuration items specified in the extensions. the particular configuration items specified in the extensions.
If there are no extensions, the server releases all configuration If there are no extensions, the server releases all configuration
information in the client's binding. information in the client's binding.
After performing the operations indicated in the DHCP Release message After performing the operations indicated in the DHCP Release message
and its extensions, the DHCP server formulates a DHCP Reply message, and its extensions, the DHCP server formulates a DHCP Reply message,
copying the transaction-ID from the DHCP Release message. For copying the transaction-ID from the DHCP Release message. For
each Extension in the DHCP Release message successfully processed each Extension in the DHCP Release message successfully processed
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
skipping to change at page 26, line 28 skipping to change at page 27, line 37
message to the client. message to the client.
6.5. Sending DHCP Reconfigure Messages 6.5. Sending DHCP Reconfigure Messages
If a DHCP server needs to change the configuration associated with If a DHCP server needs to change the configuration associated with
any of its clients, it constructs a DHCP Reconfigure message and any of its clients, it constructs a DHCP Reconfigure message and
sends it to each such client. The Reconfigure MAY be sent to a sends it to each such client. The Reconfigure MAY be sent to a
multicast address chosen by the server and previously sent to each of multicast address chosen by the server and previously sent to each of
its clients in an extension to a previous DHCP Reply message. its clients in an extension to a previous DHCP Reply message.
Often, it happens that a client does not send DHCP Request messages It may happen that a client does not send DHCP Request messages
after the DHCP Reconfigure message has been issued and retransmitted after the DHCP Reconfigure message has been issued and retransmitted
according to the algorithm specified in Section 8. This can happen according to the algorithm specified in Section 8. This can happen
when the cleint is not listening for the Reconfigure message, when the client is not listening for the Reconfigure message,
possibly because the client is a mobile node disconnected from the possibly because the client is a mobile node disconnected from the
network, or because the client node has sustained a power outage network, or because the client node has sustained a power outage
or operating system crash. In such cases, the DHCP server SHOULD or operating system crash. In such cases, the DHCP server SHOULD
reserve any resources issued to the client until the client responds reserve any resources issued to the client until the client responds
at some future time, or until administrative intervention causes the at some future time, until the resource allocation times out (see
section 6.6), or until administrative intervention causes the
resources to be manually returned to use. resources to be manually returned to use.
If the server gets another DHCP Request from a client, with a
transaction-ID which does not match that of the recently transmitted
reconfigure message, the server SHOULD send the DHCP Reply to
the client, and wait for RECONF_MSG_RETRANS_INTERVAL, before
retransmitting the DHCP Reconfigure again.
6.6. Client-Resource timeouts
Some resources (for instance, a client's IP address) may only be
allocated to a DHCP client for a particular length of time (for
instance, the valid lifetime of an IP address). If the client does
not renew the resource allocation for such a resource, the DHCP
server MAY make the resource available for allocation to another
client. However, under administrative control, the DHCP server MAY
reserve any resources issued to the client until the client responds
at some future time.
7. DHCP Relay Considerations 7. DHCP Relay Considerations
The DHCP protocol is constructed so that a relay does not have The DHCP protocol is constructed so that a relay does not have
to maintain any state in order to mediate DHCP client/server to maintain any state in order to mediate DHCP client/server
interactions. interactions.
All relays MUST send DHCP Request messages using the source IP All relays MUST send DHCP Request messages using the source IP
address from the interface where the DHCP request was received. address from the interface where the DHCP request was received.
The purpose of the DHCP relay is to enable clients and servers to The purpose of the DHCP relay is to enable clients and servers to
skipping to change at page 27, line 23 skipping to change at page 29, line 4
Upon receiving a DHCP Solicit message from a prospective client, a Upon receiving a DHCP Solicit message from a prospective client, a
relay, by default, forwards the message to all DHCP servers at a site relay, by default, forwards the message to all DHCP servers at a site
according to the following procedure: according to the following procedure:
- copying the prospective client's solicitation message fields into - copying the prospective client's solicitation message fields into
the appropriate fields of the outgoing solicitation, the appropriate fields of the outgoing solicitation,
- copying a non-link-local address of its interface from which the - copying a non-link-local address of its interface from which the
solicitation was received from the client into the DHCP relay solicitation was received from the client into the DHCP relay
address field, and address field, and
- by default, setting the TTL field in the solicitation to the - by default, setting the TTL field in the solicitation to the
value DEFAULT_SOLICIT_TTL (see section 8). value DEFAULT_SOLICIT_TTL (see section 8).
- finally, sending the resulting message to the All-DHCP-Servers - finally, sending the resulting message to one or more DHCP
multicast address, FF05:0:0:0:0:0:1:3. Servers.
By default, the relay sends solicitations to the All-DHCP-Servers
multicast address, FF05:0:0:0:0:0:1:3. However, the relay MAY be
configured with an alternate DHCP server address, or the FQDN of a
DHCP server. Methods for automatically updating such alternately
configured DHCP server addresses are not specified in this document.
When the relay receives a DHCP advertisement, it relays the When the relay receives a DHCP advertisement, it relays the
advertisement to the client at the client's link-local address by way advertisement to the client at the client's link-local address by way
of the interface indicated in the agent's address field. of the interface indicated in the agent's address field.
7.2. DHCP Request Message Processing 7.2. DHCP Request Message Processing
When a relay receives a DHCP Request message, it SHOULD check that When a relay receives a DHCP Request message, it SHOULD check that
the IP source address in the IP header is a link-local address, the IP source address in the IP header is a link-local address,
that the link-local address matches the link-local address field in that the link-local address matches the link-local address field in
the Request message header, and that the agent address field of the the Request message header, and that the agent address field of the
message matches an IP address associated with the interface from message matches an IP address associated with the interface from
which the DHCP Request message was received. If any of these checks which the DHCP Request message was received. If any of these checks
fail, the relay MUST silently discard the Request message. fail, the relay MUST silently discard the Request message.
The relay MUST check whether the 'S' bit is set in the message The relay MUST check whether the 'S' bit is set in the message
header. If not, the packet is discarded, and the relay SHOULD header. If not, the packet is discarded, and the relay SHOULD
return a DHCP Reply message to the address contained in the client's return a DHCP Reply message to the address contained in the client's
link-local address field of the Request message, with status 18. link-local address field of the Request message, with status
``PoorlyFormed'' (see Section 2.4).
If the received request message is acceptable, the relay then If the received request message is acceptable, the relay then
transmits the DHCP Request message to the address of the DHCP server transmits the DHCP Request message to the address of the DHCP server
found in the Server IP Address field of the received DHCP Request found in the Server IP Address field of the received DHCP Request
message. All of the fields of DHCP Request message transmitted by message. All of the fields of DHCP Request message transmitted by
the relay are copied over unchanged from the DHCP Request received the relay are copied over unchanged from the DHCP Request received
from the client. Only the fields in the IP header will differ from from the client. Only the fields in the IP header will differ from
the packet received from the client. If the Relay receives an ICMP the packet received from the client. If the Relay receives an ICMP
error, the Relay SHOULD return a DHCP Reply message to the client error, the Relay SHOULD return a DHCP Reply message to the client
address (which can be found in the payload of the ICMP message [5]), address (which can be found in the payload of the ICMP message [5]),
with status 64. with status ``ICMPError'' (see Section 2.4).
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 link-local address field has the 'L' bit set. It MUST check that the link-local address field
contains a link-local address. If either check fails, the packet contains a link-local address. If either check fails, the packet
MUST be silently discarded. If both checks are satisfied, the relay MUST be silently discarded. If both checks are satisfied, the relay
MUST send a DHCP Reply message to the link-local address listed in MUST send a DHCP Reply message to the link-local address listed in
the received Reply message. Only the fields in the IP header will the received Reply message. Only the fields in the IP header will
differ from the packet received from the server, not the payload. differ from the packet received from the server, not the payload.
skipping to change at page 28, line 34 skipping to change at page 30, line 21
When a DHCP client does not receive a DHCP Reply in response to a When a DHCP client does not receive a DHCP Reply in response to a
pending DHCP Request, the client MUST retransmit the identical DHCP pending DHCP Request, the client MUST retransmit the identical DHCP
Request, with the same transaction-ID, to the same server again Request, with the same transaction-ID, to the same server again
until it can be reasonably sure that the DHCP server is unavailable until it can be reasonably sure that the DHCP server is unavailable
and an alternative can be chosen. The DHCP server assumes that the and an alternative can be chosen. The DHCP server assumes that the
client has received the configuration information included with the client has received the configuration information included with the
extensions to the DHCP Reply message, and it is up to the client extensions to the DHCP Reply message, and it is up to the client
to continue to try for a reasonable amount of time to complete the to continue to try for a reasonable amount of time to complete the
transaction. All the actions specified for DHCP Request in this transaction. All the actions specified for DHCP Request in this
section hold also for DHCP Release messages, that do not have the 'N' section hold also for DHCP Release messages sent by the DHCP client.
bit set, sent by the DHCP client.
Similarly, when a client sends a DHCP Request message in response to Similarly, when a client sends a DHCP Request message in response to
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 for a reasonable amount the identical DHCP Reconfigure to the client a reasonable number
of time, to try to elicit the Request message from the client. If of times to try to elicit the Request message from the client.
no corresponding DHCP Request is received by the server within this If no corresponding DHCP Request is received by the server after
time, the server MAY erase or deallocate information as needed from REQUEST_MSG_MIN_RETRANS retransmissions. time, the server MAY erase
the client's binding. or deallocate information as needed from the client's binding, but
see section 6.5.
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 transaction IDs associated with
that previous state. In order to inform the server that the client that previous state. In order to inform the server that the client
no longer wishes any association to be maintained between used no longer wishes any association to be maintained between used
transaction IDs and previous transactions, the client should set the transaction-IDs and previous transactions, the client should set the
'R' bit in its DHCP Request. 'R' bit in its DHCP Request.
Retransmissions occur using the following configuration variables Retransmissions occur using the following configuration variables
for a DHCP implementation. These configuration variables MUST be for a DHCP implementation. These configuration variables MUST be
configurable by a client or server: configurable by a client or server:
ADV_CLIENT_WAIT ADV_CLIENT_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
skipping to change at page 29, line 49 skipping to change at page 31, line 34
Default: 1 second Default: 1 second
REPLY_MSG_TIMEOUT REPLY_MSG_TIMEOUT
The time in seconds that a DHCP client waits to receive a The time in seconds that a DHCP client waits to receive a
server's DHCP Reply before retransmitting a DHCP Request. server's DHCP Reply before retransmitting a DHCP Request.
Default: 2 seconds. Default: 2 seconds.
REPLY_MSG_MIN_RETRANS REQUEST_MSG_MIN_RETRANS
The minimum number of DHCP Request transmissions that a DHCP The minimum number of DHCP Request transmissions that a DHCP
client should retransmit, before aborting the request, possibly client should retransmit, before aborting the request, possibly
retrying the Request with another Server, and logging a DHCP retrying the Request with another Server, and logging a DHCP
System Error. System Error.
Default: 10 retransmissions. Default: 10 retransmissions.
REPLY_MSG_RETRANS_INTERVAL
The time between successive retransmissions of DHCP Request
messages.
Default: 2 seconds.
RECONF_MSG_TIMEOUT RECONF_MSG_TIMEOUT
The time in seconds that a DHCP server waits to receive The time in seconds that a DHCP server waits to receive
a client's DHCP Request before retransmitting its DHCP a client's DHCP Request before retransmitting its DHCP
Reconfigure. Reconfigure.
Default: 12 seconds. Default: 12 seconds.
RECONF_MSG_MIN_RETRANS RECONF_MSG_MIN_RETRANS
The minimum number of DHCP Reconfigure messages that a DHCP The minimum number of DHCP Reconfigure messages that a DHCP
server should retransmit, before assuming the the client is server should retransmit, before assuming the the client is
unavailable and that the server can proceed with the needed unavailable and that the server can proceed with logging a DHCP
reconfiguration of that client's resources, and logging a DHCP
System Error. System Error.
Default: 10 retransmissions. Default: 10 retransmissions.
RECONF_MSG_RETRANS_INTERVAL RECONF_MSG_RETRANS_INTERVAL
The least time between successive retransmissions of DHCP The least time between successive retransmissions of DHCP
Reconfigure messages. Reconfigure messages.
Default: RECONF_MSG_TIMEOUT Default: RECONF_MSG_TIMEOUT
skipping to change at page 31, line 9 skipping to change at page 32, line 37
RECONF_MSG_MAX_RESP RECONF_MSG_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.
MIN_SOLICIT_DELAY MIN_SOLICIT_DELAY
The maximum 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 DHCP server. before sending a DHCP Solicit to a DHCP server.
Default: 1 second Default: 1 second
MAX_SOLICIT_DELAY MAX_SOLICIT_DELAY
The maximum amount of time a prospective client is required to The maximum 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
skipping to change at page 32, line 26 skipping to change at page 34, line 10
Since all times are relative to the current time of the transaction, Since all times are relative to the current time of the transaction,
there is no problem within the DHCPv6 protocol related to any there is no problem within the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the current year. hardcoded dates or two-digit representation of the current year.
11. Acknowledgements 11. Acknowledgements
Thanks to the DHC Working Group for their time and input into the Thanks to the DHC Working Group for their time and input into the
specification. Ralph Droms and Thomas Narten have had a major role specification. Ralph Droms and Thomas Narten have had a major role
in shaping the continued improvement of the protocol by their careful in shaping the continued improvement of the protocol by their careful
reviews. Many thanks to Matt Crawford and Erik Nordmark for their reviews. Many thanks to Matt Crawford, Erik Nordmark, and Mike
studied review as part of the Last Call process. Thanks also for the Carney for their studied review as part of the Last Call process.
consistent input, ideas, and review by (in alphabetical order) Mike Thanks also for the consistent input, ideas, and review by (in
Carney, Brian Carpenter, Gerald Maguire, Jack McCann, Yakov Rekhter, alphabetical order) Brian Carpenter, Gerald Maguire, Jack McCann,
Matt Thomas, Sue Thomson, and Phil Wells. Yakov 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. Related Work in IPv6 A. Changes for this revision
Should this be here?
- Allowed relays to use configured DHCP Server addresses instead of
multicasting to the All-DHCP Servers address.
- Specified that clients have to keep around enough information to
retransmit the same DHCP Request if they receive a retransmitted
DHCP Reconfigure from a server.
- Specified that servers MAY reallocate resources after a client
fails to renew them. This differs from the case when a client
does not answer a Reconfigure message.
- Eliminated the 'N' bit from the DHCP Request message.
- Added a pfx-size to the DHCP Solicit message.
- Renamed REPLY_MSG_MIN_RETRANS to be REQUEST_MSG_MIN_RETRANS
- Deleted REPLY_MSG_RETRANS_INTERVAL.
- Clarified use of RECONF_MSG_MIN_RETRANS.
- Deleted transaction-ID from client bindings.
- Clarified resource handling by server when 'C' bit is set in the
DHCP Solicit message.
- Changed specification to use symbolic error names instead of
numeric error values.
- Specified that a client should silently discard a Reconfigure
message if it is waiting for a DHCP Reply.
- Specified that a server MAY be configured so that client bindings
are identified by the client's MAC address, without need to use
the additional information supplied by the relay address.
- Changed preference field to be "optional", and specified that
invalid preference fields are implicitly equal to 0xffffffff.
- Various typos and fixups.
B. Related Work in IPv6
The related work in IPv6 that would best serve an implementor The related work in IPv6 that would best serve an implementor
to study is the IPv6 Specification [6], the IPv6 Addressing to study is the IPv6 Specification [6], the IPv6 Addressing
Architecture [8], IPv6 Stateless Address Autoconfiguration [16], IPv6 Architecture [8], IPv6 Stateless Address Autoconfiguration [16], IPv6
Neighbor Discovery Processing [11], and Dynamic Updates to DNS [18]. Neighbor Discovery Processing [11], and Dynamic Updates to DNS [19].
These specifications enable DHCP to build upon the IPv6 work to These specifications enable DHCP to build upon the IPv6 work to
provide both robust stateful autoconfiguration and autoregistration provide both robust stateful autoconfiguration and autoregistration
of DNS Host Names. of DNS 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
skipping to change at page 33, line 40 skipping to change at page 36, line 19
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 [11] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [13]. To understand which replaces and enhances functions of ARP [13]. 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 [18] is a specification that supports the Dynamic Updates to DNS [19] 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 [9].
B. 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 [7, 1] and DHCPv6.
There are three key reasons for the differences: There are three key reasons for the differences:
o IPv6 inherently supports a new model and architecture for o IPv6 inherently supports a new model and architecture for
communications and autoconfiguration of addresses. communications and autoconfiguration of addresses.
o DHCPv6 in its design was able to take advantage of the inherent o DHCPv6 in its design was able to take advantage of the inherent
benefits of IPv6. benefits of IPv6.
skipping to change at page 34, line 40 skipping to change at page 37, line 19
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 Most DHCPv4 options are unnecessary now because the configuration o Most 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 [17]. the Service Location protocol [18].
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 main header. as opposed to the main 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 34 skipping to change at page 39, line 34
[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] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March
1997. 1997.
[8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
RFC 1884, December 1995. RFC 1884, December 1995.
[9] Stephen Kent and Randall Atkinson. IP Authentication Header. [9] Stephen Kent and Randall Atkinson. IP Authentication Header.
draft-ietf-ipsec-auth-header-01.txt, July 1997. (work in draft-ietf-ipsec-auth-header-03.txt, November 1997. (work in
progress). progress).
[10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP [10] 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 [11] 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] C. Perkins. Extensions for the Dynamic Host Configuration [12] C. Perkins. Extensions for the Dynamic Host Configuration
Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-09.txt, October Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-09.txt, October
skipping to change at page 38, line 8 skipping to change at page 40, line 8
[13] David C. Plummer. An Ethernet Address Resolution Protocol: [13] 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.
[14] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [14] J. B. Postel. User Datagram Protocol. RFC 768, August 1980.
[15] J. B. Postel, Editor. Internet Protocol. RFC 791, September [15] J. B. Postel, Editor. Internet Protocol. RFC 791, September
1981. 1981.
[16] S. Thomson and T. Narten. IPv6 stateless address [16] S. Thomson and T. Narten. IPv6 Stateless Address
autoconfiguration. RFC 1971, August 1996. Autoconfiguration. RFC 1971, August 1996.
[17] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [17] S. Thomson and T. Narten. IPv6 Address Autoconfiguration.
draft-ietf-ipngwg-addrconf-v2-00.txt, November 1997. (work in
progress).
[18] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. RFC 2165, July 1997. Location Protocol. RFC 2165, July 1997.
[18] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates [19] 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
 End of changes. 

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