draft-ietf-dhc-dhcpv6-09.txt   draft-ietf-dhc-dhcpv6-10.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-08.txt Sun Microsystems Obsoletes: draft-ietf-dhc-dhcpv6-09.txt Sun Microsystems
27 February 1997 26 May 1997
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-09.txt draft-ietf-dhc-dhcpv6-10.txt
Status of This Memo Status of This Memo
This document is a submission to the DHC Working Group of the This document is a submission to the DHC Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the dhcp-v6@bucknell.edu mailing list. to the dhcp-v6@bucknell.edu mailing list.
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
skipping to change at page 1, line 53 skipping to change at page 1, line 53
Address Autoconfiguration protocol specification. Address Autoconfiguration protocol specification.
Contents Contents
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Terminology and Definitions 2 2. Terminology and Definitions 1
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
3. Protocol Design Model 4 3. Protocol Design Model 4
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
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 8
4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8
4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9 4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9
4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10 4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10
4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12
4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13 4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13
4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14
5. DHCP Client Considerations 15 5. DHCP Client Considerations 15
5.1. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16 5.1. Verifying Resource Allocations After Restarts . . . . . . 15
5.2. Receiving DHCP Advertise Messages . . . . . . . . . . . . 16 5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16
5.3. Sending DHCP Request Messages . . . . . . . . . . . . . . 17 5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 17
5.4. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 18 5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 17
5.5. Sending DHCP Release Messages . . . . . . . . . . . . . . 19 5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 18
5.6. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 19 5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 19
5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 19
6. DHCP Server Considerations 20 6. DHCP Server Considerations 20
6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 21 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 21
6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 21 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 21
6.3. DHCP Request and Reply Messages . . . . . . . . . . . . . 21 6.3. DHCP Request and Reply Message Processing . . . . . . . . 21
6.3.1. Processing for Extensions to DHCP Request and Reply
Messages . . . . . . . . . . . . . . . . . 22
6.3.2. Client Requests to Deallocate Unknown Resources . 23
6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 23 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 23
6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 24 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 24
7. DHCP Relay Considerations 24 7. DHCP Relay Considerations 24
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 24 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 24
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 25 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 25
7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 25 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 26
8. Retransmission and Configuration Variables 26 8. Retransmission and Configuration Variables 26
9. Security Considerations 28 9. Security Considerations 29
10. Acknowledgements 29 10. Acknowledgements 29
A. Related Work in IPv6 29 A. Related Work in IPv6 29
B. Change History 30 B. Comparison between DHCPv4 and DHCPv6 31
B.1. Changes from November 95 to February 96 Drafts . . . . . 30
B.2. Changes from February 96 to June 96 Drafts . . . . . . . 31
B.3. Changes from June 96 to August 96 Drafts . . . . . . . . 31
B.4. Changes from August 96 to November 96 Drafts . . . . . . 32
B.5. Changes from November 96 to February 97 Drafts . . . . . 33
C. Comparison between DHCPv4 and DHCPv6 34
Chair's Address 38 Chair's Address 36
Author's Address 38 Author's Address 36
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 [3] nodes. parameters to IPv6 [6] nodes.
DHCP is built on a client-server model, where designated DHCP DHCP is built on a client-server model, where designated DHCP servers
servers allocate network addresses and automatically deliver allocate network addresses and automatically deliver configuration
configuration parameters to dynamically configurable clients. parameters to dynamically configurable clients. Throughout the
Throughout the remainder of this document, the term "server" remainder of this document, the term "server" refers to a node
refers to a node providing initialization parameters by way of the providing initialization parameters by way of the DHCP protocol,
DHCP protocol, and the term "client" refers to a node requesting and the term "client" refers to a node requesting initialization
initialization parameters from a DHCP server. DHCP servers maintain parameters from a DHCP server.
state for their clients, in contrast to IPv6 Stateless Address
Autoconfiguration [11], where IPv6 nodes should get the same results
if they repeat the autoconfiguration procedure multiple times.
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'' [7]. IPv6'' [11].
The IPv6 Addressing Architecture [4] and IPv6 Stateless Address The IPv6 Addressing Architecture [8] and IPv6 Stateless Address
Autoconfiguration specifications provide new features not available Autoconfiguration specifications provide new features not available
in IP version 4 (IPv4) [10], which are used to simplify and in IP version 4 (IPv4) [14], which are used to simplify and
generalize the operation of DHCP clients. generalize the operation of DHCP clients.
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. Appendix A summarizes how clients, servers, and relays interact. Appendix A summarizes
related work in IPv6 that will provide helpful context; it is not related work in IPv6 that will provide helpful context; it is not
part of this specification, but included for informational purposes. part of this specification, but included for informational purposes.
Appendix B itemizes changes between different versions of this Appendix B discusses the differences between DHCPv4 and DHCPv6.
protocol specification. Appendix C discusses the differences between
DHCPv4 and DHCPv6.
2. Terminology and Definitions 2. Terminology and Definitions
Relevant terminology from the IPv6 Protocol [3], IPv6 Addressing Relevant terminology from the IPv6 Protocol [6], IPv6 Addressing
Architecture [4], and IPv6 Stateless Address Autoconfiguration [11] Architecture [8], and IPv6 Stateless Address Autoconfiguration [15]
will be provided, and then the DHCPv6 terminology. will be provided, and then the DHCPv6 terminology.
2.1. IPv6 Terminology 2.1. IPv6 Terminology
IP Internet Protocol Version 6 (IPv6). The terms IPv4 and IP Internet Protocol Version 6 (IPv6). The terms IPv4 and
IPv6 are used only in contexts where necessary to avoid IPv6 are used only in contexts where necessary to avoid
ambiguity. ambiguity.
node A device that implements IP. node A device that implements IP.
skipping to change at page 3, line 25 skipping to change at page 3, line 18
a multicast address is delivered to all interfaces a multicast address is delivered to all interfaces
identified by that address. identified by that address.
2.2. DHCPv6 Terminology 2.2. DHCPv6 Terminology
configuration parameter configuration parameter
Any parameter that can be used by a node to configure Any parameter that can be used by a node to configure
its network environment and enable communication on a its network environment and enable communication on a
link or internetwork. link or internetwork.
DHCP client A node that initiates requests on a link to obtain DHCP Client (or Client)
A node that initiates requests on a link to obtain
configuration parameters. configuration parameters.
DHCP server A server is a node that responds to requests from DHCP Server (or Server)
A server is a node that responds to requests from
clients to provide: addresses, prefix lengths, or clients to provide: addresses, prefix lengths, or
other configuration parameters. other configuration parameters.
DHCP relay A node that acts as an intermediary to deliver DHCP DHCP Relay (or Relay)
A node that acts as an intermediary to deliver DHCP
messages between clients and servers. messages between clients and servers.
DHCP Agent DHCP Agent (or Agent)
Either a DHCP server or a DHCP relay. Either a DHCP server or a DHCP relay.
agent address Agent Address
The address of a neighboring DHCP relay or DHCP server The address of a neighboring DHCP Agent on the same
on the same link as the DHCP client. link as the DHCP client.
transaction-ID transaction-ID
The transaction-ID is a monotonically increasing The transaction-ID is a monotonically increasing
integer identifier specified by the client or server, integer identifier specified by the client or server,
and used to match a response to a pending message. and used to match a response to a pending message.
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).
2.3. Specification Language 2.3. Specification Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. of the specification, in accordance with RFC 2119 [3]. These words
are often capitalized.
MUST This word, or the adjective "required", means that MUST This word, or the adjective "required", means that
the definition is an absolute requirement of the the definition is an absolute requirement of the
specification. specification.
MUST NOT This phrase means that the definition is an absolute MUST NOT This phrase means that the definition is an absolute
prohibition of the specification. prohibition of the specification.
SHOULD This word, or the adjective "recommended", means SHOULD This word, or the adjective "recommended", means
that there may exist valid reasons in particular that there may exist valid reasons in particular
skipping to change at page 5, line 29 skipping to change at page 5, line 29
- A DHCP client MUST be prepared to receive multiple (possibly - A DHCP client MUST be prepared to receive multiple (possibly
different) responses to solicitations for DHCP servers. Some different) responses to solicitations for DHCP servers. Some
installations may include multiple, overlapping DHCP servers to installations may include multiple, overlapping DHCP servers to
enhance reliability and/or to increase performance. enhance reliability and/or to increase performance.
- DHCP MUST coexist with statically configured, non-participating - DHCP MUST coexist with statically configured, non-participating
nodes and with existing network protocol implementations. nodes and with existing network protocol implementations.
- DHCPv6 MUST be compatible with IPv6 Stateless Address - DHCPv6 MUST be compatible with IPv6 Stateless Address
Autoconfiguration [11]. Autoconfiguration [15].
- DHCP MUST support the requirements of automated renumbering of IP - DHCP MUST support the requirements of automated renumbering of IP
addresses [1]. addresses [4].
- DHCP servers should be able to support Dynamic Updates to - DHCP servers should be able to support Dynamic Updates to
DNS [12]. DNS [16].
- DHCP servers MUST be able to handle multiple IPv6 addresses for - DHCP servers MUST be able to handle multiple IPv6 addresses for
each client. each client.
- 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
skipping to change at page 6, line 29 skipping to change at page 6, line 29
in response to a client DHCP Solicit message. in response to a client DHCP Solicit message.
03 DHCP Request 03 DHCP Request
The DHCP Request is an IP unicast message from a client to a The DHCP Request is an IP unicast message from a client to a
server to request configuration parameters on a network. server to request configuration parameters on a network.
04 DHCP Reply 04 DHCP Reply
The DHCP Reply is an IP unicast message sent by a server to The DHCP Reply is an IP unicast message sent by a server to
respond to a client's DHCP Request. Extensions [7] to the DHCP respond to a client's DHCP Request. Extensions [11] to the
Reply describe the resources that the DHCP Server has committed DHCP Reply describe the resources that the DHCP Server has
and allocated to the client, and may contain other information committed and allocated to the client, and may contain other
for use by the client. information for use by the client.
05 DHCP Release 05 DHCP Release
The DHCP Release message is used by a DHCP client to inform The DHCP Release message is used by a DHCP client to inform
the server that the client is releasing a particular address, the server that the client is releasing a particular address,
or set of addresses or resources, so that the server may or set of addresses or resources, so that the server may
subsequently mark the addresses as invalid, or release subsequently mark the addresses as invalid, or release
resources in the server's binding for the client. resources in the server's binding for the client.
06 DHCP Reconfigure 06 DHCP Reconfigure
skipping to change at page 7, line 21 skipping to change at page 7, line 21
Transactions are usually started by a client with a DHCP Request, Transactions are usually started by a client with a DHCP Request,
which may be issued after the client knows the server's address. which may be issued after the client knows the server's address.
The response (DHCP Reply) is from the server (possibly via a DHCP The response (DHCP Reply) is from the server (possibly via a DHCP
Relay). At this point in the flow all data has been transmitted Relay). At this point in the flow all data has been transmitted
and, hopefully, received. To provide a method of recovery if either and, hopefully, received. To provide a method of recovery if either
the client or server do not receive the messages to complete the the client or server do not receive the messages to complete the
transaction, the client is required to retransmit any DHCP Request transaction, the client is required to retransmit any DHCP Request
message until it elicits the corresponding DHCP Reply or Replies, message until it elicits the corresponding DHCP Reply or Replies,
or until it can be reasonably certain that the desired DHCP Server or until it can be reasonably certain that the desired DHCP Server
is unavailable. The timeout and retransmission guidelines and is unavailable. The timeout and retransmission guidelines and
configuration variables are discussed in Section 8. configuration variables are discussed in Section 8. DHCP uses the
UDP [13] protocol to communicate between clients and servers. UDP is
not reliable, but DHCP the retransmission scheme in the referenced
section provides reliability between clients and servers.
All DHCP Agents (Servers and Relays) MUST join the link-local The following well-known multicast addresses are used by DHCP Agents:
All-DHCP-Agent multicast group at the well-known multicast address
FF02:0:0:0:0:0:1:2. All DHCP Servers MUST, in addition, join
the site-local All-DHCP-Servers multicast group at the well-known
multicast address FF05:0:0:0:0:0:1:3. All DHCP Relays MUST, on the
other hand, join in addition the site-local All-DHCP-Relays multicast
group at the well-known multicast address FF05:0:0:0:0:0:1:4.
DHCP uses the UDP [9] protocol to communicate between clients FF02:0:0:0:0:0:1:2
and servers. UDP is not reliable, but DHCP has to provide some All DHCP Agents (Servers and Relays) MUST join the
reliability between clients and servers. If a response is not link-local All-DHCP-Agents multicast group at the address
received after transmission of a DHCP message, the message MUST be FF02:0:0:0:0:0:1:2.
retransmitted according to the rules specified in Section 8. The
All-DHCP-Relays address will be used eventually when DHCP Servers FF05:0:0:0:0:0:1:3
wish to automatically configure all site DHCP Relays. All DHCP Servers MUST, in addition, join the site-local
All-DHCP-Servers multicast group at the address
FF05:0:0:0:0:0:1:3.
FF05:0:0:0:0:0:1:4
All DHCP Relays MUST, on the other hand, join in addition
the site-local All-DHCP-Relays multicast group at the
address FF05:0:0:0:0:0:1:4.
A client MUST transmit all messages over UDP using port 547 as the A client MUST transmit all messages over UDP using port 547 as the
destination port. A client MUST receive all messages from UDP port destination port. A client MUST receive all messages from UDP port
546. 546.
A DHCP Agent MUST transmit all messages to clients over UDP using A DHCP Agent MUST transmit all messages to clients over UDP using
port 546 as the destination port. A DHCP Agent MUST receive all port 546 as the destination port. A DHCP Agent MUST receive all
messages over UDP using port 547. The source port for DHCP messages messages over UDP using port 547. The source port for DHCP messages
is arbitrary. is arbitrary.
skipping to change at page 8, line 46 skipping to change at page 8, line 46
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 present, the IP address of the interface on which If present, 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
If a DHCP client does not know any DHCP Agent address, or wants To discover a DHCP Agent address a DHCP client SHOULD send a DHCP
to locate a new server to receive configuration parameters, the Solicit message to the All-DHCP-Agents multicast address (see
client SHOULD use, as the destination IP address, the well-known All section 3.3). Any DHCP Relay receiving the solicitation MUST forward
DHCP Agents multicast address FF02:0:0:0:0:0:1:2. Any DHCP Relay it to the All-DHCP-Servers multicast address, to instruct DHCP
receiving the solicitation MUST forward it to the All-DHCP-Servers Servers to send their advertisements to the prospective client. In
multicast address, to instruct DHCP Servers to send their that case, the relay MUST insert the address of its interface from
advertisements to the prospective client. In that case, the relay which the client's solicitation was received into the agent's address
MUST copy the client's link-local address into the message, copy the field, and set the 'A' bit.
address of its interface from which the client's solicitation was
received into the agent's address field, and set the 'A' bit. DHCP clients MUST NOT issue any DHCP solicitation which is long
enough so that inserting the Relay Address field would cause the
message to exceed the MTU advertised on the link.
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
skipping to change at page 9, line 47 skipping to change at page 10, line 4
reserved 0 reserved 0
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.
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
server address server address
The IP address of the DHCP server The IP address of the DHCP server
extensions See [7].
extensions See [11].
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-Agent multicast address. Then the agent address will be the All-DHCP-Agents multicast address. Then the agent address will be
IP address of one of the server's interfaces, the 'S' bit will be the IP address of one of the server's interfaces, the 'S' bit will be
set, the agent address will be an address of the server, and there set, the agent address will be an address of the server, and there
will be no server address sent in the DHCP Advertise message. It is will be no server address sent in the DHCP Advertise message.
an error for server-count to be zero if the 'S' bit is not set.
The DHCP Server MUST copy the 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. The advertisement which is sent in response to a DHCP Solicit. Both
source IP address of the IP header of any DHCP Advertise message MUST Agent address and server address (if present) of the DHCP Advertise
have sufficient scope to be reachable by the DHCP Client. Moreover, message MUST have sufficient scope to be reachable by the DHCP
the source address of any DHCP Advertise message sent by a DHCP relay Client. Moreover, the Agent address of any DHCP Advertise message
MUST NOT be a link-local address. In situations where there are no sent by a DHCP relay MUST NOT be a link-local address. In situations
routers sending Router Advertisements, then a DHCP Server MUST be where there are no routers sending Router Advertisements, then a DHCP
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 sitations where the
client has no way to route messages to a server not on the same link
4.3. DHCP Request Message Format 4.3. DHCP Request Message Format
In order to request parameters from a DHCP server, a client sends a In order to request parameters from a DHCP server, a client sends a
DHCP Request message, and MAY append the appropriate extensions [7]. DHCP Request message, and MAY append extensions [11]. If the client
If the client does not know any DHCP server address, it MUST first does not know any DHCP server address, it MUST first obtain a server
obtain a server address by multicasting a DHCP Solicit message (see address by multicasting a DHCP Solicit message (see Section 4.1). If
Section 4.1). If the client does not have a valid IP address of the client does not have a valid IP address of sufficient scope for
sufficient scope for the DHCP server to communicate with the client, the DHCP server to communicate with the client, client MUST send the
the client MUST use the unicast IP address of a local DHCP relay message to the local DHCP Relay and insert the DHCP Relay address as
(which then becomes the agent address in the message header) as the the agent address in the message header. In this case, the client
Destination IP address. In this case, the client cannot send the cannot send the message directly to the DHCP server because the
message directly to the DHCP server because the server could not server could not return any response to the client. Otherwise, the
return any response to the client. Otherwise, the client MAY omit client MAY omit the server address in the DHCP Request message; in
the server address in the DHCP Request message; in this case, the this case, the client MUST send the DHCP Request message directly to
client MUST send the DHCP Request message directly to the server, the server, using the server address as the IP destination address in
using the server address as the IP destination address in the IP 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 |S|C| reserved | transaction-ID | | msg-type |S|C| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server address | | server address |
| (16 octets, if present) | | (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address | | agent address |
skipping to change at page 11, line 44 skipping to change at page 11, line 44
transaction-ID transaction-ID
A monotonically increasing number used to identify this A monotonically increasing number used to identify this
Request, and copied into the Reply. Request, and copied into the Reply.
server address server address
If present, the IP address of the DHCP server which If present, the IP address of the DHCP server which
should receive the client's DHCP Request message. should receive the client's DHCP Request message.
agent address agent address
The IP address of a relay or server interface, copied The IP address of an agent interface, copied from a
from a DHCP Advertisement message. DHCP Advertisement message.
client's link-local address client's link-local address
The IP link-local address of the client interface from The IP link-local address of the client interface from
which the client issued the DHCP Request message which the client issued the DHCP Request message
extensions See [7]. extensions See [11].
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
skipping to change at page 13, line 6 skipping to change at page 13, line 6
transaction-ID transaction-ID
A monotonically increasing number used to identify this A monotonically increasing number used to identify this
Reply, and copied from the client's Request. Reply, and copied from the client's Request.
client's link-local address client's link-local address
If present, the IP address of the client interface If present, the IP address of the client interface
which issued the corresponding DHCP Request message. which issued the corresponding DHCP Request message.
extensions extensions
See [7]. See [11].
If the 'L' bit is set, and thus the link-local address is present in If the 'L' bit is set, and thus the link-local address is present in
the Reply message, the Reply is sent by the server to the relay's the Reply message, the Reply is sent by the server to the relay's
address which was specified as the agent address in the DHCP Request address which was specified as the agent address in the DHCP Request
message, and the relay uses the link-local address to deliver message, and the relay uses the link-local address to deliver the
the Reply message to the client. If the length in the UDP header Reply message to the client.
preceding the DHCP message does not match that which is expected in
the DHCP Request, error code 23 MUST be sent.
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 relay. When a client sends a Release message, it is assumed to
have a valid IP address with sufficient scope to allow access to have a valid IP address with sufficient scope to allow access to
the target server. Only the parameters which are specified in the the target server. Only the parameters which are specified in the
extensions are released. The DHCP server acknowledges the Release extensions are released. The DHCP server acknowledges the Release
message by sending a DHCP Reply (Section 4.4, 6.3). message by sending a DHCP Reply (Sections 4.4, 6.3).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |D| reserved | transaction-ID | | msg-type |D| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address | | agent address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
skipping to change at page 14, line 22 skipping to change at page 14, line 19
client's link-local address client's link-local address
The IP link-local address of the client interface from The IP link-local address of the client interface from
which the the client issued the DHCP Request message which the the client issued the DHCP Request message
client address client address
The IP address of the client interface from which the The IP address of the client interface from which the
the client issued the DHCP Request message. The client the client issued the DHCP Request message. The client
address field is present whenever the 'D' bit is set, address field is present whenever the 'D' bit is set,
even if it is equal to the link-local address. even if it is equal to the link-local address.
extensions See [7] extensions See [11]
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. In that case, and only then, the client to the DHCP Release message. In that case, and only then, the client
SHOULD then specify the 'D' flag. When the 'D' flag is set, the SHOULD then specify the 'D' flag. When the 'D' flag is set, the
server MUST send the DHCP Reply back to the client's address as shown server MUST send the DHCP Reply back to the client's address as shown
in the client address field of the Release message. Otherwise, when in the client address field of the Release message. Otherwise, when
the 'D' bit is not set, the server MUST use the agent address and the 'D' bit is not set, the server MUST send its DHCP Reply message
link-local address in its DHCP Reply message to forward the Reply to the agent address in the Release message, so that the relay agent
message back to the releasing client. can subsequently forward the Reply back to the releasing client at
the client's link-local address indicated in the Reply message.
Note that it is an error (Error Code 21) to include within the DHCP
Release message both the 'D' bit and an IP address extension which
has the IP address used as the client IP address field of the DHCP
Release message header.
4.6. DHCP Reconfigure Message Format 4.6. DHCP Reconfigure Message Format
The DHCP Reconfigure message is sent without the assistance of any The DHCP Reconfigure message is sent without the assistance of any
DHCP relay. When a server sends a Reconfigure message, the client DHCP relay. When a server sends a Reconfigure message, the client
to which it is sent is assumed to have a valid IP address with to which it is sent is assumed to have a valid IP address with
sufficient scope to be accessible by the server. Only the parameters sufficient scope to be accessible by the server. Only the parameters
which are specified in the extensions to the Reconfigure message need which are specified in the extensions to the Reconfigure message need
be requested again by the client. be requested again by the client.
skipping to change at page 15, line 31 skipping to change at page 15, line 31
transaction-ID transaction-ID
A monotonically increasing number used to identify A monotonically increasing number used to identify
this Reconfigure message, and copied into the this Reconfigure message, and copied into the
client's Request. client's Request.
server address server address
The IP address of the DHCP server issuing the DHCP The IP address of the DHCP server issuing the DHCP
Reconfigure message. Reconfigure message.
extensions See [7] extensions See [11]
5. DHCP Client Considerations 5. DHCP Client Considerations
A DHCP client MUST silently discard any DHCP Solicit, DHCP Request, A DHCP client MUST silently discard any DHCP Solicit, DHCP Request,
or DHCP Release message it receives. or DHCP Release message it receives.
5.1. Verifying Resource Allocations After Restarts
A DHCP client MAY retain its configured parameters and resources A DHCP client MAY retain its configured parameters and resources
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, the If the server does not respond to the DHCP Request message, the
client may still use any addresses which have not yet expired. In client may still use any resources whose lifetimes have not yet
this case, however, the client MUST begin to search for another expired. In such cases, however, the client MUST begin to search
server by multicasting a new DHCP Solicit message, again with the 'C' for another server by multicasting a new DHCP Solicit message, again
bit set, containing its IP address in the appropriate extension. with the 'C' bit set, containing its IP address in the appropriate
extension.
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, so that its IP address is no longer valid. When the client network, so that its IP address is no longer valid. When the client
multicasts a new DHCP Discover message, servers will respond with multicasts a new DHCP Discover message, servers will respond with
the information needed for the client to release its old address, if the information needed for the client to release its old address, if
need be, and request an address reachable on the new network. In need be, and request an address reachable on the new network. In
this situation, when the client receives a new IP address and the old this situation, when the client receives a new IP address and the old
IP address is no longer reachable, the client MUST release its old IP address is no longer reachable, the client MUST release its old
IP address by issuing a DHCP Release message with the appropriate IP address by issuing a DHCP Release message with the appropriate
extension. extension.
5.1. Sending DHCP Solicit Messages 5.2. Sending DHCP Solicit Messages
If a node wishes to become a new DHCP client, it MUST first A DHCP client MUST have the address of a DHCP Server to send a
locate a DHCP Server. The client does this by multicasting a DHCP Request message. The client may locate a DHCP Server by multicasting
Solicit message to the All-DHCP-Agents address multicast address a DHCP Solicit message to the All-DHCP-Agents link-local multicast
FF02:0:0:0:0:0:1:2, setting the Hop Limit == 1. If there are address, setting the Hop Limit == 1 (see Section 3.3). If there
no DHCP servers on the same link as the node, then a DHCP Relay are no DHCP servers on the same link as the node, then a DHCP Relay
MUST be present for further handling of the solicitation. The MUST be present for further handling of the solicitation. The
prospective client SHOULD wait for ADV_WAIT seconds to get all the prospective client SHOULD wait for ADV_WAIT seconds to get all the
DHCP Advertisement messages which may be sent in response to the DHCP Advertisement messages which may be sent in response to the
solicitation. solicitation.
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 stale client records that match solicitation should clean up their stale client records that match
its link-local address. its link-local address.
If a client sends a DHCP Solicit message after it reboots, the If a client sends a DHCP Solicit message after it reboots, the
solicitation SHOULD be delayed after reception of the first Router solicitation SHOULD be delayed after reception of the first Router
Advertisement [6] message, by at least some random amount of time Advertisement [10] message, by at least some random amount of time
between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds. This delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds. This delay
is intended to help stagger requests to DHCP Servers (and avoid is intended to help stagger requests to DHCP Servers (and avoid
link-layer collisions) after a power outage causes many nodes to link-layer collisions) after a power outage causes many nodes to
reboot all at once. Each subsequent DHCP Solicit message that is reboot all at once. Each subsequent DHCP Solicit message that is
issued before receiving an advertisement MUST be delayed by twice the issued before receiving an advertisement MUST be delayed by twice the
amount by which the previous DHCP Solicit message was delayed. amount by which the previous DHCP Solicit message was delayed, plus
a small random delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY
seconds.
5.2. Receiving DHCP Advertise Messages 5.3. Receiving DHCP Advertise Messages
When a DHCP client receives a DHCP Advertise message, it may After a DHCP Client has received a DHCP Advertise message, it has
formulate a DHCP Request message to receive configuration information the address of a DHCP Server for subsequent DHCP Request messages.
and resources from the DHCP servers listed in the advertisement.
If the Advertise message has no server address field and does If the Advertise message has no server address field and does
not have the 'S' bit set, the client MUST silently discard the not have the 'S' bit set, the client MUST silently discard the
message. If the server's address is shown as a Multicast address, message. If the server's address is shown as a Multicast address,
the advertisement MUST be silently discarded. the advertisement MUST be silently discarded.
If the 'S' bit is set, the DHCP Advertise message was transmitted If the 'S' bit is set, the DHCP Advertise message was transmitted
by a DHCP server on the same link as the client. In this case, the by a DHCP server on the same link as the client. In this case, any
client MUST use the agent address as the destination address for any future DHCP message transactions sent to that server MUST be sent by
future DHCP message transactions sent to that server. the client to the agent address indicated by the 'S' bit.
Advertisements may have extensions; this might allow the DHCP client Advertisements may have extensions; this might allow the DHCP client
to select the configuration that best meets its needs from among to select the configuration that best meets its needs from among
several prospective servers. several prospective servers.
5.3. 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 client MUST have address before sending the Request message, and client MUST have
acquired a (possibly identical) DHCP agent address. If the client 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 the client
MUST be the same as the DHCP server's address. A DHCP Request MUST be the same as the DHCP server's address. A DHCP Request
message MUST NOT be sent to any multicast address, since otherwise message MUST NOT be sent to any multicast address, since otherwise
multiple DHCP agents would possibly allocate resources to the client multiple DHCP agents 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
skipping to change at page 18, line 24 skipping to change at page 18, line 26
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 address),
- The time at which the next retransmission will be attempted, and - The time at which the next retransmission will be attempted, and
- All extensions appended to the request message. - All extensions appended to the request message.
If a client does not receive a DHCP Reply message (Section 5.4) 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_INITIAL_TIMEOUT seconds, or if the received DHCP Reply REPLY_MSG_INITIAL_TIMEOUT seconds, or if the received DHCP Reply
message contains a DHCP Authentication extension which fails to message contains a DHCP Authentication extension which fails to
provide the correct authentication information, the client MUST 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. retransmit according to the rules in Section 8.
If the client transmits a DHCP Request in response to a DHCP If the client transmits a DHCP Request in response to a DHCP
Reconfigure message (see Section5.6), the client can continue to Reconfigure message (see Section5.7), the client can continue to
operate with its existing configuration information and resources operate with its existing configuration information and resources
until it receives the corresponding DHCP Reply from the server. The until it receives the corresponding DHCP Reply from the server. The
same retransmission rules apply as for any other DHCP Request message same retransmission rules apply as for any other DHCP Request message
from the client. from the client.
5.4. Receiving DHCP Reply Messages 5.5. Receiving DHCP Reply Messages
When a client receives a DHCP Reply message, it MUST check whether When a client receives a DHCP Reply message, it MUST check whether
the transaction-ID in the Reply message matches the transaction-ID the transaction-ID in the Reply message matches the transaction-ID
of a pending DHCP Request message. If no match is found, the Reply of a pending DHCP Request message. If no match is found, the Reply
message MUST be silently discarded. message MUST be silently discarded.
If the Reply message is acceptable, the client processes each If the Reply message is acceptable, the client processes each
Extension [7], extracting the relevant configuration information Extension [11], extracting the relevant configuration information
and parameters for its network operation. The client can determine and parameters for its network operation. The client can determine
when all extensions in the Reply have been processed by using the when all extensions in the Reply have been processed by using the
Length field of the Reply. Some extensions in the Reply may have Length field of the Reply. Some extensions in the Reply may have
error codes, when the server was unable to honor the request, which error codes, when the server was unable to honor the request, which
will indicate to the client the reason for failure. If the server is will indicate to the client the reason for failure. If the server is
simply unable to honor the request in an extension included by the unable to honor the request in an extension included by the client,
client, that extension may simply be omitted from the Reply. that extension may simply be omitted from the Reply.
Some configuration information extracted from the extensions to the Some configuration information extracted from the extensions to the
DHCP Reply message MUST remain associated with the DHCP server that DHCP Reply message MUST remain associated with the DHCP server that
sent the message. The particular extensions that require this extra sent the message. The particular extensions that require this extra
measure of association with the server are indicated in the DHCP measure of association with the server are indicated in the DHCP
Extensions document [7]. These "resource-server" associations are Extensions document [11]. These "resource-server" associations are
used when sending DHCP Release messages. used when sending DHCP Release messages.
5.5. Sending DHCP Release Messages 5.6. Sending DHCP Release Messages
If a DHCP client determines that some of its network configuration If a DHCP client determines that some of its network configuration
parameters are no longer needed, it SHOULD enable the DHCP server to parameters are no longer needed, it SHOULD enable the DHCP server to
release allocated resources which are no longer in use by sending a release allocated resources which are no longer in use by sending a
DHCP Release message to the server. The client consults its list DHCP Release message to the server. The client consults its list
of resource-server associations in order to determine which server of resource-server associations in order to determine which server
should receive the desired Release message. If a client wishes to should receive the desired Release message. If a client wishes to
ask the server to release all information and resources relevant to ask the server to release all information and resources relevant to
the client, the client specifies no extensions; this is preferable the client, the client specifies no extensions; this is preferable
to sending a DHCP Request message with the 'C' bit set and no to sending a DHCP Request message with the 'C' bit set and no
extensions. extensions.
Suppose a client wishes to release resources which were granted to Suppose a client wishes to release resources which were granted to
it on another link. In that case, the client MUST instruct the it on another link. In that case, the client MUST instruct the
server to send the DHCP Reply directly back to the client, instead server to send the DHCP Reply directly back to the client, instead
of performing the default processing of sending the DHCP Reply back of performing the default processing of sending the DHCP Reply back
through the agent-address included in the DHCP Release. This is done through the agent-address included in the DHCP Release. This is done
by setting the 'D' bit in the DHCP Release message. Note that it is by setting the 'D' bit in the DHCP Release message (see section 4.5).
an error (Error Code 21) to include within the DHCP Release message
both the 'D' bit and an IP address extension which has the IP address
used as the client IP address field of the DHCP Release message
header.
5.6. Receiving DHCP Reconfigure Messages 5.7. Receiving DHCP Reconfigure Messages
Each DHCP client MUST listen at UDP port 546 to receive possible Each DHCP client MUST listen at UDP port 546 to receive possible
DHCP Reconfigure messages, except in cases where the client knows DHCP Reconfigure messages, except in cases where the client knows
that no Reconfigure message will ever be issued. In some cases, that no Reconfigure message will ever be issued. In some cases,
the IP address at which the client listens will be a multicast the IP address at which the client listens will be a multicast
address sent to the client by the DHCP server in an extension to address sent to the client by the DHCP server in an extension to
an earlier DHCP Reply message. If the client does not listen for an earlier DHCP Reply message. If the client does not listen for
DHCP Reconfigure messages, it is possible that the client will DHCP Reconfigure messages, it is possible that the client will
not receive notification that its DHCP server has deallocated the not receive notification that its DHCP server has deallocated the
client's IP address and/or other resources allocated to the client. client's IP address and/or other resources allocated to the client.
skipping to change at page 20, line 20 skipping to change at page 20, line 18
for the client to initiate a new DHCP Request/Reply transaction with for the client to initiate a new DHCP Request/Reply transaction with
the server which sent the Reconfigure message. The server sending the server which sent the Reconfigure message. The server sending
the Reconfigure message MAY be different than the server which sent a the Reconfigure message MAY be different than the server which sent a
DHCP Reply message containing the original configuration information. DHCP Reply message containing the original configuration information.
For each Extension which is present in the Reconfigure message, the For each Extension which is present in the Reconfigure message, the
client appends a matching Extension to its Request message, which client appends 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. From then on, the Reconfigure message into the Request message. From then on,
processing is the same as specified above in Section 5.3. processing is the same as specified above in 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 Note that a server may ask its client to join a multicast group
for the purpose of receiving DHCP Reconfigure messages. When a for the purpose of receiving DHCP Reconfigure messages. When a
Reconfigure message is delivered to the client by way of the selected Reconfigure message is delivered to the client by way of the selected
multicast address, the client MUST delay its further response for multicast address, the client MUST delay its further response for
a random amount of time uniformly distributed within the interval a random amount of time uniformly distributed within the interval
between RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds. This between RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds. This
skipping to change at page 20, line 42 skipping to change at page 20, line 40
DHCP Request messages all at the same time. DHCP Request messages all at the same time.
6. DHCP Server Considerations 6. DHCP Server Considerations
A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP
Reconfigure message it receives. 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>, since the link-local pair <link-local address, agent address>, since the link-local
address is guaranteed to be unique [11] on the link identified address is guaranteed to be unique [15] on the link identified
by the agent address. An implementation MUST support bindings by the agent address. An implementation MUST support bindings
consisting of at least a client's link-local address, agent address, consisting of at least a client's link-local address, agent address,
preferred lifetime and valid lifetime [11] for each client address, preferred lifetime and valid lifetime [15] for each client address,
and the transaction-ID. A client binding may be used to store any and the transaction-ID. 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.
Servers on the same link as the client MUST use the source address
in the IP header from the client as the destination address in DHCP
response messages sent by the server to the client.
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
source address is not a link-local address. In that case, if the agent address is present, and not a link-local address. Otherwise,
source address is a link-local address, the server MUST silently if the agent address is not present, or if it is a link-local
discard the packet. If the UDP length disagrees with the length address, the server MUST silently discard the packet. If the UDP
determined by the format of the DHCP Solicit message, the server length disagrees with the length determined by the format of the
MUST drop the packet and SHOULD log the error. Note that if the DHCP Solicit message, the server MUST drop the packet and SHOULD log
client sends a DHCP Solicit message from a link-local address, the the error. Note that if the client sends a DHCP Solicit message
multicast destination will be the All-DHCP-Agents address, not the from a link-local address, the multicast destination will be the
All-DHCP-Servers address. All-DHCP-Agents address, not the All-DHCP-Servers address.
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. The it on the same link as the solicitation was received from. If the
destination address of the advertisement MUST be the source address 'A' bit is set, the advertisement MUST be sent to the relay address;
of the solicitation. The DHCP server MUST use an IP address of the otherwise, the server MUST send the advertisement to the client's
interface on which it received the Solicit message as the source link-local address. An IP address of the interface on which the
address field of the IP header of the message. server receives the Solicit message MUST appear in the server address
field of the corresponding advertisement.
The DHCP server MAY append extensions to the Advertisement, in order The DHCP server MAY append extensions to the Advertisement, in order
to offer the soliciting node the best possible information about to offer the soliciting node the best possible information about
the services and resources which the server may be able to make the services and resources which the server may be able to make
available. available.
6.3. DHCP Request and Reply Messages 6.3. DHCP Request and Reply Message Processing
The DHCP server MUST check to ensure that the client's link-local The DHCP server MUST check to ensure that the client's link-local
address field of the Request message contains an address which could address field of the Request message contains a link-local address.
be a valid link-local address. If not, the message MUST be silently If not, the message MUST be silently discarded. Otherwise, it checks
discarded. Otherwise, it checks for the presence of the 'S' bit. If for the presence of the 'S' bit. If the 'S' bit is set, the server
the 'S' bit is set, the server MUST check that the server address MUST check that the server address matches the destination IP address
matches the destination IP address at which the Request message was at which the Request message was received by the server. If the
received by the server. If the server address does not match, the server address does not match, the Request message MUST be silently
Request message MUST be silently discarded. 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 MAY correspond to any binding known to the server, then the server
create a new binding for the previously unknown client; otherwise, it MAY create a new binding for the previously unknown client, and
SHOULD return a DHCP Reply with an error code of 20. send a DHCP Reply with any resources allocated to the new binding.
Otherwise, it SHOULD return a DHCP Reply with an error code of 19.
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.
Otherwise, if the transaction-ID has not been recently used, the Otherwise, if the server has no record of a message from the client
server identifies and allocates all the relevant information, with the same transaction-ID, the server identifies and allocates
resources, and configuration data that is associated with the client. all the relevant information, resources, and configuration data that
Then it sends that information to its DHCP client by constructing a is associated with the client. Then it sends that information to
DHCP Reply message and including the client's information in DHCP its DHCP client by constructing a DHCP Reply message and including
Extensions to the Reply message. The DHCP Reply message uses the the client's information in DHCP Extensions to the Reply message.
same transaction-ID as found in the received DHCP Request message. The DHCP Reply message uses the same transaction-ID as found in the
Note that the reply message MAY contain information not specifically received DHCP Request message. Note that the reply message MAY
requested by the client. contain information not specifically requested by the client.
If the DHCP Request message has the 'S' bit set in the message If the DHCP Request message has the 'S' bit set in the message
header, then the Request was sent to the server by a DHCP Relay. In header, then the Request was sent to the server by a DHCP Relay. In
this case, the DHCP server MUST send the corresponding DHCP Reply this case, the DHCP server MUST send the corresponding DHCP Reply
message to the agent address found in the Request (see section 7.2). message to the agent address found in the Request (see section 7.2).
6.3.1. Processing for Extensions to DHCP Request and Reply Messages
The DHCP Request may contain extensions, which are interpreted The DHCP Request may contain extensions, which are interpreted
(by default) as advisory information from the client about its (by default) as advisory information from the client about its
configuration preferences. For instance, if the IP Address Extension configuration preferences. For instance, if the IP Address Extension
is present, the DHCP server SHOULD attempt to allocate or extend the is present, the DHCP server SHOULD attempt to allocate or extend the
lifetime of the address indicated by the extension. Some extensions lifetime of the address indicated by the extension. Some extensions
may be marked by the client as required. may be marked by the client as required.
The DHCP server may accept some extensions for successful processing The DHCP server may accept some extensions for successful processing
and allocation, while still rejecting others, or the server may and allocation, while still rejecting others, or the server may
reject various extensions for different reasons. The server sets reject various extensions for different reasons. The server sets
skipping to change at page 23, line 8 skipping to change at page 23, line 10
Request. Request.
Whenever it is able to, the server includes an extension in the Whenever it is able to, the server includes an extension in the
Reply message for every extension sent by the client in the Request Reply message for every extension sent by the client in the Request
message. If the client requests some extensions that cannot be message. If the client requests some extensions that cannot be
supplied by the server, the server can simply fail to provide them, supplied by the server, the server can simply fail to provide them,
not including them in the Reply. Other extensions can be rejected by not including them in the Reply. Other extensions can be rejected by
including them in the Reply with an appropriate error code indicating including them in the Reply with an appropriate error code indicating
failure. failure.
When a client DHCP Request is received that has the 'C' bit set, 6.3.2. Client Requests to Deallocate Unknown Resources
the server should check to find out whether the extensions listed
in the Request message match those which it has associated with the When a client DHCP Request is received that has the 'C' bit set, the
client's binding. Any resources which are not indicated by the server should check to find out whether the extensions listed in the
client are presumed to be unknown by the client, and thus possible Request message match those which it has associated with the client's
candidates for reallocation to satisfy requests from other clients. binding. Any resources which are not indicated by the client are
The DHCP Server MUST deallocate all resources associated with the presumed to be unknown by the client, and thus possible candidates
client upon reception of a DHCP Request with the 'C' bit set, except for reallocation to satisfy requests from other clients. The DHCP
for those which the server is willing to reallocate response to the Server MUST deallocate all resources associated with the client
upon reception of a DHCP Request with the 'C' bit set, except for
those which the server is willing to reallocate in response to the
client's request. It may be more efficient to avoid deallocating any client's request. It may be more efficient to avoid deallocating any
resources until after the list of extensions to the request have been resources until after the list of extensions to the request have been
inspected. inspected.
6.4. Receiving DHCP Release Messages 6.4. Receiving DHCP Release Messages
If the server receives a DHCP Release Message, it MUST verify that If the server receives a DHCP Release Message, it MUST verify that
the link-local address field of the message contains an address the link-local address field of the message contains an address
which could be a valid link-local address (i.e., one with the prefix which could be a valid link-local address (i.e., one with the prefix
FE80::0000/64). If not, the message MUST be silently discarded. FE80::0000/64). If not, the message MUST be silently discarded.
skipping to change at page 24, line 15 skipping to change at page 24, line 22
by the server, a matching Extension is appended to the DHCP Reply by the server, a matching Extension is appended to the DHCP Reply
message. For extensions in the DHCP Release message which cannot be message. For extensions in the DHCP Release message which cannot be
successfully processed by the server, a DHCP Reply message containing successfully processed by the server, a DHCP Reply message containing
extensions with the appropriate error codes MUST be returned by the extensions with the appropriate error codes MUST be returned by the
server. server.
6.5. Sending DHCP Reconfigure Messages 6.5. Sending DHCP Reconfigure Messages
If a DHCP server needs to change the configuration associated to any If a DHCP server needs to change the configuration associated to any
of its clients, it constructs a DHCP Reconfigure message and sends it of its clients, it constructs a DHCP Reconfigure message and sends it
to each such client [7]. The Reconfigure MAY be sent to a multicast to each such client [11]. The Reconfigure MAY be sent to a multicast
address chosen by the server and sent to each of its clients in an address chosen by the server and sent to each of its clients in an
extension to a previous DHCP Reply message. extension to a previous DHCP Reply message.
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 facilitate DHCP client/server to maintain any state in order to facilitate DHCP client/server
interactions. interactions.
All relays MUST use the IP address of the interface from which the All relays MUST send DHCP Request messages out from an IP address of
DHCP request was received as the source address for the IP header of the interface from which the DHCP request was received.
that DHCP message.
The main purpose of the DHCP Relay is to enable clients and servers The main purpose of the DHCP Relay is to enable clients and servers
to carry out DHCP protocol transactions. DHCP Solicit messages are to carry out DHCP protocol transactions. DHCP Solicit messages are
issued by the relay when initiated by prospective DHCP clients. issued by the relay when initiated by prospective DHCP clients.
By default, the relay discovers local DHCP Servers by use of By default, the relay discovers local DHCP Servers by use of
multicasting DHCP solicitations to the All-DHCP-Servers multicast multicasting DHCP solicitations to the All-DHCP-Servers multicast
address, but relays SHOULD allow this behavior to be configurable. address, but relays SHOULD allow this behavior to be configurable.
The relay SHOULD NOT send such a multicast solicitation on the The relay SHOULD NOT send such a multicast solicitation on the
interface from which it received the solicitation from the client. interface from which it received the solicitation from the client.
skipping to change at page 25, line 4 skipping to change at page 25, line 9
7.1. DHCP Solicit and DHCP Advertise Message Processing 7.1. DHCP Solicit and DHCP Advertise Message Processing
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,
- setting the 'A' bit, - setting the 'A' bit,
- copying the address of its interface from which the solicitation - copying the address of its interface from which the solicitation
was received from the client into the DHCP Relay address field, was received from the client into the DHCP Relay address field,
and and
- finally, sending the resulting message to the All-DHCP-Servers - finally, sending the resulting message to the All-DHCP-Servers
multicast address, FF05:0:0:0:0:0:1:3, over all interfaces except multicast address, FF05:0:0:0:0:0:1:3, over all interfaces except
that from which the client's solicitation was received. that from which the client's solicitation was received.
When the relay receives a DHCP advertisement with the 'A' bit set, it When the relay receives a DHCP advertisement, it relays the
relays the advertisement to the client at the indicated link-local advertisement to the client at the client's link-local address by way
address by way of the interface indicated in the agent's address of the interface indicated in the agent's address field.
field.
7.2. DHCP Request Message Processing 7.2. DHCP Request Message Processing
When a relay receives a DHCP Request message, it MUST check that the When a relay receives a DHCP Request message, it SHOULD check
message is received from a link-local address, that the link-local that the message is received from a link-local address, that the
address matches the link-local address field in the Request message link-local address matches the link-local address field in the
header, and that the agent address field of the message matches an Request message header, and that the agent address field of the
IP address associated to the interface from which the DHCP Request message matches an IP address associated to the interface from which
message was received. If any of these checks fail, the Relay MUST the DHCP Request message was received. If any of these checks fail,
silently discard the Request message. the Relay MUST silently discard the Request message.
The relay MUST also check whether the 'S' bit is set in the message The relay MUST also check whether the 'S' bit is set in the message
header. If not, the datagram is discarded, and and the relay SHOULD header. If not, the datagram is discarded, and the relay SHOULD
return a DHCP Reply message to the source address of the Request return a DHCP Reply message to the address contained in the client's
message with error code 18. link-local address field of the Request message, with error code 18.
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 transmits the DHCP Request message to the address of the DHCP
server found in the Server IP Address field of the received DHCP server found in the Server IP Address field of the received DHCP
Request message. All of the fields of DHCP Request message header Request message. All of the fields of DHCP Request message header
transmitted by the relay are copied over unchanged from the DHCP transmitted by the relay are copied over unchanged from the DHCP
Request received from the client. Only the fields in the IP header Request received from the client. Only the fields in the IP header
will differ from the datagram received from the client, not the will differ from the datagram received from the client, not the
payload. If the Relay receives an ICMP error, the Relay SHOULD payload. If the Relay receives an ICMP error, the Relay SHOULD
return a DHCP Reply message to the client address (which can be found return a DHCP Reply message to the client address (which can be found
in the payload of the ICMP message [2]), with error code 64. in the payload of the ICMP message [5]), with error code 64.
7.3. DHCP Reply Message Processing 7.3. DHCP Reply Message Processing
When the relay receives a DHCP Reply, it MUST check whether the When the relay receives a DHCP Reply, it MUST check whether the
message has the 'L' bit set. It MUST check whether the link-local message has the 'L' bit set. It MUST check whether the link-local
address field contains an IP address that has prefix FE80::0000/64. address field contains a link-local address. If all the checks are
If all the checks are satisfied, the relay MUST send a DHCP Reply satisfied, the relay MUST send a DHCP Reply message to the link-local
message to the link-local address listed in the received Reply address listed in the received Reply message. Only the fields in the
message. Only the fields in the IP header will differ from the IP header will differ from the datagram received from the server, not
datagram received from the server, not the payload. the payload.
8. Retransmission and Configuration Variables 8. Retransmission and Configuration Variables
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
skipping to change at page 29, line 9 skipping to change at page 29, line 18
exchange. For instance, a DHCP server may wish to be certain that a exchange. For instance, a DHCP server may wish to be certain that a
DHCP Request originated from the client identified by the <link-local DHCP Request originated from the client identified by the <link-local
address, agent address> fields included within the Request message address, agent address> fields included within the Request message
header. Conversely, it is often essential for a DHCP client to header. Conversely, it is often essential for a DHCP client to
be certain that the configuration parameters and addresses it has be certain that the configuration parameters and addresses it has
received were sent to it by an authoritative DHCP server. Similarly, received were sent to it by an authoritative DHCP server. Similarly,
a DHCP server should only accept a DHCP Release message which seems a DHCP server should only accept a DHCP Release message which seems
to be from one of its clients, if it has some assurance that the to be from one of its clients, if it has some assurance that the
client actually did transmit the Release message. At the time of client actually did transmit the Release message. At the time of
this writing, there is no generally accepted mechanism useful with this writing, there is no generally accepted mechanism useful with
DHCPv4 that can be extended for use with DHCPv6. DHCPv4 that is appropriate for use with DHCPv6.
The IPv6 Authentication Header can provide security for DHCPv6 The IPv6 Authentication Header can provide security for DHCPv6
messages when both endpoints have a suitable IP address. However, messages when both endpoints have a suitable IP address. However,
a client often has only a link-local address, and such an address a client often has only a link-local address, and such an address
is not sufficient for a DHCP server which is off-link. In those is not sufficient for a DHCP server which is off-link. In those
circumstances the DHCP relay is involved, so that the DHCP message circumstances the DHCP relay is involved, so that the DHCP message
MUST have the relay's address in the IP destination address field, MUST have the relay's address in the IP destination address field,
even though the client aims to deliver the message to the DHCP even though the client aims to deliver the message to the DHCP
server. The DHCP Client-Server Authentication Extension [7] is server. The DHCP Client-Server Authentication Extension [11] is
intended to be used in these circumstances. intended to be used in these circumstances.
10. Acknowledgements 10. 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. A special thanks for the consistent input, ideas, specification. Ralph Droms and Thomas Narten have had a major role
and review by (in alphabetical order) Brian Carpenter, Ralph Droms, in shaping the continued improvement of the protocol by their careful
Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, reviews. Thanks also for the consistent input, ideas, and review by
and Phil Wells. (in alphabetical order) Brian Carpenter, Jack McCann, 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. Thanks to Stuart Cheshire for his excellent minutes. specifications. Thanks to Stuart Cheshire for his excellent minutes.
A. Related Work in IPv6 A. 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 [3], the IPv6 Addressing to study is the IPv6 Specification [6], the IPv6 Addressing
Architecture [4], IPv6 Stateless Address Autoconfiguration [11], IPv6 Architecture [8], IPv6 Stateless Address Autoconfiguration [15], IPv6
Neighbor Discovery Processing [6], and Dynamic Updates to DNS [12]. Neighbor Discovery Processing [10], and Dynamic Updates to DNS [16].
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 576 octets requires that every link in the internet have an MTU of 576 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 datagram of 536 octets will always pass through an internet a UDP datagram of 536 octets will always pass through an internet
(less 40 octets for the IPv6 header), as long as there are no IP (less 40 octets for the IPv6 header), as long as there are no IP
options prior to the UDP header in the datagram. But, IPv6 does options prior to the UDP header in the datagram. But, IPv6 does
not support fragmentation at routers, so that fragmentation takes not support fragmentation at routers, so that fragmentation takes
place end-to-end between hosts. If a DHCP implementation needs place end-to-end between hosts. If a DHCP implementation needs
to send a datagram greater than 536 octets it can either fragment to send a datagram greater than 536 octets it can either fragment
the UDP datagram in UDP or use Path MTU Discovery [5] to determine the UDP datagram in UDP or use Path MTU Discovery [9] to determine
the size of the datagram that will traverse a network path. It is the size of the datagram that will traverse a network path. It is
implementation dependent how this is accomplished in DHCP. implementation dependent how this is accomplished in DHCP.
The IPv6 Addressing Architecture specification [4] defines the The IPv6 Addressing Architecture specification [8] defines the
address scope that can be used in an IPv6 implementation, and the address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that multicast of the IPv6 address space. Two advantages of IPv6 are that multicast
addressing is required, and nodes can create link-local addresses addressing is required, and nodes can create link-local addresses
during initialization of the nodes environment. This means that a during initialization of the nodes environment. This means that a
client immediately can configure an IP address at initialization client immediately can configure an IP address at initialization
for an interface, before communicating in any manner on the link. for an interface, before communicating in any manner on the link.
The client can then use a well-known multicast address to begin The client can then use a well-known multicast address to begin
communications to discover neighbors on the link, or to send a DHCP communications to discover neighbors on the link, or to send a DHCP
Solicit and locate a DHCP server or relay. Solicit and locate a DHCP server or relay.
IPv6 Stateless Address Autoconfiguration [11] (addrconf) specifies IPv6 Stateless Address Autoconfiguration [15] (addrconf) specifies
procedures by which a node may autoconfigure addresses based on procedures by which a node may autoconfigure addresses based on
router advertisements [6], and the use of a validation lifetime to router advertisements [10], and the use of a validation lifetime to
support renumbering of addresses on the Internet. In addition the support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with addrconf is a design stateful autoconfiguration. Compatibility with addrconf is a design
requirement of DHCP (see Section 3.1). requirement of DHCP (see Section 3.1).
IPv6 Neighbor Discovery [6] is the node discovery protocol in IPv6 IPv6 Neighbor Discovery [10] is the node discovery protocol in IPv6
(replaces and enhances functions of ARP [8]). To truly understand (replaces and enhances functions of ARP [12]). To truly 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 [12] is a specification that supports the Dynamic Updates to DNS [16] 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 now integrate addresses and name space the dynamic updates to DNS to now integrate addresses and name space
to not only support autoconfiguration, but also autoregistration in to not only support autoconfiguration, but also autoregistration in
IPv6. IPv6. The security model to be used with DHCPv6 should conform as
closely as possible to that outlined in RFC 1825 [2].
B. Change History
B.1. Changes from November 95 to February 96 Drafts
Substituted use of client's link-local address for previous uses of
client's interface token.
Reorganized DHCP messages into Solicit/Advertise, Request/Reply,
Release, and Reconfigure.
Made message-specific formats instead of using the same DHCP header
for each message.
Eliminated retransmission message types.
Server commits after receiving DHCP Request, and optimistically
depends on client retransmissions as negative acknowledgement.
Eliminated total-addrs.
Eliminated all definitions and most fields related to allocating IPv6
addresses (moved to the Extensions specification).
Renamed "gateway address" to be "agent address".
Added "Considerations" sections.
B.2. Changes from February 96 to June 96 Drafts
Added language referring to DHCP Client-Server Authentication
extension.
Moved the 'L' bit in the DHCP Reply Message format to save 32 bits.
Added language for multicast Reconfigure message handling.
Added initial capability for the DHCP Relay to multicast and obtain
DHCP Server addresses.
Added capability for Servers to add Extensions to their
Advertisements.
Added 'C' bit to DHCP Solicit for deallocating resources after client
crash.
Added DHCP Advertisement lifetimes for use by DHCP Relay agents that
need to periodically update their list of DHCP servers.
B.3. Changes from June 96 to August 96 Drafts
Since the working group indicated that DHCP solicitation traffic
was not considered to be a significant factor affecting network
load, it was decided to modify the handling of solicitations so
that DHCP relays, by default, multicast DHCP Solicit message to all
DHCP servers at a site. This entailed a number of changes to the
protocol, namely:
- Adding fields to the DHCP Solicit and DHCP Advertise messages to
contain the DHCP client's link-local addresses.
- Adding the 'L' bit to the DHCP Solicit and DHCP Advertise
messages to indicate whether the link-local address is present
- Adding a 'P' bit to the DHCP Solicit message so that the client
can allow the Relay to use its non-default behavior, which is to
return cached DHCP Server addresses to the client in response to
the client's DHCP Solicit message.
- Specified a new multicast address (the All-DHCP-Servers address)
for use by DHCP Relays when "relaying" client solicitations.
Added a random backoff after reboot so that clients' solicitations
don't immediately swamp DHCP Servers after power outages.
Added new multicast addresses for All DHCP Servers and All DHCP
Relays.
B.4. Changes from August 96 to November 96 Drafts
Clarified language regarding treatment by the DHCP server of DHCP
Requests with the 'C' bit set.
Specified that the UDP source port for DHCP messages is arbitrary.
Added description for Appendix C.
Changed must to MUST where appropriate.
Changed definitions for client, server, and relay to be definitions
for DHCP client, DHCP server, and DHCP relay.
Changed definitions of DHCP multicast addresses to conform to recent
IANA allocations.
Corrected references to "leases", to more accurately refer to IPv6
address lifetimes.
B.5. Changes from November 96 to February 97 Drafts
Clients can continue to use valid addresses, after restarts or any
request triggered by a DHCP Reconfigure message, at least until it
receives the DHCP Request from the server.
All extensions sent in response to a single DHCP Request now must be
part of the same DHCP Reply message. If some requested resources and
configuration parameters are not available or cannot be allocated,
each particular extension will either have the appropriate error code
indicating the particular problem, or simply will not be included
in the Reply. The extensions are to be modified to have fields for
error codes whenever the server might have to indicate to the client
a reason why the information requested in its extension was unable to
be supplied.
If a client receives a DHCP Reconfigure message which does not list
some the client's configuration information, it can continue to
assume that configuration information is valid.
If a client reboots, it MUST set the 'C' bit and transmit a DHCP
Request. If it doesn't have a valid server address, it MUST set the
'C' bit in its DHCP Solicit message.
Relays are no longer allowed to cache server addresses. The
DHC working group decided to ice this plan until there was some
determination that it might be useful. This caused the elimination
of the 'P' bit, and quite a bit of discussion about the 'P' bit and
DHCP server address caching was eliminated. The 'server count' field
of the Advertisement and the lifetime field were eliminated, since
relays never keep track of server addresses and clients have to
solicit again whenever they lose their DHCP server.
The working group decided to make programming as simple as possible,
and therefore to include IP addresses in the appropriate DHCP
message headers whenever those addresses would otherwise have to be
discovered by manipulating the IP header itself. This caused many
changes to the message header formats. The 'L' bit in the DHCP
Solicit and DHCP Advertise messages is no longer necessary, because
the link-local address of the client is always present in the header.
Previously, there was language which required the client to match
pending Requests with Reply messages with the same destination
agent addresses. Those agent addresses were to be determined by
inspecting the IP headers of the DHCP Reply messages. We deleted
the requirement, in preference to loading possibly two more agent
addresses in every DHCP Advertise message and DHCP Reply message.
The DHCP Reconfigure message now has a transaction ID which the
client copies into the corresponding DHCP Request, and then which
subsequently the server copies again into the corresponding DHCP
Reply message.
Clients now use the DHCP server address found in the appropriate
field of the DHCP Reconfigure message header instead of inspecting
the IP header of the Reconfigure message.
C. Comparison between DHCPv4 and DHCPv6 B. 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 and DHCPv6. There a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6.
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.
o New features were added to support the evolution and the o New features were added to support the evolution and the
existence of mature Internet users in the industry. existence of mature Internet users in the industry.
skipping to change at page 37, line 7 skipping to change at page 34, line 7
be requested by a client in an implementation. be requested by a client in an implementation.
o Reclaiming addresses allocated with very long lifetimes can be o Reclaiming addresses allocated with very long lifetimes can be
implemented using the Reconfigure message type. implemented using the Reconfigure message type.
o Configuration of tightly coupled integration between stateless o Configuration of tightly coupled integration between stateless
and stateful address autoconfiguration can be implemented. and stateful address autoconfiguration can be implemented.
References References
[1] S. Bradner and A. Mankin. The Recommendation for the IP Next [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 2132, March 1997.
[2] R. Atkinson. Security Architecture for the Internet Protocol.
RFC 1825, August 1995.
[3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997.
[4] S. Bradner and A. Mankin. The Recommendation for the IP Next
Generation Protocol. RFC 1752, January 1995. Generation Protocol. RFC 1752, January 1995.
[2] A. Conta and S. Deering. Internet Control Message Protocol [5] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885,
December 1995. December 1995.
[3] 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.
[4] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. [7] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March
1997.
[8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
RFC 1884, December 1995. RFC 1884, December 1995.
[5] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP [9] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP
version 6. RFC 1981, August 1996. version 6. RFC 1981, August 1996.
[6] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for [10] 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.
[7] C. Perkins. Extensions to DHCPv6, February 1997. [11] C. Perkins. Extensions to DHCPv6.
draft-ietf-dhc-dhcpv6ext-05.txt, work in progress. draft-ietf-dhc-dhcpv6ext-06.txt (work in progress), May 1997.
[8] David C. Plummer. An Ethernet Address Resolution Protocol: [12] 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.
[9] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [13] J. B. Postel. User Datagram Protocol. RFC 768, August 1980.
[10] J. B. Postel, Editor. Internet Protocol. RFC 791, September [14] J. B. Postel, Editor. Internet Protocol. RFC 791, September
1981. 1981.
[11] S. Thomson and T. Narten. IPv6 stateless address [15] S. Thomson and T. Narten. IPv6 stateless address
autoconfiguration. RFC 1971, August 1996. autoconfiguration. RFC 1971, August 1996.
[12] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. [16] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
Dynamic Updates in the Domain Name System (DNS). in the Domain Name System (DNS). RFC 2136, April 1997.
draft-ietf-dnsind-dynDNS-11.txt, November 1996. (work
in progress).
Chair's Address Chair's Address
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
 End of changes. 

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