Network Working Group R. Droms, Ed.
Request for Comments: 3315 Cisco
Category: Standards Track J. Bound
Nokia Research Center
July 2003 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2003). All Rights Reserved.
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP
servers to pass configuration parameters such as IPv6 network
addresses to IPv6 nodes. It offers the capability of automatic
allocation of reusable network addresses and additional configuration
flexibility. This protocol is a stateful counterpart to "IPv6
Stateless Address Autoconfiguration" (RFC 2462), and can be used
separately or concurrently with the latter to obtain configuration
1.1. Protocols and Addressing
Clients and servers exchange DHCP messages using UDP . The
client uses a link-local address or addresses determined through
other mechanisms for transmitting and receiving DHCP messages.
DHCP servers receive messages from clients using a reserved,
link-scoped multicast address. A DHCP client transmits most messages
to this reserved multicast address, so that the client need not be
configured with the address or addresses of DHCP servers.
To allow a DHCP client to send a message to a DHCP server that is not
attached to the same link, a DHCP relay agent on the client's link
will relay messages between the client and server. The operation of
the relay agent is transparent to the client and the discussion of
message exchanges in the remainder of this section will omit the
description of message relaying by relay agents.
Once the client has determined the address of a server, it may under
some circumstances send messages directly to the server using
1.2. Client-server Exchanges Involving Two Messages
When a DHCP client does not need to have a DHCP server assign it IP
addresses, the client can obtain configuration information such as a
list of available DNS servers  or NTP servers  through a
single message and reply exchanged with a DHCP server. To obtain
configuration information the client first sends an
Information-Request message to the All_DHCP_Relay_Agents_and_Servers
multicast address. Servers respond with a Reply message containing
the configuration information for the client.
This message exchange assumes that the client requires only
configuration information and does not require the assignment of any
When a server has IPv6 addresses and other configuration information
committed to a client, the client and server may be able to complete
the exchange using only two messages, instead of four messages as
described in the next section. In this case, the client sends a
Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting
the assignment of addresses and other configuration information.
This message includes an indication that the client is willing to
accept an immediate Reply message from the server. The server that
is willing to commit the assignment of addresses to the client
immediately responds with a Reply message. The configuration
information and the addresses in the Reply message are then
immediately available for use by the client.
Each address assigned to the client has associated preferred and
valid lifetimes specified by the server. To request an extension of
the lifetimes assigned to an address, the client sends a Renew
message to the server. The server sends a Reply message to the
client with the new lifetimes, allowing the client to continue to use
the address without interruption.
1.3. Client-server Exchanges Involving Four Messages
To request the assignment of one or more IPv6 addresses, a client
first locates a DHCP server and then requests the assignment of
addresses and other configuration information from the server. The
client sends a Solicit message to the
All_DHCP_Relay_Agents_and_Servers address to find available DHCP
servers. Any server that can meet the client's requirements responds
with an Advertise message. The client then chooses one of the
servers and sends a Request message to the server asking for
confirmed assignment of addresses and other configuration
information. The server responds with a Reply message that contains
the confirmed addresses and configuration.
As described in the previous section, the client sends a Renew
message to the server to extend the lifetimes associated with its
addresses, allowing the client to continue to use those addresses
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in .
This document also makes use of internal conceptual variables to
describe protocol behavior and external variables that an
implementation must allow system administrators to change. The
specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demonstrate
protocol behavior. An implementation is not required to have them in
the exact form described here, so long as its external behavior is
consistent with that described in this document.
The IPv6 Specification provides the base architecture and design of
IPv6. Related work in IPv6 that would best serve an implementor to
study includes the IPv6 Specification , the IPv6 Addressing
Architecture , IPv6 Stateless Address Autoconfiguration , IPv6
Neighbor Discovery Processing , and Dynamic Updates to DNS .
These specifications enable DHCP to build upon the IPv6 work to
provide both robust stateful autoconfiguration and autoregistration
of DNS Host Names.
The IPv6 Addressing Architecture specification  defines the
address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required and nodes can create link-local addresses
during initialization. The availability of these features means that
a client can use its link-local address and a well-known multicast
address to discover and communicate with DHCP servers or relay agents
on its link.
IPv6 Stateless Address Autoconfiguration  specifies procedures by
which a node may autoconfigure addresses based on router
advertisements , and the use of a valid lifetime to support
renumbering of addresses on the Internet. In addition, the protocol
interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with stateless address
autoconfiguration is a design requirement of DHCP.
IPv6 Neighbor Discovery  is the node discovery protocol in IPv6
which replaces and enhances functions of ARP . To understand
IPv6 and stateless address autoconfiguration, it is strongly
recommended that implementors understand IPv6 Neighbor Discovery.
Dynamic Updates to DNS  is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space to
not only support autoconfiguration, but also autoregistration in
This sections defines terminology specific to IPv6 and DHCP used in
4.1. IPv6 Terminology
IPv6 terminology relevant to this specification from the IPv6
Protocol , IPv6 Addressing Architecture , and IPv6 Stateless
Address Autoconfiguration  is included below.
address An IP layer identifier for an interface
or a set of interfaces.
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
interface A node's attachment to a link.
link A communication facility or medium over
which nodes can communicate at the link
layer, i.e., the layer immediately
below IP. Examples are Ethernet (simple
or bridged); Token Ring; PPP links,
X.25, Frame Relay, or ATM networks; and
Internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6
link-layer identifier A link-layer identifier for an
interface. Examples include IEEE 802
addresses for Ethernet or Token Ring
network interfaces, and E.164 addresses
for ISDN links.
link-local address An IPv6 address having a link-only
scope, indicated by having the prefix
(FE80::/10), that can be used to reach
neighboring nodes attached to the same
link. Every interface has a link-local
multicast address 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.
neighbor A node attached to the same link.
node A device that implements IP.
packet An IP header plus payload.
prefix The initial bits of an address, or a
set of IP addresses that share the same
prefix length The number of bits in a prefix.
router A node that forwards IP packets not
explicitly addressed to itself.
unicast address An identifier for a single interface.
A packet sent to a unicast address is
delivered to the interface identified by
4.2. DHCP Terminology
Terminology specific to DHCP can be found below.
appropriate to the link An address is "appropriate to the link"
when the address is consistent with the
DHCP server's knowledge of the network
topology, prefix assignment and address
binding A binding (or, client binding) is a
group of server data records containing
the information the server has about
the addresses in an IA or configuration
information explicitly assigned to the
client. Configuration information that
has been returned to a client through a
policy - for example, the information
returned to all clients on the same
link - does not require a binding. A
binding containing information about
an IA is indexed by the tuple <DUID,
IA-type, IAID> (where IA-type is the
type of address in the IA; for example,
temporary). A binding containing
configuration information for a client
is indexed by <DUID>.
configuration parameter An element of the configuration
information set on the server and
delivered to the client using DHCP.
Such parameters may be used to carry
information to be used by a node to
configure its network subsystem and
enable communication on a link or
internetwork, for example.
DHCP Dynamic Host Configuration Protocol
for IPv6. The terms DHCPv4 and DHCPv6
are used only in contexts where it is
necessary to avoid ambiguity.
DHCP client (or client) A node that initiates requests on a link
to obtain configuration parameters from
one or more DHCP servers.
DHCP domain A set of links managed by DHCP and
operated by a single administrative
DHCP realm A name used to identify the DHCP
administrative domain from which a DHCP
authentication key was selected.
DHCP relay agent (or relay agent) A node that acts as an
intermediary to deliver DHCP messages
between clients and servers, and is on
the same link as the client.
DHCP server (or server) A node that responds to requests from
clients, and may or may not be on the
same link as the client(s).
DUID A DHCP Unique IDentifier for a DHCP
participant; each DHCP client and server
has exactly one DUID. See section 9 for
details of the ways in which a DUID may
Identity association (IA) A collection of addresses assigned to
a client. Each IA has an associated
IAID. A client may have more than one
IA assigned to it; for example, one for
each of its interfaces.
Each IA holds one type of address;
for example, an identity association
for temporary addresses (IA_TA) holds
temporary addresses (see "identity
association for temporary addresses").
Throughout this document, "IA" is used
to refer to an identity association
without identifying the type of
addresses in the IA.
Identity association identifier (IAID) An identifier for an IA,
chosen by the client. Each IA has an
IAID, which is chosen to be unique among
all IAIDs for IAs belonging to that
Identity association for non-temporary addresses (IA_NA) An IA
that carries assigned addresses that are
not temporary addresses (see "identity
association for temporary addresses")
Identity association for temporary addresses (IA_TA) An IA that
carries temporary addresses (see RFC
message A unit of data carried as the payload
of a UDP datagram, exchanged among DHCP
servers, relay agents and clients.
Reconfigure key A key supplied to a client by a server
used to provide security for Reconfigure
relaying A DHCP relay agent relays DHCP messages
between DHCP participants.
transaction ID An opaque value used to match responses
with replies initiated either by a
client or server.
5. DHCP Constants
This section describes various program and networking constants used
5.1. Multicast Addresses
DHCP makes use of the following multicast addresses:
All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped
multicast address used by a client to communicate with
neighboring (i.e., on-link) relay agents and servers.
All servers and relay agents are members of this
All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used
by a relay agent to communicate with servers, either
because the relay agent wants to send messages to
all servers or because it does not know the unicast
addresses of the servers. Note that in order for
a relay agent to use this address, it must have an
address of sufficient scope to be reachable by the
servers. All servers within the site are members of
this multicast group.
5.2. UDP Ports
Clients listen for DHCP messages on UDP port 546. Servers and relay
agents listen for DHCP messages on UDP port 547.
5.3. DHCP Message Types
DHCP defines the following message types. More detail on these
message types can be found in sections 6 and 7. Message types not
listed here are reserved for future use. The numeric encoding for
each message type is shown in parentheses.
SOLICIT (1) A client sends a Solicit message to locate
ADVERTISE (2) A server sends an Advertise message to indicate
that it is available for DHCP service, in
response to a Solicit message received from a
REQUEST (3) A client sends a Request message to request
configuration parameters, including IP
addresses, from a specific server.
CONFIRM (4) A client sends a Confirm message to any
available server to determine whether the
addresses it was assigned are still appropriate
to the link to which the client is connected.
RENEW (5) A client sends a Renew message to the server
that originally provided the client's addresses
and configuration parameters to extend the
lifetimes on the addresses assigned to the
client and to update other configuration
REBIND (6) A client sends a Rebind message to any
available server to extend the lifetimes on the
addresses assigned to the client and to update
other configuration parameters; this message is
sent after a client receives no response to a
REPLY (7) A server sends a Reply message containing
assigned addresses and configuration parameters
in response to a Solicit, Request, Renew,
Rebind message received from a client. A
server sends a Reply message containing
configuration parameters in response to an
Information-request message. A server sends a
Reply message in response to a Confirm message
confirming or denying that the addresses
assigned to the client are appropriate to the
link to which the client is connected. A
server sends a Reply message to acknowledge
receipt of a Release or Decline message.
RELEASE (8) A client sends a Release message to the server
that assigned addresses to the client to
indicate that the client will no longer use one
or more of the assigned addresses.
DECLINE (9) A client sends a Decline message to a server to
indicate that the client has determined that
one or more addresses assigned by the server
are already in use on the link to which the
client is connected.
RECONFIGURE (10) A server sends a Reconfigure message to a
client to inform the client that the server has
new or updated configuration parameters, and
that the client is to initiate a Renew/Reply
or Information-request/Reply transaction with
the server in order to receive the updated
INFORMATION-REQUEST (11) A client sends an Information-request
message to a server to request configuration
parameters without the assignment of any IP
addresses to the client.
RELAY-FORW (12) A relay agent sends a Relay-forward message
to relay messages to servers, either directly
or through another relay agent. The received
message, either a client message or a
Relay-forward message from another relay
agent, is encapsulated in an option in the
RELAY-REPL (13) A server sends a Relay-reply message to a relay
agent containing a message that the relay
agent delivers to a client. The Relay-reply
message may be relayed by other relay agents
for delivery to the destination relay agent.
The server encapsulates the client message as
an option in the Relay-reply message, which the
relay agent extracts and relays to the client.
5.4. Status Codes
DHCPv6 uses status codes to communicate the success or failure of
operations requested in messages from clients and servers, and to
provide additional information about the specific cause of the
failure of a message. The specific status codes are defined in
5.5. Transmission and Retransmission Parameters
This section presents a table of values used to describe the message
transmission behavior of clients and servers.
Parameter Default Description
SOL_MAX_DELAY 1 sec Max delay of first Solicit
SOL_TIMEOUT 1 sec Initial Solicit timeout
SOL_MAX_RT 120 secs Max Solicit timeout value
REQ_TIMEOUT 1 sec Initial Request timeout
REQ_MAX_RT 30 secs Max Request timeout value
REQ_MAX_RC 10 Max Request retry attempts
CNF_MAX_DELAY 1 sec Max delay of first Confirm
CNF_TIMEOUT 1 sec Initial Confirm timeout
CNF_MAX_RT 4 secs Max Confirm timeout
CNF_MAX_RD 10 secs Max Confirm duration
REN_TIMEOUT 10 secs Initial Renew timeout
REN_MAX_RT 600 secs Max Renew timeout value
REB_TIMEOUT 10 secs Initial Rebind timeout
REB_MAX_RT 600 secs Max Rebind timeout value
INF_MAX_DELAY 1 sec Max delay of first Information-request
INF_TIMEOUT 1 sec Initial Information-request timeout
INF_MAX_RT 120 secs Max Information-request timeout value
REL_TIMEOUT 1 sec Initial Release timeout
REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 1 sec Initial Decline timeout
DEC_MAX_RC 5 Max Decline attempts
REC_TIMEOUT 2 secs Initial Reconfigure timeout
REC_MAX_RC 8 Max Reconfigure attempts
HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward message
5.6 Representation of time values and "Infinity" as a time value
All time values for lifetimes, T1 and T2 are unsigned integers. The
value 0xffffffff is taken to mean "infinity" when used as a lifetime
(as in RFC2461 ) or a value for T1 or T2.