draft-ietf-dhc-dhcpv6-10.txt   draft-ietf-dhc-dhcpv6-11.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-09.txt Sun Microsystems Obsoletes: draft-ietf-dhc-dhcpv6-11.txt Sun Microsystems
26 May 1997 21 November 1997
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-10.txt draft-ietf-dhc-dhcpv6-11.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 by the Dynamic Host Configuration
Internet Engineering Task Force (IETF). Comments should be submitted Working Group of the Internet Engineering Task Force (IETF).
to the dhcp-v6@bucknell.edu mailing list. Comments should be submitted to the dhcp-v6@bucknell.edu mailing
list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check
``1id-abstracts.txt'' listing contained in the Internet- Drafts the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
ftp.isi.edu (US West Coast). ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCPv6) provides a framework The Dynamic Host Configuration Protocol (DHCPv6) provides a framework
for passing configuration information, via extensions, to IPv6 nodes. for passing configuration information, via extensions, to IPv6 nodes.
It offers the capability of automatic allocation of reusable network It offers the capability of automatic allocation of reusable network
addresses and additional configuration flexibility. This protocol addresses and additional configuration flexibility. This protocol
should be considered a stateful counterpart to the IPv6 Stateless should be considered a stateful counterpart to the IPv6 Stateless
Address Autoconfiguration protocol specification. Address Autoconfiguration protocol specification, and can be used
separately or together with the latter to obtain configuration
information.
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 1 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 5
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5
3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 6 3.2. DHCP Messages . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Request/Response Processing Model . . . . . . . . . . . . 7 3.3. Request/Response Processing Model . . . . . . . . . . . . 7
4. DHCP Message Formats and Field Definitions 8 4. DHCP Message Formats and Field Definitions 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 . . . . . . . . . . . . . . . 11
4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 4.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12
4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13 4.5. DHCP Release Message Format . . . . . . . . . . . . . . . 13
4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 15
5. DHCP Client Considerations 15 5. DHCP Client Considerations 16
5.1. Verifying Resource Allocations After Restarts . . . . . . 15 5.1. Verifying Resource Allocations After Restarts . . . . . . 16
5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16 5.2. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 16
5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 17 5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 17
5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 17 5.4. Sending DHCP Request Messages . . . . . . . . . . . . . . 18
5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 18 5.5. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 20
5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 19 5.6. Sending DHCP Release Messages . . . . . . . . . . . . . . 20
5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 19 5.7. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 21
5.8. Interaction with Stateless Address Autoconfiguration . . 21
6. DHCP Server Considerations 20 6. DHCP Server Considerations 22
6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 21 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 22
6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 21 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 23
6.3. DHCP Request and Reply Message Processing . . . . . . . . 21 6.3. DHCP Request and Reply Message Processing . . . . . . . . 23
6.3.1. Processing for Extensions to DHCP Request and Reply 6.3.1. Processing for Extensions to DHCP Request and Reply
Messages . . . . . . . . . . . . . . . . . 22 Messages . . . . . . . . . . . . . . . . . 24
6.3.2. Client Requests to Deallocate Unknown Resources . 23 6.3.2. Client Requests to Deallocate Unknown Resources . 25
6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 23 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 25
6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 24 6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 26
7. DHCP Relay Considerations 24 7. DHCP Relay Considerations 26
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 24 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 27
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 25 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 27
7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 26 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 28
8. Retransmission and Configuration Variables 26 8. Retransmission and Configuration Variables 28
9. Security Considerations 29 9. Security Considerations 31
10. Acknowledgements 29 10. Year 2000 considerations 32
A. Related Work in IPv6 29 11. Acknowledgements 32
B. Comparison between DHCPv4 and DHCPv6 31 A. Related Work in IPv6 32
Chair's Address 36 B. Comparison between DHCPv4 and DHCPv6 33
Author's Address 36 Chair's Address 39
Author's Address 39
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol (DHCPv6, or in this The Dynamic Host Configuration Protocol (DHCPv6, or in this
document usually DHCP) provides configuration parameters to Internet document usually DHCP) provides configuration parameters to Internet
nodes. DHCP consists of a protocol for delivering node-specific nodes. DHCP consists of a protocol for delivering node-specific
configuration parameters from a DHCP server to a client, and a configuration parameters from a DHCP server to a client, and a
mechanism for allocation of network addresses and other related mechanism for allocation of network addresses and other related
parameters to IPv6 [6] nodes. parameters to IPv6 [6] nodes.
skipping to change at page 1, line 131 skipping to change at page 1, line 137
providing initialization parameters by way of the DHCP protocol, providing initialization parameters by way of the DHCP protocol,
and the term "client" refers to a node requesting initialization and the term "client" refers to a node requesting initialization
parameters from a DHCP server. parameters from a DHCP server.
DHCPv6 uses Request and Reply messages to support a client/server DHCPv6 uses Request and Reply messages to support a client/server
processing model whereby both client and server are assured that processing model whereby both client and server are assured that
requested configuration parameters have been received and accepted requested configuration parameters have been received and accepted
by the client. DHCP supports optional configuration parameters and by the client. DHCP supports optional configuration parameters and
processing for nodes through extensions described in its companion processing for nodes through extensions described in its companion
document ``Extensions for the Dynamic Host Configuration Protocol for document ``Extensions for the Dynamic Host Configuration Protocol for
IPv6'' [11]. IPv6'' [12].
The IPv6 Addressing Architecture [8] and IPv6 Stateless Address The IPv6 Addressing Architecture [8] and IPv6 Stateless Address
Autoconfiguration specifications provide new features not available Autoconfiguration [16] specifications provide new features not
in IP version 4 (IPv4) [14], which are used to simplify and available in IP version 4 (IPv4) [15], which are used to simplify
generalize the operation of DHCP clients. and generalize the operation of DHCP clients. This document is
intended to complement those specifications for clients attached to
the kinds of Internet media for which those specifications apply. In
particular, the specification in this document does not necessarily
apply to nodes which do not enjoy a full duplex link to the Internet.
Section 2 provides definitions for terminology used throughout Section 2 provides definitions for terminology used throughout
this document. Section 3 provides an overview of the protocol this document. Section 3 provides an overview of the protocol
design model that guided the design choices in the specification; design model that guided the design choices in the specification;
section 3.2 briefly describes the protocol messages and their section 3.2 briefly describes the protocol messages and their
semantics. Section 4 provides the message formats and field semantics. Section 4 provides the message formats and field
definitions used for each message. Sections 5, 6, and 7 specify definitions used for each message. Sections 5, 6, and 7 specify
how clients, servers, and relays interact. Appendix A summarizes how clients, servers, and relays interact. The timeout and
related work in IPv6 that will provide helpful context; it is not retransmission guidelines and configuration variables are discussed
part of this specification, but included for informational purposes. in Section 8. Appendix A summarizes related work in IPv6 that will
Appendix B discusses the differences between DHCPv4 and DHCPv6. provide helpful context; it is not part of this specification, but
included for informational purposes. Appendix B discusses the
differences between DHCPv4 and DHCPv6.
2. Terminology and Definitions 2. Terminology and Definitions
Relevant terminology from the IPv6 Protocol [6], IPv6 Addressing Relevant terminology from the IPv6 Protocol [6], IPv6 Addressing
Architecture [8], and IPv6 Stateless Address Autoconfiguration [15] Architecture [8], and IPv6 Stateless Address Autoconfiguration [16]
will be provided, and then the DHCPv6 terminology. will be provided, and then the DHCPv6 terminology.
2.1. IPv6 Terminology 2.1. IPv6 Terminology
IP Internet Protocol Version 6 (IPv6). The terms IPv4 and address An IP layer identifier for an interface or a set of
IPv6 are used only in contexts where necessary to avoid interfaces.
ambiguity.
node A device that implements IP. unicast address
An identifier for a single interface. A packet sent
to a unicast address is delivered to the interface
identified by that address.
router A node that forwards IP datagrams not explicitly multicast address
addressed to itself. An identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to a
multicast address is delivered to all interfaces
identified by that address.
host Any node that is not a router. host Any node that is not a router.
IP Internet Protocol Version 6 (IPv6). The terms IPv4 and
IPv6 are used only in contexts where it is necessary to
avoid ambiguity.
interface
A node's attachment to a link.
link A communication facility or medium over which nodes link A communication facility or medium over which nodes
can communicate at the link layer, i.e., the layer can communicate at the link layer, i.e., the layer
immediately below IP. Examples are Ethernet (simple or immediately below IP. Examples are Ethernet (simple or
bridged); Token Ring; PPP links, X.25, Frame Relay, or bridged); Token Ring; PPP links, X.25, Frame Relay, or
ATM networks; and internet (or higher) layer "tunnels", ATM networks; and internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself. such as tunnels over IPv4 or IPv6 itself.
link-layer identifier link-layer identifier
a link-layer identifier for an interface. Examples a link-layer identifier for an interface. Examples
include IEEE 802 addresses for Ethernet or Token Ring include IEEE 802 addresses for Ethernet or Token Ring
network interfaces, and E.164 addresses for ISDN links. network interfaces, and E.164 addresses for ISDN links.
link-local address link-local address
An IP address having link-only scope that can be used An IP address having link-only scope, indicated by
to reach neighboring nodes attached to the same link. having the routing prefix FE80::0000/64), that can be
All interfaces have a link-local address. used to reach neighboring nodes attached to the same
link. Every interface has a link-local address.
neighbor Nodes attached to the same link.
interface message A unit of data carried in a packet, exchanged between
A node's attachment to the link. DHCP agents and clients.
address An IP layer identifier for an interface or a set of neighbor A node attached to the same link.
interfaces.
message A unit of data carried in a datagram, exchanged between node A device that implements IP.
DHCP agents and clients.
datagram An IP header plus payload. packet An IP header plus payload.
unicast address prefix A bit string that consists of some number of initial
An identifier for a single interface. A datagram sent bits of an address.
to a unicast address is delivered to the interface
identified by that address.
multicast address router A node that forwards IP packets not explicitly
An identifier for a set of interfaces (typically addressed to itself.
belonging to different nodes). A datagram sent to
a multicast address is delivered to all interfaces
identified by that address.
2.2. DHCPv6 Terminology 2.2. DHCPv6 Terminology
Agent Address
The address of a neighboring DHCP Agent on the same
link as the DHCP client.
binding A binding (or, client binding) in DHCP contains the
data which a DHCP server maintains for each of its
clients (see Section 6).
resource-server association
An association between a resource and a DHCP server
maintained by the client which received that resource
from that DHCP server.
configuration parameter configuration parameter
Any parameter that can be used by a node to configure Any parameter that can be used by a node to configure
its network environment and enable communication on a its network subsystem and enable communication on a
link or internetwork. link or internetwork.
DHCP Client (or Client) DHCP agent (or agent)
Either a DHCP server or a DHCP relay.
DHCP client (or client)
A node that initiates requests on a link to obtain A node that initiates requests on a link to obtain
configuration parameters. configuration parameters.
DHCP Server (or Server) DHCP relay (or relay)
A server is a node that responds to requests from
clients to provide: addresses, prefix lengths, or
other configuration parameters.
DHCP Relay (or Relay)
A node that acts as an intermediary to deliver DHCP A node that acts as an intermediary to deliver DHCP
messages between clients and servers. messages between clients and servers.
DHCP Agent (or Agent) DHCP server (or server)
Either a DHCP server or a DHCP relay. A server is a node that responds to requests from
clients to provide: addresses, prefix lengths, or
Agent Address other configuration parameters.
The address of a neighboring DHCP Agent 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 or server, unsigned integer identifier specified by the client
and used to match a response to a pending message. or server, and used to match a response to a pending
message.
binding A binding (or, client binding) in DHCP contains the
data which a DHCP server maintains for each of its
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, in accordance with RFC 2119 [3]. These words of the specification, in accordance with RFC 2119 [2]. These words
are often capitalized. 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
skipping to change at page 4, line 32 skipping to change at page 4, line 40
weighed before choosing a different course. weighed before choosing a different course.
Unexpected results may result otherwise. Unexpected results may result otherwise.
MAY This word, or the adjective "optional", means that MAY This word, or the adjective "optional", means that
this item is one of an allowed set of alternatives. this item is one of an allowed set of alternatives.
An implementation which does not include this option An implementation which does not include this option
MUST be prepared to interoperate with another MUST be prepared to interoperate with another
implementation which does include the option. implementation which does include the option.
silently discard silently discard
The implementation discards the datagram without The implementation discards the packet without
further processing, and without indicating an error further processing, and without indicating an error
to the sender. The implementation SHOULD provide to the sender. The implementation SHOULD provide
the capability of logging the error, including the the capability of logging the error, including the
contents of the discarded datagram, and SHOULD contents of the discarded packet, and SHOULD record
record the event in a statistics counter. the event in a statistics counter.
3. Protocol Design Model 3. Protocol Design Model
This section is provided for implementors to understand the DHCPv6 This section is provided for implementors to understand the DHCPv6
protocol design model from an architectural perspective. The goals, protocol design model from an architectural perspective. Goals and
conceptual models and implementation examples presented in this conceptual models are presented in this section.
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 when security requirements need
keys. Each node should be able to discover appropriate authentication or encryption keys. Each node should be able to
local configuration parameters without user intervention, and obtain appropriate local configuration parameters without user
incorporate those parameters into its own configuration. intervention, and 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 DHCP relays. 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 [15]. Autoconfiguration [16].
- DHCP MUST support the requirements of automated renumbering of IP - A DHCPv6 Client implementation MAY be started in the absence of
addresses [4]. any IPv6 routers on the client's link.
- DHCP servers should be able to support Dynamic Updates to - DHCP architecture MUST support the requirements of automated
DNS [16]. renumbering of IP addresses [3].
- DHCP servers MUST be able to handle multiple IPv6 addresses for - DHCP servers SHOULD be able to support Dynamic Updates to
DNS [18].
- DHCP servers MUST be able to support multiple IPv6 addresses for
each client. each client.
- DHCP MUST work on network links that do not have routers, as long
as a DHCP server is present on the link.
- A DHCP server to server protocol is NOT part of this - A DHCP server to server protocol is NOT part of this
specification. specification.
- It is NOT a design goal of DHCP to specify how a server - It is NOT a design goal of DHCP to specify how a server
configuration parameter database is maintained or determined. configuration parameter database is maintained or determined.
Methods for configuring DHCP servers are outside the scope of Methods for configuring DHCP servers are outside the scope of
this document. this document.
3.2. DHCP Messages 3.2. DHCP Messages
Each DHCP message contains a type, which defines their function Each DHCP message contains a type, which defines its function
within the protocol. Processing details for these DHCP messages are within the protocol. Processing details for these DHCP messages are
specified in Sections 5, 6, and 7. The message types are as follows: specified in Sections 5, 6, and 7. The specified message types are
as follows:
01 DHCP Solicit 01 DHCP Solicit
The DHCP Solicit message is a DHCP message sent to one or more The DHCP Solicit message is an IP multicast message sent by a
DHCP Agents. DHCP client to one or more DHCP agents.
02 DHCP Advertise 02 DHCP Advertise
The DHCP Advertise is an IP unicast message from a DHCP Agent The DHCP Advertise is an IP unicast message sent by a DHCP
in response to a client DHCP Solicit message. Agent in response to a DHCP client's 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 sent by a DHCP client
server to request configuration parameters on a network. to a DHCP 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 DHCP server
respond to a client's DHCP Request. Extensions [11] to the in response to a client's DHCP Request, or by the DHCP relay
DHCP Reply describe the resources that the DHCP Server has that relayed that client's DHCP Request. Extensions [12] to
committed and allocated to the client, and may contain other the DHCP Reply describe the resources that the DHCP server has
information for use by the client. committed and allocated to this client, and may contain other
information for use by this client.
05 DHCP Release 05 DHCP Release
The DHCP Release message is used by a DHCP client to inform The DHCP Release is an IP unicast message sent by a DHCP
the server that the client is releasing a particular address, client to inform the DHCP server that the client is releasing
or set of addresses or resources, so that the server may resources.
subsequently mark the addresses as invalid, or release
resources in the server's binding for the client.
06 DHCP Reconfigure 06 DHCP Reconfigure
The DHCP Reconfigure message is used by a DHCP server to inform The DHCP Reconfigure is an IP unicast or multicast message sent
its client that the server has new configuration information of by a DHCP server to inform one or more clients that the server
importance to the client. The client is expected to initiate a has new configuration information of importance. Each client
new Request/Reply transaction. is expected to initiate a new Request/Reply transaction.
DHCP message types not defined here (msg-types 0 and 7-255) are
reserved and SHOULD be silently ignored.
3.3. Request/Response Processing Model 3.3. Request/Response Processing Model
The request/response processing for DHCPv6 is transaction based The request/response processing for DHCPv6 is transaction based and
and uses a best-effort set of messages to guarantee a completed uses a set of best-effort messages to complete the transaction.
transaction.
Transactions are usually started by a client with a DHCP Request, To find a server, a client sends a DHCP Solicit message from the
which may be issued after the client knows the server's address. interface which it wishes to configure. The client then awaits
The response (DHCP Reply) is from the server (possibly via a DHCP a DHCP Advertise message, which will provide an IP address of a
Relay). At this point in the flow all data has been transmitted DHCP server. Transactions are started by a client with a DHCP
and, hopefully, received. To provide a method of recovery if either Request, which may be issued after the client knows the server's
the client or server do not receive the messages to complete the address. The response (DHCP Reply) is sent from the server (possibly
transaction, the client is required to retransmit any DHCP Request via a DHCP Relay). At this point in the flow all data has been
message until it elicits the corresponding DHCP Reply or Replies, transmitted and is presumed to have been received. To provide a
or until it can be reasonably certain that the desired DHCP Server method of recovery if either the client or server do not receive the
is unavailable. The timeout and retransmission guidelines and messages to complete the transaction, the client retransmits each
configuration variables are discussed in Section 8. DHCP uses the DHCP Request message until it elicits the corresponding DHCP Reply,
UDP [13] protocol to communicate between clients and servers. UDP is or until it can be reasonably certain that the desired DHCP server
not reliable, but DHCP the retransmission scheme in the referenced is unavailable, or it determines that it does not want a response
section provides reliability between clients and servers. (i.e., it MAY abort the transaction). The timeout and retransmission
guidelines and configuration variables are discussed in Section 8.
The following well-known multicast addresses are used by DHCP Agents: DHCP uses the UDP [14] protocol to communicate between clients and
servers. UDP is not reliable, but the DHCP retransmission scheme
in the referenced section provides reliability between clients and
servers. The following well-known multicast addresses are used by
DHCP agents and clients:
FF02:0:0:0:0:0:1:2 FF02:0:0:0:0:0:1:2
All DHCP Agents (Servers and Relays) MUST join the All DHCP Agents (Servers and Relays) MUST join the
link-local All-DHCP-Agents multicast group at the address link-local All-DHCP-Agents multicast group at the address
FF02:0:0:0:0:0:1:2. FF02:0:0:0:0:0:1:2.
FF05:0:0:0:0:0:1:3 FF05:0:0:0:0:0:1:3
All DHCP Servers MUST, in addition, join the site-local All DHCP servers MUST join the site-local
All-DHCP-Servers multicast group at the address All-DHCP-Servers multicast group at the address
FF05:0:0:0:0:0:1:3. FF05:0:0:0:0:0:1:3.
FF05:0:0:0:0:0:1:4 FF05:0:0:0:0:0:1:4
All DHCP Relays MUST, on the other hand, join in addition All DHCP Relays MUST join the site-local All-DHCP-Relays
the site-local All-DHCP-Relays multicast group at the multicast group at the address FF05:0:0:0:0:0:1:4.
address FF05:0:0:0:0:0:1:4.
A client MUST transmit all messages over UDP using port 547 as the A DHCP server or agent MUST transmit all messages to DHCP clients on
destination port. A client MUST receive all messages from UDP port UDP port 546. A DHCP client MUST transmit all messages to a DHCP
546. agent over UDP using port 547. A DHCP server MUST transmit all
messages to DHCP Relays over UDP on port 546. The source port for
DHCP messages is arbitrary.
A DHCP Agent MUST transmit all messages to clients over UDP using For the proper operation of the DHCP protocol to operate within a
port 546 as the destination port. A DHCP Agent MUST receive all network where one or more firewalls [4] are used, DHCP transactions
messages over UDP using port 547. The source port for DHCP messages using UDP destination ports 546 and 547 will need to be permitted.
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. All reserved
types not defined here (msg-types 0 and 7-255) are reserved. fields in a message MUST be ignored by the receiver of the message.
4.1. DHCP Solicit Message Format 4.1. DHCP Solicit Message Format
A DHCP client (or DHCP relay on behalf of a client) transmits a DHCP A DHCP client transmits a DHCP Solicit message over the interface it
Solicit message to obtain one or more DHCP server addresses. is trying to configure, to obtain one or more DHCP server addresses.
In the event that there is no DHCP server on this link, such a
request MAY be forwarded by a DHCP relay attached to this link (if
such a relay exists) on behalf of a client to a DHCP server.
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|A| reserved | | msg-type |C| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay address | | relay address |
| (16 octets, if present) | | (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.
A If set, the relay's address is present
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 nonzero, the IP address of the interface on which
the relay received the client's DHCP Solicit message the relay received the client's DHCP Solicit message
To discover a DHCP Agent address a DHCP client SHOULD send a DHCP To obtain a DHCP Agent address a DHCP client SHOULD send a DHCP
Solicit message to the All-DHCP-Agents multicast address (see Solicit message to the All-DHCP-Agents multicast address (see
section 3.3). Any DHCP Relay receiving the solicitation MUST forward section 3.3). Any DHCP Relay receiving the solicitation MUST forward
it to the All-DHCP-Servers multicast address, to instruct DHCP it to the All-DHCP-Servers multicast address, to instruct DHCP
Servers to send their advertisements to the prospective client. In servers to send their advertisements to the prospective client.
that case, the relay MUST insert the address of its interface from In that case, the relay MUST copy a non-link-local address of its
which the client's solicitation was received into the agent's address interface from which the client's solicitation was received into the
field, and set the 'A' bit. relay address field.
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |S| reserved | | msg-type |S|P| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address | | server preference (if present) |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server address | | server address |
| (16 octets, if present) | | (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ... | extensions (variable number and length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 2 msg-type 2
S If set, the agent address is also a server address. S If set, the server address is present.
P If set, the server preference is present.
reserved 0 reserved 0
agent address server preference
The IP address of a DHCP Agent interface on the same A 32-bit unsigned integer indicating a server's
link as the client. willingness to provide service to the client.
client's link-local address client's link-local address
The IP link-local address of the client interface The IP link-local address of the client interface
from which the client issued the DHCP Request message from which the client issued the DHCP Request message
agent address
The IP address of a DHCP Agent interface on the same
link as the client.
server address server address
The IP address of the DHCP server If present, the IP address of the DHCP server
extensions See [11]. extensions See [12].
Suppose that a DHCP server on the same link as a client issues the Suppose that a DHCP server on the same link as a client issues the
DHCP Advertise in response to a DHCP Solicit message sent to the DHCP Advertise in response to a DHCP Solicit message sent to the
All-DHCP-Agents multicast address. Then the agent address will be All-DHCP-Agents multicast address. Then the agent address will be an
the IP address of one of the server's interfaces, the 'S' bit will be IP address of one of the server's interfaces on the same link as the
set, the agent address will be an address of the server, and there client, and the 'S' bit will be set to zero. No server address will
will be no server address sent in the DHCP Advertise message. be present in the DHCP Advertise message.
The DHCP Server MUST copy the client's link-local address into the If the 'P' bit is set, the server preference field is present. If
the 'P' bit is not set, the server preference field is not present,
but implicitly has the value of 0xffffffff (in other words, the
highest possible value).
The DHCP server MUST copy the client's link-local address into the
advertisement which is sent in response to a DHCP Solicit. Both advertisement which is sent in response to a DHCP Solicit. Both
Agent address and server address (if present) of the DHCP Advertise agent address and server address (if present) of the DHCP Advertise
message MUST have sufficient scope to be reachable by the DHCP message MUST have sufficient scope to be reachable by the DHCP
Client. Moreover, the Agent address of any DHCP Advertise message client. Moreover, the Agent address of any DHCP Advertise message
sent by a DHCP relay MUST NOT be a link-local address. In situations sent by a DHCP relay MUST NOT be a link-local address. In situations
where there are no routers sending Router Advertisements, then a DHCP where there are no routers sending Router Advertisements, then a DHCP
Server MUST be configured on the same link as prospective clients. server MUST be configured on the same link as prospective clients.
The DHCPv6 protocol design does not apply to sitations where the The DHCPv6 protocol design does not apply to situations where the
client has no way to route messages to a server not on the same link client has no way to route messages to a server not on the same link.
See section 5.3 for information about how clients handle the server
preference field.
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 configuration parameters from a DHCP server, a
DHCP Request message, and MAY append extensions [11]. If the client client sends a DHCP Request message, and MAY append extensions [12].
does not know any DHCP server address, it MUST first obtain a server If the client does not know any DHCP server address, it MUST first
address by multicasting a DHCP Solicit message (see Section 4.1). If obtain a server address by multicasting a DHCP Solicit message (see
the client does not have a valid IP address of sufficient scope for Section 4.1). If the client does not have a valid IP address of
the DHCP server to communicate with the client, client MUST send the sufficient scope for the DHCP server to communicate with the client,
message to the local DHCP Relay and insert the DHCP Relay address as the client MUST send the message to the local DHCP relay and insert
the agent address in the message header. In this case, the client the DHCP relay address as the agent address in the message header.
cannot send the message directly to the DHCP server because the In this case, the client cannot send the message directly to the
server could not return any response to the client. Otherwise, the DHCP server because the server could not return any response to the
client MAY omit the server address in the DHCP Request message; in client. Otherwise, the client MAY omit the server address in the
this case, the client MUST send the DHCP Request message directly to DHCP Request message; in this case, the client MUST clear the S-bit
the server, using the server address as the IP destination address in in the DHCP Request message and send it directly to to the server,
the IP header. using the server address as the IP destination address in the IP
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 |C|S|R|N| rsvd | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server address | | client's link-local address |
| (16 octets, if present) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address | | agent address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | server address |
| (16 octets) | | (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 3 msg-type 3
C If set, the client requests the server to remove all
resources associated with the client binding, except
those resources provided as extensions.
S If set, the server address is present S If set, the server address is present
R If set, the client has rebooted and requests that all
of its previous transaction IDs be expunged and made
available for re-use.
C If set, the client requests the server to clear all N If set, the client has begun operating in stateless
other existing resources and bindings (not requested address autoconfiguration.
in extensions) currently associated with the client,
deallocating as needed.
reserved 0 rsvd 0
transaction-ID transaction-ID
A monotonically increasing number used to identify this A monotonically increasing unsigned integer used to
Request, and copied into the Reply. identify this Request, and copied into the Reply.
server address client's link-local address
If present, the IP address of the DHCP server which The IP link-local address of the client interface from
should receive the client's DHCP Request message. which the client issued the DHCP Request message
agent address agent address
The IP address of an agent interface, copied from a The IP address of an agent's interface, copied from a
DHCP Advertisement message. DHCP Advertisement message.
client's link-local address server address
The IP link-local address of the client interface from If present, the IP address of the DHCP server which
which the client issued the DHCP Request message should receive the client's DHCP Request message.
extensions See [11]. extensions See [12].
4.4. DHCP Reply Message Format 4.4. DHCP Reply Message Format
The server sends one DHCP Reply message in response to every DHCP The server sends one DHCP Reply message in response to every DHCP
Request or DHCP Release received. If the request comes with the 'S' Request or DHCP Release received. If the request comes with the 'S'
bit set, the client could not directly send the Request to the server bit set, the client could not directly send the Request to the server
and had to use a neighboring relay agent. In that case, the server and had to use a neighboring relay agent. In that case, the server
sends back the DHCP Reply with the 'L' bit set, and the DHCP Reply is sends back the DHCP Reply with the 'L' bit set, and the DHCP Reply is
addressed to the agent address found in the DHCP Request message. If addressed to the agent address found in the DHCP Request message. If
the 'L' bit is set, then the client's link-local address will also be the 'L' bit is set, then the client's link-local address will also be
present. present.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |L| error code | transaction-ID | | msg-type |L| status | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | client's link-local address |
| (16 octets, if present) | | (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 4 msg-type 4
L If set, the link-local address is present L If set, the client's link-local address is present
error code status One of the following decimal 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 or Release 18 Poorly formed Request or Release
19 Resources unavailable 19 Resources unavailable
20 Client record unavailable 20 Client record unavailable
21 Invalid client IP address in Release 21 Invalid client IP address in Release
23 Relay cannot find Server Address 23 Relay cannot find Server Address
24 Cannot understand selected Character Set 24 Cannot understand selected Character Set
64 Server unreachable (ICMP error) 64 Server unreachable (ICMP error)
transaction-ID transaction-ID
A monotonically increasing number used to identify this A monotonically increasing unsigned integer used to
Reply, and copied from the client's Request. identify this 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 [11]. See [12].
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 the message, and the relay uses the link-local address to deliver the
Reply message to the client. Reply message to the client.
4.5. DHCP Release Message Format 4.5. DHCP Release Message Format
The DHCP Release message is sent without the assistance of any DHCP The DHCP Release message is sent without the assistance of any DHCP
relay. When a client sends a Release message, it is assumed to relay. When a client sends a Release message, it is assumed to have
have a valid IP address with sufficient scope to allow access to a valid IP address with sufficient scope to allow access to the
the target server. Only the parameters which are specified in the target server. If parameters are specified in the extensions, only
extensions are released. The DHCP server acknowledges the Release those parameters are released. The DHCP server acknowledges the
message by sending a DHCP Reply (Sections 4.4, 6.3). Release message by sending a DHCP Reply (Sections 4.4, 6.3).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |D| reserved | transaction-ID | | msg-type |D| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address | | client's link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | agent address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client address | | client address |
| (16 octets, if present) | | (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 5 msg-type 5
D If the 'D' ("Direct") flag is set, the client instructs D If the 'D' ("Direct") flag is set, the client instructs
the server to send the DHCP Reply directly back to the the server to send the DHCP Reply directly back to the
client, instead of using the given agent address and client, instead of using the given agent address and
link-local address to relay the Reply message. link-local address to relay the Reply message.
reserved 0 reserved 0
transaction-ID transaction-ID
A monotonically increasing number used to identify this A monotonically increasing unsigned integer used to
Release, and copied into the Reply. identify this Release, and copied into the Reply.
agent address
The IP address of the agent interface to which the
client issued the DHCP Request 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 the client issued the DHCP Request message which the the client issued the DHCP Release message
agent address
The IP address of the agent interface to which the
client issued a previous 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 Release 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 [11] extensions See [12]
Suppose that the client has an IP address that will still be valid Suppose that the client has an IP address that will still be valid
after the server performs the operations requested in the extensions after the server performs the operations requested in the extensions
to the DHCP Release message. In that case, and only then, the client to the DHCP Release message, and which has sufficient scope to be
SHOULD then specify the 'D' flag. When the 'D' flag is set, the reachable from the server. In that case, and only then, the client
server MUST send the DHCP Reply back to the client's address as shown SHOULD set the 'D' flag. When the 'D' flag is set, the server MUST
in the client address field of the Release message. Otherwise, when send the DHCP Reply back to the client using the client address field
the 'D' bit is not set, the server MUST send its DHCP Reply message of the Release message. Otherwise, when the 'D' bit is not set, the
to the agent address in the Release message, so that the relay agent server MUST send its DHCP Reply message to the agent address in the
can subsequently forward the Reply back to the releasing client at Release message, so that the relay agent can subsequently forward the
the client's link-local address indicated in the Reply message. Reply back to the releasing client at the client's link-local address
Note that it is an error (Error Code 21) to include within the DHCP indicated in the Reply message. Note that it is an error (status
Release message both the 'D' bit and an IP address extension which code 21) to include within the DHCP Release message both the 'D' bit
has the IP address used as the client IP address field of the DHCP and an IP address extension which has the IP address used as the
Release message header. client IP address field of the DHCP Release message header. If the
clients link-local address and agent address do not match a client
binding (see section 6) an error (status code 20) will be returned to
the client.
4.6. DHCP Reconfigure Message Format 4.6. DHCP Reconfigure Message Format
The DHCP Reconfigure message is sent without the assistance of any Reconfigure messages can only be sent to clients which have
DHCP relay. When a server sends a Reconfigure message, the client established an IP address which routes to the link at which they are
to which it is sent is assumed to have a valid IP address with reachable, hence the DHCP Reconfigure message is sent without the
sufficient scope to be accessible by the server. Only the parameters assistance of any DHCP relay. When a server sends a Reconfigure
which are specified in the extensions to the Reconfigure message need message, the client to which it is sent is assumed to have a valid
be requested again by the client. IP address with sufficient scope to be accessible by the server.
Reconfigure messages can only be sent to clients which are reachable
by the DHCP server. Hence, the DHCP Reconfigure message is sent
without the assistance of any DHCP relay. Only the parameters which
are specified in the extensions to the Reconfigure message need be
requested again by the client. A Reconfigure message can either be
unicast or multicast by the server.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | reserved | transaction-ID | | msg-type |N| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server address | | server address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 6 msg-type 6
N The 'N' flag indicates that the client should not
expect a DHCP Reply in response to the DHCP Request
it sends as a result of the DHCP Reconfigure message.
reserved 0 reserved 0
transaction-ID transaction-ID
A monotonically increasing number used to identify A monotonically increasing unsigned integer used to
this Reconfigure message, and copied into the identify this Reconfigure message, and copied into
client's Request. the 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 [11] extensions See [12]
5. DHCP Client Considerations 5. DHCP Client Considerations
A DHCP client MUST silently discard any DHCP Solicit, DHCP Request, A node which is not a DHCP agent MUST silently discard any DHCP
or DHCP Release message it receives. Solicit, DHCP Request, or DHCP Release message it receives.
5.1. Verifying Resource Allocations After Restarts 5.1. Verifying Resource Allocations After Restarts
A 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 after
client may still use any resources whose lifetimes have not yet REPLY_MSG_MIN_RETRANS (see section 8), the client may still use any
expired. In such cases, however, the client MUST begin to search resources whose lifetimes have not yet expired. In such cases,
for another server by multicasting a new DHCP Solicit message, again however, the client MUST begin to search for another server by
with the 'C' bit set, containing its IP address in the appropriate multicasting a new DHCP Solicit message, again with the 'C' bit set.
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, where its IP address is no longer valid. In this situation,
multicasts a new DHCP Discover message, servers will respond with when the client receives a new IP address and the old IP address
the information needed for the client to release its old address, if is no longer needed, the client MUST release its old IP address by
need be, and request an address reachable on the new network. In issuing a DHCP Release message with the appropriate extension if it
this situation, when the client receives a new IP address and the old can communicate with its previous server.
IP address is no longer reachable, the client MUST release its old
IP address by issuing a DHCP Release message with the appropriate
extension.
5.2. Sending DHCP Solicit Messages 5.2. Sending DHCP Solicit Messages
A DHCP client MUST have the address of a DHCP Server to send a A DHCP client MUST have the address of a DHCP server to send
Request message. The client may locate a DHCP Server by multicasting a Request message. The client SHOULD locate a DHCP server by
a DHCP Solicit message to the All-DHCP-Agents link-local multicast multicasting a DHCP Solicit message to the All-DHCP-Agents link-local
address, setting the Hop Limit == 1 (see Section 3.3). If there multicast address, setting the Hop Limit == 1 (see Section 3.3).
are no DHCP servers on the same link as the node, then a DHCP Relay If there are no DHCP servers on the same link as the node, then a
MUST be present for further handling of the solicitation. The DHCP relay MUST be present if solicitations sent from a client's
prospective client SHOULD wait for ADV_WAIT seconds to get all the link-local address are to be handled. The prospective client SHOULD
DHCP Advertisement messages which may be sent in response to the wait for ADV_CLIENT_WAIT to get all the DHCP Advertisement messages
solicitation. which may be sent in response to the solicitation.
When sending a DHCP Solicit message, a client MUST set the Relay
Address field to 16 octets of zeros.
If a DHCP client reboots and does not have a valid IP address, If a DHCP client reboots and does not have a valid IP address,
it MUST set the 'C' bit in the DHCP Solicit message it sends it MUST set the 'C' bit in the DHCP Solicit message it sends
when restarting. By setting the 'C' bit in the solicitation, a when restarting. By setting the 'C' bit in the solicitation, a
DHCP client requests that all the DHCP Servers that receive the DHCP client requests that all the DHCP servers that receive the
solicitation should clean up their stale client records that match solicitation should clean up their client records that match its
its link-local address. link-local address. The server MUST take the Relay Address Field and
use it as the agent address prefix to locate the client binding (see
section 6.0 for server bindings).
If a client sends a DHCP Solicit message after it reboots, the If a client sends a DHCP Solicit message after it reboots, the
solicitation SHOULD be delayed after reception of the first Router solicitation SHOULD be delayed after reception of the first Router
Advertisement [10] message, by at least some random amount of time Advertisement [11] message, by at least some random amount of time
between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds. This delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see section 8
is intended to help stagger requests to DHCP Servers (and avoid seconds. This delay is intended to help stagger requests to DHCP
link-layer collisions) after a power outage causes many nodes to servers (and avoid link-layer collisions) after a power outage
reboot all at once. Each subsequent DHCP Solicit message that is causes many nodes to reboot all at once. Each subsequent DHCP
issued before receiving an advertisement MUST be delayed by twice the Solicit message that is issued before receiving an advertisement
amount by which the previous DHCP Solicit message was delayed, plus MUST be delayed by twice the amount by which the previous DHCP
a small random delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY Solicit message was delayed, plus a small random delay between
seconds. MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds.
5.3. Receiving DHCP Advertise Messages 5.3. Receiving DHCP Advertise Messages
After a DHCP Client has received a DHCP Advertise message, it has After a DHCP client has received a DHCP Advertise message, it has the
the address of a DHCP Server for subsequent DHCP Request messages. address of a DHCP server for subsequent DHCP Request messages. If
If the Advertise message has no server address field and does the 'S' bit is zero, the DHCP Advertise message was transmitted by
not have the 'S' bit set, the client MUST silently discard the a DHCP server on the same link as the client, and the client uses
message. If the server's address is shown as a Multicast address, the Agent address as the address of a DHCP server; otherwise, the
the advertisement MUST be silently discarded. DHCP server address is located in the server address field. If the
server's address is shown as a Multicast address, the advertisement
MUST be silently discarded.
If the 'S' bit is set, the DHCP Advertise message was transmitted A DHCP server MAY append extensions to its Advertisements; this might
by a DHCP server on the same link as the client. In this case, any allow the DHCP client to select the configuration that best meets its
future DHCP message transactions sent to that server MUST be sent by needs from among several prospective servers.
the client to the agent address indicated by the 'S' bit.
Advertisements may have extensions; this might allow the DHCP client Unless a DHCP Advertisement is received with a "server preference"
to select the configuration that best meets its needs from among field of 0xffffffff, a DHCP client must wait ADV_CLIENT_WAIT seconds
several prospective servers. after issuing the DHCP Solicit message in order to receive the
Advertisement with the highest preference. After waiting for that
period of time, a client MUST select the highest preference DHCP
server as the target of its DHCP request. If a DHCP client receives
an advertised preference of 0xffffffff, it does not have to wait for
any more advertisements.
If a DHCP client sends a DHCP Request to a highly preferred DHCP
server but fails to receive a DHCP reply from that server after
following the retransmission algorithm in section 8, the client may
subsequently attempt to send a DHCP Request to a less preferred
server.
A DHCP client is free to cache the result of any DHCP Advertisement
it hears. However, it should be noted that this is purely a
potential performance enhancement as the results need not be constant
over time, hence it may not get a response if it uses the address
obtained from this message and may have to emit its own DHCP Solicit
message subsequently.
5.4. Sending DHCP Request Messages 5.4. Sending DHCP Request Messages
A DHCP client obtains configuration information from a DHCP server by A DHCP client obtains configuration information from a DHCP server by
sending a DHCP Request message. The client MUST know the server's sending a DHCP Request message. The client MUST know the server's
address before sending the Request message, and client MUST have address before sending the Request message, and the client MUST
acquired a (possibly identical) DHCP agent address. If the client have acquired a (possibly identical) DHCP agent address. If the
and server are on the same link, the agent address used by the client client and server are on the same link, the agent address used by the
MUST be the same as the DHCP server's address. A DHCP Request client MUST be the same as the DHCP server's address. A DHCP Request
message MUST NOT be sent to any multicast address, since otherwise 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 packets were lost
lost due to collisions, etc. due to collisions, etc.
If the client has no valid IP address of sufficient scope, and the If the DHCP server is off-link, and the client has no valid IP
DHCP server is off-link, then the client MUST include the server address of sufficient scope, then the client MUST include the server
address in the appropriate field of the DHCP Request message and set address in the appropriate field and set the 'S' bit in the DHCP
the 'S' bit. In this case, the IP destination address of the Request Request message. In this case, the IP destination address in the IP
message will be a DHCP relay address. header will be a DHCP relay address.
Otherwise, if the client already has a valid IP address of sufficient Otherwise, if the client already has a valid IP address of sufficient
scope and knows the IP address of a candidate DHCP server, it scope and knows the IP address of a candidate DHCP server, it
SHOULD send the Request message directly to the DHCP server without MUST send the Request message directly to the DHCP server without
requiring the services of the local DHCP relay. requiring the services of the local DHCP relay.
If a client wishes to instruct a DHCP server to deallocate all If a client wishes to instruct a DHCP server to deallocate all
unknown previous resources, configuration information, and bindings unknown previous resources, configuration information, and bindings
associated with its agent address and link-local address, it sets the associated with its agent address and link-local address, it sets the
'C' bit in the DHCP Request. A client MAY send in such a Request 'C' bit in the DHCP Request. A client MAY send in such a Request
even when it is no longer attached to the link on which the relay even when it is no longer attached to the link on which the relay
address is attached. address is attached. The 'C' bit allows better reclamation of
available resources, since otherwise a client might not be able to
release resources that it has no record of using.
In any case, after choosing a transaction-ID which is numerically In any case, after choosing a transaction-ID which is numerically
greater than its previous transaction-ID, and filling in the greater than its previous transaction-ID, and filling in the
appropriate fields of the DHCP Request message, the client MAY append appropriate fields of the DHCP Request message, the client MAY append
various DHCP Extensions to the message. These extensions denote various DHCP Extensions to the message. These extensions denote
specific requests by the client; for example, a client may request specific requests by the client; for example, a client may request
a particular IP address, or request that the server send an update a particular IP address, or request that the server send an update
containing the client's new IP address to a Domain Name Server. When containing the client's new IP address to a Domain Name Server. When
all desired extensions have been applied, the DHCP client unicasts all desired extensions have been applied, the DHCP client sends the
the DHCP Request to the appropriate DHCP Agent. DHCP Request to the appropriate DHCP Agent.
For each pending DHCP Request message, a client MUST maintain the For each pending DHCP Request message, a client MUST maintain the
following information: following information:
- The transaction-ID of the request message, - The transaction-ID of the request message,
- The server address, - The server address,
- The agent address (which can be the same as the server address), - The agent address (which can be the same as the server 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.5) with If a client does not receive a DHCP Reply message (Section 5.5) with
the same transaction-ID as a pending DHCP Request message within the same transaction-ID as a pending DHCP Request message within
REPLY_MSG_INITIAL_TIMEOUT seconds, or if the received DHCP Reply REPLY_MSG_TIMEOUT (see section 8) seconds, or if the received DHCP
message contains a DHCP Authentication extension which fails to Reply message contains a DHCP Authentication extension which fails
provide the correct authentication information, the client MUST to provide the correct authentication information, the client MUST
retransmit the Request with the same transaction-ID and continue to retransmit the Request with the same transaction-ID and continue to
retransmit according to the rules in Section 8. retransmit according to the rules in Section 8. If (after following
those rules) the client never receives a Reply message, it naturally
SHOULD start over again by sending a new DHCP Solicit message to find
a different server.
If the client receives an ICMP error message in response to such
a DHCP Request, it likewise naturally SHOULD start over again by
sending a new DHCP Solicit message, to find a different server.
If the client transmits a DHCP Request in response to a DHCP If the client transmits a DHCP Request in response to a DHCP
Reconfigure message (see Section5.7), 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. When the 'N' bit is set, a DHCP Request sent in
response to a DHCP Reconfigure message will not elicit a DHCP Reply
message from the server.
5.5. Receiving DHCP Reply Messages 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 [11], extracting the relevant configuration information Extension [12], 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 UDP
Length field of the Reply. Some extensions in the Reply may have Length field of the Reply. Some extensions in the Reply may have
error codes, when the server was unable to honor the request, which status codes, which indicate to the client the reason for failure
will indicate to the client the reason for failure. If the server is when the server was unable to honor the request. If the server is
unable to honor the request in an extension included by the client, unable to honor the request in an extension included by the client,
that extension may simply be omitted from the Reply. that extension may simply be omitted from the Reply. The server MAY
also provide the client with configuration parameters the client did
not specifically request.
Some configuration information extracted from the extensions to the 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 [11]. These "resource-server" associations are Extensions document [12]. These "resource-server" associations are
used when sending DHCP Release messages. used when sending DHCP Release messages.
5.6. Sending DHCP Release Messages 5.6. Sending DHCP Release Messages
If a DHCP client determines that some of its network configuration If a client wishes to ask the server to release all information and
parameters are no longer needed, it SHOULD enable the DHCP server to resources relevant to the client, the client SHOULD send a DHCP
release allocated resources which are no longer in use by sending a Release message without any extensions; this is preferable to sending
DHCP Release message to the server. The client consults its list a DHCP Request message with the 'C' bit set and no extensions. If
of resource-server associations in order to determine which server a DHCP client wishes to retain some of its network configuration
should receive the desired Release message. If a client wishes to parameters, but determines that others are no longer needed, it
ask the server to release all information and resources relevant to SHOULD enable the DHCP server to release allocated resources which
the client, the client specifies no extensions; this is preferable are no longer in use by sending a DHCP Release message to the
to sending a DHCP Request message with the 'C' bit set and no server, and including extensions to identify the unneeded items. The
extensions. client consults its list of resource-server associations in order to
determine which server should receive the desired Release message.
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, and the client has an IP address with enough
server to send the DHCP Reply directly back to the client, instead scope so that the DHCP server can reach it. In that case, the client
of performing the default processing of sending the DHCP Reply back MUST instruct the server to send the DHCP Reply directly back to the
through the agent-address included in the DHCP Release. This is done client at that address, instead of performing the default processing
by setting the 'D' bit in the DHCP Release message (see section 4.5). of sending the DHCP Reply back through the agent-address included in
the DHCP Release. This is done by setting the 'D' bit in the DHCP
Release message (see section 4.5).
5.7. 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 implementation MUST support listening at UDP port
DHCP Reconfigure messages, except in cases where the client knows 546 to receive possible DHCP Reconfigure messages; in cases where the
that no Reconfigure message will ever be issued. In some cases, client knows that no Reconfigure message will ever be issued, the
the IP address at which the client listens will be a multicast client MAY be configured to avoid executing this supported feature.
address sent to the client by the DHCP server in an extension to In some cases, the IP address at which the client listens will be
an earlier DHCP Reply message. If the client does not listen for a multicast address sent to the client by the DHCP server in an
DHCP Reconfigure messages, it is possible that the client will extension to an earlier DHCP Reply message. If the client does not
not receive notification that its DHCP server has deallocated the listen for DHCP Reconfigure messages, it is possible that the client
client's IP address and/or other resources allocated to the client. will not receive notification that its DHCP server has deallocated
See discussion in 6.5. The client MAY receive an update to the the client's IP address and/or other resources allocated to the
prefix for their addresses and then MUST use that prefix for their client. See discussion in 6.5. The client MAY receive a prefix
addresses. update for one or more of their addresses and then MUST use that
prefix for those addresses.
If a DHCP client receives a DHCP Reconfigure message, it is a request If a DHCP client receives a DHCP Reconfigure message, it is a request
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 MUST append a matching Extension to its Request message, which
it formulates to send to the server specified in the server address it formulates to send to the server specified in the server address
field of the message. The client also copies a transaction-ID from field of the message. The client also copies a transaction-ID from
the Reconfigure message into the Request message. From then on, the Reconfigure message into the Request message. If the 'N' bit is
processing is the same as specified above in Section 5.4. not set, processing from then on 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 (see
will minimize the likelihood that the server will be bombarded with section 8). This will minimize the likelihood that the server will
DHCP Request messages all at the same time. be flooded with DHCP Request messages.
5.8. Interaction with Stateless Address Autoconfiguration
If a client begins to receive Router Advertisements [11] with the 'M'
bit no longer set (so that the link is no longer a "managed" link),
then the client SHOULD send one or more DHCP Release messages to
deallocate the IP addresses it has received. The client sends the
DHCP Release messages to the servers recorded in the resource-server
associations maintained for the IP addresses.
If a client is receiving Router Advertisements with the 'M' bit equal
to 0, then it is using IP addresses obtained by way of Stateless
Address Autoconfiguration [16]. In this case, if the client receives
a DHCP Reconfigure message, the client MUST return a DHCP Request
message to the DHCP server with the 'N' bit set.
Suppose a client, after using Stateless Address Autoconfiguration
to configure its stateless IP address, begins to receive Router
Advertisements with the 'M' bit set. Then the client MAY continue
to use its existing IP addresses, but it MUST send a DHCP Solicit
message to discover a DHCP server. If the solicitation results in
the receipt of of a DHCP Advertisement message from a DHCP server,
the client MUST subsequently transact a DHCP Request message with at
least one such DHCP server.
6. DHCP Server Considerations 6. DHCP Server Considerations
A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP A node which is not a DHCP client or DHCP relay MUST ignore any DHCP
Reconfigure message it receives. Advertise, DHCP Reply, or DHCP Reconfigure message it receives.
A server maintains a collection of client records, called A server maintains a collection of client records, called
``bindings''. Each binding is uniquely identifiable by the ordered ``bindings''. Each binding is uniquely identifiable by the ordered
pair <link-local address, agent address>, since the link-local pair <link-local address, agent address prefix>, since the link-local
address is guaranteed to be unique [15] on the link identified address is guaranteed to be unique [16] on the link identified by the
by the agent address. An implementation MUST support bindings agent address. An implementation MUST support bindings consisting
consisting of at least a client's link-local address, agent address, of at least a client's link-local address, agent address prefix,
preferred lifetime and valid lifetime [15] for each client address, preferred lifetime and valid lifetime [16] for each client address,
and the transaction-ID. A client binding may be used to store any 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.
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
agent address is present, and not a link-local address. Otherwise, relay address is present, and not a link-local address. If the
if the agent address is not present, or if it is a link-local relay address is not present, or if it is a link-local address,
address, the server MUST silently discard the packet. If the UDP the server MUST silently discard the packet. Note that if the
length disagrees with the length determined by the format of the client sends a DHCP Solicit message from a link-local address, the
DHCP Solicit message, the server MUST drop the packet and SHOULD log multicast destination will be the All-DHCP-Agents address, not the
the error. Note that if the client sends a DHCP Solicit message All-DHCP-Servers address.
from a link-local address, the multicast destination will be the
All-DHCP-Agents address, not the All-DHCP-Servers address. As an optimization, a server processing a Solicit message from relays
MAY check the prefix of the IP source address in the IP header to
determine whether the server has received the Solicit from multiple
relays on the same link.
6.2. Sending DHCP Advertise Messages 6.2. Sending DHCP Advertise Messages
Upon receiving and verifying the correctness of a DHCP Solicit Upon receiving and verifying the correctness of a DHCP Solicit
message, a server constructs a DHCP Advertise message and transmits message, a server constructs a DHCP Advertise message and transmits
it on the same link as the solicitation was received from. If the it on the same link as the solicitation was received from. When
'A' bit is set, the advertisement MUST be sent to the relay address; the solicitation is received at the DHCP Servers multicast address,
otherwise, the server MUST send the advertisement to the client's the server SHOULD delay the transmission of its advertisement
link-local address. An IP address of the interface on which the for a random amount of time between SERVER_MIN_ADV_DELAY and
server receives the Solicit message MUST appear in the server address SERVER_MAX_ADV_DELAY (see section 8).
field of the corresponding advertisement.
If the relay address is nonzero, the server MUST put the relay
address in the agent address field of the advertisement message, and
MUST send the advertisement message to the relay address; otherwise,
the server MUST send the advertisement to the client's link-local
address. An IP address of the interface on which the server received
the Solicit message MUST appear in the server address field of the
corresponding advertisement.
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 Message Processing 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 a link-local address. address field of the Request message contains a link-local address.
If not, the message MUST be silently discarded. Otherwise, it checks If not, the message MUST be silently discarded. If the 'S' bit
for the presence of the 'S' bit. If the 'S' bit is set, the server is set, the server MUST check that the server address matches the
MUST check that the server address matches the destination IP address destination IP address at which the Request message was received
at which the Request message was received by the server. If the by the server. If the server address does not match, the Request
server address does not match, the Request message MUST be silently 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 correspond to any binding known to the server, then the server
MAY create a new binding for the previously unknown client, and MAY create a new binding for the previously unknown client, and
send a DHCP Reply with any resources allocated to the new binding. send a DHCP Reply with any resources allocated to the new binding.
Otherwise, it SHOULD return a DHCP Reply with an error code of 19. Otherwise, if the server cannot create a new binding, it SHOULD
return a DHCP Reply with a status of 20. If the client is updating
its resources but the database is temporarily unavailable, the server
SHOULD return a DHCP Reply with a status 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.
skipping to change at page 22, line 28 skipping to change at page 24, line 27
with the same transaction-ID, the server identifies and allocates with the same transaction-ID, the server identifies and allocates
all the relevant information, resources, and configuration data that all the relevant information, resources, and configuration data that
is associated with the client. Then it sends that information to is associated with the client. Then it sends that information to
its DHCP client by constructing a DHCP Reply message and including its DHCP client by constructing a DHCP Reply message and including
the client's information in DHCP Extensions to the Reply message. the client's information in DHCP Extensions to the Reply message.
The DHCP Reply message uses the same transaction-ID as found in the The DHCP Reply message uses the same transaction-ID as found in the
received DHCP Request message. Note that the reply message MAY received DHCP Request message. Note that the reply message MAY
contain information not specifically requested by the client. contain information not specifically requested by the client.
If the DHCP Request message has the 'S' bit set in the message If the DHCP Request message has the 'S' bit set in the message
header, then the Request was sent to the server by a DHCP Relay. In header, 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).
Otherwise, the server SHOULD send the corresponding DHCP Reply
message to the IP source address in the IP header received from the
client Request message.
6.3.1. Processing for Extensions to DHCP Request and Reply Messages 6.3.1. Processing for Extensions to DHCP Request and Reply Messages
The DHCP Request may contain extensions, which are interpreted The DHCP Request may contain extensions [12], 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 the
the Error Code appropriately for those extensions which return error status appropriately for those extensions which return status to the
status to the client. The DHCP server sends a single Reply message client. The DHCP server sends a single Reply message in response to
in response to each DHCP Request, with the same transaction-ID as the each DHCP Request, with the same transaction-ID as the 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
including them in the Reply with an appropriate error code indicating by including them in the Reply with an appropriate status indicating
failure. failure. The server can include extensions in the reply that were
not requested by the client.
6.3.2. Client Requests to Deallocate Unknown Resources 6.3.2. Client Requests to Deallocate Unknown Resources
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 MUST deallocate all resources associated with the client server MUST deallocate all resources associated with the client
upon reception of a DHCP Request with the 'C' bit set, except for 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 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
which could be a valid link-local address (i.e., one with the prefix could be a valid link-local address (see Section 2.1). If not, the
FE80::0000/64). If not, the message MUST be silently discarded. message MUST be silently discarded.
In response to a DHCP Release Message with a valid client's In response to a DHCP Release Message with a valid client's
link-local address and agent address, the DHCP server formulates a link-local address and agent address, the DHCP server formulates a
DHCP Reply message that will be sent back to the releasing client by DHCP Reply message that will be sent back to the releasing client by
way of the client's link-local address. A DHCP Reply message sent way of the client's link-local address. A DHCP Reply message sent
in response to a DHCP Release message MUST be sent to the client's in response to a DHCP Release message MUST be sent to the client's
link-local address via the agent address in the Release message link-local address via the agent address in the Release message
and set the 'L' bit in the Reply, unless the 'D' bit is set in the with the 'L' bit set in the Reply, unless the 'D' bit is set in the
Release message. Release message.
If the received agent address and link-local address do not If the received agent address and link-local address do not
correspond to any binding known to the server, then the server SHOULD correspond to any binding known to the server, then the server SHOULD
return a DHCP Reply with an error code of 20. return a DHCP Reply, indicating the error by setting the status code
to 20.
Otherwise, if the agent address and link-local address indicate a Otherwise, if the agent address and link-local address indicate a
binding known to the server, then the server continues processing the binding known to the server, then the server continues processing the
Release message. If there are any extensions, the server releases Release message. If there are any extensions, the server releases
the particular configuration items specified in the extensions. the particular configuration items specified in the extensions.
Otherwise, if there are no extensions, the server releases all If there are no extensions, the server releases all configuration
configuration information in the client's binding. information in the client's binding.
After performing the operations indicated in the DHCP Release message After performing the operations indicated in the DHCP Release message
and its extensions, the DHCP server formulates a DHCP Reply message, and its extensions, the DHCP server formulates a DHCP Reply message,
copying the transaction-ID, from the DHCP Release message. For copying the transaction-ID from the DHCP Release message. For
each Extension in the DHCP Release message successfully processed each Extension in the DHCP Release message successfully processed
by the server, a matching Extension is appended to the DHCP Reply by the server, a matching Extension is appended to the DHCP Reply
message. For extensions in the DHCP Release message which cannot be message. For extensions in the DHCP Release message which cannot be
successfully processed by the server, a DHCP Reply message containing successfully processed by the server, a DHCP Reply message containing
extensions with the appropriate error codes MUST be returned by the extensions with the appropriate status MUST be returned by the
server. server. If the Release message contains no extensions, the server
does not include any extensions in the corresponding DHCP Reply
message to the client.
6.5. Sending DHCP Reconfigure Messages 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 with
of its clients, it constructs a DHCP Reconfigure message and sends it any of its clients, it constructs a DHCP Reconfigure message and
to each such client [11]. The Reconfigure MAY be sent to a multicast sends it to each such client. The Reconfigure MAY be sent to a
address chosen by the server and sent to each of its clients in an multicast address chosen by the server and previously sent to each of
extension to a previous DHCP Reply message. its clients in an extension to a previous DHCP Reply message.
Often, it happens that a client does not send DHCP Request messages
after the DHCP Reconfigure message has been issued and retransmitted
according to the algorithm specified in Section 8. This can happen
when the cleint is not listening for the Reconfigure message,
possibly because the client is a mobile node disconnected from the
network, or because the client node has sustained a power outage
or operating system crash. In such cases, the DHCP server SHOULD
reserve any resources issued to the client until the client responds
at some future time, or until administrative intervention causes the
resources to be manually returned to use.
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 mediate DHCP client/server
interactions. interactions.
All relays MUST send DHCP Request messages out from an IP address of All relays MUST send DHCP Request messages using the source IP
the interface from which the DHCP request was received. address from the interface where the DHCP request was received.
The main purpose of the DHCP Relay is to enable clients and servers The purpose of the DHCP relay is to enable clients and servers to
to carry out DHCP protocol transactions. DHCP Solicit messages are 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
By default, the relay discovers local DHCP Servers by use of default, the relay locates DHCP servers by use of multicasting DHCP
multicasting DHCP solicitations to the All-DHCP-Servers multicast solicitations to the All-DHCP-Servers multicast address, but relays
address, but relays SHOULD allow this behavior to be configurable. SHOULD allow this behavior to be configurable. The relay SHOULD NOT
The relay SHOULD NOT send such a multicast solicitation on the send such a multicast solicitation on the interface from which it
interface from which it received the solicitation from the client. received the solicitation from the client. The source address must
be a site-local or global-scope address belonging to the relay's
interface on which the client's original solicitation was received.
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, - copying a non-link-local address of its interface from which the
solicitation was received from the client into the DHCP relay
address field, and
- copying the address of its interface from which the solicitation - by default, setting the TTL field in the solicitation to the
was received from the client into the DHCP Relay address field, value DEFAULT_SOLICIT_TTL (see section 8).
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.
that from which the client's solicitation was received.
When the relay receives a DHCP advertisement, it relays the When the relay receives a DHCP advertisement, it relays the
advertisement to the client at the client's link-local address by way advertisement to the client at the client's link-local address by way
of the interface indicated in the agent's address field. of the interface indicated in the agent's address field.
7.2. DHCP Request Message Processing 7.2. DHCP Request Message Processing
When a relay receives a DHCP Request message, it SHOULD check When a relay receives a DHCP Request message, it SHOULD check that
that the message is received from a link-local address, that the the IP source address in the IP header is a link-local address,
link-local address matches the link-local address field in the that the link-local address matches the link-local address field in
Request message header, and that the agent address field of the the Request message header, and that the agent address field of the
message matches an IP address associated to the interface from which message matches an IP address associated with the interface from
the DHCP Request message was received. If any of these checks fail, which the DHCP Request message was received. If any of these checks
the Relay MUST silently discard the Request message. fail, 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 check whether the 'S' bit is set in the message
header. If not, the datagram is discarded, and the relay SHOULD header. If not, the packet is discarded, and the relay SHOULD
return a DHCP Reply message to the address contained in the client's return a DHCP Reply message to the address contained in the client's
link-local address field of the Request message, with error code 18. link-local address field of the Request message, with status 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
server found in the Server IP Address field of the received DHCP found in the Server IP Address field of the received DHCP Request
Request message. All of the fields of DHCP Request message header message. All of the fields of DHCP Request message transmitted by
transmitted by the relay are copied over unchanged from the DHCP the relay are copied over unchanged from the DHCP Request received
Request received from the client. Only the fields in the IP header from the client. Only the fields in the IP header will differ from
will differ from the datagram received from the client, not the the packet received from the client. If the Relay receives an ICMP
payload. If the Relay receives an ICMP error, the Relay SHOULD error, the Relay SHOULD return a DHCP Reply message to the client
return a DHCP Reply message to the client address (which can be found address (which can be found in the payload of the ICMP message [5]),
in the payload of the ICMP message [5]), with error code 64. with status 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 that the message
message has the 'L' bit set. It MUST check whether the link-local has the 'L' bit set. It MUST check that the link-local address field
address field contains a link-local address. If all the checks are contains a link-local address. If either check fails, the packet
satisfied, the relay MUST send a DHCP Reply message to the link-local MUST be silently discarded. If both checks are satisfied, the relay
address listed in the received Reply message. Only the fields in the MUST send a DHCP Reply message to the link-local address listed in
IP header will differ from the datagram received from the server, not the received Reply message. Only the fields in the IP header will
the payload. differ from the packet 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
Request, with the same transaction-ID, to the same server again Request, with the same transaction-ID, to the same server again
until it can be reasonably sure that the DHCP server is unavailable until it can be reasonably sure that the DHCP server is unavailable
and an alternative can be chosen. The DHCP Server assumes that the and an alternative can be chosen. The DHCP server assumes that the
client has received the configuration information included with the client has received the configuration information included with the
extensions to the DHCP Reply message, and it is up to the client extensions to the DHCP Reply message, and it is up to the client
to continue to try for a reasonable amount of time to complete the to continue to try for a reasonable amount of time to complete the
transaction in order to make that assumption hold true. All the transaction. All the actions specified for DHCP Request in this
actions specified for DHCP Request in this section hold also for DHCP section hold also for DHCP Release messages, that do not have the 'N'
Release messages sent by the DHCP Client. bit set, sent by the DHCP client.
Similarly, when a client sends a DHCP Request message in response to Similarly, when a client sends a DHCP Request message in response to
a Reconfigure message from the server, the client assumes that the a Reconfigure message from the server, the client assumes that the
DHCP server has received the Request. The server MUST retransmit the DHCP server has received the Request. The server MUST retransmit
identical DHCP Reconfigure to the client for a reasonable amount of the identical DHCP Reconfigure to the client for a reasonable amount
time, to try to elicit the Request message from the client, in order of time, to try to elicit the Request message from the client. If
to make the best effort for that assumption to hold true. If no no corresponding DHCP Request is received by the server within this
corresponding DHCP Request is ever received by the server, the server time, the server MAY erase or deallocate information as needed from
MAY erase or deallocate information as needed from the client's the client's binding.
binding.
These retransmissions occur using the following configuration When a client reboots and loses its previous state, the server
variables for a DHCP implementation that MUST be configurable by a should no longer keep track of the transaction IDs associated with
client or server: that previous state. In order to inform the server that the client
no longer wishes any association to be maintained between used
transaction IDs and previous transactions, the client should set the
'R' bit in its DHCP Request.
ADV_WAIT Retransmissions occur using the following configuration variables
for a DHCP implementation. These configuration variables MUST be
configurable by a client or server:
The amount of time a client waits to hear DHCP Advertisements ADV_CLIENT_WAIT
after issuing a DHCP Solicit to the All-DHCP Agents multicast
address.
Default: 5 seconds The minimum amount of time a client waits to receive DHCP
REPLY_MSG_INITIAL_TIMEOUT Advertisements after transmitting a DHCP Solicit to the
All-DHCP Agents multicast address.
Default: 2 seconds
DEFAULT_SOLICIT_TTL
The default TTL value used by DHCP relays when sending DHCP
Solicit messages on behalf of a client.
Default: 4
SERVER_MIN_ADV_DELAY
The minimum amount of time a server waits to transmit a DHCP
Advertisement after receiving a DHCP Solicit at the All-DHCP
Servers or All-DHCP Agents multicast address.
Default: 100 milliseconds
SERVER_MAX_ADV_DELAY
The maximum amount of time a server waits to transmit a DHCP
Advertisement after receiving a DHCP Solicit at the All-DHCP
Agents multicast address.
Default: 1 second
REPLY_MSG_TIMEOUT
The time in seconds that a DHCP client waits to receive a The time in seconds that a DHCP client waits to receive a
server's DHCP Reply before retransmitting a DHCP Request. server's DHCP Reply before retransmitting a DHCP Request.
Default: 2 seconds. Default: 2 seconds.
REPLY_MSG_MIN_RETRANS REPLY_MSG_MIN_RETRANS
The minimum number of DHCP Request transmissions that a DHCP The minimum number of DHCP Request transmissions that a DHCP
client should retransmit, before aborting the request, possibly client should retransmit, before aborting the request, possibly
skipping to change at page 27, line 27 skipping to change at page 30, line 16
Default: 10 retransmissions. Default: 10 retransmissions.
REPLY_MSG_RETRANS_INTERVAL REPLY_MSG_RETRANS_INTERVAL
The time between successive retransmissions of DHCP Request The time between successive retransmissions of DHCP Request
messages. messages.
Default: 2 seconds. Default: 2 seconds.
RECONF_MSG_INITIAL_TIMEOUT RECONF_MSG_TIMEOUT
The time in seconds that a DHCP server waits to receive The time in seconds that a DHCP server waits to receive
a client's DHCP Request before retransmitting its DHCP a client's DHCP Request before retransmitting its DHCP
Reconfigure. Reconfigure.
Default: 2 seconds. Default: 12 seconds.
RECONF_MSG_MIN_RETRANS RECONF_MSG_MIN_RETRANS
The minimum number of DHCP Reconfigure messages that a DHCP The minimum number of DHCP Reconfigure messages that a DHCP
server should retransmit, before assuming the the client is server should retransmit, before assuming the the client is
unavailable and that the server can proceed with the needed unavailable and that the server can proceed with the needed
reconfiguration of that client's resources, and logging a DHCP reconfiguration of that client's resources, and logging a DHCP
System Error. System Error.
Default: 10 retransmissions. Default: 10 retransmissions.
RECONF_MSG_RETRANS_INTERVAL RECONF_MSG_RETRANS_INTERVAL
The least time between successive retransmissions of DHCP The least time between successive retransmissions of DHCP
Reconfigure messages. Reconfigure messages.
Default: 2 seconds. Default: RECONF_MSG_TIMEOUT
RECONF_MSG_MIN_RESP RECONF_MSG_MIN_RESP
The minimum amount of time before a client can respond to a The minimum amount of time before a client can respond to a
DHCP Reconfigure message sent to a multicast address. DHCP Reconfigure message sent to a multicast address.
Default: 2 second. Default: 2 seconds.
RECONF_MSG_MAX_RESP RECONF_MSG_MAX_RESP
The maximum amount of time before a client MUST respond to a The maximum amount of time before a client MUST respond to a
DHCP Reconfigure message sent to a multicast address. DHCP Reconfigure message sent to a multicast address.
Default: 10 seconds. Default: 10 seconds.
MIN_SOLICIT_DELAY MIN_SOLICIT_DELAY
The maximum amount of time a prospective client is required The maximum amount of time a prospective client is required to
to wait, after determining from a Router Discovery message wait, after determining from a Router Advertisement message
that the client should perform stateful address configuration, that the client should perform stateful address configuration,
before sending a DHCP Solicit to a DHCP Server. before sending a DHCP Solicit to a DHCP server.
Default: 1 second Default: 1 second
MAX_SOLICIT_DELAY MAX_SOLICIT_DELAY
The maximum amount of time a prospective client is required The maximum amount of time a prospective client is required to
to wait, after determining from a Router Discovery message wait, after determining from a Router Advertisement message
that the client should perform stateful address configuration, that the client should perform stateful address configuration,
before sending a DHCP Solicit to a DHCP Server. before sending a DHCP Solicit to a DHCP server.
Default: 5 seconds Default: 5 seconds
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: 600 seconds Default: 600 seconds
skipping to change at page 29, line 11 skipping to change at page 31, line 45
might be correctly authenticated just as if the failed message had might be correctly authenticated just as if the failed message had
never arrived; however, receiving such failed messages SHOULD be never arrived; however, receiving such failed messages SHOULD be
logged. logged.
9. Security Considerations 9. Security Considerations
DHCP clients and servers often have to authenticate the messages they DHCP clients and servers often have to authenticate the messages they
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 quite often essential for a DHCP client
be certain that the configuration parameters and addresses it has to 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. Again, a client
this writing, there is no generally accepted mechanism useful with might wish to only accept DHCP Reconfigure messages that are certain
DHCPv4 that is appropriate for use with DHCPv6. to have originated from a server with authority to issue them.
The IPv6 Authentication Header can provide security for DHCPv6 The IPv6 Authentication Header can provide security for DHCPv6
messages when both endpoints have a suitable IP address. However, messages when both endpoints have a suitable IP address. However,
a client often has only a link-local address, and such an address a client often has only a link-local address, and such an address
is not sufficient for a 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 [11] is server. The DHCP Client-Server Authentication Extension [12] is
intended to be used in these circumstances. intended to be used in these circumstances.
10. Acknowledgements 10. Year 2000 considerations
Since all times are relative to the current time of the transaction,
there is no problem within the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the current year.
11. Acknowledgements
Thanks to the DHC Working Group for their time and input into the Thanks to the DHC Working Group for their time and input into the
specification. Ralph Droms and Thomas Narten have had a major role specification. Ralph Droms and Thomas Narten have had a major role
in shaping the continued improvement of the protocol by their careful in shaping the continued improvement of the protocol by their careful
reviews. Thanks also for the consistent input, ideas, and review by reviews. Many thanks to Matt Crawford and Erik Nordmark for their
(in alphabetical order) Brian Carpenter, Jack McCann, Yakov Rekhter, studied review as part of the Last Call process. Thanks also for the
consistent input, ideas, and review by (in alphabetical order) Mike
Carney, Brian Carpenter, Gerald Maguire, Jack McCann, Yakov Rekhter,
Matt Thomas, Sue Thomson, and Phil Wells. 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.
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 [6], the IPv6 Addressing to study is the IPv6 Specification [6], the IPv6 Addressing
Architecture [8], IPv6 Stateless Address Autoconfiguration [15], IPv6 Architecture [8], IPv6 Stateless Address Autoconfiguration [16], IPv6
Neighbor Discovery Processing [10], and Dynamic Updates to DNS [16]. Neighbor Discovery Processing [11], and Dynamic Updates to DNS [18].
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 1500 octets
or greater (in IPv4 the requirement is 68 octets). This means that or greater (in IPv4 the requirement is 68 octets). This means that
a UDP datagram of 536 octets will always pass through an internet a UDP packet of 536 octets will always pass through an internet
(less 40 octets for the IPv6 header), as long as there are no IP (less 40 octets for the IPv6 header), as long as there are no IP
options prior to the UDP header in the datagram. But, IPv6 does options prior to the UDP header in the packet. But, IPv6 does not
not support fragmentation at routers, so that fragmentation takes support fragmentation at routers, so that fragmentation takes place
place end-to-end between hosts. If a DHCP implementation needs end-to-end between hosts. If a DHCP implementation needs to send a
to send a datagram greater than 536 octets it can either fragment packet greater than 1500 octets it can either fragment the UDP packet
the UDP datagram in UDP or use Path MTU Discovery [9] to determine into fragments of 1500 octets or less, or use Path MTU Discovery [10]
the size of the datagram that will traverse a network path. It is to determine the size of the packet that will traverse a network
implementation dependent how this is accomplished in DHCP. path. It is implementation dependent how this is accomplished in
DHCP. Path MTU Discovery for IPv6 is supported for both UDP and TCP
and can cause end-to-end fragmentation when the PMTU changes for a
destination.
The IPv6 Addressing Architecture specification [8] 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 support
addressing is required, and nodes can create link-local addresses for multicast is required, and nodes can create link-local addresses
during initialization of the nodes environment. This means that a during initialization. This means that a client can immediately use
client immediately can configure an IP address at initialization its link-local address and a well-known multicast address to begin
for an interface, before communicating in any manner on the link.
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 [15] (addrconf) specifies IPv6 Stateless Address Autoconfiguration [16] (addrconf) specifies
procedures by which a node may autoconfigure addresses based on procedures by which a node may autoconfigure addresses based on
router advertisements [10], and the use of a validation lifetime to router advertisements [11], and the use of a valid lifetime to
support renumbering of addresses on the Internet. In addition the support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with addrconf is a design stateful autoconfiguration. Compatibility with addrconf is a design
requirement of DHCP (see Section 3.1). requirement of DHCP (see Section 3.1).
IPv6 Neighbor Discovery [10] is the node discovery protocol in IPv6 IPv6 Neighbor Discovery [11] is the node discovery protocol in IPv6
(replaces and enhances functions of ARP [12]). To truly understand which replaces and enhances functions of ARP [13]. To understand
IPv6 and addrconf it is strongly recommended that implementors IPv6 and addrconf it is strongly recommended that implementors
understand IPv6 Neighbor Discovery. understand IPv6 Neighbor Discovery.
Dynamic Updates to DNS [16] is a specification that supports the Dynamic Updates to DNS [18] 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 integrate addresses and name space to
to not only support autoconfiguration, but also autoregistration in not only support autoconfiguration, but also autoregistration in
IPv6. The security model to be used with DHCPv6 should conform as IPv6. The security model to be used with DHCPv6 should conform as
closely as possible to that outlined in RFC 1825 [2]. closely as possible to the authentication model outlined in [9].
B. 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 [7, 1] and DHCPv6. a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6.
There are three key reasons for the differences: There are three key reasons for the differences:
o IPv6 inherently supports a new model and architecture for o IPv6 inherently supports a new model and architecture for
communications and autoconfiguration of addresses. communications and autoconfiguration of addresses.
o DHCPv6 in its design was able to take advantage of the inherent o DHCPv6 in its design was able to take advantage of the inherent
benefits of IPv6. benefits of IPv6.
o New features were added to support the evolution and the o New features were added to support the expected evolution and
existence of mature Internet users in the industry. the existence of more complicated Internet network service
requirements.
IPv6 Architecture/Model Changes: IPv6 Architecture/Model Changes:
o The link-local address permits a node to have an address o The link-local address permits a node to have an address
immediately when the node boots, which means all clients have a immediately when the node boots, which means all clients have a
source IP address at all times to locate a server or relay agent source IP address at all times to locate a server or relay agent
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
skipping to change at page 31, line 47 skipping to change at page 34, line 40
o Stateful autoconfiguration has to coexist and integrate with o Stateful autoconfiguration has to coexist and integrate with
stateless autoconfiguration supporting Duplicate Address stateless autoconfiguration supporting Duplicate Address
Detection and the two IPv6 lifetimes, to facilitate the dynamic Detection and the two IPv6 lifetimes, to facilitate the dynamic
renumbering of addresses and the management of those addresses. renumbering of addresses and the management of those addresses.
o Multiple addresses per interface are inherently supported in o Multiple addresses per interface are inherently supported in
IPv6. IPv6.
o Most DHCPv4 options are unnecessary now because the configuration o Most DHCPv4 options are unnecessary now because the configuration
parameters are either obtained through IPv6 Neighbor Discovery or parameters are either obtained through IPv6 Neighbor Discovery or
the Service Location protocol. the Service Location protocol [17].
DHCPv6 Architecture/Model Changes: DHCPv6 Architecture/Model Changes:
o The message type is the first byte in the packet. o The message type is the first byte in the packet.
o IPv6 Address allocations are now handled in a message extension o IPv6 Address allocations are now handled in a message extension
as opposed to the main header. as opposed to the main header.
o Client/Server bindings are now mandatory and take advantage of o Client/Server bindings are now mandatory and take advantage of
the client's link-local address to always permit communications the client's link-local address to always permit communications
skipping to change at page 32, line 35 skipping to change at page 35, line 25
addresses from system configuration or by the use of a site wide addresses from system configuration or by the use of a site wide
DHCPv6 Multicast packet. DHCPv6 Multicast packet.
o The protocol is optimized and removes the use of ACKs and NAKs o The protocol is optimized and removes the use of ACKs and NAKs
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 The function of DHCPINFORM is inherent in the new packet design;
request configuration parameters other than IPv6 addresses in the a client can request configuration parameters other than IPv6
optional extension headers. addresses in the optional extension headers.
o Clients MUST listen to their UDP port for the new Reconfigure o Clients MUST listen to their UDP port for the new Reconfigure
message type from servers, unless they join the appropriate message from servers.
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:
o Configuration of Dynamic Updates to DNS to support multiple o Configuration of Dynamic Updates to DNS to support different
implementation policy requirements. requirements.
o Configuration of what policy is enforced when addresses are o Configuration of what policy is enforced when addresses are
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
skipping to change at page 34, line 10 skipping to change at page 37, line 10
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. Alexander and R. Droms. DHCP Options and BOOTP Vendor [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 2132, March 1997. Extensions. RFC 2132, March 1997.
[2] R. Atkinson. Security Architecture for the Internet Protocol. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement
RFC 1825, August 1995.
[3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997. Levels. RFC 2119, March 1997.
[4] S. Bradner and A. Mankin. The Recommendation for the IP Next [3] S. Bradner and A. Mankin. The Recommendation for the IP Next
Generation Protocol. RFC 1752, January 1995. Generation Protocol. RFC 1752, January 1995.
[4] William R. Cheswick and Steven Bellovin. Firewalls and Internet
Security. Addison-Wesley, Reading, Massachusetts, 1994. (ISBN:
0-201-63357-4).
[5] 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.
[6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[7] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March [7] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March
1997. 1997.
[8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
RFC 1884, December 1995. RFC 1884, December 1995.
[9] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP [9] Stephen Kent and Randall Atkinson. IP Authentication Header.
draft-ietf-ipsec-auth-header-01.txt, July 1997. (work in
progress).
[10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP
version 6. RFC 1981, August 1996. version 6. RFC 1981, August 1996.
[10] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for [11] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP version 6 (IPv6). RFC 1970, August 1996. IP version 6 (IPv6). RFC 1970, August 1996.
[11] C. Perkins. Extensions to DHCPv6. [12] C. Perkins. Extensions for the Dynamic Host Configuration
draft-ietf-dhc-dhcpv6ext-06.txt (work in progress), May 1997. Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-09.txt, October
1997. (work in progress).
[12] David C. Plummer. An Ethernet Address Resolution Protocol: [13] David C. Plummer. An Ethernet Address Resolution Protocol:
Or Converting Network Protocol Addresses to 48.bit Ethernet Or Converting Network Protocol Addresses to 48.bit Ethernet
Addresses for Transmission on Ethernet Hardware. RFC 826, Addresses for Transmission on Ethernet Hardware. RFC 826,
November 1982. November 1982.
[13] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [14] J. B. Postel. User Datagram Protocol. RFC 768, August 1980.
[14] J. B. Postel, Editor. Internet Protocol. RFC 791, September [15] J. B. Postel, Editor. Internet Protocol. RFC 791, September
1981. 1981.
[15] S. Thomson and T. Narten. IPv6 stateless address [16] S. Thomson and T. Narten. IPv6 stateless address
autoconfiguration. RFC 1971, August 1996. autoconfiguration. RFC 1971, August 1996.
[16] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates [17] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. RFC 2165, July 1997.
[18] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
in the Domain Name System (DNS). RFC 2136, April 1997. in the Domain Name System (DNS). RFC 2136, April 1997.
Chair's Address Chair's Address
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
E-mail: droms@bucknell.edu E-mail: droms@bucknell.edu
Author's Address Author's Address
Questions about this memo can be directed to: Questions about this memo can be directed to:
Jim Bound Charles Perkins Jim Bound Charles Perkins
Digital Equipment Corporation Netcentricity Group Digital Equipment Corporation Technology Development
110 Spitbrook Road, ZKO3-3/U14 Sun Microsystems, Inc. 110 Spitbrook Road, ZKO3-3/U14 Sun Microsystems, Inc.
Nashua, NH 03062 2550 Garcia Avenue. Nashua, NH 03062 901 San Antonio Rd.
Mountain View, CA 94043 Palo Alto, CA 94303
Phone: +1-603-881-0400 +1-415-336-7153 Phone: +1-603-884-0400 +1-650-786-6464
Fax: +1-415-336-0673 Fax: +1-650-786-6445
E-mail: bound@zk3.dec.com charles.perkins@corp.sun.com E-mail: bound@zk3.dec.com charles.perkins@sun.com
 End of changes. 

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