draft-ietf-dhc-dhcpv6-07.txt   draft-ietf-dhc-dhcpv6-08.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-06.txt IBM Research Obsoletes: draft-ietf-dhc-dhcpv6-07.txt IBM Research
27 August 1996 22 November 1996
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-07.txt draft-ietf-dhc-dhcpv6-08.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 62 skipping to change at page 1, line 63
2. Terminology and Definitions 2 2. Terminology and Definitions 2
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3 2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3
2.3. Specification Language . . . . . . . . . . . . . . . . . 4 2.3. Specification Language . . . . . . . . . . . . . . . . . 4
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 7 4. DHCP Message Formats and Field Definitions 8
4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 4.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8
4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9 4.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 9
4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10 4.3. DHCP Request Message Format . . . . . . . . . . . . . . . 10
4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12
4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13 4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13
4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14
5. DHCP Client Considerations 15 5. DHCP Client Considerations 15
5.1. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 15 5.1. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 15
5.2. Receiving DHCP Advertise Messages . . . . . . . . . . . . 16 5.2. Receiving DHCP Advertise Messages . . . . . . . . . . . . 16
skipping to change at page 1, line 88 skipping to change at page 1, line 89
6. DHCP Server Considerations 19 6. DHCP Server Considerations 19
6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 20 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 20
6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 20 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 20
6.3. DHCP Request and Reply Messages . . . . . . . . . . . . . 21 6.3. DHCP Request and Reply Messages . . . . . . . . . . . . . 21
6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 22 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 22
6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 23 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 23
7. DHCP Relay Considerations 23 7. DHCP Relay Considerations 23
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 28
10. Acknowledgements 29 10. Acknowledgements 29
A. Related Work in IPv6 29 A. Related Work in IPv6 29
B. Change History 30 B. Change History 30
B.1. Changes from November 95 to February 96 Drafts . . . . . 30 B.1. Changes from November 95 to February 96 Drafts . . . . . 30
B.2. Changes from February 96 to June 96 Drafts . . . . . . . 31 B.2. Changes from February 96 to June 96 Drafts . . . . . . . 31
B.3. Changes from June 96 to August 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
C. Comparison between DHCPv4 and DHCPv6 32 C. Comparison between DHCPv4 and DHCPv6 33
Chair's Address 36 Chair's Address 37
Author's Address 36 Author's Address 37
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 [3] nodes.
skipping to change at page 1, line 152 skipping to change at page 1, line 154
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 itemizes changes between different versions of this
protocol specification. 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, IPv6 Addressing Relevant terminology from the IPv6 Protocol, IPv6 Addressing
Architecture, and IPv6 Stateless Address Autoconfiguration will be Architecture, and IPv6 Stateless Address Autoconfiguration will be
provided, and then the DHCPv6 terminology. 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
skipping to change at page 3, line 21 skipping to change at page 3, line 21
multicast address multicast address
An identifier for a set of interfaces (typically An identifier for a set of interfaces (typically
belonging to different nodes). A datagram sent to belonging to different nodes). A datagram sent to
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
its network environment and enable communication on a configure its network environment and enable
link or internetwork. communication on a link or internetwork.
client A node that initiates requests on a link to obtain DHCP client A node that initiates requests on a link to obtain
configuration parameters. configuration parameters.
server A server is a node that responds to requests from DHCP 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.
relay A node that acts as an intermediary to deliver DHCP DHCP 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
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 relay or DHCP
on the same link as the DHCP client. server on the same 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 and used to integer identifier specified by the client and used
match a DHCP Reply to a pending DHCP Request. to match a DHCP Reply to a pending DHCP Request.
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. These words are often capitalized.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
This section is provided for implementors to understand the DHCPv6 This section is provided for implementors to understand the DHCPv6
protocol design model from an architectural perspective. The goals, protocol design model from an architectural perspective. The goals,
conceptual models and implementation examples presented in this conceptual models and implementation examples presented in this
section do not specify requirements of the DHCPv6 protocol. section do not specify requirements of the DHCPv6 protocol.
3.1. Design Goals 3.1. Design Goals
The following list gives general design goals for this DHCP The following list gives general design goals for this DHCP
specification. specification.
- DHCP should be a mechanism rather than a policy. DHCP must allow - DHCP should be a mechanism rather than a policy. DHCP MUST allow
local system administrators control over configuration parameters local system administrators control over configuration parameters
where desired; e.g., local system administrators should be able where desired; e.g., local system administrators should be able
to enforce local policies concerning allocation and access to to enforce local policies concerning allocation and access to
local resources where desired. local resources where desired.
- DHCP MUST NOT introduce any requirement for manual configuration - DHCP MUST NOT introduce any requirement for manual configuration
of DHCP clients, except possibly for manually configured of DHCP clients, except possibly for manually configured
keys. Each node should be able to discover appropriate keys. Each node should be able to discover appropriate
local configuration parameters without user intervention, and local configuration parameters without user intervention, and
incorporate those parameters into its own configuration. incorporate those parameters into its own configuration.
- DHCP MUST NOT require a server on each link. To allow for scale - DHCP MUST NOT require a server on each link. To allow for scale
and economy, DHCP must work across relay agents. and economy, DHCP MUST work across DHCP relays.
- 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 [11].
- DHCP must support the requirements of automated renumbering of IP - DHCP MUST support the requirements of automated renumbering of IP
addresses [1]. addresses [1].
- DHCP servers should be able to support Dynamic Updates to - DHCP servers should be able to support Dynamic Updates to
DNS [12]. DNS [12].
- 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.
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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.
All DHCP Agents MUST join the DHCPv6 Server/Relay-Agent multicast All DHCP Agents (Servers and Relays) MUST join the All-DHCP-Agents
group at the well-known multicast address FF02:0:0:0:0:0:1:0. All multicast group at the well-known multicast address
DHCP Servers MUST, in addition, join the DHCPv6 Server multicast FF02:0:0:0:0:0:1:2. All DHCP Servers MUST, in addition, join
group at the well-known multicast address FF02:0:0:0:0:0:1:tbd. the All-DHCP-Servers multicast group at the well-known multicast
All DHCP Relays MUST, on other hand, join in addition the address FF05:0:0:0:0:0:1:3. All DHCP Relays MUST, on other
DHCPv6 Relay multicast group at the well-known multicast address hand, join in addition the ALL-DHCP-Relays multicast group at the
FF02:0:0:0:0:0:1:tbd. well-known multicast address FF05:0:0:0:0:0:1:4.
DHCP uses the UDP [9] protocol to communicate between clients and DHCP uses the UDP [9] protocol to communicate between clients
servers. UDP is not reliable, but DHCP must provide some reliability and servers. UDP is not reliable, but DHCP has to provide some
between clients and servers. If a response is not received after reliability between clients and servers. If a response is not
transmission of a DHCP message, the message MUST be retransmitted received after transmission of a DHCP message, the message MUST be
according to the rules specified in Section 8. retransmitted according to the rules specified in Section 8. The
DHCP Relays address will be used eventually when DHCP Servers wish to
automatically configure all site DHCP Relays.
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. messages over UDP using port 547. The source port for DHCP messages
is arbitrary.
4. DHCP Message Formats and Field Definitions 4. DHCP Message Formats and Field Definitions
All fields in DHCP messages MUST be initialized to binary zeroes by All fields in DHCP messages MUST be initialized to binary zeroes by
both the client and server unless otherwise noted. DHCP message both the client and server unless otherwise noted. DHCP message
types not defined here (msg-types 0 and 7-255) are reserved. types not defined here (msg-types 0 and 7-255) are reserved.
4.1. DHCP Solicit Message Format 4.1. DHCP Solicit Message Format
A DHCP client or relay transmits a DHCP Solicit message to obtain one A DHCP client (or DHCP relay on behalf of a client) transmits a DHCP
or more DHCP server addresses. Solicit message to obtain one or more DHCP server addresses.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |C|L|A|P| RESERVED | | msg-type |C|L|A|P| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-local address (if present) | | link-local address (if present) |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay agent address (if present) | | DHCP relay address (if present) |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 1 msg-type 1
C If set, the client requests that all servers receiving C If set, the client requests that all servers receiving
the message deallocate the resources associated with the message deallocate the resources associated with
the client. the client.
L If set, the link-local address is present L If set, the link-local address is present
A If set, the relay's address is present A If set, the relay's address is present
P If set, the client is willing to accept previously P If set, the client is willing to accept previously
cached server addresses from relays cached server addresses from relays
RESERVED 0 RESERVED 0
If a DHCP client does not know any DHCP Agent address, or wants If a DHCP client does not know any DHCP Agent address, or wants
to locate a new server to receive configuration parameters, the to locate a new server to receive configuration parameters, the
client SHOULD use, as the destination IP address, the DHCPv6 client SHOULD use, as the destination IP address, the
Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0. If the All-DHCP-Agent multicast address FF02:0:0:0:0:0:1:2. If the
'P' bit is not set, any DHCP Relay receiving the solicitation MUST 'P' bit is not set, any DHCP Relay receiving the solicitation MUST
forward it to the All-DHCP-Servers multicast address, to instruct forward it to the All-DHCP-Servers multicast address, to instruct
DHCP Servers to send their advertisements to the prospective client. DHCP Servers to send their advertisements to the prospective client.
In that case, the relay MUST copy the client's link-local address In that case, the relay MUST copy the client's link-local address
into the message, set the 'L' bit, copy the address of its interface into the message, set the 'L' bit, copy the address of its interface
from which the client's solicitation was received into the agent's from which the client's solicitation was received into the agent's
address field, and set the 'A' bit. address field, and set the 'A' bit.
4.2. DHCP Advertise Message Format 4.2. DHCP Advertise Message Format
skipping to change at page 10, line 23 skipping to change at page 10, line 27
the 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
may be zero server addresses sent in the DHCP Advertise message. It may be zero server addresses sent in the DHCP Advertise message. It
is an error for server-count to be zero if the 'S' bit is not set. is an error for server-count to be zero if the 'S' bit is not set.
If the DHCP Server is sending the advertisement in response to a If the DHCP Server is sending the advertisement in response to a
solicitation with the client's link-local address present, the server solicitation with the client's link-local address present, the server
MUST copy the link-local address into the advertisement. MUST copy the link-local address into the advertisement.
The source IP address of the IP header of any DHCP Advertise message The source IP address of the IP header of any DHCP Advertise message
must have sufficient scope to be reachable by the DHCP Server. In MUST have sufficient scope to be reachable by the DHCP Client. In
particular, the source address of any DHCP Advertise message sent particular, the source address of any DHCP Advertise message sent
by a DHCP relay MUST NOT be a link-local address. In situations by a DHCP relay MUST NOT be a link-local address. In situations
where there are no routers sending Router Advertisements, then a DHCP where there are no routers sending Router Advertisements, then a DHCP
Server MUST be configured on the same link as prospective clients. Server MUST be configured on the same link as prospective clients.
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 the appropriate extensions [7].
If the client does not know any DHCP server address, it must first If the client does not know any DHCP server address, it MUST first
obtain a server address by multicasting a DHCP Solicit message (see obtain a server address by multicasting a DHCP Solicit message (see
Section 4.1). If the client does not have a valid IP address of Section 4.1). If the client does not have a valid IP address of
sufficient scope for the DHCP server to communicate with the client, sufficient scope for the DHCP server to communicate with the client,
the client MUST use the unicast IP address of a local DHCP relay the client MUST use the unicast IP address of a local DHCP relay
as the destination IP address. Otherwise, the client MAY omit the as the destination IP address. Otherwise, the client MAY omit the
server address in the DHCP Request message; in this case, the client server address in the DHCP Request message; in this case, the client
MUST send the DHCP Request message directly to the server, using the MUST send the DHCP Request message directly to the server, using the
server address as the IP destination address in the IP header. server address as the IP destination address in the IP header.
0 1 2 3 0 1 2 3
skipping to change at page 12, line 42 skipping to change at page 12, line 42
One of the following values: One of the following values:
0 Success 0 Success
16 Failure, reason unspecified 16 Failure, reason unspecified
17 Authentication failed or nonexistent 17 Authentication failed or nonexistent
18 Poorly formed request 18 Poorly formed request
19 Resources unavailable 19 Resources unavailable
20 Client record unavailable 20 Client record unavailable
21 Invalid source address in Release 21 Invalid source address in Release
22 Unable to honor required extension parameters 22 Unable to honor required extension parameters
24 Bad Hair Day
32 Insufficient Funds
64 Server unreachable (ICMP error) 64 Server unreachable (ICMP error)
transaction-ID transaction-ID
Copied from the transaction-ID which the DHCP server Copied from the transaction-ID which the DHCP server
received in the DHCP Request, to help the client match received in the DHCP Request, to help the client match
this reply with an outstanding Request. this reply with an outstanding Request.
link-local address 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.
skipping to change at page 15, line 6 skipping to change at page 14, line 48
be requested again by the client. be requested again by the client.
The client SHOULD listen at UDP port 546 to receive possible The client SHOULD 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 an 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 DHCP earlier DHCP Reply message. If the client does not listen for DHCP
Reconfigure messages, it is possible that the client will not receive Reconfigure messages, it is possible that the client will not receive
notification that its DHCP server has deallocated the client's notification that its DHCP server has deallocated the client's
The client MAY receive an update to the prefix for their addresses
and then MUST use that prefix for their addreses.
IP address and/or other resources allocated to the client. See IP address and/or other resources allocated to the client. See
discussion in 6.5. discussion in 6.5.
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 | msg-flags | reserved | | msg-type | msg-flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 42 skipping to change at page 15, line 41
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.
5.1. Sending DHCP Solicit Messages 5.1. Sending DHCP Solicit Messages
If a node wishes to become a new DHCP client, it must first If a node wishes to become a new DHCP client, it MUST first
locate a DHCP Server. The client does this by multicasting a DHCP locate a DHCP Server. The client does this by multicasting a DHCP
Solicit message to the All-DHCP-Agents address multicast address Solicit message to the All-DHCP-Agents address multicast address
FF02:0:0:0:0:0:1:0, setting the Hop Limit == 1. If there are no FF02:0:0:0:0:0:1:2, setting the Hop Limit == 1. If there are no
DHCP servers on the same link as the node, then a DHCP Relay must be DHCP servers on the same link as the node, then a DHCP Relay MUST be
present for further handling of the solicitation. If the node is present for further handling of the solicitation. If the node is
willing to accept cached server addresses from the DHCP Relay instead willing to accept cached server addresses from the DHCP Relay instead
of requesting the Relay to multicast its solicitation over all site of requesting the Relay to multicast its solicitation over all site
networks, then the node MAY set the 'P' bit in its solicitation. networks, then the node MAY set the 'P' bit in its solicitation.
By setting the 'C' bit in the solicitation, a DHCP client requests By setting the 'C' bit in the solicitation, a DHCP client requests
that all the DHCP Servers that receive the solicitation should clean that all the DHCP Servers that receive the solicitation should clean
up their stale client records that match its link-local address. up their stale client records that match its link-local address.
If a client sends a DHCP Solicit message after it reboots, the If a client sends a DHCP Solicit message after it reboots, the
skipping to change at page 16, line 43 skipping to change at page 16, line 41
client MUST use the agent address as the destination address for any client MUST use the agent address as the destination address for any
future DHCP message transactions sent to that server. future DHCP message transactions sent to that server.
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.3. 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 different) DHCP agent address. If the client acquired a (possibly different) 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
know which servers had made the allocations, if any datagrams were know which servers had made the allocations, if any datagrams were
lost due to collisions, etc. lost due to collisions, etc.
If the client has no valid IP address of sufficient scope, and the If the client has no valid IP address of sufficient scope, and the
skipping to change at page 18, line 33 skipping to change at page 18, line 33
all expected extensions are not found in the same Reply message, all expected extensions are not found in the same Reply message,
then they are likely to be located in another Reply, possibly then they are likely to be located in another Reply, possibly
with a different Error Code, but with the same transaction-ID. The with a different Error Code, but with the same transaction-ID. The
DHCP Client MUST continue processing DHCP Reply messages until all DHCP Client MUST continue processing DHCP Reply messages until all
requested extensions are accounted for. If some requested extensions requested extensions are accounted for. If some requested extensions
are not accounted for within DHCP Reply messages sent by the server, are not accounted for within DHCP Reply messages sent by the server,
the client MUST reissue the entire DHCP Request again, with all the client MUST reissue the entire DHCP Request again, with all
extensions, and the same transaction-ID. extensions, and the same transaction-ID.
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 [7]. These "resource-server" associations are
used when sending DHCP Release messages. used when sending DHCP Release messages.
5.5. Sending DHCP Release Messages 5.5. 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. Note that it is
an error (Error Code 21) to include within the DHCP Release message 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 both the 'D' bit and an IP address extension which has the IP address
used as the source address of the datagram containing DHCP Release used as the source address of the datagram containing DHCP Release
message. message.
5.6. Receiving DHCP Reconfigure Messages 5.6. Receiving DHCP Reconfigure Messages
skipping to change at page 19, line 35 skipping to change at page 19, line 35
client appends a matching Extension to its DHCP Request message client appends a matching Extension to its DHCP Request message
which it formulates to send to the DHCP server which is found in which it formulates to send to the DHCP server which is found in
the IP source address of the message. The client also selects a the IP source address of the message. The client also selects a
transaction-ID numerically greater than its last choice and inserts transaction-ID numerically greater than its last choice and inserts
it into the Request message. From then on, processing is the same as it into the Request message. From then on, processing is the same as
specified above in Section 5.3. specified above in Section 5.3.
Note that a client may be requested by its server to join a multicast Note that a client may be requested by its server to join a multicast
group for the purpose of receiving DHCP Reconfigure messages. When a group 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
will minimize the likelihood that the server will be bombarded with will minimize the likelihood that the server will be bombarded with
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 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
skipping to change at page 20, line 38 skipping to change at page 20, line 38
relay agent. If the UDP length disagrees with the length determined relay agent. If the UDP length disagrees with the length determined
by the format of the DHCP Solicit message, the server MUST drop the by the format of the DHCP Solicit message, the server MUST drop the
packet and SHOULD log the error. packet and SHOULD log the error.
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. The
destination address of the advertisement MUST be the source address destination address of the advertisement MUST be the source address
of the solicitation. The DHCP server must use an IP address of the of the solicitation. The DHCP server MUST use an IP address of the
interface on which it received the Solicit message as the source interface on which it received the Solicit message as the source
address field of the IP header of the message. address field of the IP header of the message.
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 Messages
skipping to change at page 21, line 21 skipping to change at page 21, line 21
the 'S' bit is set, the server MUST check that the server address the 'S' bit is set, the server MUST check that the server address
matches the destination IP address at which the Request message was matches the destination IP address at which the Request message was
received by the server. If the server address does not match, the received by the server. If the server address does not match, the
Request message MUST be silently discarded. Request message MUST be silently discarded.
If the received agent address and link-local address do not If the received agent address and link-local address do not
correspond to any binding known to the server, then the server MAY correspond to any binding known to the server, then the server MAY
create a new binding for the previously unknown client; otherwise, it create a new binding for the previously unknown client; otherwise, it
SHOULD return a DHCP Reply with an error code of 20. SHOULD return a DHCP Reply with an error code of 20.
Before processing the Request, the server must determine whether or Before processing the Request, the server MUST determine whether or
not the Request is a retransmission of an earlier DHCP Request from not the Request is a retransmission of an earlier DHCP Request from
the same client. This is done by comparing the transaction-ID to the same client. This is done by comparing the transaction-ID to
all those transaction-IDs received from the same client during the 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 (the transaction-ID has not been recently used), when the Otherwise (the transaction-ID has not been recently used), when the
server has identified and allocated all the relevant information, server has identified and allocated all the relevant information,
skipping to change at page 22, line 24 skipping to change at page 22, line 24
attempt to put all the extensions that were processed with the same attempt to put all the extensions that were processed with the same
Error Code into the same DHCP Reply, in the order in which they were Error Code into the same DHCP Reply, in the order in which they were
received. received.
When a client DHCP Request is received that has the 'C' bit set, the When a client DHCP Request is received that has the 'C' bit set, the
server should check to find out whether the extensions listed in the server should check to find out whether the extensions listed in the
Request message match those which it has associated with the client's Request message match those which it has associated with the client's
binding. Any resources which are not indicated by the client are binding. Any resources which are not indicated by the client are
presumed to be unknown by the client, and thus possible candidates presumed to be unknown by the client, and thus possible candidates
for reallocation to satisfy requests from other clients. The DHCP for reallocation to satisfy requests from other clients. The DHCP
Server is NOT required to deallocate all resources associated with Server MUST deallocate all resources associated with the client upon
the client upon reception of a DHCP Request with the 'C' bit set, and reception of a DHCP Request with the 'C' bit set, except for those
wise implementations will not deallocate any resources until after which meet the following two conditions:
- they are requested by the client in extensions to the same
Request message , and
- the server is willing to reallocate them in response to the
client's request.
. Wise implementations will not deallocate any resources until after
the list of extensions to the request have been inspected. the list of extensions to the request have been 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:00:00:00/64). If not, the message MUST be silently discarded. FE80:00:00:00/64). If not, the message MUST be silently discarded.
In response to a DHCP Release Message with a valid link-local address In response to a DHCP Release Message with a valid link-local address
skipping to change at page 24, line 24 skipping to change at page 24, line 31
- copying the prospective client's link-local address into the - copying the prospective client's link-local address into the
appropriate field of the outgoing solicitation, appropriate field 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, and finally, was received from the client, and finally,
- sending the resulting message to the All-DHCP-Servers multicast - sending the resulting message to the All-DHCP-Servers multicast
address, FF02:0:0:0:0:0:1:tbd, over all interfaces except that address, FF05:0:0:0:0:0:1:3, over all interfaces except that from
from which the client's solicitation was received. which the client's solicitation was received.
When the relay receives a DHCP advertisement with the 'L' and 'A' When the relay receives a DHCP advertisement with the 'L' and 'A'
bits set, it relays the advertisement to the client at the indicated bits set, it relays the advertisement to the client at the indicated
link-local address by way of the interface indicated in the agent's link-local address by way of the interface indicated in the agent's
address field. Any datagram with the 'L' bit set and the 'A' bit not address field. Any datagram with the 'L' bit set and the 'A' bit not
set MUST be silently discarded. set MUST be silently discarded.
If the relay receives a DHCP solicit message with the 'P' bit If the relay receives a DHCP solicit message with the 'P' bit
set, the relay MAY construct a DHCP Advertise message and transmit set, the relay MAY construct a DHCP Advertise message and transmit
it to the soliciting client on the same link as the solicitation it to the soliciting client on the same link as the solicitation
skipping to change at page 25, line 44 skipping to change at page 26, line 8
relay are copied over unchanged from the DHCP Request received from relay are copied over unchanged from the DHCP Request received from
the client. Only the fields in the IP header will differ from the the client. Only the fields in the IP header will differ from the
datagram received from the client, not the payload. If the Relay datagram received from the client, not the payload. If the Relay
receives an ICMP error, the Relay SHOULD return a DHCP Reply message receives an ICMP error, the Relay SHOULD return a DHCP Reply message
to the client address (which can be found in the payload of the ICMP to the client address (which can be found in the payload of the ICMP
message [2]), with error code 64. message [2]), 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 When the relay receives a DHCP Reply, it MUST check whether
the message has the 'L' bit set. It must check whether the the message has the 'L' bit set. It MUST check whether the
link-local address field contains an IP address that has prefix link-local address field contains an IP address that has prefix
FE80:00:00:00/64. If all the checks are satisfied, the relay MUST FE80:00:00:00/64. If all the checks are satisfied, the relay MUST
send a DHCP Reply message to the link-local address listed in the send a DHCP Reply message to the link-local address listed in the
received Reply message. Only the fields in the IP header will differ received Reply message. Only the fields in the IP header will differ
from the datagram received from the server, not the payload. from the datagram received from the server, not 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
skipping to change at page 27, line 46 skipping to change at page 28, line 7
RECONF_MSG_MAX_RESP RECONF_MSG_MAX_RESP
The maximum amount of time before a client MUST respond to a The maximum amount of time before a client MUST respond to a
DHCP Reconfigure message sent to a multicast address. DHCP Reconfigure message sent to a multicast address.
Default: 10 seconds. Default: 10 seconds.
RELAY_DISCOVERY_PERIOD RELAY_DISCOVERY_PERIOD
The period fo time between successive attempts by the DHCP The period of time between successive attempts by the DHCP
Relay to discovery available DHCP Servers. Relay to discover available DHCP Servers.
Default: 3600 seconds (1 hour). Default: 3600 seconds (1 hour).
MAX_SOLICIT_DELAY MAX_SOLICIT_DELAY
The maximum amount of time a prospective client is required The maximum amount of time a prospective client is required
to wait, after determining from a Router Discovery message to wait, after determining from a Router Discovery message
that the client should perform stateful address configuration, that the client should perform stateful address configuration,
before sending a DHCP Solicit to a DHCP Server. before sending a DHCP Solicit to a DHCP Server.
skipping to change at page 28, line 38 skipping to change at page 28, line 45
XID_TIMEOUT XID_TIMEOUT
The amount of time a DHCP server has to keep track of The amount of time a DHCP server has to keep track of
client transaction-IDs in order to make sure that client client transaction-IDs in order to make sure that client
retransmissions using the same transaction-ID are idempotent. retransmissions using the same transaction-ID are idempotent.
Default: 10800 seconds Default: 10800 seconds
9. Security Considerations 9. Security Considerations
DHCP clients and servers must often be able to authenticate the DHCP clients and servers often have to authenticate the messages they
messages they exchange. For instance, a DHCP server may wish to be exchange. For instance, a DHCP server may wish to be certain that a
certain that a DHCP Request originated from the client identified by DHCP Request originated from the client identified by the <link-local
the <link-local address, agent address> fields included within the address, agent address> fields included within the Request message
Request message header. Conversely, it is often essential for a DHCP header. Conversely, it is often essential for a DHCP client to
client to be certain that the configuration parameters and addresses be certain that the configuration parameters and addresses it has
it has received were sent to it by an authoritative DHCP server. received were sent to it by an authoritative DHCP server. Similarly,
Similarly, a DHCP server should only accept a DHCP Release message a DHCP server should only accept a DHCP Release message which seems
which seems to be from one of its clients, if it has some assurance to be from one of its clients, if it has some assurance that the
that the client actually did transmit the Release message. At the client actually did transmit the Release message. At the time of
time of this writing, there is no generally accepted mechanism useful this writing, there is no generally accepted mechanism useful with
with DHCPv4 that can be extended for use with DHCP. DHCPv4 that can be extended for use with DHCP.
The IPv6 Authentication Header can provide security for DHCP The IPv6 Authentication Header can provide security for DHCP
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 must be involved, so that the DHCP circumstances the DHCP relay is involved, so that the DHCP message
message MUST have the relay's address in the IP destination address MUST have the relay's address in the IP destination address field,
field, even though the client aims to deliver the message to the even though the client aims to deliver the message to the DHCP
DHCP server. The DHCP Client-Server Authentication Extension [7] is server. The DHCP Client-Server Authentication Extension [7] 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. A special thanks for the consistent input, ideas,
and review by (in alphabetical order) Brian Carpenter, Ralph Droms, and review by (in alphabetical order) Brian Carpenter, Ralph Droms,
Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson,
and Phil Wells. and Phil Wells.
skipping to change at page 29, line 42 skipping to change at page 29, line 47
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 [3], the IPv6 Addressing
Architecture [4], IPv6 Stateless Address Autoconfiguration [11], IPv6 Architecture [4], IPv6 Stateless Address Autoconfiguration [11], IPv6
Neighbor Discovery Processing [6], and Dynamic Updates to DNS [12]. Neighbor Discovery Processing [6], and Dynamic Updates to DNS [12].
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 or requires that every link in the internet have an MTU of 576 octets
greater (in IPv4 the requirement is 68 octets). This means that a or greater (in IPv4 the requirement is 68 octets). This means that
UDP datagram of 536 octets will always pass through an internet (less a UDP datagram of 536 octets will always pass through an internet
40 octets for the IPv6 header), as long as there are no IP options (less 40 octets for the IPv6 header), as long as there are no IP
prior to the UDP header in the datagram. But, IPv6 does not support options prior to the UDP header in the datagram. But, IPv6 does
fragmentation at routers and fragmentation must take place end-to-end not support fragmentation at routers, so that fragmentation takes
between hosts. If a DHCP implementation needs to send a datagram place end-to-end between hosts. If a DHCP implementation needs
greater than 536 octets it can either fragment the UDP datagram to send a datagram greater than 536 octets it can either fragment
in UDP or use Path MTU Discovery [5] to determine the size of the the UDP datagram in UDP or use Path MTU Discovery [5] to determine
datagram that will traverse a network path. It is implementation the size of the datagram that will traverse a network path. It is
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 [4] 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
skipping to change at page 32, line 22 skipping to change at page 32, line 28
- Specified a new multicast address (the All-DHCP-Servers address) - Specified a new multicast address (the All-DHCP-Servers address)
for use by DHCP Relays when "relaying" client solicitations. for use by DHCP Relays when "relaying" client solicitations.
Added a random backoff after reboot so that clients' solicitations Added a random backoff after reboot so that clients' solicitations
don't immediately swamp DHCP Servers after power outages. don't immediately swamp DHCP Servers after power outages.
Added new multicast addresses for All DHCP Servers and All DHCP Added new multicast addresses for All DHCP Servers and All DHCP
Relays. 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.
C. Comparison between DHCPv4 and DHCPv6 C. Comparison between DHCPv4 and DHCPv6
This appendix is provided for readers who will find it useful to see This appendix is provided for readers who will find it useful to see
a model and architecture comparison between DHCPv4 and DHCPv6. There a model and architecture comparison between DHCPv4 and DHCPv6. There
are three key reasons for the differences: 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
skipping to change at page 33, line 5 skipping to change at page 33, line 35
on the local link. on the local link.
o The need for bootp compatibility and broadcast flags are removed, o The need for bootp compatibility and broadcast flags are removed,
which permitted a great deal of freedom in designing the new which permitted a great deal of freedom in designing the new
packet formats for the client and server interaction. packet formats for the client and server interaction.
o Multicast and the scoping methods in IPv6 permitted the design of o Multicast and the scoping methods in IPv6 permitted the design of
discovery packets that would inherently define their range by the discovery packets that would inherently define their range by the
multicast address for the function required. multicast address for the function required.
o Stateful autoconfiguration must coexist and integrate with o Stateful autoconfiguration has to coexist and integrate with
stateless autoconfiguration supporting Duplicate Address stateless autoconfiguration supporting Duplicate Address
Detection and two lease times to facilitate the dynamic Detection and the two IPv6 lifetimes, to facilitate the dynamic
renumbering of addresses and the management of those addresses. renumbering of addresses and the management of those addresses.
o Multiple addresses per interface are inherently supported in o Multiple addresses per interface are inherently supported in
IPv6. IPv6.
o Most DHCPv4 options are unnecessary now because the configuration o Most DHCPv4 options are unnecessary now because the configuration
parameters are either obtained through IPv6 Neighbor Discovery or parameters are either obtained through IPv6 Neighbor Discovery or
the Service Location protocol. the Service Location protocol.
DHCPv6 Architecture/Model Changes: DHCPv6 Architecture/Model Changes:
skipping to change at page 34, line 5 skipping to change at page 34, line 34
once the client and server set-up is complete. once the client and server set-up is complete.
o The server assumes the client receives its responses unless it o The server assumes the client receives its responses unless it
receives a retransmission of the same client request. This receives a retransmission of the same client request. This
permits recovery in the case where the network has faulted. permits recovery in the case where the network has faulted.
o DHCPINFORM is inherent in the new packet design; a client can o DHCPINFORM is inherent in the new packet design; a client can
request configuration parameters other than IPv6 addresses in the request configuration parameters other than IPv6 addresses in the
optional extension headers. optional extension headers.
o Clients must listen to their UDP port for the new Reconfigure o Clients MUST listen to their UDP port for the new Reconfigure
message type from servers, unless they join the appropriate message type from servers, unless they join the appropriate
multicast group as specified by the DHCP server. multicast group as specified by the DHCP server.
o Dynamic Updates to DNS are supported in the IPv6 Address o Dynamic Updates to DNS are supported in the IPv6 Address
extension. extension.
o New extensions have been defined. o New extensions have been defined.
New Internet User Features: New Internet User Features:
skipping to change at page 34, line 30 skipping to change at page 35, line 10
deprecated for dynamic renumbering can be implemented. deprecated for dynamic renumbering can be implemented.
o Configuration of how relay-agents locate remote servers for a o Configuration of how relay-agents locate remote servers for a
link can be implemented. link can be implemented.
o An Authentication extension has been added. o An Authentication extension has been added.
o Configuration of additional addresses for server applications can o Configuration of additional addresses for server applications can
be requested by a client in an implementation. be requested by a client in an implementation.
o Configuration of reclaiming infinite leases can be implemented o Reclaiming addresses allocated with very long lifetimes can be
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. 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 [2] A. Conta and S. Deering. Internet Control Message Protocol
 End of changes. 

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