Internet Engineering Task Force J. Bound
INTERNET DRAFT Digital Equipment Corp.
DHC Working Group C. Perkins
Obsoletes: draft-ietf-dhc-dhcpv6-03.txt IBM Research
12 February 1996
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-04.txt
Status of This Memo
This document is a submission to the DHC Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the dhcp-v6@bucknell.edu mailing list.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information, via options, to IPv6 hosts.
It offers the capability of automatic allocation of reusable network
addresses and additional configuration options. This protocol should
be considered a stateful counterpart to the IPv6 Stateless Address
Autoconfiguration protocol specification.
Bound, Perkins Expires 12 August 1996 [Page i]
Internet Draft DHCP Version 6 12 February 1996
Contents
Status of This Memo i
Abstract i
1. Introduction 1
1.1. Specification Language . . . . . . . . . . . . . . . . . 1
2. Terminology and Definitions 2
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 4
3. Protocol Design Model 5
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5
3.2. DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 6
3.3. Request/Response Processing Model . . . . . . . . . . . . 7
4. DHCPv6 Message Formats and Field Definitions 8
4.1. UDP Ports used for DHCPv6 messages . . . . . . . . . . . 8
4.2. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8
4.3. DHCP Advertise Message Format . . . . . . . . . . . . . . 9
4.4. DHCP Request Message Format . . . . . . . . . . . . . . . 10
4.5. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12
4.6. DHCP Release Message Format . . . . . . . . . . . . . . . 13
4.7. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14
5. DHCP Client Considerations 15
5.1. DHCP Solicit Message Processing . . . . . . . . . . . . . 15
5.2. DHCP Advertise Message Processing . . . . . . . . . . . . 15
5.3. DHCP Request Message Processing . . . . . . . . . . . . . 16
5.4. DHCP Reply Message Processing . . . . . . . . . . . . . . 17
5.5. DHCP Release Message Processing . . . . . . . . . . . . . 18
5.6. DHCP Reconfigure Message Processing . . . . . . . . . . . 18
6. DHCP Server Considerations 19
6.1. DHCP Solicit and Advertise Message Processing . . . . . . 19
6.2. DHCP Request and Reply Message Processing . . . . . . . . 19
6.3. DHCP Release Message Processing . . . . . . . . . . . . . 20
6.4. DHCP Reconfigure Message Processing . . . . . . . . . . . 21
7. DHCP Relay Considerations 22
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 22
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 23
Bound, Perkins Expires 12 August 1996 [Page ii]
Internet Draft DHCP Version 6 12 February 1996
7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 23
7.4. Retransmission and Configuation Variables . . . . . . . . 23
8. Security Considerations 25
9. Acknowledgements 25
A. Related Work in IPv6 26
B. Change History 27
B.1. Changes from November 95 to February 96 Drafts . . . . . 27
Chair's Address 29
Author's Address 29
Bound, Perkins Expires 12 August 1996 [Page iii]
Internet Draft DHCP Version 6 12 February 1996
1. Introduction
The Dynamic Host Configuration Protocol (DHCP) provides configuration
parameters to Internet hosts. DHCP consists of a protocol for
delivering host-specific configuration parameters from a DHCP server
to a host, and a mechanism for allocation of network addresses and
other related parameters to IPv6 hosts.
DHCP is built on a client-server model, where designated DHCP
server hosts allocate network addresses and automatically deliver
configuration parameters to dynamically configured hosts. Throughout
the remainder of this document, the term "server" refers to a host
providing initialization parameters through DHCP, and the term
"client" refers to a host requesting initialization parameters from
a DHCP server. DHCPv6 servers maintain state for their clients,
in contrast to IPv6 Stateless Address Autoconfiguration [9],
where IPv6 hosts should get the same results if they repeat the
autoconfiguration procedure multiple times.
DHCPv6 uses Request and Reply messages to support a client/server
processing model whereby both client and server are assured that
requested configuration parameters have been received and accepted by
the client. DHCPv6 supports optional configuration parameters and
processing for hosts through its companion document Extensions for
the Dynamic Host Configuration Protocol for IPv6 [5].
The IPv6 Addressing Architecture [3] and IPv6 Stateless Address
Autoconfiguration specifications provide new features not available
in IP version 4 (IPv4) [8], which are used to simplify and generalize
the operation of DHCPv6 clients.
Section 2 provides definitions for terminology used throughout this
document. Section 3 provides a overview of the protocol design model
that guides the design choices in the specification; section 3.2
briefly describes the protocol messages and their semantics.
Section 4 provides the message formats and field definitions used for
each message. Sections 5, 6, and 7 specify how clients, servers,
and relays interact. Appendix A summarizes related work in IPv6 that
will provide helpful context; it is not part of this specification,
but included for informational purposes.
1.1. Specification Language
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
Bound, Perkins Expires 12 August 1996 [Page 1]
Internet Draft DHCP Version 6 12 February 1996
MUST This word, or the adjective "required", means
that the definition is an absolute requirement
of the specification.
MUST NOT This phrase means that the definition is an
absolute prohibition of the specification.
SHOULD This word, or the adjective "recommended",
means that there may exist valid reasons in
particular circumstances to ignore this item,
but the full implications must be understood
and carefully weighed before choosing a
different course. Unexpected results may
result otherwise.
MAY This word, or the adjective "optional", means
that this item is one of an allowed set of
alternatives. An implementation which does
not include this option MUST be prepared to
interoperate with another implementation which
does include the option.
silently discard The implementation discards the datagram
without further processing, and without
indicating an error to the sender. The
implementation SHOULD provide the capability of
logging the error, including the contents of
the discarded datagram, and SHOULD record the
event in a statistics counter.
2. Terminology and Definitions
Relevant terminology from the IPv6 Protocol [2], IPv6 Addressing
Architecture, and IPv6 Stateless Address Autoconfiguration will be
provided, and then the DHCPv6 terminology.
2.1. IPv6 Terminology
IP
Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6
are used only in contexts where necessary to avoid ambiguity.
node
A device that implements IPv6.
Bound, Perkins Expires 12 August 1996 [Page 2]
Internet Draft DHCP Version 6 12 February 1996
router
A node that forwards IPv6 datagrams not explicitly addressed to
itself.
host
Any node that is not a router.
link
A communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately
below IPv6. Examples are Ethernet (simple or bridged); PPP
links, X.25, Frame Relay, or ATM networks; and internet (or
higher) layer "tunnels", such as tunnels over IPv4 or IPv6
itself.
link-layer identifier
a link-layer identifier for an interface. Examples include
IEEE 802 addresses for Ethernet links, and E.164 addresses for
ISDN links.
link-local address
An address having link-only scope that can be used to reach
neighboring nodes attached to the same link. All interfaces
have a link-local address.
neighbors
Nodes attached to the same link.
interface
A node's attachment to the link.
address
An IP layer identifier for an interface or a set of interfaces.
message
The data exchanged between DHCP agents and clients; in this
specification, messages are delivered via IPv6 and UDP.
Bound, Perkins Expires 12 August 1996 [Page 3]
Internet Draft DHCP Version 6 12 February 1996
datagram
An IP header plus payload.
unicast address
An identifier for a single interface. A datagram sent to a
unicast address is delivered to the interface identified by
that address.
multicast address
An identifier for a set of interfaces (typically belonging to
different nodes). A datagram sent to a multicast address is
delivered to all interfaces identified by that address.
2.2. DHCPv6 Terminology
configuration parameter
Any parameter that can be used by a node to configure its
network environment and enable communication on a link or
internetwork.
client
A host that initiates requests on a link to obtain
configuration parameters.
server
A server is a node that responds to requests from clients on a
link to provide: addresses, dynamic updates to DNS, or other
configuration parameters.
relay
A node that may advertise DHCP server addresses, or may act as
an intermediary to deliver DHCP messages between clients and
servers.
DHCP Agent
Either a DHCPv6 server or a DHCPv6 relay.
Bound, Perkins Expires 12 August 1996 [Page 4]
Internet Draft DHCP Version 6 12 February 1996
agent address
The address of a neighboring DHCP relay or DHCP server on the
same link as the DHCP client.
msg-type
The msg-type defines the DHCPv6 protocol type for a message.
transaction-ID
The transaction-ID is a monotonically increasing integer
identifier specified by the client and is used by the client to
match a DHCP Reply to a pending DHCP Request.
server address
The server address specifies the address for the server
responding to a client.
binding
A binding in DHCPv6 contains the data which a DHCPv6 server
MUST maintain for each of its clients. An implementation
MUST support bindings consisting of at least a client's
link-local address, agent address, preferred lifetime and valid
lifetime [9] for each client address, and the transaction-ID.
3. Protocol Design Model
This section is provided for implementors to understand the DHCPv6
protocol design model from an architectural perspective. The goals,
conceptual models and implementation examples presented in this
section do not specify requirements of the DHCPv6 protocol.
3.1. Design Goals
The following list gives general design goals for this DHCPv6
specification.
- DHCPv6 should be a mechanism rather than a policy. DHCPv6 must
allow local system administrators control over configuration
parameters where desired; e.g., local system administrators
should be able to enforce local policies concerning allocation
and access to local resources where desired.
Bound, Perkins Expires 12 August 1996 [Page 5]
Internet Draft DHCP Version 6 12 February 1996
- DHCPv6 MUST NOT introduce any requirement for manual
configuration of DHCPv6 client hosts, except possibly for
manually configured keys. Each host should be able to discover
appropriate local configuration parameters without user
intervention, and incorporate those parameters into its own
configuration.
- DHCPv6 MUST NOT require a server on each link. To allow for
scale and economy, DHCPv6 must work across relay agents.
- A DHCPv6 client must be prepared to receive multiple responses to
solicitations for DHCP servers. Some installations may include
multiple, overlapping DHCPv6 servers to enhance reliability
and/or to increase performance.
- DHCPv6 must coexist with statically configured, non-participating
hosts and with existing network protocol implementations.
- DHCPv6 MUST be compatible with IPv6 Stateless Address
Autoconfiguration.
- DHCPv6 must support the requirements of automated renumbering of
IPv6 addresses [1].
- DHCPv6 servers should be able to support Dynamic Updates to
DNS [10].
- A DHCPv6 server to server protocol is NOT part of this DHCPv6
specification.
- It is NOT a design goal of DHCPv6 to specify how a server
configuration parameter database is maintained or determined.
Methods for configuring DHCP servers are outside the scope of
this document.
3.2. DHCPv6 Messages
Each DHCPv6 message contains a type, which defines whether the
message originated from a DHCPv6 server or client.
The message types are as follows:
01 DHCP Solicit
The DHCP Solicit message is a DHCPv6 multicast (or in special
circumstances unicast) message from a client to one or more
neighboring DHCPv6 Agents.
Bound, Perkins Expires 12 August 1996 [Page 6]
Internet Draft DHCP Version 6 12 February 1996
02 DHCP Advertise
The DHCP Advertise is an IPv6 unicast message from a DHCP Agent
in response to a client DHCP Solicit.
03 DHCP Request
The DHCP Request is an IPv6 unicast message from a client to
a server, when the client knows the IPv6 unicast address of a
server, to request configuration parameters on a network.
04 DHCP Reply
The DHCP Reply is an IPv6 unicast message sent by a server to
respond to a client's DHCP Request. Extensions [5] to the DHCP
Reply describe the resources that the DHCP Server has committed
and allocated to the client, and may contain other information
for use by the client.
05 DHCP Release
The DHCP Release message is used by a DHCPv6 client to inform
the server that the client is releasing a particular address,
or set of addresses or resources, even though the addresses or
resources may still be marked valid in the server's binding for
the client.
06 DHCP Reconfigure
The DHCP Reconfigure message is used by a DHCPv6 server
to inform the client that the server has new configuration
information of importance to the client. The client is
expected to initiate a new Request/Reply transaction.
3.3. Request/Response Processing Model
Processing details for the DHCP messages listed above are specified
in Sections 5, 6, and 7.
The request/response processing for DHCPv6 is transaction based
and uses a best-effort set of messages to guarantee a completed
transaction. The timeout and retransmission guidelines and
configuration variables are discussed in Section 7.4.
The request/response set is always started by a client with a DHCP
Request, which may be issued after the client knows the server's
address. The response message is from the server and is the DHCP
Bound, Perkins Expires 12 August 1996 [Page 7]
Internet Draft DHCP Version 6 12 February 1996
Reply. At this point in the flow all data has been received. To
provide a method of recovery if either the client or server do not
receive the messages to complete the transaction, the client is
required to retransmit any DHCP Request message until it elicits a
DHCP Reply, or until it can be reasonably certain that the desired
DHCP Server is unavailable.
4. DHCPv6 Message Formats and Field Definitions
All fields in DHCPv6 messages MUST be initialized to binary zeroes by
both the client and server unless otherwise noted. DHCPv6 message
types not defined here (msg-types 0 and 7-255) are reserved.
All DHCP Agents MUST join the DHCPv6 Server/Relay-Agent multicast
group at the well-known multicast address FF02:0:0:0:0:0:1:0.
Servers on the same link as the client MUST use the source address
in the IPv6 header from the client as the destination address in the
server's response datagrams.
4.1. UDP Ports used for DHCPv6 messages
DHCPv6 uses the UDP [7] protocol to communicate between clients
and servers. UDP is not reliable, but DHCPv6 must provide some
reliability between clients and servers. If a response is not
received after transmission of a DHCP message, the message MUST be
retransmitted according to the rules specified in 7.4.
A Client MUST transmit all messages over UDP using UDP port 547 as
the destination port. A client MUST receive all messages from UDP
port 546.
A DHCP Agent MUST transmit all messages over UDP using UDP port 546
as the destination port. A DHCP Agent MUST receive all messages over
UDP using UDP port 547.
4.2. DHCP Solicit Message Format
A DHCPv6 client transmits a DHCP Solicit message to obtain the
address of a neighboring DHCP Agent, and to obtain one or more
addresses for DHCP servers which the DHCP Agent is configured to
advertise. If a DHCPv6 client does not know any DHCP Agent address,
or wants to locate a new server to receive configuration parameters,
Bound, Perkins Expires 12 August 1996 [Page 8]
Internet Draft DHCP Version 6 12 February 1996
the client SHOULD use, as the destination IP address, the DHCPv6
Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | msg-flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 1
msg-flags 0
RESERVED 0
extensions No extensions are defined at this time.
4.3. DHCP Advertise Message Format
A DHCPv6 agent sends a DHCP Advertise message to inform a prospective
client about the IPv6 address of a DHCP Agent to which a DHCP Request
message may be sent.
A DHCPv6 agent MAY periodically transmit DHCP Advertise messages to
the All-DHCPv6 Clients multicast address, no more often than once per
second, and with TTL == 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |S| msg-flags | server-count | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 2
S If set, the agent address is also a server
address.
Bound, Perkins Expires 12 August 1996 [Page 9]
Internet Draft DHCP Version 6 12 February 1996
msg-flags 0
server-count The number of addresses listed in the server
addresses field.
RESERVED 0
agent address The IPv6 address of a neighboring DHCP Agent
interface
server addresses The IPv6 address(es) of the DHCPv6 server(s)
which the DHCP Agent has been configured to
advertise.
extensions See [5].
Note that if a neighboring DHCPv6 server issues the DHCP Advertise,
then the agent address will be the IPv6 address of one of the
server's interfaces, the 'S' bit will be set, the agent address will
be an address of the server, and there may be zero server addresses
sent in the DHCP Advertise message. It is an error for server-count
to be zero if the 'S' bit is not set.
4.4. DHCP Request Message Format
In order to request parameters from a DHCP server, a client sends a
DHCP Request message and appends the extensions which are appropriate
for obtaining the needed parameters [5]. If the client does not know
any DHCPv6 server address, it must first obtain a server address by
multicasting a DHCP Solicit message (see Section 4.2). If the client
does not have a valid IPv6 address which is reachable by the DHCPv6
server, the client MUST use the unicast IP address of a local DHCPv6
relay as the destination IP address. Otherwise, the client MAY omit
the server address in the DHCP Request message; in this case, the
client MUST send the DHCP Request message directly to the server just
Bound, Perkins Expires 12 August 1996 [Page 10]
Internet Draft DHCP Version 6 12 February 1996
as it would any other datagram destined for the server, using the
server address as the IPv6 destination address in the IPv6 header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |S|C| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) |
| server address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 3
S If set, the server address is present
C If set, the client requests the server to
clear all existing resources and bindings
currently associated with the client,
deallocating as needed.
reserved 0
transaction-ID A monotonically increasing number which the
client asks the server to copy into its DHCP
Reply, so that the client can match Replies
with pending Requests.
server address If present, the IPv6 address of the DHCPv6
server which should receive the client's DHCP
Request message.
agent address The IPv6 address of the relay or server
interface from which the client received the
DHCP Advertise message
link-local address The IPv6 link-local address of the client
interface from which the the client issued
the DHCP Request message
Bound, Perkins Expires 12 August 1996 [Page 11]
Internet Draft DHCP Version 6 12 February 1996
extensions See [5].
4.5. DHCP Reply Message Format
The server sends a DHCP Reply message in response to every DHCP
Request received. If the request comes with the 'S' 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 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 the
'L' bit is set, then the client's link-local address will also be
present.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | error code | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) |
| link-local address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 3
error code One of the following values:
0 Success
1 Failure, reason unspecified
2 Authentication failed or nonexistent
3 Poorly formed request
4 Resources unavailable
5 Client record unavailable
16 Wrong phase of moon
32 Dogbert didn't like it
64 Server unreachable (ICMP error)
transaction-ID Copied from the transaction-ID which the
DHCPv6 server received in the DHCP Request.
to help the client match this reply with an
outstanding Request.
L If set, the link-local address is present
Bound, Perkins Expires 12 August 1996 [Page 12]
Internet Draft DHCP Version 6 12 February 1996
RESERVED 0
link-local address If present, the IPv6 address of the client
interface which issued the corresponding DHCP
Request message.
extensions See [5].
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
address which was specified as the agent address in the DHCP Request
message, and the relay uses the link-local address to deliver the
Reply message to the client.
4.6. DHCP Release Message Format
The DHCP Release message is sent without the assistance of any DHCPv6
relay. When a client sends a Release message, it is assumed to
have a valid IPv6 address with sufficient scope to allow access to
the target server. Only the parameters which are specified in the
extensions are released. The DHCP server acknowledges the Release
message by sending a DHCP Reply (Section 6.2).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |D| msg-flags | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 5
D If the 'D' ("Direct") flag is set, the client
instructs the server to send the DHCP Reply
directly back to the client, instead of
using the given agent address and link-local
address to relay the Reply message.
msg-flags 0
Bound, Perkins Expires 12 August 1996 [Page 13]
Internet Draft DHCP Version 6 12 February 1996
transaction-ID A monotonically increasing number which the
client asks the server to use in its DHCP
Reply, to help the client match Replies with
outstanding Releases.
agent address The IPv6 address of the agent interface to
which the client issued the DHCP Request
message
link-local address The IPv6 link-local address of the client
interface from which the the client issued
the DHCP Request message
extensions See [5]
If the client knows that the address it uses as the source IP address
in its IPv6 header will still be valid after the server performs the
operations requested in the extensions to the DHCP Release message,
the client can then specify the 'D' flag. When the 'D' flag is set,
the server MUST send the DHCP Reply back to the client's address
as shown in the source address of the IPv6 header of the Release
message. Otherwise, when the 'D' bit is not set, the server MUST use
the agent address and link-local address in its DHCP Reply message to
forward the Reply message back to the releasing client.
4.7. DHCP Reconfigure Message Format
The DHCP Reconfigure message is sent without the assistance of any
DHCPv6 relay. When a server sends a Reconfigure message, the client
to which it is sent is assumed to have a valid IPv6 address with
sufficient scope to be accessible by the server. Only the parameters
which are specified in the extensions to the Reconfigure message need
be requested again by the client.
The client SHOULD listen at UDP port 546 to receive possible DHCP
Reconfigure messages. If the client does not listen for DHCP
Reconfigure messages, it is possible that the client will not receive
notification that its DHCP server has deallocated the client's IPv6
address and/or other resources allocated to the client.
Bound, Perkins Expires 12 August 1996 [Page 14]
Internet Draft DHCP Version 6 12 February 1996
See discussion in 6.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | msg-flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 6
msg-flags 0
reserved 0
extensions See [5]
5. DHCP Client Considerations
A DHCPv6 client MUST silently discard any DHCP Solicit, DHCP Request,
or DHCP Release message it receives.
A DHCPv6 client should retain its configured parameters and resources
across client system reboots and DHCPv6 client program restarts.
However, in these circumstances a DHCPv6 client SHOULD also formulate
a DHCP Request message to verify that its configured parameters and
resources are still valid. This Request message MUST have the 'C'
bit set, to clear client binding information at the server, of which
the client may no longer have any record.
5.1. DHCP Solicit Message Processing
If a node wishes to become a new DHCPv6 client, it must first locate
a neighboring DHCP Agent. The client does this by multcasting
a DHCP Solicit message to the well-known multicast address
FF02:0:0:0:0:0:1:0, setting the TTL == 1.
5.2. DHCP Advertise Message Processing
When a DHCPv6 client receives a DHCP Advertise message, it may
formulate a DHCP Request message to receive configuration information
and resources from the DHCP servers listed in the advertisement. If
the Advertise message has zero server addresses and does not have the
'S' bit set, the client MUST silently discard the message.
Bound, Perkins Expires 12 August 1996 [Page 15]
Internet Draft DHCP Version 6 12 February 1996
If the 'S' bit is set, the DHCP Advertise message was transmitted
by a DHCPv6 server. In this case, the Advertise message may
have Extensions; this might allow the DHCPv6 client to select
the configuration that best meets its needs from among several
prospective servers. Also in this case, the client MUST use the
agent address as the address of its server for future DHCPv6 message
transactions.
5.3. DHCP Request Message Processing
A DHCPv6 client obtains configuration information from a DHCPv6
server by sending a DHCP Request message. The client must know the
server's address before sending the Request message. In addition,
the client must have acquired a valid DHCP agent address. If the
client and server are on the same link, the agent address used by the
client MUST be the same as the DHCP server's address.
If the client has no valid IPv6 address and the DHCP server is
off-link, then the client MUST include the server address in the
appropriate field of the DHCP Request message and set the 'S' bit.
In this case, the IPv6 destination address of the Request message
MUST be the agent address.
Otherwise, if the client already has a valid IPv6 address and knows
the IPv6 address of a candidate IPv6 server, it MUST send the Request
message directly to the DHCPv6 server without requiring the services
of the local DHCPv6 relay.
If a client wishes to instruct a DHCP server to deallocate all
previous resources, configuration information, and bindings
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
even when it is no longer attached to the link on which the relay
address is attached.
A client MAY maintain information about which relay address and
server address it has been using for use after a reboot. When
the client has a pending DHCP Request and reboots before the
corresponding DHCP Reply is received, the client MUST issue its next
DHCP Request after rebooting with the 'C' bit set.
In any case, after choosing a transaction-ID which is numerically
greater than its previous transaction-ID, and filling in the
appropriate fields of the DHCP Request message, the client MAY append
various DHCPv6 Extensions to the message. These Extensions denote
specific requests by the client; for example, a client may request
a particular IP address, or request that the server send an update
Bound, Perkins Expires 12 August 1996 [Page 16]
Internet Draft DHCP Version 6 12 February 1996
containing the client's new IP address to a Domain Name Server. When
all Extensions have been applied, the DHCPv6 client unicasts the DHCP
Request to the appropriate DHCP Agent.
For each pending DHCP Request message, a client MUST maintain the
following information:
- The transaction-ID of the Request message,
- The server address,
- The agent address,
- The time at which the next retransmission will be attempted, and
- All Extensions appended to the reply message.
If a client does not receive a DHCP Reply message with the
same transaction-ID as a pending DHCP Request message within
REPLY_MSG_INITIAL_TIMEOUT seconds, it MUST retransmit the Request
with the same transaction-ID and continue to retransmit according to
the rules in Section 7.4.
Note that if a client crashes while its DHCP Request is still
pending, no state is maintained, and the client MUST reissue a DHCP
Request after it restarts.
5.4. DHCP Reply Message Processing
When a client receives a DHCP Reply message, it MUST check whether
the transaction-ID in the Reply message matches the transaction-ID
of a pending DHCP Request message. If no match is found, the Reply
message MUST be silently discarded, and an error SHOULD be logged.
If the transaction-ID matches that of a pending Request, and the 'L'
bit is set, but the source address in the IPv6 header does not match
the pending agent address, the client MUST discard the message, and
SHOULD log the event. Likewise, if the transaction-ID matches that
of a pending Request, and the 'L' bit is not set, but the source
address in the IPv6 header does not match the pending server address,
the client MUST discard the message, and SHOULD log the event.
If the Reply message is acceptable, the client processes each
Extension [5], extracting the relevant configuration information and
parameters for its network operation.
Some configuration information extracted from the Extensions to the
DHCP Reply message must remain associated with the DHCP server that
Bound, Perkins Expires 12 August 1996 [Page 17]
Internet Draft DHCP Version 6 12 February 1996
sent the message. The particular extensions that require this extra
measure of association with the server are indicated in the DHCPv6
Extensions document [5]. These associations may be useful with DHCP
Release messages.
5.5. DHCP Release Message Processing
If a DHCPv6 client determines that some of its network configuration
parameters are no longer valid, it may enable the DHCPv6 server to
release allocated resources which are no longer in use by sending a
DHCP Release message to the server. The client must consult its list
of resource-server associations in order to determine which server
should receive the desired Release message. If a client wishes to
ask the server to release all information and resources relevent to
the client, the client specifies no Extensions.
A client wishes to release resources which were granted to it at
another link-local address. In that case, the client must instruct
the server to send the DHCP Reply directly back to the client,
instead of performing the default processing 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.
5.6. DHCP Reconfigure Message Processing
DISCUSSION: On the one hand, clients REALLY SHOULD listen for
Reconfigure messages. On the other hand, some
implementors claim that requiring a client to
always listen at a port is asking too much. This
issue needs further discussion.
If a DHCPv6 client receives a DHCP Reconfigure message, it is
a request for the client to initiate a new DHCP Request/Reply
transaction with the server which sent the Reconfigure message.
The server sending the Reconfigure message MAY be different than
the server which sent a DHCP Reply message containing the original
configuration information.
For each Extension which is present in the Reconfigure message, the
client appends a matching Extension to its DHCP Request message
which it formulates to send to the DHCPv6 server which is found in
the IP source address of the message. The client also selects a
transaction-ID numerically greater than its last choice and inserts
it into the Request message. From then on, processing is the same as
specified above in Section 5.3.
Bound, Perkins Expires 12 August 1996 [Page 18]
Internet Draft DHCP Version 6 12 February 1996
6. DHCP Server Considerations
A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP
Reconfigure message it receives.
A server uses the combination <link-local address, agent address> to
index into its records of client bindings. A DHCPv6 server should
retain its client's bindings across server reboots, and, whenever
possible, a DHCPv6 client should be assigned the same configuration
parameters despite server host system reboots and DHCPv6 server
program restarts. A DHCPv6 server MUST support fixed or permanent
allocation of configuration parameters to specific hosts.
6.1. DHCP Solicit and Advertise Message Processing
Upon receiving a DHCP Solicit message from a client, a server
constructs a DHCP Advertise message and transmits it to the
soliciting client on the same link as the solicitation was received
from. The destination address of the advertisement MUST be the
source address of the solicitation. The DHCP server must use a IPv6
address of the interface on which it received the client's DHCP
Solicit message as the source address field of the IPv6 header of the
message.
6.2. DHCP Request and Reply Message Processing
The DHCPv6 server MUST check to ensure that a valid link-local
address is present in the client's link-local address field of the
Request message. If not, the message MUST be silently discarded.
Otherwise, it checks for the presence of the 'S' bit. If the 'S' bit
is set, the server MUST check that the server address matches the
destination IPv6 address at which the Request message was received
by the server. If the server address does not match, the Request
message MUST be silently discarded.
If the message is accepted, the server extracts the client's
link-local address and the agent address, and uses the information to
locate or create an appropriate client record (called a binding) used
to store all the relevant information, resources, and configuration
data which will be associated with the client. Each client record is
uniquely identifiable by the ordered pair <link-local address, agent
address>, since the link-local address is guaranteed to be unique [9]
on the link identified by the agent address. If the received agent
address and link-local address do not correspond to any binding known
to the server, then the server MAY create a new binding for the
Bound, Perkins Expires 12 August 1996 [Page 19]
Internet Draft DHCP Version 6 12 February 1996
previously unknown client; otherwise, it SHOULD return a DHCP Reply
with a error code of 5.
Before processing the Request, the server must determine whether or
not the Request is a retransmission of an earlier DHCP Request from
the same client. This is done by comparing the transaction-ID to
all those transaction-IDs received from the same client during the
previous TRANSACTION_ID_TIMEOUT seconds. If the transaction-ID is
the same as 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 processing the previous DHCP Request with the same
transaction-ID.
Otherwise (the transaction-ID has not been recently used), when the
server has identified and allocated all the relevant information,
resources, and configuration data that is associated with the client,
it sends that information to its DHCPv6 client by constructing a
DHCP Reply message and including the client's information in DHCPv6
Extensions to the Reply message. The DHCP Reply message uses the
same transaction-ID as found in the received DHCP Request message.
If the DHCP Request message has the 'S' bit set in the message
header, the DHCPv6 server MUST send the corresponding DHCP Reply
message to the agent address found in the Request.
The DHCP Request may contain Extensions, which are interpreted
as advisory (or mandatory) information from the client about its
configuration preferences. For instance, if the IP Address Extension
is present, the DHCPv6 server SHOULD attempt to allocate or extend
the lifetime of the address indicated by the Extension.
6.3. DHCP Release Message Processing
If the server receives a DHCP Release Message, it MUST verify that a
valid link-local address is present in the link-local address field
of the message. If not, the message MUST be silently discarded.
In response to a DHCP Release Message with a valid link-local
address, the DHCPv6 server formulates a 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 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 and set the 'L' bit in the
Reply, (unless the 'D' bit is set in the Release message).
Bound, Perkins Expires 12 August 1996 [Page 20]
Internet Draft DHCP Version 6 12 February 1996
If the received agent address and link-local address do not
correspond to any binding known to the server, then the server SHOULD
return a DHCP Reply with a error code of 5.
Otherwise, if the agent address and link-local address indicate a
binding known to the server, then the server continues processing
for the Release message. If there are any Extensions, the server
releases the particular configuration items specified in the
extensions. Otherwise, if there are no extensions, the server
releases all configuration information in the client's binding.
After performing the operations indicated in the DHCP Release
message and its Extensions, the DHCPv6 server formulates a DHCP
Reply message, copying the transaction-ID, from the DHCP Release
message. For each Extension in the DHCP Release message successfully
processed by the server, a matching Extension is appended to the DHCP
Reply message. Extensions in the DHCP Release message which cannot
be successfully processed by the server MUST NOT correspond to any
Extension appended to the Reply by the server.
6.4. DHCP Reconfigure Message Processing
If a DHCPv6 server needs to change the configuration associated
to any of its clients, it constructs a DHCP Reconfigure message
and sends it to each such client. The Reconfigure message MUST
contain the particular Extensions which inform the client about which
configuration information needs to be changed.
DISCUSSION: Perhaps a DHCPv6 server should be allowed to
multicast a DHCP Reconfigure message to its
clients. There are issues to be resolved here.
There is concern about encouraging servers to send
such messages to any DHCP-wide multicast address.
Perhaps a new extension should be defined so that
the server can ask (some of) its clients to join a
specific multicast group. Then the server could
efficiently multicast Reconfigure messages to
whatever group it wants.
This would have the additional advantage that
clients could receive Reconfigure messages without
listening to any specific UDP port.
If multiple clients can receive the same
Reconfigure message, some algorithm must be
specified so that the clients stagger their
Bound, Perkins Expires 12 August 1996 [Page 21]
Internet Draft DHCP Version 6 12 February 1996
responses (i.e., their DHCP Requests) so that
the server isn't deluged all at once with some
arbitrarily large number of client Requests.
7. DHCP Relay Considerations
The DHCPv6 protocol is constructed so that a relay does not have
to maintain any state in order to facilitate DHCPv6 client/server
interactions.
All relays MUST use the IPv6 address of the interface from which the
DHCPv6 message is transmitted as the source address for the IP header
of that DHCPv6 message.
7.1. DHCP Solicit and DHCP Advertise Message Processing
Upon receiving a DHCP Solicit message from a client, a relay
constructs a DHCP Advertise message and transmits it to the
soliciting client on the same link as the solicitation was received
from. The destination address of the advertisement MUST be the
source address of the solicitation.
DISCUSSION: If the Solicit is delivered to a server and
the server is allowed to send the corresponding
Advertise back to a client, the server could then
include some prospective information to "entice" a
client to use its services. For instance, a server
could include proposed lifetime information, and a
client could pick the server with the best "terms".
Presumably, this forwarding behavior should be a
matter of relay configuration instead of client
request. I'll assume that for now and try to make
the protocol reflect the ability of DHCP Advertise
messages to contain Extensions and come from DHCP
servers off-link. That may take a little more
doing which isn't in the protocol right now, be
patient.
When transmitting a DHCP Advertise message, a relay indicates how
many server addresses which it was configured to advertise, and
includes each address in the DHCP Advertise message. The DHCP
Advertise message must use a routeable IPv6 address in the source
address of the IPv6 header of the message. In particular, the source
address of any DHCP Advertise message sent by a DHCPv6 relay MUST NOT
be a link-local address.
Bound, Perkins Expires 12 August 1996 [Page 22]
Internet Draft DHCP Version 6 12 February 1996
7.2. DHCP Request Message Processing
When a relay receives a DHCP Request message, it MUST check that the
message is received from a link-local address, that the link-local
address matches the link-local address field in the Request message
header, and that the agent address field of the message matches an
IPv6 address associated to the interface from which the DHCP Request
message was received. The relay MUST also check whether the 'S'
bit is set in the message header. If any of these checks fail, the
message is not acceptable and MUST be silently discarded.
If the received request message is acceptable, the relay then
transmits the DHCP Request message to the DHCPv6 server found in the
Server Address field of the received DHCP Request message. All of
the fields of DHCP Request message header transmitted by the relay
are copied over unchanged from the DHCP Request received from the
client. Only the fields in the IPv6 header will differ from the
datagram received from the client, not the payload.
7.3. DHCP Reply Message Processing
When the relay receives a DHCP Reply, it MUST check whether the
message has the 'L' bit set. It must check whether the link-local
address field contains an IPv6 address that has prefix FE80::00 .
If all the checks are satisfied, the relay MUST send a DHCP Reply
message to the link-local address listed in the received Reply
message. Only the fields in the IPv6 header will differ from the
datagram received from the server, not the payload.
7.4. Retransmission and Configuation Variables
When a DHCPv6 client does not receive a DHCP Reply in response to a
pending DHCP Request, the client MUST retransmit the identical DHCP
Request to the same server again until it can be reasonably sure that
the DHCPv6 server is unavailable and an alternative can be chosen.
It is important for the DHCP Server to be sure that its client has
received the configuration information included with the Extensions
to the DHCP Reply message.
Likewise, but less commonly, when a DHCP server does not receive a
DHCP Request message in response to its DHCP Reconfigure message to
the client, the server MUST retransmit the identical DHCP Reconfigure
to the client until it is reasonably certain that the client is not
available for reconfiguration. If no corresponding DHCP Request
is ever received by the server, the server MAY erase or deallocate
information as needed from the client's binding.
Bound, Perkins Expires 12 August 1996 [Page 23]
Internet Draft DHCP Version 6 12 February 1996
These retransmissions occur using the following configuration
variables for a DHCPv6 implementation that MUST be configurable by a
client or server are as follows:
REPLY_MSG_INITIAL_TIMEOUT
The time in seconds that a DHCPv6 client waits to receive a
server's DHCP Reply before retransmitting a DHCP Request.
Default: 2 seconds.
REPLY_MSG_MIN_RETRANS
The minimum number of DHCP Request transmissions that a DHCPv6
client should retransmit, before aborting the request, possibly
retrying the Request with another Server, and logging DHCPv6
System Error.
Default: 10 retransmissions.
RECONF_MSG_INITIAL_TIMEOUT
The time in seconds that a DHCPv6 server waits to receive
a client's DHCP Request before retransmitting its DHCP
Reconfigure.
Default: 2 seconds.
RECONF_MSG_MIN_RETRANS
The minimum number of DHCP Reconfigure messages that a DHCPv6
server should retransmit, before assuming the the client is
unavailable and that the server can proceed with the needed
reconfiguration of that client's resources, and logging DHCPv6
System Error.
Default: 10 retransmissions.
The following parameter specifies how long a DHCPv6 server has to
keep track of client transaction-IDs in order to make sure that
client retransmissions using the same transaction-ID are idempotent.
TRANSACTION_IT_TIMEOUT
Default: 10800 seconds
Bound, Perkins Expires 12 August 1996 [Page 24]
Internet Draft DHCP Version 6 12 February 1996
8. Security Considerations
It may often be very important for DHCP clients and servers to be
able to authenticate the messages they exchange. For instance, a
DHCP server may wish to be certain that a DHCP Request originated
from the client identified by the <link-local address, agent address>
fields included within the Request message header. Conversely,
it is often essential for a DHCP client to be certain that the
configuration parameters and addresses it has received were sent to
it by an authoritative DHCP server. Similarly, 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 client actually did
transmit the Release message. At the time of this writing, there
is no generally accepted mechanism useful with DHCPv4 that can be
extended for use with DHCPv6.
There has been some discussion about the advisability and
desirability of using IPv6 Authentication to allow DHCPv6 clients
and servers to authenticate messages which they exchange. However,
in many circumstances a client has only a link-local address, and a
link-local address cannot be forwarded to a server which is off-link.
Thus, the DHCP relay _has_to be involved, for instance, with the DHCP
Request when the client has only a link-local address, and therefore
the DHCP Request (in this circumstance) MUST have the relay's address
in the IPv6 destination address field.
That means that the authentication (in this circumstance) CANNOT be
end-to-end. That means that IPsec cannot apply. Thus, in order to
authenticate DHCP Request messages in many circumstances will require
a more specialized technique for message authentication, as specified
in the DHCPv6 Extensions companion document [5].
One possibility is to allow relays to encapsulate the DHCP Request
before delivery to the server. Then the client could apply
end-to-end authentication (such as afforded by IPSec) which would
nevertheless remain untouched by the relay. The relay could, if
desired, apply its own authentication header to the encapsulated
datagrams.
9. Acknowledgements
Thanks to the DHC Working Group for their time and input into the
specification. A special thanks for the consistent input, ideas,
and review by (in alphabetical order) Brian Carpenter, Ralph Droms,
Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson,
and Phil Wells.
Bound, Perkins Expires 12 August 1996 [Page 25]
Internet Draft DHCP Version 6 12 February 1996
Thanks to Steve Deering and Bob Hinden, who have consistently
taken the time to discuss the more complex parts of the IPv6
specifications.
The authors MUST also thank their employers for the opportunity and
funding to work on DHCPv6 and IPv6 in general as an individual in the
IETF.
A. Related Work in IPv6
The related work in IPv6 that would best serve an implementor
to study is the IPv6 Specification [2], the IPv6 Addressing
Architecture [3], IPv6 Stateless Address Autoconfiguration [9], IPv6
Neighbor Discovery Processing [4], and Dynamic Updates to DNS [10].
These specifications afford DHCPv6 to build upon the IPv6 work to
provide both robust stateful autoconfiguration and autoregistration
of DNS Host Names.
The IPv6 Specification provides the base architecture and design of
IPv6. A key point for DHCPv6 implementors to understand is that IPv6
requires that every link in the internet have an MTU of 576 octets or
greater (in IPv4 the requirement is 68 octets). This means that a
UDP datagram of 536 octets will always pass through an internet (less
40 octets for the IPv6 header), as long as there are no IP options
prior to the UDP header in the datagram. But, IPv6 does not support
fragmentation at routers and fragmentation must take place end-to-end
between hosts. If a DHCPv6 implementation needs to send a datagram
greater than 536 octets it can either fragment the UDP datagram
in UDP or use Path MTU Discovery [2] to determine the size of the
datagram that will traverse a network path. It is implementation
defined how this is accomplished in DHCPv6.
The IPv6 Addressing Architecture Specification provides 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 is that multicast
addressing is well defined and nodes can create link-local addresses
during initialization of the nodes environment. This means that a
host immediately can configure an IPv6 address at initialization
for an interface, before communicating in any manner on the link.
The host can then use a well-known multicast address to begin
communications to discover neighbors on the link, or as was discussed
in the specification to locate a DHCPv6 server or relay.
The IPv6 Stateless Address Autoconfiguration Specification [9]
defines how a host can autoconfigure addresses based on neighbor
discovery router advertisements, and the use of a validation lifetime
Bound, Perkins Expires 12 August 1996 [Page 26]
Internet Draft DHCP Version 6 12 February 1996
to support renumbering of addresses on the Internet. In addition the
addrconf specification defines the protocol interaction for a host to
begin stateless or stateful autoconfiguration. DHCPv6 is one vehicle
to perform stateful autoconfiguration. Compatibility with addrconf
is a design goal of DHCPv6.
IPv6 Neighbor Discovery (ND) [4] is the node discovery protocol in
IPv6 (replaces and enhances functions of IPv4 ARP Model [6]). To
truly understand IPv6 and addrconf it is strongly recommended that
implementors understand IPv6 ND.
Dynamic Updates to DNS [10] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCPv6 can use
the dynamic updates to DNS to now integrate addresses and name space
to not only support autoconfiguration, but also autoregistration in
IPv6.
B. Change History
B.1. Changes from November 95 to February 96 Drafts
Substituted use of client's link-local address for previous uses of
client's interface token.
Reorganized DHCP messages into Solicit/Advertise, Request/Reply,
Release, and Reconfigure.
Made message-specific formats instead of using the same DHCP header
for each message.
Eliminated retransmission message types.
Server commits after receiving DHCP Request, and optimistically
depends on client retransmissions as negative acknowledgement.
Eliminated total-addrs.
Eliminated all definitions and most fields related to allocating IPv6
addresses (moved to the Extensions specification).
Renamed "gateway address" to be "agent address".
Bound, Perkins Expires 12 August 1996 [Page 27]
Internet Draft DHCP Version 6 12 February 1996
References
[1] S. Bradner and A. Mankin. The Recommendation for the IP Next
Generation Protocol. RFC 1752, January 1995.
[2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995.
[3] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
RFC 1883, December 1995.
[4] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor
Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in
progress, November 1995.
[5] C. Perkins. Extensions to DHCPv6. draft-ietf-dhc-dhcpv6ext-00.txt
-- work in progress, November 1995.
[6] David C. Plummer. An Ethernet Address Resolution Protocol:
Or Converting Network Protocol Addresses to 48.bit Ethernet
Addresses for Transmission on Ethernet Hardware. RFC 826,
November 1982.
[7] J. B. Postel. User Datagram Protocol. RFC 768, August 1980.
[8] J. B. Postel, editor. Internet Protocol. RFC 791, September
1981.
[9] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt
- work in progress, November 1995.
[10] S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the
Domain Name System (DNS). draft-ietf-dnsind-dynDNS-06.txt --
work in progress, February 1996.
Bound, Perkins Expires 12 August 1996 [Page 28]
Internet Draft DHCP Version 6 12 February 1996
Chair's Address
The working group can be contacted via the current chair:
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
E-mail: droms@bucknell.edu
Author's Address
Questions about this memo can be directed to:
Jim Bound Charles Perkins
Digital Equipment Corporation T. J. Watson Research Center
110 Spitbrook Road, ZKO3-3/U14 IBM Corporation
Nashua, NH 03062 30 Saw Mill River Rd., Rm J1-A25
Hawthorne, NY 10532
Phone: +1-603-881-0400 +1-914-784-7350
Fax: +1-914-784-6205
E-mail: bound@zk3.dec.com perk@watson.ibm.com
Bound, Perkins Expires 12 August 1996 [Page 29]