draft-ietf-dhc-dhcpv6-03.txt   draft-ietf-dhc-dhcpv6-04.txt 
INTERNET-DRAFT J. Bound Internet Engineering Task Force J. Bound
DHC Working Group Digital Equipment Corp INTERNET DRAFT Digital Equipment Corp.
Obsoletes: draft-ietf-dhc-dhcpv6-02.txt November 1995 DHC Working Group C. Perkins
Obsoletes: draft-ietf-dhc-dhcpv6-03.txt IBM Research
12 February 1996
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-04.txt
draft-ietf-dhc-dhcpv6-03.txt Status of This Memo
Status of this Memo
This document is a submission to the DHC Working Group of the This document is a submission to the DHC Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the dhcp-v6@bucknell.edu mailing list. to the dhcp-v6@bucknell.edu mailing list.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
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 any and may be updated, replaced, or obsoleted by other documents at
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 the
``1id-abstracts.txt'' listing contained in the Internet- Drafts ``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 (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Abstract Abstract
This document is an Internet application protocol, for IP version 6 The Dynamic Host Configuration Protocol (DHCP) provides a framework
(IPv6), that specifies a client/server model for communications for passing configuration information, via options, to IPv6 hosts.
between hosts to dynamically configure parameters for a network, and It offers the capability of automatic allocation of reusable network
autoconfigure addresses within a stateful model. This document addresses and additional configuration options. This protocol should
supports the model for IPv6 Stateless Address Autoconfiguration, be considered a stateful counterpart to the IPv6 Stateless Address
where there are clear integration points between stateless and Autoconfiguration protocol specification.
stateful address autoconfiguration for IPv6.
Table of Contents:
1. Introduction.................................................3
1.1. Requirements...............................................3
2. Terminology and Definitions..................................4
2.1. IPv6 Terminology...........................................4
2.2. DHCPv6 Terminology.........................................6
3. Protocol Design Model........................................9
3.1. Design Goals...............................................9
3.2. Request/Response Model....................................10
3.3. Leased Address Model......................................11
3.3.1. Address Lifetimes.......................................11
3.3.2. Duplicate Address Detection.............................12
3.3.3. Releasing Infinite Lifetime Addresses...................13
3.4. DNS Host Name Autoregistration Model......................13
4. Request/Response Processing.................................13
4.1. Processing when Server Address is not Known...............14
4.2. Processing when Server Address is Known...................16
4.3. Retransmission and Configuation Variables.................16
5. Datagram and Field Definitions..............................18
5.1. Datagram..................................................18
5.2. Field Definitions.........................................19
6. Client/Server Message Formats...............................21
6.1. Client/Server UDP Ports, Multicast Group, and Addresses...21
6.2. Client DISCOVER and CONF-REQUEST Messages.................21
6.3. Server CONF-RESPONSE Message..............................23
6.4. Client ACCEPT Message.....................................24
6.5. Server SERVER-ACK Message.................................25
6.6. Client RELEASE Message....................................27
7. Relay-Agent Processing......................................28
8. Security Considerations.....................................29
Appendix A - Related Work in IPv6..............................29
Change History.................................................31
Acknowledgements...............................................33
References.....................................................33
Authors' Address...............................................34
1. Introduction
DHCPv6 is an Internet application protocol, for IP version 6 (IPv6),
that specifies a client/server model for communications between hosts
to dynamically configure parameters for a network, and autoconfigure
addresses within a stateful model. DHCPv6 supports the model for
IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF], where there
are clear integration points between stateless and stateful address
autoconfiguration for IPv6.
DHCPv6 uses a set of request/response messages to support a
transaction processing model where a commit to the data can be
verified by both the client and server. This affords DHCPv6 the
ability in the future to support dynamic updates to data located
within a sites network. In addition to the capability of verifying
commits to transactions a recovery mechanism is specified, should
commits need to be rolled back during the course of a DHCPv6
transaction being processed.
DHCPv6 supports optional configuration parameters and processing for
hosts through its companion document Options for the Dynamic Host
Configuration Protocol for IPv6 [DHCPv6-OPT].
The IPv6 Addressing Architecture [IPv6-ADDR] and IPv6 Stateless
Address Autoconfiguration specifications provide new functionality
not present in IP version 4 (IPv4). This new IPv6 functionality
provides inherent benefits to autoconfigure IPv6 addresses for nodes.
In addition the IETF DNS Working Group has defined a method to
support Dynamic Updates to DNS [DYN-UPD], which can be used by a node
to add, delete, and change node names dynamically.
DHCPv6 used several of the architecture principles from DHCPv4
[DHCP-v4], but it is beyond the scope of this document to contrast
and compare DHCPv6 with DHCPv4.
Section 2 provides definitions for terminology used throughout this
document. Section 3 provides a review of the protocol design model
parts that are inherent in the specification. Section 4 provides the
request/response model and interaction between the set of messages
and the semantics for those messages. Section 5 provides the
datagram packet format and field definitions for that datagram.
Section 6 provides the message formats and field contents for
processing the client and server messages. Section 7 provides the
specification of how relay-agents and servers interact with clients,
when the server is not on the same link as the client. Section 8
provides the security specifications that can be used to support
security in DHCPv6. Appendix A provides a summary of related work in
IPv6 that will help put DHCPv6 in the context of IPv6 for the reader,
and is not part of this specification, but here for information
purposes.
1.1. Requirements
Throughout this document, the words that are used to define the
significance of the particular requirements are capitalized. These
words are:
o "MUST"
This word or the adjective "REQUIRED" means that the item is an
absolute requirement of this specification.
o "MUST NOT"
This phrase means the item is an absolute prohibition of this
specification.
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there may Contents
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before choosing a different course.
o "SHOULD NOT" Status of This Memo i
This phrase means that there may exist valid reasons in particular Abstract i
circumstances when the listed behavior is acceptable or even
useful, but the full implications should be understood and the
case carefully weighted before implementing any behavior described
with this label.
o "MAY" 1. Introduction 1
1.1. Specification Language . . . . . . . . . . . . . . . . . 1
This word or the adjective "OPTIONAL" means that this item is 2. Terminology and Definitions 2
truly optional. One vendor may choose to include the item because 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
a particular marketplace requires it or because it enhances the 2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 4
product, for example, another vendor may omit the same item.
2. Terminology and Definitions 3. Protocol Design Model 5
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5
3.2. DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 6
3.3. Request/Response Processing Model . . . . . . . . . . . . 7
Relevant terminology from the IPv6 Protocol [IPv6-SPEC], IPv6 4. DHCPv6 Message Formats and Field Definitions 8
Addressing Architecture, and IPv6 Stateless Address Autoconfiguration 4.1. UDP Ports used for DHCPv6 messages . . . . . . . . . . . 8
will be provided, and then the DHCPv6 terminology. 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
2.1. IPv6 Terminology 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
IP - Internet Protocol Version 6 (IPv6). The terms 6. DHCP Server Considerations 19
IPv4 and IPv6 are used only in contexts where 6.1. DHCP Solicit and Advertise Message Processing . . . . . . 19
necessary to avoid ambiguity. 6.2. DHCP Request and Reply Message Processing . . . . . . . . 19
6.3. DHCP Release Message Processing . . . . . . . . . . . . . 20
6.4. DHCP Reconfigure Message Processing . . . . . . . . . . . 21
node - A device that implements IPv6. 7. DHCP Relay Considerations 22
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 22
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 23
7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 23
7.4. Retransmission and Configuation Variables . . . . . . . . 23
router - A node that forwards IPv6 packets not explicitly 8. Security Considerations 25
addressed to itself.
host - Any node that is not a router. 9. Acknowledgements 25
upper-layer - A protocol layer immediately above IP. Examples are A. Related Work in IPv6 26
transport protocols such as TCP and UDP, control
protocols such as ICMP, routing protocols such as
OSPF, and internet or lower-layer protocols being
"tunneled" over (e.g. encapsulated in) IP such as
IPX, Appletalk, or IP itself.
link - A communication facility or medium over which nodes B. Change History 27
can communicate at the link layer, i.e., the layer B.1. Changes from November 95 to February 96 Drafts . . . . . 27
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.
neighbors - Nodes attached to the same link. Chair's Address 29
interface - A node's attachment to the link. Author's Address 29
address - An IP layer identifier for an interface or a set 1. Introduction
of interfaces.
packet - An IP header plus payload. 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.
communication DHCP is built on a client-server model, where designated DHCP
- Any packet exchange between nodes that requires server hosts allocate network addresses and automatically deliver
that the address of each node used in the exchange configuration parameters to dynamically configured hosts. Throughout
remain the same for the duration of the packet the remainder of this document, the term "server" refers to a host
exchange. Examples are a TCP connection or UDP providing initialization parameters through DHCP, and the term
request/response. "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.
unicast address DHCPv6 uses Request and Reply messages to support a client/server
- An identifier for a single interface. A packet sent processing model whereby both client and server are assured that
to a unicast address is delivered to the interface requested configuration parameters have been received and accepted by
identified by that address. 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].
multicast address The IPv6 Addressing Architecture [3] and IPv6 Stateless Address
- An identifier for a set of interfaces (typically Autoconfiguration specifications provide new features not available
belonging to different nodes). A packet sent to a in IP version 4 (IPv4) [8], which are used to simplify and generalize
multicast address is delivered to all interfaces the operation of DHCPv6 clients.
identified by that address.
link-layer identifier Section 2 provides definitions for terminology used throughout this
- a link-layer identifier for an interface. Examples document. Section 3 provides a overview of the protocol design model
include IEEE 802 addresses for Ethernet links, that guides the design choices in the specification; section 3.2
and E.164 addresses for ISDN links. 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.
link-local address 1.1. Specification Language
- 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.
preferred address In this document, several words are used to signify the requirements
- An address assigned to an interface whose use by of the specification. These words are often capitalized.
upper layer protocols is unrestricted. Preferred
addresses may be used as the source or destination
address of packets sent from or to the interface.
deprecated address MUST This word, or the adjective "required", means
- An address assigned to an interface whose use is that the definition is an absolute requirement
discouraged, but not forbidden. A deprecated of the specification.
address should no longer be used as a source address
in new communications. but packets sent to a
deprecated address are delivered as expected.
A deprecated address may continue to be used as a
source address for the duration of existing
communications.
valid address MUST NOT This phrase means that the definition is an
- A preferred or deprecated address. A valid address absolute prohibition of the specification.
may appear as the source or destination address of a
packet, and the internet routing system is expected to
be able to deliver packets sent to a valid address.
invalid address SHOULD This word, or the adjective "recommended",
- An address that is not assigned to any interface. A means that there may exist valid reasons in
valid address becomes invalid when its valid particular circumstances to ignore this item,
lifetime expires. Invalid addresses should not appear but the full implications must be understood
as the source or destination of a packet. and carefully weighed before choosing a
different course. Unexpected results may
result otherwise.
preferred lifetime MAY This word, or the adjective "optional", means
- The length of time that a valid address is preferred. that this item is one of an allowed set of
When the preferred lifetime expires, the address alternatives. An implementation which does
becomes deprecated. not include this option MUST be prepared to
interoperate with another implementation which
does include the option.
valid lifetime silently discard The implementation discards the datagram
- The length of time the address remains in the valid without further processing, and without
state. The valid lifetime MUST be greater than or indicating an error to the sender. The
equal to the preferred lifetime. When the valid implementation SHOULD provide the capability of
lifetime expires, the address becomes invalid. logging the error, including the contents of
the discarded datagram, and SHOULD record the
event in a statistics counter.
interface token 2. Terminology and Definitions
- A link-dependent identifier for an interface that
is (at least) unique per link. Stateless Address
Autoconfiguration combines an interface token with
a prefix to form an address. From an address
autoconfiguration perspective, an interface token
is a bit string of known length. The exact length
of an interface token and the way it is created is
defined in a separate link-specific document that
covers issues related to the transmission of IP
over a particular link type (e.g., [IPv6-ETHER]).
In many cases the token will be the same as the
link-layer address.
2.2. DHCPv6 Terminology Relevant terminology from the IPv6 Protocol [2], IPv6 Addressing
Architecture, and IPv6 Stateless Address Autoconfiguration will be
provided, and then the DHCPv6 terminology.
configuration parameters 2.1. IPv6 Terminology
- Is any parameter that can be used by a node to
configure their network environment so the node can
communicate on a link or on an internet.
client - A client is a host that initiates requests on a link IP
to obtain: addresses, dynamic updates to DNS, or
other configuration parameters.
server - A server is a node that responds to requests from Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6
clients on a link to provide: addresses, dynamic are used only in contexts where necessary to avoid ambiguity.
updates to DNS, or other configuration parameters.
relay-agent - A relay-agent is a node that listens on a link for node
client requests, and then forwards the packet to a
server on the network. The server will respond back
to the relay-agent, who will forward the response to
the client on the relay-agents link.
message-type - The message-type defines the DHCPv6 protocol type for A device that implements IPv6.
this packet.
message-flag - The message-flag defines an optional processing router
notification for DHCPv6. The message-flag can also
be used by the Options for DHCPv6 specification.
error-code - The error-code specifies errors from a client or A node that forwards IPv6 datagrams not explicitly addressed to
server. The error-code can also be used by the itself.
Options for DHCPv6 specification.
total-addresses host
- The total-addresses specifies the total number of
addresses being provided from a server to a client.
For each address there is a preferred and valid
lifetime.
completed-transaction Any node that is not a router.
- A completed-transaction is a communications exchange
between a client and server, using the required set
of DHCPv6 request/response message-types, where the
final response message in the request/response set
has been received by the client and by the server.
transaction-ID link
- The transaction-ID is an integer identifier specified
by the client and is used by the client and server as
a transaction identifier to define the set of
request/response messages between the client and
server, for a clients interface token.
client-link address A communication facility or medium over which nodes can
- The client-link address specifies the clients communicate at the link layer, i.e., the layer immediately
link-local address. The client-link address below IPv6. Examples are Ethernet (simple or bridged); PPP
is used by a relay-agent to respond to a client links, X.25, Frame Relay, or ATM networks; and internet (or
on a link, after receiving a server response. higher) layer "tunnels", such as tunnels over IPv4 or IPv6
itself.
server address link-layer identifier
- The server address specifies the address for the
server responding to a client.
gateway address a link-layer identifier for an interface. Examples include
- The gateway address specifies the address of the IEEE 802 addresses for Ethernet links, and E.164 addresses for
relay-agent for a server, which may be multiple ISDN links.
relay-agent hops away from the original relay-agent.
client address link-local address
- The client address specifies an address from a
server to be used by a client.
binding - A binding in DHCPv6 is an N-tuple that a client An address having link-only scope that can be used to reach
and server MUST maintain in DHCPv6 for a neighboring nodes attached to the same link. All interfaces
completed-transaction, where N is the number of have a link-local address.
configuration parameters for a client. An
implementation MUST support at least a 5-tuple
binding consisting of a clients interface token,
client address, preferred lifetime and valid
lifetime for each client address, and the
transaction-ID.
3. Protocol Design Model neighbors
This section is provided for implementors to understand the DHCPv6 Nodes attached to the same link.
protocol design model from an architectural perspective. Any
conceptual models presented in this specification that provide
implementation examples are not a requirement of the DHCPv6 protocol.
3.1. Design Goals interface
The following list gives general design goals for DHCPv6. A node's attachment to the link.
DHCPv6 should be a mechanism rather than a policy. DHCPv6 must address
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.
Hosts should require no manual configuration. Each host should be An IP layer identifier for an interface or a set of interfaces.
able to discover appropriate local configuration parameters
without user intervention, and incorporate those parameters into
its own configuration.
Networks should require no hand configuration for individual message
hosts. Under normal circumstances, the network manager should not
have to enter any per-host configuration parameters.
DHCPv6 should not require a server on each link. To allow for The data exchanged between DHCP agents and clients; in this
scale and economy, DHCPv6 must work across relay agents. specification, messages are delivered via IPv6 and UDP.
A DHCPv6 client must be prepared to receive multiple responses to datagram
a request for configuration parameters. Some installations may
include multiple, overlapping DHCPv6 servers to enhance
reliability and increase performance.
DHCPv6 must coexist with statically configured, non-participating An IP header plus payload.
hosts and with existing network protocol implementations.
DHCPv6 should as much as possible be compatible with IPv6 unicast address
Stateless Address Autoconfiguration.
DHCPv6 must support the requirements of automated renumbering of An identifier for a single interface. A datagram sent to a
IPv6 addresses. unicast address is delivered to the interface identified by
that address.
DHCPv6 servers should be able to support Dynamic Updates to DNS multicast address
[DYN-UPD].
It is NOT a design goal of DHCPv6 to specify a server to server An identifier for a set of interfaces (typically belonging to
protocol. different nodes). A datagram sent to a multicast address is
delivered to all interfaces identified by that address.
It is NOT a design goal of DHCPv6 to specify how a server 2.2. DHCPv6 Terminology
configuration parameter database is maintained or determined.
The following list gives design goals specific to the transmission of configuration parameter
the network layer parameters.
Guarantee that any specific network address will not be in use by Any parameter that can be used by a node to configure its
more than one host at a time. network environment and enable communication on a link or
internetwork.
Guarantee that client addresses that are not provided by DHCPv6 client
will not be added to a servers configuration parameter database or
the servers binding for a clients interface token.
Retain host configuration parameters across client reboots. A A host that initiates requests on a link to obtain
client should, whenever possible, be assigned the same configuration parameters.
configuration parameters in response to a request.
Retain host configuration across server reboots, and, whenever server
possible, a host should be assigned the same configuration
parameters despite restarts of the DHCPv6 mechanism,
Allow automatic assignment of configuration parameters to new A server is a node that responds to requests from clients on a
hosts to avoid hand configuration for new hosts. link to provide: addresses, dynamic updates to DNS, or other
configuration parameters.
Support fixed or permanent allocation of configuration parameters relay
to specific hosts.
3.2. Request/Response Model A node that may advertise DHCP server addresses, or may act as
an intermediary to deliver DHCP messages between clients and
servers.
DHCPv6 uses a message-type to define whether the packet originated DHCP Agent
from a DHCPv6 server or client. The set of packets used to complete
a DHCPv6 transaction are defined as the request and response set.
The message types are as follows: Either a DHCPv6 server or a DHCPv6 relay.
01 DISCOVER agent address
The DISCOVER message is a DHCPv6 multicast packet from a client The address of a neighboring DHCP relay or DHCP server on the
to locate and request configuration parameters on a network, same link as the DHCP client.
when the client does not know the servers address.
02 CONF-REQUEST msg-type
The CONF-REQUEST is an IPv6 unicast packet from a client to a The msg-type defines the DHCPv6 protocol type for a message.
server, when the client knows the IPv6 unicast address of a
server, to request configuration parameters on a network.
03 CONF-RESPONSE transaction-ID
The CONF-RESPONSE is an IPv6 unicast packet from a server in The transaction-ID is a monotonically increasing integer
response to a client DISCOVER or CONF-REQUEST, which provides identifier specified by the client and is used by the client to
the requested configuration parameters. match a DHCP Reply to a pending DHCP Request.
04 ACCEPT server address
The ACCEPT is a client response to a server CONF-RESPONSE. When The server address specifies the address for the server
the client used DISCOVER to locate a server and request responding to a client.
configuration parameters on a network, the ACCEPT should be
sent using the DHCPv6 multicast address, which also serves to
inform other servers that responded to the DISCOVER they were
not selected. When the client used CONF-RESPONSE to request
configuration parameters from a server whose address was known,
the ACCEPT should be sent as an IPv6 unicast packet. The
ACCEPT is also an implied acknowledgment to the server selected
that the client has received the servers configuration
parameters from the CONF-RESPONSE.
05 SERVER-ACK binding
The SERVER-ACK is an IPv6 unicast packet sent by a server to A binding in DHCPv6 contains the data which a DHCPv6 server
inform a client that it received an ACCEPT. The SERVER-ACK is MUST maintain for each of its clients. An implementation
used by the server to inform the client it has received an MUST support bindings consisting of at least a client's
acknowledgment that the client has received the configuration link-local address, agent address, preferred lifetime and valid
parameters from the server, and denotes a completed-transaction lifetime [9] for each client address, and the transaction-ID.
to a server. The server at that point MUST commit its bindings
and any updates it may do for the client. The SERVER-ACK for
the client denotes a completed-transaction. The client at that
point MUST commit its bindings.
06 RELEASE 3. Protocol Design Model
The RELEASE is used by the client for two reasons: 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.
1. To inform the server that the client did not receive the 3.1. Design Goals
SERVER-ACK required to complete the client transaction,
and the server should delete that binding and any
updates it may have done on behalf of the client.
2. To inform the server that the client is releasing a The following list gives general design goals for this DHCPv6
particular address or set of addresses, even though the specification.
lifetimes for those addresses may not have become
invalid.
The processing and algorithms for the request/response set of - DHCPv6 should be a mechanism rather than a policy. DHCPv6 must
message-types will be discussed in section 4.0. 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.
3.3. Leased Address Model - 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.
The leased address model specifies a set of lifetimes associated with - DHCPv6 MUST NOT require a server on each link. To allow for
addresses returned by the server. These lifetimes are meant to scale and economy, DHCPv6 must work across relay agents.
support site renumbering, and are completely compatible with the
leasing model in IPv6 Stateless Address Autoconfiguration.
The DHCPv6 philosophy is that the client has the responsibility to - A DHCPv6 client must be prepared to receive multiple responses to
renew a lease for an address that is about to expire, or request a solicitations for DHCP servers. Some installations may include
new address or the same address before the lease actually expires. multiple, overlapping DHCPv6 servers to enhance reliability
If the client does not request a new lease for an address, the server and/or to increase performance.
MUST assume the client does not want a new lease for that address.
The server MAY provide that address to another client requesting an
address, after all other addresses available to the server have been
exhausted.
3.3.1. Address Lifetimes - DHCPv6 must coexist with statically configured, non-participating
hosts and with existing network protocol implementations.
An address returned to a client has a preferred and valid lifetime. - DHCPv6 MUST be compatible with IPv6 Stateless Address
The lifetimes represent the lease for addresses provided to the Autoconfiguration.
client, from the server.
The client MAY request a value for the lifetimes returned by a - DHCPv6 must support the requirements of automated renumbering of
server, but the client MUST use the lifetimes provided by the server IPv6 addresses [1].
response.
When an address for a client interface becomes deprecated the - DHCPv6 servers should be able to support Dynamic Updates to
processing of the lease MUST be as follows: DNS [10].
When the preferred lifetime of an address expires, the clients - A DHCPv6 server to server protocol is NOT part of this DHCPv6
address becomes a deprecated address. A deprecated address can be specification.
used as a source address in new communications and existing
communications. But a deprecated address means the node will soon
have an address whose valid lifetime will expire, when this
happens the address cannot be used in any communications.
An address is a deprecated until its valid lifetime expires at - It is NOT a design goal of DHCPv6 to specify how a server
which point the address becomes an invalid address. An invalid configuration parameter database is maintained or determined.
address MUST NOT be used as a source address in outgoing Methods for configuring DHCP servers are outside the scope of
communications, and MUST NOT be recognized as a valid destination this document.
address for incoming communications.
Once an address is deprecated an implementation SHOULD request a 3.2. DHCPv6 Messages
new lease or address for that interface.
If the clients preferred lifetime is zero for an address the address Each DHCPv6 message contains a type, which defines whether the
is immediately deprecated. message originated from a DHCPv6 server or client.
Implementors of DHCPv6 would find it beneficial to coordinate the use The message types are as follows:
of the preferred lifetime and valid lifetime for layers below the
DHCPv6 application layer with their implementation of Stateless
Address Autoconfiguration. It is suggested that implementations use
the same modules to configure addresses for stateless and stateful
address autoconfiguration. Implementors might want to consider an
option to stop all new communications for a deprecated address, to
support a very robust renumbering strategy, but this cannot be the
default behavior.
3.3.2. Duplicate Address Detection 01 DHCP Solicit
DHCPv6 clients MUST support Duplicate Address Detection as specified The DHCP Solicit message is a DHCPv6 multicast (or in special
in IPv6 Stateless Address Autoconfiguration. This will provide a high circumstances unicast) message from a client to one or more
guarantee that DHCPv6 client addresses are not duplicated on a link. neighboring DHCPv6 Agents.
It is an option for a server to inform the client it does not have to 02 DHCP Advertise
perform Duplicate Address Detection by the server setting a value of
01 in the message-flag in client responses. In this case it is
assumed that the server implementation is providing the guarantee
that the client addresses returned are unique on the link. It is
implementation defined how a server verifies the uniqueness of client
addresses on a link.
A conceptual model of an implementation for DHCPv6 duplicate address The DHCP Advertise is an IPv6 unicast message from a DHCP Agent
detection is that the client DHCPv6 module, which supports updating in response to a client DHCP Solicit.
the network interfaces for a host, would use the same application
configuration interface for DHCPv6 as is used for IPv6 Stateless
Address Autoconfiguration on an IPv6 conforming implementation. An
implementation can integrate and reuse the same modules in the
network operating system kernel to spawn duplicate address detection,
address lifetime processing, and the processing of deprecated and
invalid addresses for existing and new connections.
3.3.3. Releasing Infinite Lifetime Addresses 03 DHCP Request
DHCPv6 specifies no behavior which would require a client to listen The DHCP Request is an IPv6 unicast message from a client to
for asynchronous messages from servers on a well known UDP port. The a server, when the client knows the IPv6 unicast address of a
reason for this is that minimal implementations may not be able to server, to request configuration parameters on a network.
support such a feature in a client. But DHCPv6 does permit the
client to request an infinite lease for addresses. The problem in
this case is that though the server has permitted an infinite lease
for a client it may later be required that the client give up that
lease or the addresses, for some organizational reason.
This specification leaves it as implementation defined how this 04 DHCP Reply
problem is solved in a DHCPv6 network environment.
One solution to the problem is to define an SNMP MIB for DHCPv6 The DHCP Reply is an IPv6 unicast message sent by a server to
clients that when set by a network management agent causes a client respond to a client's DHCP Request. Extensions [5] to the DHCP
to revalidate all of its addresses with the DHCPv6 server or issue a Reply describe the resources that the DHCP Server has committed
RELEASE to the server. and allocated to the client, and may contain other information
for use by the client.
3.4. DNS Host Name Autoregistration Model 05 DHCP Release
It is important that DHCPv6 provide a server implementation set of The DHCP Release message is used by a DHCPv6 client to inform
options for Dynamic Updates to DNS (DYNDNS), to support the the server that the client is releasing a particular address,
autoregistration of addresses to names in IPv6. DYNDNS SHOULD be or set of addresses or resources, even though the addresses or
supported as a set of options in DHCPv6 as specified in the Options resources may still be marked valid in the server's binding for
for DHCPv6 specification. The minimum requirements to support DYNDNS the client.
in DHCPv6 are as follows:
1. Clients SHOULD be able to request or change names for 06 DHCP Reconfigure
addresses.
2. Servers SHOULD be able to provide names for addresses The DHCP Reconfigure message is used by a DHCPv6 server
provided to a client. 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. If servers support DYNDNS then they MUST support the 3.3. Request/Response Processing Model
following:
a) Create, Update, and Delete of IPv6 AAAA Records Processing details for the DHCP messages listed above are specified
[IPv6-DNS] as specified in DYNDNS [DYN-UPD]. in Sections 5, 6, and 7.
b) Create, Update, and Delete of IPv6 IP6.INT Domain PTR The request/response processing for DHCPv6 is transaction based
records for any IPv6 AAAA addresses defined in a client and uses a best-effort set of messages to guarantee a completed
DYNDNS request, or that the server automatically generated transaction. The timeout and retransmission guidelines and
for a client. configuration variables are discussed in Section 7.4.
4. Request/Response Processing 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
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.
The request/response processing for DHCPv6 is transaction based and 4. DHCPv6 Message Formats and Field Definitions
uses a best-effort set of messages to guarantee a completed-
transaction. The case where the client does not know the servers
address is depicted, and then the case where the client does know the
servers address is depicted. Then the timeout and retransmission
guidelines and configuration variables are discussed.
4.1. Processing when Server Address is not Known 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.
The processing for the DHCPv6 request/response model when the client All DHCP Agents MUST join the DHCPv6 Server/Relay-Agent multicast
does not know the server address is as follows: group at the well-known multicast address FF02:0:0:0:0:0:1:0.
Server Client Server Servers on the same link as the client MUST use the source address
(not selected) (selected) in the IPv6 header from the client as the destination address in the
server's response datagrams.
v v v 4.1. UDP Ports used for DHCPv6 messages
| | |
| Begin Transaction |
| | |
| _____________ | _____________ |
| DISCOVER | DISCOVER |
| (DHCPv6 Multicast) |
| | |
Determine Client Configuration | Determine Client Configuration
| (Unicast) |
| ___________ | ____________ |
| CONF-RESPONSE | CONF-RESPONSE |
| | |
| Collects replies |
| | |
| Selects configuration |
| | |
| _____________ | _____________ |
| ACCEPT | ACCEPT |
| (DHCPv6 Multicast) |
| | |
| | Commits Client Bindings
| | (Unicast)
| | |
| | _____________ |
| | SERVER-ACK |
| | |
| Transaction Complete |
| Client commits Bindings |
| | |
| IF the Client did not |
| receive the SERVER-ACK |
| delete the Bindings |
| (Unicast) |
| | |
| | _____________ |
| | RELEASE |
| | |
| | Server deletes the Bindings
| | and rolls back any updates that
| | that may have been done for the
| | client.
| | |
v v v
DHCPv6 uses the UDP [RFC-768] protocol to communicate between clients DHCPv6 uses the UDP [7] protocol to communicate between clients
and servers. UDP is not reliable, but DHCPv6 must provide some and servers. UDP is not reliable, but DHCPv6 must provide some
reliabilty between clients and servers. The network trade-off is reliability between clients and servers. If a response is not
time versus the reliability that the completed set of received after transmission of a DHCP message, the message MUST be
request/response messages were received by both the client and the retransmitted according to the rules specified in 7.4.
server to define a completed-transaction.
The request/response set is always started by a client either with a A Client MUST transmit all messages over UDP using UDP port 547 as
DISCOVER when the client does not know the servers address, or a the destination port. A client MUST receive all messages from UDP
CONF-REQUEST when the client does know the servers address. The port 546.
second message is from the server and is the CONF-RESPONSE. The
client then acknowledges the servers CONF-RESPONSE with an ACCEPT.
At this point in the flow all data has been received and additional
messages are defined to insure the transaction is completed, and to
provide a method of recovery if either the client or server do not
receive the messages to complete the transaction.
The server after receiving the ACCEPT sends a SERVER-ACK, which is an A DHCP Agent MUST transmit all messages over UDP using UDP port 546
acknowledgment to the client the server has received the clients as the destination port. A DHCP Agent MUST receive all messages over
ACCEPT. At that point the time vs reliability trade-off in DHCPv6 is UDP using UDP port 547.
for the server to commit its bindings, and perform any updates as a
result of the client messages (e.g. Update DNS). If the client
receives the SERVER-ACK, then the client can commit its bindings.
But if the client does not receive the SERVER-ACK then it should send
the server a RELEASE to inform the server that any bindings should be
deleted and any updates for the client should be rolled back. The
client RELEASE provides the final recovery check in the DHCPv6
request/response set to complete a transaction.
Retransmission of messages is discussed in section 4.3. 4.2. DHCP Solicit Message Format
The ACCEPT in the flow above is a multicast packet which serves an A DHCPv6 client transmits a DHCP Solicit message to obtain the
overloaded function, to respond to the selected server, and to inform address of a neighboring DHCP Agent, and to obtain one or more
other servers on the network the client is not selecting them. 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,
the client SHOULD use, as the destination IP address, the DHCPv6
Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0.
4.2. Processing when Server Address is Known 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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The processing for the DHCPv6 request/response model when the client msg-type 1
does knows the server address is as follows (all packets are
Unicast):
Client Server msg-flags 0
v v v RESERVED 0
| | |
| Begin Transaction |
| | |
| | _____________ |
| | CONF-REQUEST |
| | |
| | Determine Client Configuration
| | |
| | ____________ |
| | CONF-RESPONSE |
| | |
| | _____________ |
| | ACCEPT |
| | |
| | Commits Client Bindings
| | |
| | _____________ |
| | SERVER-ACK |
| | |
| Transaction Complete |
| Client commits Bindings |
| | |
| IF the Client did not |
| receive the SERVER-ACK |
| | |
| | _____________ |
| | RELEASE |
| | |
| | Server deletes the Bindings
| | and rolls back any updates that
| | that may have been done for the
| | client.
| | |
v v v
The processing above is the same as was discussed in 4.1, except the extensions No extensions are defined at this time.
CONF-REQUEST is used by the client to request configuration parameters
from the server, and the CONF-REQUEST and ACCEPT are unicast packets.
4.3. Retransmission and Configuation Variables 4.3. DHCP Advertise Message Format
Configuration variables for a DHCPv6 implementation that MUST be A DHCPv6 agent sends a DHCP Advertise message to inform a prospective
configurable by a client or server are as follows: client about the IPv6 address of a DHCP Agent to which a DHCP Request
message may be sent.
Retranstimer - The time in seconds that a DHCPv6 client or server A DHCPv6 agent MAY periodically transmit DHCP Advertise messages to
should wait before retransmitting a message. the All-DHCPv6 Clients multicast address, no more often than once per
second, and with TTL == 1.
Default: 3 seconds. 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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maxretrans - The maximum retransmissions that a DHCPv6 client msg-type 2
or server should retransmit, before logging a
DHCPv6 System Error to the user.
Default: 3 retransmissions. S If set, the agent address is also a server
address.
The problem with retransmissions occurs when they are continually msg-flags 0
received by a client or server (e.g. duplicate bindings or updates).
To support informing a client or server that a retransmission is server-count The number of addresses listed in the server
being done a second set of message-types are supported in DHCPv6 as addresses field.
follows:
20 - DISCOVER-Retrans RESERVED 0
21 - CONF-REQUEST-Retrans
22 - CONF-RESPONSE-Retrans
23 - ACCEPT-Retrans
24 - SERVER-ACK-Retrans
25 - RELEASE-Retrans
When a client or server retransmits a DHCPv6 packet at the agent address The IPv6 address of a neighboring DHCP Agent
application layer over UDP, they MUST change the message-type to the interface
same message-type with the Retrans suffix.
A response to a retransmission SHOULD be a duplicate of a previous server addresses The IPv6 address(es) of the DHCPv6 server(s)
response to the client or server. It is implementation defined how which the DHCP Agent has been configured to
this is accomplished. advertise.
One method of retransmitting duplicates in an implementation extensions See [5].
conceptually is to use the 5-Tuple binding for a client or server to
search for a previous response. At a minimum the client interface
token and transaction-ID will be present in all messages; hence a
binding can be searched (whether committed or in process) to verify
if a previous response has been sent.
5. Datagram and Field Definitions 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.
5.1. Datagram 4.4. DHCP Request Message Format
DHCPv6 Datagram 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
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 | msg-flag | error-code | total-addrs | | msg-type |S|C| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interface token |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| gateway address | | (if present) |
| (16 octets) | | server address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-link address | | agent address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred lifetime | | link-local address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client address |
| (16 octets) | | (16 octets) |
| (can be multiple addresses and lifetimes present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) | | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Field Definitions msg-type 3
All fields in the datagram MUST be initialized to binary zeroes by
both the client and server messages unless otherwise noted in Section
6.
msg-type - 1 octet integer value (message-type)
Value Description
01 DISCOVER
02 CONF-REQUEST
03 CONF-RESPONSE
04 ACCEPT
05 SERVER-ACK
06 RELEASE
07-19 RESERVED
20 DISCOVER-Retrans
21 CONF-REQUEST-Retrans
22 CONF-RESPONSE
23 ACCEPT-Retrans
24 SERVER-ACK-Retrans
25 RELEASE-Retrans
26-255 RESERVED
msg-flag - 1 octet integer value (message-flag)
Value Description
01 Server - Duplicate Address Detection not Required.
02-255 RESERVED
error-code - 1 octet integer value
Value Description
01 Server - Addresses are not available at this time.
02 Server - Address not known by the Server
03-255 RESERVED
total-addrs - 1 octet integer value (total-addresses)
RESERVED - 2 octets Reserved for future use.
transaction-ID - 2 octets integer value
interface token - 8 octets link-dependent identifier
server address - 16 octets address
gateway address - 16 octets address
client-link address - 16 octets link-local address
preferred lifetime - 4 octets integer value in seconds
valid lifetime - 4 octets integer value in seconds
client address - 16 octets address
options - variable number of octets [DHCPv6-OPT]
6. Client/Server Message Formats
6.1. Client/Server UDP Ports, Multicast Group, and Addresses
A client MUST transmit all messages over UDP using UDP Server Port 547.
A server or relay-agent MUST transmit all messages over UDP using UDP
Client Port 546.
A client MUST receive all messages over UDP using UDP Client Port 546.
A server or relay-agent MUST receive all messages over UDP using UDP
Server Port 547.
A server or relay-agent MUST join the DHCPv6 Server/Relay-Agent
multicast group 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
servers response packet. Servers that respond to relay-agents and
relay-agent processing are discussed in section 7.
In the cases where a client or server must retransmit messages the
msg-type codes in this section are used as stated in section 4.3 with
the values that represent the Retrans suffix for the msg-types.
6.2. Client DISCOVER and CONF-REQUEST Messages
msg-type:
If the client does not know the server address or wants to locate a new
server to receive configuration parameters the client sets the msg-type
to DISCOVER. In this case the client MUST use as the destination
IP address the DHCPv6 Server/Relay-Agent multicast address
FF02:0:0:0:0:0:1:0.
If the client knows the server address the client sets the msg-type to
CONF-REQUEST. In this case the client MUST use as the destination
IP address the server address.
msg-flag:
Set to binary zeroes.
error-code:
Set to binary zeroes.
total-addrs:
Set to the number of addresses the client is requesting.
transaction-ID:
Set to an integer value.
interface token:
Set to a unique link dependent identifier for the clients interface.
server address:
Set to binary zeroes for DISCOVER.
Set to server address for CONF-REQUEST.
gateway address:
Set to binary zeroes.
client-link address:
Set to the clients link-local address for the link on which the client
transmitted the packet.
preferred lifetime:
Set to binary zeroes if the client is not requesting a lifetime.
Set to the number of seconds the client wants for the lifetime.
Set to all 1's (oxffffffff) if the client wants an infinite lifetime.
The client must provide a preferred lifetime for each address
requested.
valid lifetime:
Set to binary zeroes if the client is not requesting a lifetime.
Set to the number of seconds the client wants for the lifetime.
Set to all 1's (oxffffffff) if the client wants an infinite lifetime.
The client must provide a valid lifetime for each address
requested. The valid lifetime must be greater than or equal to the
preferred lifetime.
client address:
Set to binary zeroes if the client is not requesting a renewal for an
existing address it received from a server.
Set to an address the client previously received from a server when the
client is requesting a new set of lifetimes for the address.
A client MUST NOT provide a server with an address that was not given
to the client by a server. DHCPv6 does not permit a server to create
leases for manual configured addresses, or update leases for addresses
created by IPv6 Stateless Address Autoconfiguration.
options:
See Options for DHCPv6 specification [DHCPv6-OPT].
6.3. Server CONF-RESPONSE Message
msg-type:
Set msg-type to CONF-RESPONSE.
msg-flag: S If set, the server address is present
Set to 01 if the server knows addresses provided are verified to be C If set, the client requests the server to
unique, otherwise set to binary zeroes. clear all existing resources and bindings
currently associated with the client,
deallocating as needed.
error-code: reserved 0
Set to 01 if the server cannot provide any addresses to the client at transaction-ID A monotonically increasing number which the
this time. client asks the server to copy into its DHCP
Set to 02 if the server detects an address from the client it did not Reply, so that the client can match Replies
provide to the client. with pending Requests.
total-addrs: server address If present, the IPv6 address of the DHCPv6
server which should receive the client's DHCP
Request message.
Set to the number of addresses the server is returning the client. agent address The IPv6 address of the relay or server
interface from which the client received the
DHCP Advertise message
transaction-ID: 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].
Set to the value the client provided in the DISCOVER or CONF-REQUEST 4.5. DHCP Reply Message Format
msg-type.
interface token: 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.
Set to a unique link dependent identifier for the clients interface as 0 1 2 3
provided in the clients DISCOVER or CONF-REQUEST msg-type. 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) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
server address: msg-type 3
The address of the server responding. error code One of the following values:
gateway address: 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)
Set to the same value that existed when the server received the packet. 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.
client-link address: L If set, the link-local address is present
RESERVED 0
Set to the same value that existed when the server received the packet. link-local address If present, the IPv6 address of the client
interface which issued the corresponding DHCP
Request message.
preferred lifetime: extensions See [5].
Set to the value requested by the client or the value required by the If the 'L' bit is set, and thus the link-local address is present in
server. 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.
valid lifetime: 4.6. DHCP Release Message Format
Set to the value requested by the client or the value required by the The DHCP Release message is sent without the assistance of any DHCPv6
server. 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).
The valid lifetime MUST be greater than or equal to the preferred 0 1 2 3
lifetime. 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) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
client address: msg-type 5
Set to an address provided by the server if the client is not attempting D If the 'D' ("Direct") flag is set, the client
to renew existing addresses, meaning the address fields from the client instructs the server to send the DHCP Reply
have a value of binary zeroes. directly back to the client, instead of
using the given agent address and link-local
address to relay the Reply message.
If the error-code is set to 02 the server will only return the addresses msg-flags 0
that the server can verify were provided by the server. If no addresses transaction-ID A monotonically increasing number which the
could be verified the total-addrs field, lifetimes, and client address client asks the server to use in its DHCP
will be set to binary zeroes. In the case as far as the server is Reply, to help the client match Replies with
concerned the DHCPv6 transaction is completed and the server will not outstanding Releases.
expect a client ACCEPT message to its CONF-RESPONSE message.
options: agent address The IPv6 address of the agent interface to
which the client issued the DHCP Request
message
See Options for DHCPv6 specification [DHCPv6-OPT]. link-local address The IPv6 link-local address of the client
interface from which the the client issued
the DHCP Request message
6.4. Client ACCEPT Message extensions See [5]
msg-type: 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.
Set msg-type to ACCEPT. 4.7. DHCP Reconfigure Message Format
If the client sent a DISCOVER to request configuration parameters on the The DHCP Reconfigure message is sent without the assistance of any
link, then the client should use as the IP destination address the DHCPv6 DHCPv6 relay. When a server sends a Reconfigure message, the client
Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0. 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.
If the client sent a CONF-REQUEST to request configuration parameters on The client SHOULD listen at UDP port 546 to receive possible DHCP
the link, then the client should use as the IP destination address the server Reconfigure messages. If the client does not listen for DHCP
address in the CONF-RESPONSE from the server. 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.
If the client sees an error-code of 02 and the total-addrs field is See discussion in 6.3.
zero, the server cannot process any of the addresses requested and the
client should not send an ACCEPT to the server. If the client sees an
error-code of 02 and total-addrs does not equal zero it means the server
dropped addresses that it could not locate requested by the client.
msg-flag: 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) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Set to binary zeroes. msg-type 6
error-code: msg-flags 0
Set to binary zeroes. reserved 0
total-addrs: extensions See [5]
Set to 1. 5. DHCP Client Considerations
transaction-ID: A DHCPv6 client MUST silently discard any DHCP Solicit, DHCP Request,
or DHCP Release message it receives.
Set to the integer value that the client used on its initial DISCOVER or A DHCPv6 client should retain its configured parameters and resources
CONF-REQUEST msg-type to the server. 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.
interface token: 5.1. DHCP Solicit Message Processing
Set to the unique link dependent identifier for the clients interface If a node wishes to become a new DHCPv6 client, it must first locate
that was used for the clients initial DISCOVER or CONF-REQUEST msg-type a neighboring DHCP Agent. The client does this by multcasting
to the server. a DHCP Solicit message to the well-known multicast address
FF02:0:0:0:0:0:1:0, setting the TTL == 1.
server address: 5.2. DHCP Advertise Message Processing
Set to the address provided by the servers CONF-RESPONSE. 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.
gateway address: 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.
Set to binary zeroes. 5.3. DHCP Request Message Processing
client-link address: 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.
Set to the clients link-local address for the link on which the client If the client has no valid IPv6 address and the DHCP server is
transmitted the packet. 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.
preferred lifetime: 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.
Set to the first or only preferred lifetime returned for an address by If a client wishes to instruct a DHCP server to deallocate all
the server. 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.
valid lifetime: 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.
Set to the first or only valid lifetime returned for an address by the In any case, after choosing a transaction-ID which is numerically
server. 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
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.
The valid lifetime MUST be greater than or equal to the preferred For each pending DHCP Request message, a client MUST maintain the
lifetime. following information:
client address: - The transaction-ID of the Request message,
Set to the first or only address provided by the server. - The server address,
If the client did receive more than one address and lifetime, it MUST - The agent address,
store this data in an implementation defined manner, so that it can
issue a complete RELEASE for all addresses provided from the server
CONF-RESPONSE, if necessary later. But the ACCEPT does not need to carry
all those addresses to acknowledge the servers CONF-RESPONSE packet in
an ACCEPT.
options: - The time at which the next retransmission will be attempted, and
No options are present. - All Extensions appended to the reply message.
6.5. Server SERVER-ACK 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.
msg-type: 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.
Set msg-type to SERVER-ACK. 5.4. DHCP Reply Message Processing
If the client sent the ACCEPT to acknowledge a servers CONF-RESPONSE When a client receives a DHCP Reply message, it MUST check whether
message on the DHCPv6 Server/Relay-Agent multicast address the transaction-ID in the Reply message matches the transaction-ID
FF02:0:0:0:0:0:1:0, the server MUST look at the server address in the of a pending DHCP Request message. If no match is found, the Reply
packet to determine if the ACCEPT is for them or not. 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 message is not for a particular server then this is an indirect If the Reply message is acceptable, the client processes each
message to that particular server the client is not accepting them as Extension [5], extracting the relevant configuration information and
their server for this transaction, and MUST NOT send a SERVER-ACK to the parameters for its network operation.
clients ACCEPT.
msg-flag: Some configuration information extracted from the Extensions to the
DHCP Reply message must remain associated with the DHCP server that
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.
Set to binary zeroes. 5.5. DHCP Release Message Processing
error-code: 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.
Set to binary zeroes. 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.
total-addrs: 5.6. DHCP Reconfigure Message Processing
Set to 1. 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.
transaction-ID: 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.
Set to the integer value that the client used on its initial DISCOVER or For each Extension which is present in the Reconfigure message, the
CONF-REQUEST msg-type to the server. 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.
interface token: 6. DHCP Server Considerations
Set to the unique link dependent identifier for the clients interface A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP
that was used for the clients initial DISCOVER or CONF-REQUEST msg-type Reconfigure message it receives.
to the server.
server address: 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.
Set to the servers address. 6.1. DHCP Solicit and Advertise Message Processing
gateway address: 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.
Set to the same value that existed when the server received the packet. 6.2. DHCP Request and Reply Message Processing
client-link address: 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.
Set to the same value that existed when the server received the packet. 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
previously unknown client; otherwise, it SHOULD return a DHCP Reply
with a error code of 5.
preferred lifetime: 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.
Set to the value provided by the client. 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.
valid lifetime: 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.
Set to the value provided by the client. 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.
The valid lifetime MUST be greater than or equal to the preferred 6.3. DHCP Release Message Processing
lifetime.
client address: 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.
Set to the address provided by the client. 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).
At this point the server MUST commit the configuration parameters If the received agent address and link-local address do not
provided to the client from the servers CONF-RESPONSE. correspond to any binding known to the server, then the server SHOULD
return a DHCP Reply with a error code of 5.
options: 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.
No options are present. 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.6. Client RELEASE Message 6.4. DHCP Reconfigure Message Processing
msg-type: 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.
Set msg-type to RELEASE. 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.
If the client had sent an ACCEPT to the server and received a SERVER-ACK Perhaps a new extension should be defined so that
for that message then the client MUST commit the configuration the server can ask (some of) its clients to join a
parameters provided by the servers CONF-RESPONSE and a RELEASE message specific multicast group. Then the server could
is not required. But if the client did not receive a SERVER-ACK efficiently multicast Reconfigure messages to
in response to the clients ACCEPT, then the client MUST issue a RELEASE whatever group it wants.
to the server.
If the client no longer needs an address or has been notified to return This would have the additional advantage that
an address to the server, then the client SHOULD issue a RELEASE to the clients could receive Reconfigure messages without
server. listening to any specific UDP port.
msg-flag: If multiple clients can receive the same
Reconfigure message, some algorithm must be
specified so that the clients stagger their
responses (i.e., their DHCP Requests) so that
the server isn't deluged all at once with some
arbitrarily large number of client Requests.
Set to binary zeroes. 7. DHCP Relay Considerations
error-code: The DHCPv6 protocol is constructed so that a relay does not have
to maintain any state in order to facilitate DHCPv6 client/server
interactions.
Set to binary zeroes. 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.
total-addrs: 7.1. DHCP Solicit and DHCP Advertise Message Processing
Set to the total number of addresses the client is releasing. In the Upon receiving a DHCP Solicit message from a client, a relay
case of a RELEASE where the client did not receive the SERVER-ACK this constructs a DHCP Advertise message and transmits it to the
value MUST equal the total number of addresses for the servers soliciting client on the same link as the solicitation was received
CONF-RESPONSE. from. The destination address of the advertisement MUST be the
source address of the solicitation.
transaction-ID: 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.
Set to the integer value that the client used on its initial DISCOVER or When transmitting a DHCP Advertise message, a relay indicates how
CONF-REQUEST msg-type to the server. 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.
interface token: 7.2. DHCP Request Message Processing
Set to the unique link dependent identifier for the clients interface When a relay receives a DHCP Request message, it MUST check that the
that was used for the clients initial DISCOVER or CONF-REQUEST msg-type message is received from a link-local address, that the link-local
to the server. 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.
server address: 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.
Set to binary zeroes. 7.3. DHCP Reply Message Processing
gateway address: 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.
Set to binary zeroes. 7.4. Retransmission and Configuation Variables
client-link address: 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.
Set to the clients link-local address for the link on which the client Likewise, but less commonly, when a DHCP server does not receive a
transmitted the packet. 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.
preferred lifetime: These retransmissions occur using the following configuration
variables for a DHCPv6 implementation that MUST be configurable by a
client or server are as follows:
Set to the valid lifetime returned for an address by the server. REPLY_MSG_INITIAL_TIMEOUT
valid lifetime: The time in seconds that a DHCPv6 client waits to receive a
server's DHCP Reply before retransmitting a DHCP Request.
Set to the valid lifetime returned for an address by the server. Default: 2 seconds.
The valid lifetime MUST be greater than or equal to the preferred REPLY_MSG_MIN_RETRANS
lifetime.
client address: 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.
Set to the address provided by the server. Default: 10 retransmissions.
The client will return the number of addresses and associated lifetimes RECONF_MSG_INITIAL_TIMEOUT
provided in the servers CONF-RESPONSE.
options: The time in seconds that a DHCPv6 server waits to receive
a client's DHCP Request before retransmitting its DHCP
Reconfigure.
No options are present. Default: 2 seconds.
7. Relay-Agent Processing RECONF_MSG_MIN_RETRANS
The relay-agent MUST use UDP DHCPv6 Server Port 547 as the UDP port to The minimum number of DHCP Reconfigure messages that a DHCPv6
accept client responses in an implementation. 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.
The relay-agent MUST join the DHCP Server/Relay-Agent multicast group Default: 10 retransmissions.
well-known multicast address FF02:0:0:0:0:0:1:0.
When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it MUST: 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.
If the gateway address is NOT zero then the relay-agent MUST: TRANSACTION_IT_TIMEOUT
Put the relay-agents IP address in the gateway address field of Default: 10800 seconds
the clients request packet.
All relay-agents MUST: 8. Security Considerations
Put their relay-agent address as the source address for the IP It may often be very important for DHCP clients and servers to be
header. 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.
Put the next relay-agent or known server address as the There has been some discussion about the advisability and
destination address in the IP header. 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.
Forward the packet to the to the next hop relay-agent or That means that the authentication (in this circumstance) CANNOT be
known server. 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].
When the remote server receives the client request from the relay-agent One possibility is to allow relays to encapsulate the DHCP Request
it will know its a remote client request (not on the servers link), before delivery to the server. Then the client could apply
because there is a gateway address in the request. So servers MUST end-to-end authentication (such as afforded by IPSec) which would
verify the gateway address is not zero, to determine if the clients request nevertheless remain untouched by the relay. The relay could, if
is from a remote link. desired, apply its own authentication header to the encapsulated
datagrams.
The server responds as specified in section 6.0, but uses the 9. Acknowledgements
gateway address as the destination address in the IP header.
When the relay-agent receives the remote servers response, it MUST Thanks to the DHC Working Group for their time and input into the
forward the packet to the client, by using the client-link address as specification. A special thanks for the consistent input, ideas,
the source address for the IP Header. and review by (in alphabetical order) Brian Carpenter, Ralph Droms,
Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson,
and Phil Wells.
8. Security Considerations Thanks to Steve Deering and Bob Hinden, who have consistently
taken the time to discuss the more complex parts of the IPv6
specifications.
Security for DHCPv6 can be used as specified in [IPv6-SA], [IPv6-AUTH], The authors MUST also thank their employers for the opportunity and
and [IPv6-ESP], which are implementation requirements for IPv6. funding to work on DHCPv6 and IPv6 in general as an individual in the
IETF.
Appendix A - Related Work in IPv6 A. Related Work in IPv6
The related work in IPv6 that would best serve an implementor to study The related work in IPv6 that would best serve an implementor
is the IPv6 Specification [IPv6-SPEC], the IPv6 Addressing Architecture to study is the IPv6 Specification [2], the IPv6 Addressing
[IPv6-ADDR], IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF], Architecture [3], IPv6 Stateless Address Autoconfiguration [9], IPv6
IPv6 Neighbor Discovery Processing [IPv6-ND], and Dynamic Updates to DNS Neighbor Discovery Processing [4], and Dynamic Updates to DNS [10].
[DYN-UPD]. These specifications afford DHCPv6 to build upon the IPv6 These specifications afford DHCPv6 to build upon the IPv6 work to
work to provide both robust stateful autoconfiguration and provide both robust stateful autoconfiguration and autoregistration
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 DHCPv6 implementors to understand is that IPv6 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 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 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 UDP datagram of 536 octets will always pass through an internet (less
octets for the IPv6 header), as long as there are no IP options prior to 40 octets for the IPv6 header), as long as there are no IP options
the UDP datagram in the packet. But, IPv6 does not support prior to the UDP header in the datagram. But, IPv6 does not support
fragmentation at routers and fragmentation must take place end-to-end fragmentation at routers and fragmentation must take place end-to-end
between hosts. If a DHCPv6 implementation needs to send a packet between hosts. If a DHCPv6 implementation needs to send a datagram
greater than 536 octets it can either fragment the UDP datagram in UDP greater than 536 octets it can either fragment the UDP datagram
or use Path MTU Discovery [IPv6-SPEC] to determine the size of the in UDP or use Path MTU Discovery [2] to determine the size of the
packet that will traverse a network path. It is implementation defined datagram that will traverse a network path. It is implementation
how this is accomplished in DHCPv6. defined how this is accomplished in DHCPv6.
The IPv6 Addressing Architecture Specification provides the address The IPv6 Addressing Architecture Specification provides the address
scope that can be used in an IPv6 implementation, and the various scope that can be used in an IPv6 implementation, and the various
configuration architecture guidelines for network designers of the IPv6 configuration architecture guidelines for network designers of
address space. Two advantages of IPv6 is that multicast addressing is well the IPv6 address space. Two advantages of IPv6 is that multicast
defined and nodes can create link-local addresses during initialization addressing is well defined and nodes can create link-local addresses
of the nodes environment. This means that a host immediately can configure during initialization of the nodes environment. This means that a
an IPv6 address at initialization for an interface, before communicating in host immediately can configure an IPv6 address at initialization
any manner on the link. The host can then use a well-known multicast address for an interface, before communicating in any manner on the link.
to begin communications to discover neighbors on the link, or as was The host can then use a well-known multicast address to begin
discussed in the specification to locate a DHCPv6 server or relay-agent. 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 (addrconf) The IPv6 Stateless Address Autoconfiguration Specification [9]
defines how a host can autoconfigure addresses based on neighbor discovery defines how a host can autoconfigure addresses based on neighbor
router advertisements, and the use of a validation lifetime to support discovery router advertisements, and the use of a validation lifetime
renumbering of addresses on the Internet. In addition the addrconf to support renumbering of addresses on the Internet. In addition the
specification defines the protocol interaction for a host to begin stateless addrconf specification defines the protocol interaction for a host to
or stateful autoconfiguration. DHCPv6 is one vehicle to perform stateful begin stateless or stateful autoconfiguration. DHCPv6 is one vehicle
autoconfiguration. Compatibility with addrconf is a design goal of DHCPv6 to perform stateful autoconfiguration. Compatibility with addrconf
where possible. is a design goal of DHCPv6.
IPv6 Neighbor Discovery (ND) is the node discovery protocol in IPv6 IPv6 Neighbor Discovery (ND) [4] is the node discovery protocol in
(replaces and enhances functions of IPv4 ARP Model). To truly IPv6 (replaces and enhances functions of IPv4 ARP Model [6]). To
understand IPv6 and addrconf it is strongly recommended that truly understand IPv6 and addrconf it is strongly recommended that
implementors understand IPv6 ND. implementors understand IPv6 ND.
Dynamic Updates to DNS is a specification that supports the Dynamic Updates to DNS [10] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCPv6 can use 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 the dynamic updates to DNS to now integrate addresses and name space
not only support autoconfiguration, but also autoregistration in IPv6. to not only support autoconfiguration, but also autoregistration in
IPv6.
Change History
Changes from July 95 to November 95 Drafts:
Refined request/response codes and processing to support transaction
processing model.
Permit multiple addresses and lifetimes in a request and response.
Moved Dynamic Updates to DNS as an Option to be defined in that
specification.
Settled on using UDP as it supports DHCP client server model as opposed
to TCP which has overhead for this model.
Reformatted specification to support analysis, packet formats, and
processing in their own sections to make it easier for implementors to
read.
Removed address count as it is not necessary for synchronization.
Added error-code, msg-flag, and total-addrs fields.
Made transaction-ID 2 octets.
Updated terminology to coordinate with IPv6 Stateless Address
Autoconfiguration.
Added more implementation notes.
Moved IPv6 Related Work to an Appendix.
Fixed various bugs in the spec from DHC WG input.
Added Security reference pointers.
Removed options format, which will be in the options spec.
Added retransmission configuration variables, msg-types, and logic.
Changes from March 95 to July 95 Drafts:
Used integer values instead of bit values for type and code fields.
Used message-type and message-code fields and rely on looking at
the fields in the datagram instead of multiple over-lapping
request/response codes.
Added address-count field processing to be specified by the
client as opposed to the server, and the processing for when
client and server address-counts become disjoint.
Added Requirements wording for MUST, SHOULD, MAY, etc.
Added Design Goals section.
Redefined transaction-ID and interface-token.
Added Client/Server Binding definition and processing
section to handle those bindings.
Added more terminology, definitions, and rationale.
Added model to support Dynamic Updates to DNS for Host Names.
Reduced the request/response model to 3 packets by not doing
a server confirm to a clients confirm to a servers response.
Added model to support like lifetime fields for lease B. Change History
management to coordinate with IPv6 Stateless Address
Autoconfiguration.
Added model and processing definitions for future DHCPv6 Options B.1. Changes from November 95 to February 96 Drafts
Specification.
Added gateway-address and client-link-address for relay-agent Substituted use of client's link-local address for previous uses of
processing. client's interface token.
Removed excessive use of the acronym DHCPv6 for section titles Reorganized DHCP messages into Solicit/Advertise, Request/Reply,
and when referencing clients and servers. Release, and Reconfigure.
Added Draft ***Open Issues*** Section for review by the DHC Working Made message-specific formats instead of using the same DHCP header
Group. for each message.
Added Change History. Eliminated retransmission message types.
Acknowledgements Server commits after receiving DHCP Request, and optimistically
depends on client retransmissions as negative acknowledgement.
The DHC Working Group for their time and input into the specification. Eliminated total-addrs.
A special thanks for the consistent input, ideas, and review by (in
alphabetical order) Brian Carpenter, Ralph Droms, Thomas Narten, Jack
Mccann, Charlie Perkins, Yakov Rekhter, Matt Thomas, Sue Thomson, and
Phil Wells.
The author would also like to thank Steve Deering and Bob Hinden, Eliminated all definitions and most fields related to allocating IPv6
who have consistently taken the time to discuss the more complex addresses (moved to the Extensions specification).
parts of the IPv6 specifications.
The author MUST also thank his employer for the opportunity and funding Renamed "gateway address" to be "agent address".
to work on DHCPv6 and IPv6 in general as an individual in the IETF.
References References
[DHCPv6-OPT] [1] S. Bradner and A. Mankin. The Recommendation for the IP Next
C. Perkins, "Options for the Dynamic Host Configuration Generation Protocol. RFC 1752, January 1995.
Protocol for IPv6 (ODHCPv6)" Internet Draft, November 1995
<draft TBD>
[IPv6-SPEC] [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
S. Deering and R. Hinden, "Internet Protocol Version 6 Specification. RFC 1883, December 1995.
[IPv6] Specification" Internet Draft, June 1995
<draft-ietf-ipngwg-ipv6-spec-02.txt>
[IPv6-ADDR] [3] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
R. Hinden, S. Deering, Editors, "IP Version 6 Addressing Architecture" RFC 1883, December 1995.
<draft-ietf-ipngwg-ipv6-addr-arch-03.txt>
[IPv6-ADDRCONF] [4] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor
S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration" Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in
<draft-ietf-addrconf-ipv6-auto-05.txt> progress, November 1995.
[IPv6-ND] [5] C. Perkins. Extensions to DHCPv6. draft-ietf-dhc-dhcpv6ext-00.txt
T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Neighbor Discovery" -- work in progress, November 1995.
<draft-ietf-ipngwg-discovery-02.txt>
[IPv6-DNS] [6] David C. Plummer. An Ethernet Address Resolution Protocol:
S. Thompson and C. Huitema, "DNS Extensions to support IP Or Converting Network Protocol Addresses to 48.bit Ethernet
version 6", Internet Draft, March 1995 Addresses for Transmission on Ethernet Hardware. RFC 826,
<draft-ietf-ipngwg-dns-00.txt> November 1982.
[RFC-1034] [7] J. B. Postel. User Datagram Protocol. RFC 768, August 1980.
P. Mockapetris, "Domain Names - implementation and specification"
STD-13, 11/01/87
[RFC-1035]
P. Mockapetris, "Domain Names - concepts and facilities"
STD-13, 11/01/87
[DYN-UPD] [8] J. B. Postel, editor. Internet Protocol. RFC 791, September
S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain 1981.
Name System (DNS)" Internet Draft, March 1995
<draft-ietf-dnsind-dynDNS-01.txt>
[RFC-768] [9] S. Thomson and T. Narten. IPv6 Stateless Address
J. Postel, "User Datagram Protocol" Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt
STD-6, 08/28/80. - work in progress, November 1995.
[DHCP-v4] [10] S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the
R. Droms, "Dynamic Host Configuration Protocol" Domain Name System (DNS). draft-ietf-dnsind-dynDNS-06.txt --
RFC 1541 Proposed Standard, October 1993 work in progress, February 1996.
[IPv6-Ether] Chair's Address
M. Crawford, "A Method for the Transmission of IPv6 Packets over
Ethernet Networks", Internet Draft, October 1995
<draft-ietf-ipngwg-ethernet-ntwrks-01.txt>
[IPv6-SA] The working group can be contacted via the current chair:
R. Atkinson, "Security Architecture for the Internet Protocol"
RFC 1825, August 1995
[IPv6-AUTH] Ralph Droms
R. Atkinson, "IP Authentication Header" Computer Science Department
RFC 1826, August 1995 323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
[IPv6-ESP] Phone: (717) 524-1145
R. Atkinson, "IP Encapsulating Security Payload (ESP)" E-mail: droms@bucknell.edu
RFC 1827, August 1995
Authors' Address Author's Address
Jim Bound Questions about this memo can be directed to:
Digital Equipment Corporation
110 Spitbrook Road, ZKO3-3/U14 Jim Bound Charles Perkins
Nashua, NH 03062 Digital Equipment Corporation T. J. Watson Research Center
Phone: (603) 881-0400 110 Spitbrook Road, ZKO3-3/U14 IBM Corporation
Email: bound@zk3.dec.com 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
 End of changes. 

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