draft-ietf-dhc-dhcpv6-02.txt   draft-ietf-dhc-dhcpv6-03.txt 
INTERNET-DRAFT J. Bound INTERNET-DRAFT J. Bound
DHC Working Group Digital Equipment Corp DHC Working Group Digital Equipment Corp
Obsoletes: draft-ietf-dhc-dhcpv6-01.txt July 95 Obsoletes: draft-ietf-dhc-dhcpv6-02.txt November 1995
Dynamic Host Configuration Protocol for IPv6 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-02.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
Internet Engineering Task Force (IETF). Comments should be submitted
to the dhcp-v6@bucknell.edu mailing list.
This document is an Internet-Draft. Internet-Drafts are working 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 any
time. It is inappropriate to use Internet-Drafts as reference 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 Shadow ``1id-abstracts.txt'' listing contained in the Internet- Drafts
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
DHCPv6 is an Internet application protocol that uses a Client/Server This document is an Internet application protocol, for IP version 6
model to communicate between hosts. DHCPv6 executes over the UDP (IPv6), that specifies a client/server model for communications
[RFC-768] transport protocol, and the Internet Protocol Version 6 between hosts to dynamically configure parameters for a network, and
(IPv6) [IPv6-SPEC]. DHCPv6 is an IPv6 specification for a statefull autoconfigure addresses within a stateful model. This document
implementation of address autoconfiguration as referenced in IPv6 supports the model for IPv6 Stateless Address Autoconfiguration,
Stateless Address Configuration [IPv6-ADDRCONF]. DHCPv6 supports where there are clear integration points between stateless and
mechanisms to autoconfigure host IPv6 addresseses, autoregister host stateful address autoconfiguration for IPv6.
names dynamically in the Domain Name System (DNS), and specifies the
format to add future Configuration Parameter options to the protocol
for extensibility.
The work on this protocol will take place in the Dynamic Host Table of Contents:
Configuration (DHC) Working group. One may join the Working Group
mail list by sending mail to host-conf-request@sol.eg.bucknell.edu.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 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
Table of Contents: 1. Introduction
1. Introduction................................................3 DHCPv6 is an Internet application protocol, for IP version 6 (IPv6),
1.1 Requirements................................................3 that specifies a client/server model for communications between hosts
2. Terminology and Definitions.................................5 to dynamically configure parameters for a network, and autoconfigure
2.1 IPv6 Terminology............................................5 addresses within a stateful model. DHCPv6 supports the model for
2.2 DHCPv6 Terminology..........................................6 IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF], where there
3. Protocol Design Model.......................................8 are clear integration points between stateless and stateful address
3.1 Related Work in IPv6........................................8 autoconfiguration for IPv6.
3.2 Design Goals................................................9
3.3 Request/Response Model.....................................10
3.4 Leased Address Model.......................................11
3.5 DNS Host Name Autoregistration Model.......................12
3.6 Defining Optional Configuration-Data.......................13
4. Datagram and Data Formats..................................14
4.1 Datagram...................................................14
4.2 Data Formats...............................................14
5. Client/Server Processing...................................16
5.1 Client Transmission........................................16
5.2 Server Transmission........................................16
5.3 Client/Server Bindings.....................................17
5.4 Client Requests............................................17
5.5 Server Response............................................18
5.6 Client Confirmations/Rejections............................19
6. Relay-Agent Processing.....................................19
Draft ***Open Issues***........................................21
Change History.................................................22
Acknowledgements...............................................23
References.....................................................23
Authors' Addresses.............................................24
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 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.
1. Introduction DHCPv6 supports optional configuration parameters and processing for
hosts through its companion document Options for the Dynamic Host
Configuration Protocol for IPv6 [DHCPv6-OPT].
DHCPv6 is an Internet application protocol that uses a Client/Server The IPv6 Addressing Architecture [IPv6-ADDR] and IPv6 Stateless
model to communicate between hosts. DHCPv6 executes over the UDP Address Autoconfiguration specifications provide new functionality
[RFC-768] transport protocol, and the Internet Protocol Version 6 not present in IP version 4 (IPv4). This new IPv6 functionality
(IPv6) [IPv6-SPEC]. DHCPv6 is an IPv6 specification for a statefull provides inherent benefits to autoconfigure IPv6 addresses for nodes.
implementation of address autoconfiguration as referenced in IPv6 In addition the IETF DNS Working Group has defined a method to
Stateless Address Configuration [IPv6-ADDRCONF]. DHCPv6 supports support Dynamic Updates to DNS [DYN-UPD], which can be used by a node
mechanisms to autoconfigure host IPv6 addresseses, autoregister host to add, delete, and change node names dynamically.
names dynamically in the Domain Name System (DNS), and specifies the
format to add future Configuration Parameter options to the protocol
for extensibility.
The IPv6 new version of the Internet Protocol, is being developed DHCPv6 used several of the architecture principles from DHCPv4
with 128bit addresses. The IPv6 addressing architecture [IPv6-ADDR] [DHCP-v4], but it is beyond the scope of this document to contrast
and stateless address configuration [IPv6-ADDRCONF] specifications and compare DHCPv6 with DHCPv4.
provide new functionality not present in the Internet Protocol
version 4 (IPv4), which provide inherent benefits to autoconfigure
IPv6 addresses for host nodes. In addition the IETF DNS Working
Group has work in progress to support Dynamic Updates to DNS [DYN-
UPD], which can be used by a node to add, delete, and change host
names dynamically.
DHCPv6 uses the enhancements in IPv6 and DNS to define an efficient Section 2 provides definitions for terminology used throughout this
protocol, and is not required to support any IPv4 protocol for document. Section 3 provides a review of the protocol design model
backward compatibility. DHCPv6 does use many of the architectural parts that are inherent in the specification. Section 4 provides the
principles in DHCP for IPv4 (DHCPv4) [DHCP-v4]. It is not within the request/response model and interaction between the set of messages
scope of this document to compare and contrast DHCPv4 with DHCPv6. 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 1.1. Requirements
Throughout this document, the words that are used to define the Throughout this document, the words that are used to define the
significance of the particular requirements are capitalized. These significance of the particular requirements are capitalized. These
words are: words are:
o "MUST" o "MUST"
This word or the adjective "REQUIRED" means that the item is an This word or the adjective "REQUIRED" means that the item is an
absolute requirement of this specification. absolute requirement of this specification.
o "MUST NOT" o "MUST NOT"
This phrase means the item is an absolute prohibition of this This phrase means the item is an absolute prohibition of this
specification. specification.
o "SHOULD" o "SHOULD"
This word or the adjective "RECOMMENDED" means that there may This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this exist valid reasons in particular circumstances to ignore this
item, but the full impliciations should be understood and the case item, but the full implications should be understood and the case
carefully weighed before choosing a different course. carefully weighed before choosing a different course.
o "SHOULD NOT" o "SHOULD NOT"
This phrase means that there may exist valid reasons in particular This phrase means that there may exist valid reasons in particular
circumstances when the listed behavior is acceptable or even circumstances when the listed behavior is acceptable or even
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
useful, but the full implications should be understood and the useful, but the full implications should be understood and the
case carefully weighted before implementing any behavior described case carefully weighted before implementing any behavior described
with this label. with this label.
o "MAY" o "MAY"
This word or the adjective "OPTIONAL" means that this item is This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item because truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because it enhances the a particular marketplace requires it or because it enhances the
product, for example, another vendor may omit the same item. product, for example, another vendor may omit the same item.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
2. Terminology and Definitions 2. Terminology and Definitions
Terminology and Definitions are critical to the understanding of any Relevant terminology from the IPv6 Protocol [IPv6-SPEC], IPv6
IETF specification. This Section will provide the terms and Addressing Architecture, and IPv6 Stateless Address Autoconfiguration
definitions used throughout this specification. Relevant IPv6 will be provided, and then the DHCPv6 terminology.
specification [IPv6-SPEC], IPv6 Addressing Architecture [IPv6-ADDR],
and IPv6 Statelss Address Configuration [IPv6-ADDRCONF] terminology
will be provided, then the DHCPv6 terminology.
2.1 IPv6 Terminology
node: A device that implements IPv6. 2.1. IPv6 Terminology
router: A node that forwards IPv6 packets not explicitly addressed to IP - Internet Protocol Version 6 (IPv6). The terms
itself. IPv4 and IPv6 are used only in contexts where
necessary to avoid ambiguity.
host: Any node that is not a router. node - A device that implements IPv6.
link: A communication facility or medium over which nodes can router - A node that forwards IPv6 packets not explicitly
communicate at the link layer, i.e., the layer immediately below addressed to itself.
IPv6. Examples are Ethernets (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. host - Any node that is not a router.
interface: A nodes's attachment to the link. upper-layer - A protocol layer immediately above IP. Examples are
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.
address: An IPv6 layer identifier for an interface or a set of link - A communication facility or medium over which nodes
interfaces. can communicate at the link layer, i.e., the layer
immediately below IPv6. Examples are Ethernet
(simple or bridged); PPP links, X.25, Frame Relay,
or ATM networks; and internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself.
packet: An IPv6 header plus payload. neighbors - Nodes attached to the same link.
link MTU: The maximum transmission unit, i.e., maximum packet size in interface - A node's attachment to the link.
octets, that can be conveyed in one piece over a link.
path MTU: The minimum link MTU of all the links in a path between a address - An IP layer identifier for an interface or a set
source node and a destination node. of interfaces.
unicast address: An identifier for a single interface. A packet sent packet - An IP header plus payload.
to a unicast address is delivered to the interface identified by that
address.
multicast address: An identifier for a set of interfaces (typically communication
belonging to different nodes). A packet sent to a multicast address - Any packet exchange between nodes that requires
is delivered to all interfaces identified by that address. that the address of each node used in the exchange
remain the same for the duration of the packet
exchange. Examples are a TCP connection or UDP
request/response.
link-local address: The link-local address is for use on a single unicast address
link. On initialization of an interface, a host forms a link-local - An identifier for a single interface. A packet sent
address by concatenating a well-known link-local prefix to a token to a unicast address is delivered to the interface
that is unique per link. For example, in the case of a host attached identified by that address.
to a link that uses IEEE 802 addresses, the token is an IEEE 802
address associated with the interface.
validation-lifetime: This is the address lifetime for a single multicast address
address provided to a host. The validation-timer is in absolute time - An identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to a
multicast address is delivered to all interfaces
identified by that address.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 link-layer identifier
- a link-layer identifier for an interface. Examples
include IEEE 802 addresses for Ethernet links,
and E.164 addresses for ISDN links.
and in seconds (e.g. 3 hours would have the value 10800). link-local address
- An address having link-only scope that can be used
to reach neighboring nodes attached to the same link.
All interfaces have a link-local address.
deprecation-liftetime: This is the lifetime for a single address the preferred address
host uses to begin the deprecation of an address prior to the - An address assigned to an interface whose use by
validation-lifetime expiring, so that the host can determine if the upper layer protocols is unrestricted. Preferred
address can receive a new validation-lifetime. The deprecation- addresses may be used as the source or destination
lifetime is in absolute time and in seconds (e.g. 3 hours would have address of packets sent from or to the interface.
the value 10800). The deprecation-lifetime MUST be no greater than
the validation-lifetime.
deprecated-address: This is a single address that is in the deprecated address
deprecated state on a host because the deprecation-lifetime period - An address assigned to an interface whose use is
has expired. discouraged, but not forbidden. A deprecated
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.
invalid-address: This is a single address whose validation-lifetime valid address
has expired. - A preferred or deprecated address. A valid address
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.
2.2 DHCPv6 Terminology invalid address
- An address that is not assigned to any interface. A
valid address becomes invalid when its valid
lifetime expires. Invalid addresses should not appear
as the source or destination of a packet.
configuration-type: Configuration Type defines an optional preferred lifetime
configuration parameter in the DHCPv6 protocol. - The length of time that a valid address is preferred.
When the preferred lifetime expires, the address
becomes deprecated.
configuration-data: Configuration Data is information a host can use valid lifetime
to configure a host on a network, so that the host can interoperate - The length of time the address remains in the valid
with other hosts on a network. Configuration Data will vary in state. The valid lifetime MUST be greater than or
length depending on the configuration type. equal to the preferred lifetime. When the valid
lifetime expires, the address becomes invalid.
client: A Client is a host that initiates requests on a link to interface token
obtain: addresses, DNS host name processing, or configuration-data. - 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.
server: A Server is a host that responds to requests from clients on 2.2. DHCPv6 Terminology
a link to provide: addresses, DNS host name processing, or
configuration-data.
relay-agent: A Relay-Agent is a router that listens on the link for configuration parameters
clients requests, and then forwards the request to a server on the - Is any parameter that can be used by a node to
network. The server will respond back to the Relay-Agent, who will configure their network environment so the node can
forward the reply to the client on the Relay-Agents link. communicate on a link or on an internet.
message-type: The Message-Type defines the DHCPv6 protocol operation client - A client is a host that initiates requests on a link
for this packet. to obtain: addresses, dynamic updates to DNS, or
other configuration parameters.
message-code: The Message-Code defines a notification for a message- server - A server is a node that responds to requests from
type from a client or server. clients on a link to provide: addresses, dynamic
updates to DNS, or other configuration parameters.
name-length: The Name-Length defines the length of the host name relay-agent - A relay-agent is a node that listens on a link for
provided by a client or a server for DNS Autoregistration of host client requests, and then forwards the packet to a
names. 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.
interface-token: The Interface-Token is specified by the client and message-type - The message-type defines the DHCPv6 protocol type for
is a unique opaque identifer for a clients interface, and must be this packet.
accessbile after a client reboots (e.g. IEEE 802 MAC address).
address-count: The address-count is specified by the client with any message-flag - The message-flag defines an optional processing
request sent to a server, and represents the number of addresses the notification for DHCPv6. The message-flag can also
client has received from a server for a specified interface-token. be used by the Options for DHCPv6 specification.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 error-code - The error-code specifies errors from a client or
server. The error-code can also be used by the
Options for DHCPv6 specification.
client-address: The Client-Address is the field in the DHCPv6 total-addresses
protocol that contains the address for the clients interface-token. - 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.
server-address: The Server-Address is the field in the DHCPv6 completed-transaction
protocol that contains the address of the server responding to the - A completed-transaction is a communications exchange
clients request. 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.
gateway-address: The Gateway-Address is the field in the DHCPv6 transaction-ID
protocol that contains the relay-agents address, so a server, that - The transaction-ID is an integer identifier specified
may be multiple relay-agent hops away from the orginal relay-agent, by the client and is used by the client and server as
can respond directly to the relay-agent that forwarded the request, a transaction identifier to define the set of
by extracting the Gateway- Address to be used as the server packets request/response messages between the client and
destination address. server, for a clients interface token.
client-link-address: The client-link-address is the field in the client-link address
DHCPv6 protocol the relay-agents use to save the clients source - The client-link address specifies the clients
address in the IPv6 header, so they can respond back to the server on link-local address. The client-link address
the link. is used by a relay-agent to respond to a client
on a link, after receiving a server response.
transaction-ID: The Transaction-ID is specified by the client as an server address
opaque transaction identifier, which uniquely identifies the current - The server address specifies the address for the
operation between the client and the server. The server may utilize server responding to a client.
this transaction identifier in order to detect duplicate transactions
and to provide context between messages in a multi-message exchange
with a client who has multiple requests for the same interface-token.
host-name: The Host-Name is the name to be associated with an gateway address
address. If the name-length is zero then the Host-Name is not - The gateway address specifies the address of the
present in the DHCPv6 request or response. relay-agent for a server, which may be multiple
relay-agent hops away from the original relay-agent.
binding: The Binding in DHCPv6 is a N-tuple that a client and server client address
MUST maintain in DHCPv6 for each completed transaction, where N is - The client address specifies an address from a
the number of configuration-data identifiers for a client. An server to be used by a client.
implementation MUST support at least a 4-tuple Binding consisting of
the clients interface-token, address, validation-lifetime, and
deprecation-lifetime for that address. An example of a completed
transaction in DHCPv6 is when the client requests an address for an
interface-token and receives an address and lease for that token. It
is implementation defined if greater than a 4-tuple Binding is
supported by an implementation, and is not prohibited by this
specification.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 binding - A binding in DHCPv6 is an N-tuple that a client
and server MUST maintain in DHCPv6 for a
completed-transaction, where N is the number of
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 3. Protocol Design Model
This section is provided for implementors to understand the DHCPv6 This section is provided for implementors to understand the DHCPv6
protocol design model from an architectural perspective. It provides protocol design model from an architectural perspective. Any
related work in IPv6 that influenced the protocol design and the conceptual models presented in this specification that provide
design goals. The request/response protocol model is discussed and implementation examples are not a requirement of the DHCPv6 protocol.
the objective of this model in the design. The leased address
strategy and purpose is discussed. The objective of the
autoregistration for DNS Host Names is discussed and the capabilities
that are possible in this specification. The client/server model is
discussed to prepare an implementor for the client/server processing
provided later in the specification. Then the configuration options
are defined and how they are used to build additional extensible
configuration-data for DHCPv6.
3.1 Related Work in IPv6
The related work in IPv6 that would best serve an implementor to
study is the IPv6 Specification [IPv6-SPEC], the IPv6 Addressing
Architecture [IPv6-ADDR], IPv6 Stateless Address Configuration
[IPv6-ADDRCONF], IPv6 Neighbor Discovery Processing [IPv6-ND], and
Dynamic Updates to DNS [DYN-UPD]. These specifications afford DHCPv6
to build upon the IPv6 work to provide both robust statefull
autoconfiguration and autoregistration of DNS Host Names. In
addition related work for DHCP for IPv4 is directly related to
DHCPv6.
The IPv6 Specification provides the base architecture and design of
IPv6. A key point for DHCPv6 implementors to understand is that IPv6
requires that every link in the internet have an MTU of 576 octets or
greater (in IPv4 the requirement is 68 octets). This means that a
UDP datagram of 536 octets will always pass through an internet (less
40 octets for the IPv6 header), as long as there are no options prior
to the UDP datagram in the packet. But, IPv6 does not support
fragmentation at routers and fragmentation must take place end-to-end
between hosts. If a DHCPv6 implementation needs to send a packet
greater than 536 octets it can either fragment the UDP datagram in
UDP or use Path MTU Discovery [IPv6-SPEC] to determine the size of
the packet that will traverse a network path. It is implementation
defined how this is accomplished in DHCPv6.
The IPv6 Addressing Architecture Specification provides the address
scope that can be used in an IPv6 implementation, and the various
configuration architecture guidelines for network designers of the
IPv6 address space. Two advantages of IPv6 is that multicast
addressing is well defined and nodes can create link-local addresses
during initialization of the nodes environment. This means that a
host immediately can ascertain an IPv6 address at initialization for
an interface, before communicating in any manner on the link. The
host can then use a well-known multicast address to begin
communications to discover neighbors on the link, or as will be
discussed later in the specification locate a DHCPv6 server or
relay-agent.
The IPv6 Stateless Address Configuration Specification (addrconf)
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
defines how a host can autoconfigure addresses based on neighbor
discovery router advertisements, and the use of a validation-lifetime
and a deprecation-lifetime for addresses. In addition the addrconf
specification defines the protocol interaction for a host to begin
stateless or statefull autoconfiguration. DHCPv6 is one vehicle to
perform statefull autoconfiguration. Compatibility with addrconf is
a design goal of DHCPv6 where possible.
IPv6 Neighbor Discovery (ND) is the node discovery protocol in IPv6
(replaces and enhances functions of IPv4 ARP Model). To truly
understand IPv6 and addrconf it is strongly recommended that
implementors understand IPv6 ND.
Dynamic Updates to DNS is a specification that supports the dynamic
update of DNS records for both IPv4 and IPv6. This will be discussed
further later in this section of the specification. An implementor
cannot implement DHCPv6 without understanding Dyanmic Updates to DNS.
3.2 Design Goals 3.1. Design Goals
The following list gives general design goals for DHCPv6. Most The following list gives general design goals for DHCPv6.
DHCPv4 Design Goals [DHCP-v4] are kept in this specification.
DHCPv6 should be a mechanism rather than a policy. DHCPv6 must DHCPv6 should be a mechanism rather than a policy. DHCPv6 must
allow local system administrators control over configuration allow local system administrators control over configuration
parameters where desired; e.g., local system administrators should parameters where desired; e.g., local system administrators should
be able to enforce local policies concerning allocation and access be able to enforce local policies concerning allocation and access
to local resources where desired. to local resources where desired.
Hosts should require no manual configuration. Each host should be Hosts should require no manual configuration. Each host should be
able to discover appropriate local configuration parameters able to discover appropriate local configuration parameters
without user intervention and incorporate those parameters into without user intervention, and incorporate those parameters into
its own configuration. its own configuration.
Networks should require no hand configuration for individual Networks should require no hand configuration for individual
hosts. Under normal circumstances, the network manager should not hosts. Under normal circumstances, the network manager should not
have to enter any per-host configuration parameters. have to enter any per-host configuration parameters.
DHCPv6 should not require a server on each link. To allow for DHCPv6 should not require a server on each link. To allow for
scale and economy, DHCPv6 must work across relay agents. scale and economy, DHCPv6 must work across relay agents.
A DHCPv6 client must be prepared to receive multiple responses to A DHCPv6 client must be prepared to receive multiple responses to
a request for configuration parameters. Some installations may a request for configuration parameters. Some installations may
include multiple, overlapping DHCPv6 servers to enhance include multiple, overlapping DHCPv6 servers to enhance
reliability and increase performance. reliability and increase performance.
DHCPv6 must coexist with statically configured, non-participating DHCPv6 must coexist with statically configured, non-participating
hosts and with existing network protocol implementations. hosts and with existing network protocol implementations.
DHCPv6 should as much as possible be compatible with IPv6 DHCPv6 should as much as possible be compatible with IPv6
Stateless Address Configuration. Stateless Address Autoconfiguration.
DHCPv6 must support the requirements of automated renumbering of
IPv6 addresses.
DHCPv6 servers should be able to support Dynamic Updates to DNS DHCPv6 servers should be able to support Dynamic Updates to DNS
[DYN-UPD]. [DYN-UPD].
It is NOT a design goal of DHCPv6 to specify a server to server It is NOT a design goal of DHCPv6 to specify a server to server
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
protocol. protocol.
It is NOT a design goal of DHCPv6 to specify how a server It is NOT a design goal of DHCPv6 to specify how a server
configuration database is maintained or determined. configuration parameter database is maintained or determined.
The following list gives design goals specific to the transmission of The following list gives design goals specific to the transmission of
the network layer parameters. the network layer parameters.
Guarantee that any specific network address will not be in use by Guarantee that any specific network address will not be in use by
more than one host at a time. more than one host at a time.
Guarantee that client addresses that are not provided by DHCPv6 Guarantee that client addresses that are not provided by DHCPv6
will not be added to a servers configuration database or the will not be added to a servers configuration parameter database or
servers binding for a clients interface-token. the servers binding for a clients interface token.
Retain host configuration across host reboot. A client should, Retain host configuration parameters across client reboots. A
whenever possible, be assigned the same configuration-data in client should, whenever possible, be assigned the same
response to each request. configuration parameters in response to a request.
Retain host configuration across server reboots, and, whenever Retain host configuration across server reboots, and, whenever
possible, a host should be assigned the same configuration possible, a host should be assigned the same configuration
parameters despite restarts of the DHCPv6 mechanism, parameters despite restarts of the DHCPv6 mechanism,
Allow automatic assignment of configuration parameters to new Allow automatic assignment of configuration parameters to new
hosts to avoid hand configuration for new hosts. hosts to avoid hand configuration for new hosts.
Support fixed or permanent allocation of configuration parameters Support fixed or permanent allocation of configuration parameters
to specific hosts. to specific hosts.
Clients must not assume that addresses are updated to the DNS, 3.2. Request/Response Model
unless the server provides a host-name with an address to a
client.
3.3 Request/Response Model
DHCPv6 uses a message type to define whether the packet orginated DHCPv6 uses a message-type to define whether the packet originated
from a DHCPv6 Server or Client. 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: The message types are as follows:
01 - client-configuration-request 01 DISCOVER
02 - client-confirm-response
03 - client-reject-response
04 - server-configuration-response
Request/Response Model States The DISCOVER message is a DHCPv6 multicast packet from a client
to locate and request configuration parameters on a network,
when the client does not know the servers address.
1. Request (client) 02 CONF-REQUEST
2. Response with configuration-data or error found (server).
3. Confirmation Response or reject (client).
The time out period for a client or server to wait for a response The CONF-REQUEST is an IPv6 unicast packet from a client to a
MUST NOT exceed 3 minutes. When a client or server times out waiting server, when the client knows the IPv6 unicast address of a
for a response to a packet sent, the implementation MUST NOT commit server, to request configuration parameters on a network.
any binding based on the configuration-data sent in the packet. It
is implementation defined if the client or server packet is
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 03 CONF-RESPONSE
retransmitted. The CONF-RESPONSE is an IPv6 unicast packet from a server in
response to a client DISCOVER or CONF-REQUEST, which provides
the requested configuration parameters.
3.4 Leased Address Model 04 ACCEPT
An address returned to a client has a validation-lifetime and The ACCEPT is a client response to a server CONF-RESPONSE. When
deprecation-lifetime. The lifetimes represent the lease for a single the client used DISCOVER to locate a server and request
address for a client. The server MUST provide a validation-lifetime configuration parameters on a network, the ACCEPT should be
and SHOULD provide a deprecation-lifetime to a client in a server sent using the DHCPv6 multicast address, which also serves to
response packet to a clients request for an address. 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.
The client may suggest a value for the lifetimes in an address 05 SERVER-ACK
request to a server, or leave them as zero. The client MUST use the
lifetimes provided by the server response if the values are different The SERVER-ACK is an IPv6 unicast packet sent by a server to
than the lifetimes requested by the client. inform a client that it received an ACCEPT. The SERVER-ACK is
used by the server to inform the client it has received an
acknowledgment that the client has received the configuration
parameters from the server, and denotes a completed-transaction
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
The RELEASE is used by the client for two reasons:
1. To inform the server that the client did not receive the
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
particular address or set of addresses, even though the
lifetimes for those addresses may not have become
invalid.
The processing and algorithms for the request/response set of
message-types will be discussed in section 4.0.
3.3. Leased Address Model
The leased address model specifies a set of lifetimes associated with
addresses returned by the server. These lifetimes are meant to
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 The DHCPv6 philosophy is that the client has the responsibility to
renew a lease for an address that is about to expire, or request a renew a lease for an address that is about to expire, or request a
new address or the same address before the lease actually expires. new address or the same address before the lease actually expires.
If the client does not request a new lease for an address, the server If the client does not request a new lease for an address, the server
MUST assume the client does not want a new lease for that address, MUST assume the client does not want a new lease for that address.
and the server MAY provide that address to another client requesting The server MAY provide that address to another client requesting an
an address. address, after all other addresses available to the server have been
exhausted.
If the the client has a deprecation-lifetime for an address the 3.3.1. Address Lifetimes
processing of the lease SHOULD be as follows:
When the deprecation-lifetime of an address expires, the clients An address returned to a client has a preferred and valid lifetime.
address becomes a deprecated-address. A deprecated address SHOULD The lifetimes represent the lease for addresses provided to the
NOT be used as a source address in new communications. However, a client, from the server.
deprecated-address SHOULD continue to be used as a source address
if it is in use in existing communications. Implementors of
DHCPv6 SHOULD coordinate the use of the validation-lifetime and
deprecation-lifetime for layers below the DHCPv6 application layer
with their implementation of IPv6 Stateless Address Configuration
[IPv6-ADDRCONF].
An address is a deprecated-address until its invalidation-lifetime The client MAY request a value for the lifetimes returned by a
expires at which point the address becomes an invalid-address. An server, but the client MUST use the lifetimes provided by the server
invalid-address MUST NOT be used as a source address in outgoing response.
When an address for a client interface becomes deprecated the
processing of the lease MUST be as follows:
When the preferred lifetime of an address expires, the clients
address becomes a deprecated address. A deprecated address can be
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
which point the address becomes an invalid address. An invalid
address MUST NOT be used as a source address in outgoing
communications, and MUST NOT be recognized as a valid destination communications, and MUST NOT be recognized as a valid destination
address in incoming communications. address for incoming communications.
If the clients deprecation-lifetime is zero for an address the Once an address is deprecated an implementation SHOULD request a
processing for the lease SHOULD be as follows: new lease or address for that interface.
There is no concept of a deprecated-address for a client if the If the clients preferred lifetime is zero for an address the address
deprecation-lifetime is zero when provided to the client in a is immediately deprecated.
server response. The address for the client is valid until the
validation-lifetime expires at which point the address becomes an
invalid-address. An invalid-address MUST NOT be used as a source
address in outgoing communications, and MUST NOT be recognized as
a valid destination address in incoming communications.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 Implementors of DHCPv6 would find it beneficial to coordinate the use
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.5 DNS Host Name Autoregistration Model 3.3.2. Duplicate Address Detection
DHCPv6 supports the autoregistration of DNS Host names and providing DHCPv6 clients MUST support Duplicate Address Detection as specified
DNS Host Names with addresses for clients. Autoregistration is in IPv6 Stateless Address Autoconfiguration. This will provide a high
supported by the presence of the name field in DHCPv6, which the guarantee that DHCPv6 client addresses are not duplicated on a link.
client may provide to the server in a request. In addition a server
may provide a DNS Host Name with an IPv6 address to a client in a
response.
If the name-length field is zero, there is no name field contained in It is an option for a server to inform the client it does not have to
the packet. 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.
DHCPv6 only specifies the name-field, and not the actual protocol or A conceptual model of an implementation for DHCPv6 duplicate address
primitives to interact with DNS. The functions that the server uses detection is that the client DHCPv6 module, which supports updating
to interact with the DNS to provide autoregistration is defined in the network interfaces for a host, would use the same application
Dynamic Updates to DNS [DYN-UPD]. DHCPv6 servers SHOULD support configuration interface for DHCPv6 as is used for IPv6 Stateless
Dynamic Updates to DNS. 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.
If the client provides a Host Name (HN) or a Fully Qualified Domain 3.3.3. Releasing Infinite Lifetime Addresses
Name (FQDN) [RFC 1034&1035]:
The server SHOULD perform a DNS query for the HN or FQDN IPv6 DNS DHCPv6 specifies no behavior which would require a client to listen
AAAA resource record [IPv6-DNS]: for asynchronous messages from servers on a well known UDP port. The
reason for this is that minimal implementations may not be able to
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.
If the name is found and the address does not match the clients This specification leaves it as implementation defined how this
address for the name provided by the client, the server SHOULD add problem is solved in a DHCPv6 network environment.
this address to the DNS name record (multiple addresses are
supported for names at this time in DNS and the client may want to
use the same name for multiple addresses on an interface).
If the name is not found the client supplied name SHOULD be added One solution to the problem is to define an SNMP MIB for DHCPv6
to the DNS. clients that when set by a network management agent causes a client
to revalidate all of its addresses with the DHCPv6 server or issue a
RELEASE to the server.
In either condition above the server MUST add the associated DNS 3.4. DNS Host Name Autoregistration Model
inverse address mapping as an IP6.INT domain PTR record [IPv6-DNS]
for this clients address and name.
If the server returns a name after updating the DNS it MUST return It is important that DHCPv6 provide a server implementation set of
a FQDN to the client. options for Dynamic Updates to DNS (DYNDNS), to support the
autoregistration of addresses to names in IPv6. DYNDNS SHOULD be
supported as a set of options in DHCPv6 as specified in the Options
for DHCPv6 specification. The minimum requirements to support DYNDNS
in DHCPv6 are as follows:
If the client does not request a HN or FQDN from a server, the server 1. Clients SHOULD be able to request or change names for
MAY provide, in its response with the address to a client, a FQDN the addresses.
client can use for that address. The server MUST NOT provide a
client with a server generated FQDN, unless the associated IPv6 AAAA
record and IP6.INT domain PTR record exists in the DNS.
When a clients address invalidation-lifetime expires on the server, 2. Servers SHOULD be able to provide names for addresses
the server SHOULD delete the clients IPv6 AAAA record and IP6.INT provided to a client.
domain PTR record from the DNS.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 3. If servers support DYNDNS then they MUST support the
following:
3.6 Defining Optional Configuration-Data a) Create, Update, and Delete of IPv6 AAAA Records
[IPv6-DNS] as specified in DYNDNS [DYN-UPD].
Optional configuration-data MUST be specified for DHCPv6 as follows b) Create, Update, and Delete of IPv6 IP6.INT Domain PTR
and aligned on an integer multiple of 8 octets: records for any IPv6 AAAA addresses defined in a client
DYNDNS request, or that the server automatically generated
for a client.
option-type: 1 Octet 4. Request/Response Processing
This field permits 254 options for DHCPv6 and will represent the The request/response processing for DHCPv6 is transaction based and
tag for the option. The values of 0 and 1 are used for pad uses a best-effort set of messages to guarantee a completed-
options discussed below. 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.
option-length: 2 Octets 4.1. Processing when Server Address is not Known
This field specifies the length of the configuration-data not The processing for the DHCPv6 request/response model when the client
including the the option-type and and option-length fields. does not know the server address is as follows:
option-data: Variable number of Octets Server Client Server
(not selected) (selected)
The option-data is the configuration-data that immediately follows v v v
the option-length field. | | |
| 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
If the server does not support an option-type requested it MUST DHCPv6 uses the UDP [RFC-768] protocol to communicate between clients
return the option-type and the option-length set to zero in the and servers. UDP is not reliable, but DHCPv6 must provide some
response to the client. reliabilty between clients and servers. The network trade-off is
time versus the reliability that the completed set of
request/response messages were received by both the client and the
server to define a completed-transaction.
A server implementation MUST start any options after the first option The request/response set is always started by a client either with a
returned to a client on an integer multiple of 8 octets. This is an DISCOVER when the client does not know the servers address, or a
architectural REQUIREMENT, and the client when parsing options can CONF-REQUEST when the client does know the servers address. The
assume the next option, if it exists will begin on the next integer second message is from the server and is the CONF-RESPONSE. The
multiple of 8 octets boundary. 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.
This specification does not define any options. DHCPv6 options are The server after receiving the ACCEPT sends a SERVER-ACK, which is an
defined in XXXXXXXXX. It is permissible for options to also create acknowledgment to the client the server has received the clients
new message-types and message-codes as required. ACCEPT. At that point the time vs reliability trade-off in DHCPv6 is
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.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 Retransmission of messages is discussed in section 4.3.
4. Datagram and Data Formats The ACCEPT in the flow above is a multicast packet which serves an
overloaded function, to respond to the selected server, and to inform
other servers on the network the client is not selecting them.
4.1 Datagram 4.2. Processing when Server Address is Known
The processing for the DHCPv6 request/response model when the client
does knows the server address is as follows (all packets are
Unicast):
Client Server
v v v
| | |
| 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
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
Configuration variables for a DHCPv6 implementation that MUST be
configurable by a client or server are as follows:
Retranstimer - The time in seconds that a DHCPv6 client or server
should wait before retransmitting a message.
Default: 3 seconds.
Maxretrans - The maximum retransmissions that a DHCPv6 client
or server should retransmit, before logging a
DHCPv6 System Error to the user.
Default: 3 retransmissions.
The problem with retransmissions occurs when they are continually
received by a client or server (e.g. duplicate bindings or updates).
To support informing a client or server that a retransmission is
being done a second set of message-types are supported in DHCPv6 as
follows:
20 - DISCOVER-Retrans
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
application layer over UDP, they MUST change the message-type to the
same message-type with the Retrans suffix.
A response to a retransmission SHOULD be a duplicate of a previous
response to the client or server. It is implementation defined how
this is accomplished.
One method of retransmitting duplicates in an implementation
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
5.1. Datagram
DHCPv6 Datagram DHCPv6 Datagram
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | msg-code | name-lgth | addr-count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| transaction-ID | | msg-type | msg-flag | error-code | total-addrs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interface-token | | RESERVED | transaction-ID |
| (8 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-address | | interface token |
| (16 Octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address | | server address |
| (16 Octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| gateway-address | | gateway address |
| (16 Octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-link-address | | client-link address |
| (16 Octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| validation-lifetime | | preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| deprecation-lifetime | | valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| host-name | | client address |
| (variable octets 0-255) | | (16 octets) |
| (can be multiple addresses and lifetimes present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-type | option-lgth | option-data (variable octets) | | options (variable number and length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2 Data Formats 5.2. Field Definitions
All fields in the datagram MUST be initialized to binary zeroes All fields in the datagram MUST be initialized to binary zeroes by
by both the client and server messages unless otherwise noted both the client and server messages unless otherwise noted in Section
in Section 5. Client and Server processing of messages. 6.
msg-type : 1 Octet integer value (message-type) msg-type - 1 octet integer value (message-type)
Value Description Value Description
1 - Client request for configuration data. 01 DISCOVER
2 - Server response with configuration data. 02 CONF-REQUEST
3 - Client confirmation of server response. 03 CONF-RESPONSE
4 - Client rejection of server 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
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 msg-flag - 1 octet integer value (message-flag)
msg-code : 1 Octet integer value (message-code) Value Description
01 Server - Duplicate Address Detection not Required.
02-255 RESERVED
error-code - 1 octet integer value
Value Description Value Description
1 - Server Response - Client address-count is in error. 01 Server - Addresses are not available at this time.
2 - Server Response - Dynamic Updates to DNS not supported. 02 Server - Address not known by the Server
03-255 RESERVED
name-lgth : 1 Octet integer value (name-length) total-addrs - 1 octet integer value (total-addresses)
addr-count : 1 Octet integer value (address-count) RESERVED - 2 octets Reserved for future use.
transaction-ID : 4 Octets integer value transaction-ID - 2 octets integer value
interface-token : 4 Octets integer value interface token - 8 octets link-dependent identifier
client-address : 16 Octets address server address - 16 octets address
server-address : 16 Octets address gateway address - 16 octets address
gateway-address : 16 Octets address client-link address - 16 octets link-local address
client-link-address : 16 Octets address preferred lifetime - 4 octets integer value in seconds
validation-lifetime : 4 Octets integer value valid lifetime - 4 octets integer value in seconds
client address - 16 octets address
deprecation-lifetime : 4 Octets integer value options - variable number of octets [DHCPv6-OPT]
host-name : 0-255 Octets character(s) value(s) 6. Client/Server Message Formats
option-type : 1 Octet integer value 6.1. Client/Server UDP Ports, Multicast Group, and Addresses
option-length : 1 Octet integer value A client MUST transmit all messages over UDP using UDP Server Port 547.
option-data : Variable Octets variant value(s) A server or relay-agent MUST transmit all messages over UDP using UDP
Client Port 546.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 A client MUST receive all messages over UDP using UDP Client Port 546.
5. Client/Server Processing A server or relay-agent MUST receive all messages over UDP using UDP
Server Port 547.
5.1 Client Transmission 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.
UDP DHCPv6 Server Port 546 MUST be used by the client to send UDP Servers on the same link as the client MUST use the source address in
datagrams to the server. 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.
If the client knows its address it MUST be put in the source address In the cases where a client or server must retransmit messages the
field of the IPv6 Header. Otherwise the clients link-local address msg-type codes in this section are used as stated in section 4.3 with
MUST be used as the source address field in the IPv6 Header [IPv6- the values that represent the Retrans suffix for the msg-types.
ADDRCONF].
If the client knows the address of the server on its link it MUST put 6.2. Client DISCOVER and CONF-REQUEST Messages
that address in the destination address field of the IPv6 Header.
Otherwise the client MUST put the DHCP Server/Relay-Agent well-known
multicast address FF02:0:0:0:0:0:1:0 using link-local scope [IPv6-
ADDR] as the destination address field in the IPv6 Header.
The client MUST set msg-type to 1 to transmit a request to the 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:
Set to 01 if the server knows addresses provided are verified to be
unique, otherwise set to binary zeroes.
error-code:
Set to 01 if the server cannot provide any addresses to the client at
this time.
Set to 02 if the server detects an address from the client it did not
provide to the client.
total-addrs:
Set to the number of addresses the server is returning the client.
transaction-ID:
Set to the value the client provided in the DISCOVER or CONF-REQUEST
msg-type.
interface token:
Set to a unique link dependent identifier for the clients interface as
provided in the clients DISCOVER or CONF-REQUEST msg-type.
server address:
The address of the server responding.
gateway address:
Set to the same value that existed when the server received the packet.
client-link address:
Set to the same value that existed when the server received the packet.
preferred lifetime:
Set to the value requested by the client or the value required by the
server. server.
The client MUST set msg type to 3 to confirm the acceptance of packet valid lifetime:
from a server response.
The client MUST set msg type to 4 to reject a packet from a server Set to the value requested by the client or the value required by the
response. server.
The client MUST use UDP DHCPv6 Client Port 546 as the UDP port to The valid lifetime MUST be greater than or equal to the preferred
accept server responses in an implementation. lifetime.
5.2 Server Transmission client address:
UDP DHCPv6 Client Port 546 MUST be used by the server to send UDP Set to an address provided by the server if the client is not attempting
datagrams to the client. to renew existing addresses, meaning the address fields from the client
have a value of binary zeroes.
A server, on the same link as the client, MUST use the source address If the error-code is set to 02 the server will only return the addresses
in the IPv6 Header from the client as the destination address in the that the server can verify were provided by the server. If no addresses
servers response packet. Servers not on the same link are discussed could be verified the total-addrs field, lifetimes, and client address
in Section 6 Relay-Agent Processing. will be set to binary zeroes. In the case as far as the server is
concerned the DHCPv6 transaction is completed and the server will not
expect a client ACCEPT message to its CONF-RESPONSE message.
The server MUST set msg type to 2 to transmit a response to a client. options:
The server MUST use UDP DHCPv6 Server Port 547 as the UDP port to See Options for DHCPv6 specification [DHCPv6-OPT].
accept client requests in an implementation.
The server MUST join the DHCP Server/Relay-Agent mulicast group 6.4. Client ACCEPT Message
well-known multicast address FF02:0:0:0:0:0:1:0 using link-local
scope [IPv6-ADDR], to listen for client requests, that do not know
the address of a server on the clients link.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 msg-type:
5.3 Client/Server Bindings Set msg-type to ACCEPT.
Client and server bindings MUST be maintained at least as a 4-tuple If the client sent a DISCOVER to request configuration parameters on the
consisting of the clients interface-token, address, validation- link, then the client should use as the IP destination address the DHCPv6
lifetime, and deprecation-lifetime in an implementaiton. It is Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0.
critical for the interoperability of DHCPv6 that the clients bindings
remain consistent with the servers bindings across reboots.
When a client sends a request it MUST enter in the addr-count field If the client sent a CONF-REQUEST to request configuration parameters on
the number of addresses that it has for a particular interface-token the link, then the client should use as the IP destination address the server
in the clients bindings. address in the CONF-RESPONSE from the server.
When the server receives the client request, it MUST verify that the If the client sees an error-code of 02 and the total-addrs field is
addr-count field provided by the client matches the number of zero, the server cannot process any of the addresses requested and the
addresses the server has for that clients binding, for the client should not send an ACCEPT to the server. If the client sees an
interface-token provided by the client. If the server has a error-code of 02 and total-addrs does not equal zero it means the server
different addr-count than the client for a particular interface dropped addresses that it could not locate requested by the client.
token, the server MUST send a response to the client setting msg-code
to 1 informing the client addr-count at the server is not in synch
with the client.
Once the client receives a response with a msg-code set to 1 it MUST msg-flag:
set addr-count to zero on subsequent requests to the server, for that
interface-token.
When a server receives a request from a client and the addr-count is Set to binary zeroes.
set to zero, but the client has a binding for that interface-token,
the server MUST reissue the configuration-data in those bindings to
the client.
5.4 Client Requests error-code:
The client sets the following fields for a request for Set to binary zeroes.
configuration-data:
msg-type: Set to 1. total-addrs:
name-lgth: Set to the length of the host-name if provided. Set to 1.
addr-count: Set to the number of addresses the client has for the transaction-ID:
interface-token specified in this request.
transaction-ID: Set to a unqiue integer value. Set to the integer value that the client used on its initial DISCOVER or
CONF-REQUEST msg-type to the server.
interface-token: Set to a unqiue opaque identifier. interface token:
client-address: Set ONLY if the client is requesting a host name Set to the unique link dependent identifier for the clients interface
for a particular address, else not set. that was used for the clients initial DISCOVER or CONF-REQUEST msg-type
to the server.
validation-lifetime: Set to the value the client would like the server address:
server to use, else not set.
deprecation-lifetime: Set to the value the client would like the Set to the address provided by the servers CONF-RESPONSE.
server to use, else not set.
host-name: Set only if name-lgth is greater than zero otherwise gateway address:
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 Set to binary zeroes.
this field is not present. client-link address:
option-type: Set to a future option request for configuration- Set to the clients link-local address for the link on which the client
data, otherwise the field is not present. Multiple option-types transmitted the packet.
may be set adjacent to each other.
5.5 Server Response preferred lifetime:
The server sets the following fields for a response to a client for Set to the first or only preferred lifetime returned for an address by
configuration-data: the server.
msg-type: Set to 2. valid lifetime:
msg-code: Set to 1 if addr-count not equal to servers bindings for Set to the first or only valid lifetime returned for an address by the
the clients specified interface-token. Set to 2 if the server server.
cannot support Dynamic Updates to DNS because the client requested
a host-name for an address provided, or from the servers set of
addresses.
If the server determines that addr-count is not equal to its The valid lifetime MUST be greater than or equal to the preferred
bindings it stops all other DHCPv6 processing, hence, the lifetime.
server would not be in the situation of setting msg-code to
both 1 and 2. The server sets msg-code to 1 and MUST put all
other values supplied by the clients request in the response
packet except the msg-type and msg-code fields.
Processing of msg-code set to 1 for the client and server is client address:
done as specified in 5.3 Client/Server Bindings.
name-lgth: Set to the length of the host-name if present. Set to the first or only address provided by the server.
addr-count: Set to the same value specified by the client. If the client did receive more than one address and lifetime, it MUST
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.
transaction-ID: Set to the same value specified by the client. options:
interface-token: Set to the same value specified by the client. No options are present.
client-address: If the client-address from the request packet is 6.5. Server SERVER-ACK Message
zero the server sets the client-address to the next available
address for this interface-token. If there is a client-address in
the request packet the client is requesting a host-name for this
address, and the server MUST return the address provided by the
client if the server supports Dynmic Updates to DNS, and has
updated the DNS with a host-name for that address.
server-address: The server MUST set this field to its address in msg-type:
all response packets.
validation-lifetime: The server sets this address to the Set msg-type to SERVER-ACK.
validation-lifetime of the servers configuration database. It is
implementation defined if the server will use the validiation-
lifetime if specified by a client request packet.
deprecation-lifetime: The server sets this address to the If the client sent the ACCEPT to acknowledge a servers CONF-RESPONSE
deprecation-lifetime of the servers configuration database. It is message on the DHCPv6 Server/Relay-Agent multicast address
implementation defined if the server will use the deprecation- FF02:0:0:0:0:0:1:0, the server MUST look at the server address in the
packet to determine if the ACCEPT is for them or not.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 If the message is not for a particular server then this is an indirect
message to that particular server the client is not accepting them as
their server for this transaction, and MUST NOT send a SERVER-ACK to the
clients ACCEPT.
lifetime if specified by a client request packet. msg-flag:
host-name: The server returns a hostname or msg-code set to 2, if Set to binary zeroes.
the name-lgth field is greater than zero. Processing of host-name
is specified in Section 3.5 DNS Host Name Autoregistration Model.
option-type: The server returns the same option-types specified by error-code:
the client requests.
option-lgth: The server returns the length of the configuration- Set to binary zeroes.
data or zeroes if the option is not supported.
option-data: The server returns the configuration-data requested total-addrs:
by the client.
5.6 Client Confirmations/Rejections Set to 1.
The client sets the following fields for a confirmation or rejection transaction-ID:
after receiving configuration-data from the server. configuration-
data:
msg-type: Set to 3 if the client is confirming a servers response. Set to the integer value that the client used on its initial DISCOVER or
Set to 4 if the client is rejecting a servers response. CONF-REQUEST msg-type to the server.
When the server receives a rejection msg-type 4 from a client interface token:
the server MUST assume the client is using another server. The
server then MUST remove any bindings for that client it may
have created, and MUST delete any DNS HN or FQDN records it may
have added on behalf of the client.
transaction-ID: Same value as specified in the servers response. Set to the unique link dependent identifier for the clients interface
that was used for the clients initial DISCOVER or CONF-REQUEST msg-type
to the server.
interface-token: Same value as specified in the servers response. server address:
client-address: Same value as specified in the servers response. Set to the servers address.
6. Relay-Agent Processing gateway address:
The relay-agent MUST use UDP DHCPv6 Server Port 547 as the UDP port Set to the same value that existed when the server received the packet.
to accept client responses in an implementation.
The relay-agent MUST join the DHCP Server/Relay-Agent mulicast group client-link address:
well-known multicast address FF02:0:0:0:0:0:1:0 using link-local
scope [IPv6-ADDR], to listen for client requests.
When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it Set to the same value that existed when the server received the packet.
MUST:
If the gateway-address is NOT zero then the relay-agent MUST: preferred lifetime:
Put the relay-agents IPv6 address in the gateway-address field Set to the value provided by the client.
of the clients request packet.
Put the the source address from the IPv6 Header of the clients valid lifetime:
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 Set to the value provided by the client.
request packet in the client-link-address. The valid lifetime MUST be greater than or equal to the preferred
lifetime.
client address:
Set to the address provided by the client.
At this point the server MUST commit the configuration parameters
provided to the client from the servers CONF-RESPONSE.
options:
No options are present.
6.6. Client RELEASE Message
msg-type:
Set msg-type to RELEASE.
If the client had sent an ACCEPT to the server and received a SERVER-ACK
for that message then the client MUST commit the configuration
parameters provided by the servers CONF-RESPONSE and a RELEASE message
is not required. But if the client did not receive a SERVER-ACK
in response to the clients ACCEPT, then the client MUST issue a RELEASE
to the server.
If the client no longer needs an address or has been notified to return
an address to the server, then the client SHOULD issue a RELEASE to the
server.
msg-flag:
Set to binary zeroes.
error-code:
Set to binary zeroes.
total-addrs:
Set to the total number of addresses the client is releasing. In the
case of a RELEASE where the client did not receive the SERVER-ACK this
value MUST equal the total number of addresses for the servers
CONF-RESPONSE.
transaction-ID:
Set to the integer value that the client used on its initial DISCOVER or
CONF-REQUEST msg-type to the server.
interface token:
Set to the unique link dependent identifier for the clients interface
that was used for the clients initial DISCOVER or CONF-REQUEST msg-type
to the server.
server address:
Set to binary zeroes.
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 the valid lifetime returned for an address by the server.
valid lifetime:
Set to the valid lifetime returned for an address by the server.
The valid lifetime MUST be greater than or equal to the preferred
lifetime.
client address:
Set to the address provided by the server.
The client will return the number of addresses and associated lifetimes
provided in the servers CONF-RESPONSE.
options:
No options are present.
7. Relay-Agent Processing
The relay-agent MUST use UDP DHCPv6 Server Port 547 as the UDP port to
accept client responses in an implementation.
The relay-agent MUST join the DHCP Server/Relay-Agent multicast group
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:
If the gateway address is NOT zero then the relay-agent MUST:
Put the relay-agents IP address in the gateway address field of
the clients request packet.
All relay-agents MUST: All relay-agents MUST:
Put their relay-agent address as the source address for the Put their relay-agent address as the source address for the IP
IPv6 Header. header.
Put the next relay-agent or known server address as the Put the next relay-agent or known server address as the
destination address in the IPv6 Header. destination address in the IP header.
Forward the packet to the to the next hop relay-agent or known Forward the packet to the to the next hop relay-agent or
server. known server.
When the remote server receives the client request from the relay- When the remote server receives the client request from the relay-agent
agent it will know its a remote client request (not on the servers it will know its a remote client request (not on the servers link),
link), because there is a gateway-address in the request. So servers because there is a gateway address in the request. So servers MUST
MUST test the gateway-address is not zero, to determine if the verify the gateway address is not zero, to determine if the clients request
clients request is from a remote link. is from a remote link.
The server responds as specified in 5.5 Server Response, but uses the The server responds as specified in section 6.0, but uses the
gateway-address as the destination address in the IPv6 Header. gateway address as the destination address in the IP header.
When the relay-agent receives the remote servers response, it MUST When the relay-agent receives the remote servers response, it MUST
forward the packet to the client, by using the client-link-address as forward the packet to the client, by using the client-link address as
the source address for the IPv6 Header. the source address for the IP Header.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 8. Security Considerations
Draft ***Open Issues*** Security for DHCPv6 can be used as specified in [IPv6-SA], [IPv6-AUTH],
and [IPv6-ESP], which are implementation requirements for IPv6.
1. The present model uses UDP with a client request, server Appendix A - Related Work in IPv6
response, and then client confirmation or rejection. The server will
set state or remove state based on this model. There is always the
possibility of the classic transactional error when the client-to-
server response is not received by the server, or the client assumes
the server received the response and it did not (see the draft).
This can be greatly alleviated by using TCP instead of UDP for the The related work in IPv6 that would best serve an implementor to study
transaction. This would have great benefits such as: is the IPv6 Specification [IPv6-SPEC], the IPv6 Addressing Architecture
[IPv6-ADDR], IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF],
IPv6 Neighbor Discovery Processing [IPv6-ND], and Dynamic Updates to DNS
[DYN-UPD]. These specifications afford DHCPv6 to build upon the IPv6
work to provide both robust stateful autoconfiguration and
autoregistration of DNS Host Names.
1. Guranteed virtual link, hence if the transaction completes The IPv6 Specification provides the base architecture and design of
the server and client know immediately upon return to the IPv6. A key point for DHCPv6 implementors to understand is that IPv6
application. requires that every link in the internet have an MTU of 576 octets or
greater (in IPv4 the requirement is 68 octets). This means that a
UDP datagram of 536 octets will always pass through an internet (less 40
octets for the IPv6 header), as long as there are no IP options prior to
the UDP datagram in the packet. But, IPv6 does not support
fragmentation at routers and fragmentation must take place end-to-end
between hosts. If a DHCPv6 implementation needs to send a packet
greater than 536 octets it can either fragment the UDP datagram in UDP
or use Path MTU Discovery [IPv6-SPEC] to determine the size of the
packet that will traverse a network path. It is implementation defined
how this is accomplished in DHCPv6.
2. PATH MTU Discovery for TCP is inherent in an implementation The IPv6 Addressing Architecture Specification provides the address
and the DHCPv6 application does not have to adjust for IPv6 scope that can be used in an IPv6 implementation, and the various
fragmentation model. configuration architecture guidelines for network designers of the IPv6
address space. Two advantages of IPv6 is that multicast addressing is well
defined and nodes can create link-local addresses during initialization
of the nodes environment. This means that a host immediately can configure
an IPv6 address at initialization for an interface, before communicating in
any manner on the link. The host can then use a well-known multicast address
to begin communications to discover neighbors on the link, or as was
discussed in the specification to locate a DHCPv6 server or relay-agent.
We can also use UDP to locate servers and TCP for the transaction. The IPv6 Stateless Address Autoconfiguration Specification (addrconf)
defines how a host can autoconfigure addresses based on neighbor discovery
router advertisements, and the use of a validation lifetime to support
renumbering of addresses on the Internet. In addition the addrconf
specification defines the protocol interaction for a host to begin stateless
or stateful autoconfiguration. DHCPv6 is one vehicle to perform stateful
autoconfiguration. Compatibility with addrconf is a design goal of DHCPv6
where possible.
2. Dynamic Updates to DNS need careful review for clarity and what IPv6 Neighbor Discovery (ND) is the node discovery protocol in IPv6
is required for just host name processing in DHCPv6. (replaces and enhances functions of IPv4 ARP Model). To truly
understand IPv6 and addrconf it is strongly recommended that
implementors understand IPv6 ND.
3. We need to determine the integration required with IPv6 Stateless Dynamic Updates to DNS is a specification that supports the
Address Configuration when both stateless and statefull is being used dynamic update of DNS records for both IPv4 and IPv6. DHCPv6 can use
by a client host. the dynamic updates to DNS to now integrate addresses and name space to
not only support autoconfiguration, but also autoregistration in IPv6.
4. In the Design Goals section should the MUSTs, SHOULDs, etc be Change History
capitalized and REQUIRED? Its not in DHCPv4?
5. Charlie Perkins will be doing our option spec for DHCPv6. We need Changes from July 95 to November 95 Drafts:
to make sure it synchs up with this spec.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995 Refined request/response codes and processing to support transaction
processing model.
Change History 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: Changes from March 95 to July 95 Drafts:
Used integer values instead of bit values for type and code Used integer values instead of bit values for type and code fields.
fields.
Used message-type and message-code fields and rely on looking at Used message-type and message-code fields and rely on looking at
the fields in the datagram instead of multiple over-lapping the fields in the datagram instead of multiple over-lapping
request/response codes. request/response codes.
Added address-count field processing to be specified by the client Added address-count field processing to be specified by the
as opposed to the server, and the processing for when client and client as opposed to the server, and the processing for when
server address-counts become disjoint. client and server address-counts become disjoint.
Added Requirements wording for MUST, SHOULD, MAY, etc. Added Requirements wording for MUST, SHOULD, MAY, etc.
Added Design Goals section. Added Design Goals section.
Re-Defined transaction-ID and interface-token. Redefined transaction-ID and interface-token.
Added Client/Server Binding definition and processing section to Added Client/Server Binding definition and processing
handle those bindings. section to handle those bindings.
Added more terminology, definitions, and rationale. Added more terminology, definitions, and rationale.
Added model to support Dynamic Updates to DNS for Host Names. Added model to support Dynamic Updates to DNS for Host Names.
Reduced the request/response model to 3 packets by not doing a Reduced the request/response model to 3 packets by not doing
server confirm to a clients confirm to a servers response. a server confirm to a clients confirm to a servers response.
Added model to support like lifetime fields for lease management Added model to support like lifetime fields for lease
to coordinate with IPv6 Stateless Address Configuration. management to coordinate with IPv6 Stateless Address
Autoconfiguration.
Added model and processing definitions for future DHCPv6 Options Added model and processing definitions for future DHCPv6 Options
Specification. Specification.
Added gateway-address and client-link-address for relay-agent Added gateway-address and client-link-address for relay-agent
processing. processing.
Removed excessive use of the acroynym DHCPv6 for section titles Removed excessive use of the acronym DHCPv6 for section titles
and when referencing clients and servers. and when referencing clients and servers.
Added Draft ***Open Issues*** Section for review by the DHC Added Draft ***Open Issues*** Section for review by the DHC Working
Working Group. Group.
Added Change History. Added Change History.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
Acknowledgements Acknowledgements
The DHC Working Group for their time and input into the The DHC Working Group for their time and input into the specification.
specification. A special thanks for the consistent input, ideas, and A special thanks for the consistent input, ideas, and review by (in
review by Ralph Droms, Thomas Narten, Jack Mccann, and Charlie alphabetical order) Brian Carpenter, Ralph Droms, Thomas Narten, Jack
Perkins. A big warm and extended thanks to Sue Thomson, Yakov Mccann, Charlie Perkins, Yakov Rekhter, Matt Thomas, Sue Thomson, and
Rehkter, and Phil Wells, who spent many hours in person and on the Phil Wells.
phone with the author to get the work done.
Sue Thomson and Yakov Rehkter were co-authors on the first
specification, and with the author have since March 1994 kept a
consistent view and belief that autoregistration MUST be part of the
Next Generation Internet Protocol version 6 and integrated into
autoconfiguration.
The author would also like to thank Steve Deering and Bob Hinden, who The author would also like to thank Steve Deering and Bob Hinden,
have consistently taken the time to discuss the more complex parts of who have consistently taken the time to discuss the more complex
the IPv6 specifications. parts of the IPv6 specifications.
The author MUST also thank his employer for the opportunity to work The author MUST also thank his employer for the opportunity and funding
on DHCPv6 and IPv6 in general. to work on DHCPv6 and IPv6 in general as an individual in the IETF.
References References
[DHCPv6-OPT]
C. Perkins, "Options for the Dynamic Host Configuration
Protocol for IPv6 (ODHCPv6)" Internet Draft, November 1995
<draft TBD>
[IPv6-SPEC] [IPv6-SPEC]
S. Deering and R. Hinden, "Internet Protocol Version 6 S. Deering and R. Hinden, "Internet Protocol Version 6
[IPv6] Specification" Internet Draft, June 1995 [IPv6] Specification" Internet Draft, June 1995
<draft-ietf-ipngwg-ipv6-spec-02.txt> <draft-ietf-ipngwg-ipv6-spec-02.txt>
[IPv6-ADDR] [IPv6-ADDR]
R. Hinden, S. Deering, Editors, "IP Version 6 Addressing R. Hinden, S. Deering, Editors, "IP Version 6 Addressing Architecture"
Architecture"
<draft-ietf-ipngwg-ipv6-addr-arch-03.txt> <draft-ietf-ipngwg-ipv6-addr-arch-03.txt>
[IPv6-ADDRCONF] [IPv6-ADDRCONF]
S. Thomson, "IPv6 Stateless Address Configuration" S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration"
Internet Draft, June 1995 <draft-ietf-addrconf-ipv6-auto-02.txt> <draft-ietf-addrconf-ipv6-auto-05.txt>
[IPv6-ND] [IPv6-ND]
T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Neighbor T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Neighbor Discovery"
Discovery" <draft-ietf-ipngwg-discovery-02.txt>
<draft-ietf-ipngwg-discovery-00.txt>
[IPv6-DNS] [IPv6-DNS]
S. Thompson and C. Huitema, "DNS Extensions to support IP S. Thompson and C. Huitema, "DNS Extensions to support IP
version 6", Internet Draft, March 1995 version 6", Internet Draft, March 1995
<draft-ietf-ipngwg-dns-00.txt> <draft-ietf-ipngwg-dns-00.txt>
[RFC-1034] [RFC-1034]
P. Mockapetris, "Domain Names - implementation and specification" P. Mockapetris, "Domain Names - implementation and specification"
STD-13, 11/01/87 STD-13, 11/01/87
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
[RFC-1035] [RFC-1035]
P. Mockapetris, "Domain Names - concepts and facilities" P. Mockapetris, "Domain Names - concepts and facilities"
STD-13, 11/01/87 STD-13, 11/01/87
[DYN-UPD] [DYN-UPD]
S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain
Name System (DNS)" Internet Draft, March 1995 Name System (DNS)" Internet Draft, March 1995
<draft-ietf-dnsind-dynDNS-01.txt> <draft-ietf-dnsind-dynDNS-01.txt>
[RFC-768] [RFC-768]
J. Postel, "User Datagram Protocol" J. Postel, "User Datagram Protocol"
STD-6, 08/28/80. STD-6, 08/28/80.
[DHCP-v4] [DHCP-v4]
R. Droms, "Dynamic Host Configuration Protocol" R. Droms, "Dynamic Host Configuration Protocol"
RFC 1541 Proposed Standard, October 1993 RFC 1541 Proposed Standard, October 1993
Authors' Addresses [IPv6-Ether]
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]
R. Atkinson, "Security Architecture for the Internet Protocol"
RFC 1825, August 1995
[IPv6-AUTH]
R. Atkinson, "IP Authentication Header"
RFC 1826, August 1995
[IPv6-ESP]
R. Atkinson, "IP Encapsulating Security Payload (ESP)"
RFC 1827, August 1995
Authors' Address
Jim Bound Jim Bound
Digital Equipment Corporation Digital Equipment Corporation
110 Spitbrook Road, ZKO3-3/U14 110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062 Nashua, NH 03062
Phone: (603) 881-0400 Phone: (603) 881-0400
Email: bound@zk3.dec.com Email: bound@zk3.dec.com
 End of changes. 

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