draft-ietf-dhc-dhcpv6-01.txt   draft-ietf-dhc-dhcpv6-02.txt 
INTERNET-DRAFT J. Bound INTERNET-DRAFT J. Bound
DHC Working Group Digital Equipment Corp DHC Working Group Digital Equipment Corp
March 1995 Y. Rekhter Obsoletes: draft-ietf-dhc-dhcpv6-01.txt July 95
T.J. Watson Research Center IBM Corp
Sue Thomson
Bellcore
Dynamic Host Configuration Protocol for IPv6 Dynamic Host Configuration Protocol for IPv6
draft-ietf-dhc-dhcpv6-01.txt draft-ietf-dhc-dhcpv6-02.txt
Status of this Memo Status of this Memo
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 Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 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).
Discussion for this draft will take place on host- Distribution of this document is unlimited.
conf@sol.cs.bucknell.edu.
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a DHCPv6 is an Internet application protocol that uses a Client/Server
mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6- model to communicate between hosts. DHCPv6 executes over the UDP
ADDR], provides parameters to autoregister [DYN-DNS-UPD] and receive [RFC-768] transport protocol, and the Internet Protocol Version 6
Domain Name System (DNS) [RFC-1034&1035] Host names, and provides a (IPv6) [IPv6-SPEC]. DHCPv6 is an IPv6 specification for a statefull
mechanism to specify additional configuration options in the implementation of address autoconfiguration as referenced in IPv6
protocol. Stateless Address Configuration [IPv6-ADDRCONF]. DHCPv6 supports
mechanisms to autoconfigure host IPv6 addresseses, autoregister host
names dynamically in the Domain Name System (DNS), and specifies the
format to add future Configuration Parameter options to the protocol
for extensibility.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 The work on this protocol will take place in the Dynamic Host
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
Table of Contents: Table of Contents:
1. Introduction................................................3 1. Introduction................................................3
2. Terminology.................................................3 1.1 Requirements................................................3
3. DHCPv6 Protocol Design Model................................4 2. Terminology and Definitions.................................5
3.1 DHCPv6 Protocol Request/Response Model......................4 2.1 IPv6 Terminology............................................5
3.2 DHCPv6 Leased Address Model.................................4 2.2 DHCPv6 Terminology..........................................6
3.3 DHCPv6 DNS Host Name Autoregistration Model.................5 3. Protocol Design Model.......................................8
3.4 DHCPv6 Client/Server Model..................................5 3.1 Related Work in IPv6........................................8
4. DHCPv6 Protocol Format......................................7 3.2 Design Goals................................................9
5. DHCPv6 Client/Server Processing.............................9 3.3 Request/Response Model.....................................10
5.1 DHCPv6 Client Transmission..................................9 3.4 Leased Address Model.......................................11
5.2 DHCPv6 Server Transmission..................................9 3.5 DNS Host Name Autoregistration Model.......................12
5.3 DHCPv6 Client Requests......................................9 3.6 Defining Optional Configuration-Data.......................13
5.4 DHCPv6 Client Responses....................................10 4. Datagram and Data Formats..................................14
5.5 DHCPv6 Server Responses....................................11 4.1 Datagram...................................................14
5.6 DHCPv6 Server Lease Expiration.............................13 4.2 Data Formats...............................................14
6. DHCPv6 Relay-Agent Processing..............................13 5. Client/Server Processing...................................16
Acknowledgements...............................................15 5.1 Client Transmission........................................16
References.....................................................15 5.2 Server Transmission........................................16
Authors' Addresses.............................................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-01.txt March 1995 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a
mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6-
ADDR], provides parameters to autoregister [DYN-DNS-UPD] and receive
Domain Name System (DNS) [RFC-1034&1035] Host names, and provides a
mechanism to specify additional configuration options in the
protocol.
DHCPv6 is an Internet application protocol that uses a Client/Server DHCPv6 is an Internet application protocol that uses a Client/Server
model to communicate between Hosts. DHCPv6 executes over the UDP model to communicate between hosts. DHCPv6 executes over the UDP
[RFC-768] transport protocol, and the IPv6 Internet Protocol Version [RFC-768] transport protocol, and the Internet Protocol Version 6
6 [IPv6-SPEC]. DHCPv6 will need to request Server and Client Ports (IPv6) [IPv6-SPEC]. DHCPv6 is an IPv6 specification for a statefull
from IANA. implementation of address autoconfiguration as referenced in IPv6
Stateless Address Configuration [IPv6-ADDRCONF]. DHCPv6 supports
mechanisms to autoconfigure host IPv6 addresseses, autoregister host
names dynamically in the Domain Name System (DNS), and specifies the
format to add future Configuration Parameter options to the protocol
for extensibility.
DHCPv6 is the IPv6 specification for a statefull implementation of The IPv6 new version of the Internet Protocol, is being developed
address autoconfiguration as defined in IPv6 Stateless Address with 128bit addresses. The IPv6 addressing architecture [IPv6-ADDR]
Configuration [IPv6-ADDRCONF]. and stateless address configuration [IPv6-ADDRCONF] specifications
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.
2. Terminology DHCPv6 uses the enhancements in IPv6 and DNS to define an efficient
protocol, and is not required to support any IPv4 protocol for
backward compatibility. DHCPv6 does use many of the architectural
principles in DHCP for IPv4 (DHCPv4) [DHCP-v4]. It is not within the
scope of this document to compare and contrast DHCPv4 with DHCPv6.
Configuration Data: Configuration Data is information a Host can use 1.1 Requirements
to configure a Host on a network so that the Host can interoperate
with other Hosts on a network.
DHCPv6 Client: A DHCPv6 Client is a Host that initiates requests on a Throughout this document, the words that are used to define the
network to obtain Configuration Data from a DHCPv6 server. significance of the particular requirements are capitalized. These
words are:
DHCPv6 Server: A DHCPv6 Server is a Host that responds to requests o "MUST"
from DHCPv6 clients to provide Configuration Data.
DHCPv6 Relay-Agent: A DHCPv6 Relay-Agent is a DHCPv6 Server that This word or the adjective "REQUIRED" means that the item is an
listens on the network for DHCPv6 Clients requesting Configuration absolute requirement of this specification.
Data, and then relays the request to a DHCPv6 Server and the reply
back to the DHCPv6 Client.
Transaction ID - This is used to uniquely identify a set of DHCPv6 o "MUST NOT"
request/response messages between DHCPv6 Servers and Clients. The
Transaction ID is generated by the DHCPv6 Client requests.
Interface-Token: An Interface Token is used to uniquely identify a This phrase means the item is an absolute prohibition of this
DHCPv6 Client network interface. specification.
Lease: This is the address lifetime for a single address provided to o "SHOULD"
a DHCPv6 Client.
Expired Lease: An Expired Lease is one where the Lease duration of an This word or the adjective "RECOMMENDED" means that there may
address has ended or because it has been mandated by a DHCPv6 Server exist valid reasons in particular circumstances to ignore this
to a DHCPv6 Client. item, but the full impliciations should be understood and the case
carefully weighed before choosing a different course.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 o "SHOULD NOT"
3. DHCPv6 Protocol Design Model This phrase means that there may exist valid reasons in particular
circumstances when the listed behavior is acceptable or even
3.1 DHCPv6 Protocol Request/Response Model INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
useful, but the full implications should be understood and the
case carefully weighted before implementing any behavior described
with this label.
o "MAY"
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because it enhances the
product, for example, another vendor may omit the same item.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
2. Terminology and Definitions
Terminology and Definitions are critical to the understanding of any
IETF specification. This Section will provide the terms and
definitions used throughout this specification. Relevant IPv6
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.
router: A node that forwards IPv6 packets not explicitly addressed to
itself.
host: Any node that is not a router.
link: A communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
IPv6. Examples are 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.
interface: A nodes's attachment to the link.
address: An IPv6 layer identifier for an interface or a set of
interfaces.
packet: An IPv6 header plus payload.
link MTU: The maximum transmission unit, i.e., maximum packet size in
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
source node and a destination node.
unicast address: An identifier for a single interface. A packet sent
to a unicast address is delivered to the interface identified by that
address.
multicast address: An identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to a multicast address
is delivered to all interfaces identified by that address.
link-local address: The link-local address is for use on a single
link. On initialization of an interface, a host forms a link-local
address by concatenating a well-known link-local prefix to a token
that is unique per link. For example, in the case of a host attached
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
address provided to a host. The validation-timer is in absolute time
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
and in seconds (e.g. 3 hours would have the value 10800).
deprecation-liftetime: This is the lifetime for a single address the
host uses to begin the deprecation of an address prior to the
validation-lifetime expiring, so that the host can determine if the
address can receive a new validation-lifetime. The deprecation-
lifetime is in absolute time and in seconds (e.g. 3 hours would have
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 state on a host because the deprecation-lifetime period
has expired.
invalid-address: This is a single address whose validation-lifetime
has expired.
2.2 DHCPv6 Terminology
configuration-type: Configuration Type defines an optional
configuration parameter in the DHCPv6 protocol.
configuration-data: Configuration Data is information a host can use
to configure a host on a network, so that the host can interoperate
with other hosts on a network. Configuration Data will vary in
length depending on the configuration type.
client: A Client is a host that initiates requests on a link to
obtain: addresses, DNS host name processing, or configuration-data.
server: A Server is a host that responds to requests from clients on
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
clients requests, and then forwards the request to a server on the
network. The server will respond back to the Relay-Agent, who will
forward the reply to the client on the Relay-Agents link.
message-type: The Message-Type defines the DHCPv6 protocol operation
for this packet.
message-code: The Message-Code defines a notification for a message-
type from a client or server.
name-length: The Name-Length defines the length of the host name
provided by a client or a server for DNS Autoregistration of host
names.
interface-token: The Interface-Token is specified by the client and
is a unique opaque identifer for a clients interface, and must be
accessbile after a client reboots (e.g. IEEE 802 MAC address).
address-count: The address-count is specified by the client with any
request sent to a server, and represents the number of addresses the
client has received from a server for a specified interface-token.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
client-address: The Client-Address is the field in the DHCPv6
protocol that contains the address for the clients interface-token.
server-address: The Server-Address is the field in the DHCPv6
protocol that contains the address of the server responding to the
clients request.
gateway-address: The Gateway-Address is the field in the DHCPv6
protocol that contains the relay-agents address, so a server, that
may be multiple relay-agent hops away from the orginal relay-agent,
can respond directly to the relay-agent that forwarded the request,
by extracting the Gateway- Address to be used as the server packets
destination address.
client-link-address: The client-link-address is the field in the
DHCPv6 protocol the relay-agents use to save the clients source
address in the IPv6 header, so they can respond back to the server on
the link.
transaction-ID: The Transaction-ID is specified by the client as an
opaque transaction identifier, which uniquely identifies the current
operation between the client and the server. The server may utilize
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
address. If the name-length is zero then the Host-Name is not
present in the DHCPv6 request or response.
binding: The Binding in DHCPv6 is a N-tuple that a client and server
MUST maintain in DHCPv6 for each completed transaction, where N is
the number of configuration-data identifiers for a client. An
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
3. Protocol Design Model
This section is provided for implementors to understand the DHCPv6
protocol design model from an architectural perspective. It provides
related work in IPv6 that influenced the protocol design and the
design goals. The request/response protocol model is discussed and
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
The following list gives general design goals for DHCPv6. Most
DHCPv4 Design Goals [DHCP-v4] are kept in this specification.
DHCPv6 should be a mechanism rather than a policy. DHCPv6 must
allow local system administrators control over configuration
parameters where desired; e.g., local system administrators should
be able to enforce local policies concerning allocation and access
to local resources where desired.
Hosts should require no manual configuration. Each host should be
able to discover appropriate local configuration parameters
without user intervention and incorporate those parameters into
its own configuration.
Networks should require no hand configuration for individual
hosts. Under normal circumstances, the network manager should not
have to enter any per-host configuration parameters.
DHCPv6 should not require a server on each link. To allow for
scale and economy, DHCPv6 must work across relay agents.
A DHCPv6 client must be prepared to receive multiple responses to
a request for configuration parameters. Some installations may
include multiple, overlapping DHCPv6 servers to enhance
reliability and increase performance.
DHCPv6 must coexist with statically configured, non-participating
hosts and with existing network protocol implementations.
DHCPv6 should as much as possible be compatible with IPv6
Stateless Address Configuration.
DHCPv6 servers should be able to support Dynamic Updates to DNS
[DYN-UPD].
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.
It is NOT a design goal of DHCPv6 to specify how a server
configuration database is maintained or determined.
The following list gives design goals specific to the transmission of
the network layer parameters.
Guarantee that any specific network address will not be in use by
more than one host at a time.
Guarantee that client addresses that are not provided by DHCPv6
will not be added to a servers configuration database or the
servers binding for a clients interface-token.
Retain host configuration across host reboot. A client should,
whenever possible, be assigned the same configuration-data in
response to each request.
Retain host configuration across server reboots, and, whenever
possible, a host should be assigned the same configuration
parameters despite restarts of the DHCPv6 mechanism,
Allow automatic assignment of configuration parameters to new
hosts to avoid hand configuration for new hosts.
Support fixed or permanent allocation of configuration parameters
to specific hosts.
Clients must not assume that addresses are updated to the DNS,
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 orginated
from a DHCPv6 Server or Client, and a request message code to define from a DHCPv6 Server or Client.
the operation requested, and a message response to define either a
response to a request or a confirmation/rejection to a response.
The request/response model is as follows: The message types are as follows:
1. Request (Client) 01 - client-configuration-request
2. Response with configuration data (Server). 02 - client-confirm-response
3. Confirmation Response with accept or reject (Client). 03 - client-reject-response
4. Confirmation Response for accept (Server). 04 - server-configuration-response
The time out period for a DHCPv6 Host to wait for a response is Request/Response Model States
implementation defined. When a DHCPv6 Host times out waiting for a
response to a packet sent, the Host should not commit any state based
on the content of the packet sent. It is implementation defined if
the packet is retransmitted.
A DHCPv6 packet will only contain one address and one name, depending 1. Request (client)
on the message type, request, and response codes in a packet. 2. Response with configuration-data or error found (server).
Because IPv6 supports multiple addresses per interface the DHCPv6 3. Confirmation Response or reject (client).
Server may also inform the DHCPv6 Client that there are multiple
addresses available for its use. This may be conveyed to the DHCPv6
Client in the Number of Address Fields provided in a response packet
by the DHCPv6 Server.
Multiple addresses and names may be specified as an extended The time out period for a client or server to wait for a response
configuration option [IPv6-DHCP-OPTIONS]. A design objective of MUST NOT exceed 3 minutes. When a client or server times out waiting
DHCPv6 is to avoid fragmentation in IPv6, when possible. If the for a response to a packet sent, the implementation MUST NOT commit
DHCPv6 packet exceeds 576 octets then UDP must perform Path MTU any binding based on the configuration-data sent in the packet. It
Discovery [PMTU]. The support of multiple names and addresses can be is implementation defined if the client or server packet is
a configuration option in DHCPv6.
If the DHCPv6 Host cannot match up any of the specified parameters, INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
as discussed in section 5 DHCPv6 Client/Server Processing, in this
protocol specification the packet should be silently discarded.
3.2 DHCPv6 Leased Address Model retransmitted.
A DHCPv6 address returned to a DHCPv6 Client has a Lease time. A 3.4 Leased Address Model
design objective of DHCPv6 is to support Dynamic Readdressing. To
accomplish this objective, addresses must be able to be reclaimed by
a network site. Hence, all addresses must be Leased in DHCPv6.
The DHCPv6 Client has the responsibility to renew a Lease for an An address returned to a client has a validation-lifetime and
address that is about to expire or request a new address with a Lease deprecation-lifetime. The lifetimes represent the lease for a single
time. address for a client. The server MUST provide a validation-lifetime
and SHOULD provide a deprecation-lifetime to a client in a server
response packet to a clients request for an address.
In the case where it is necessary to Expire a Lease because of a The client may suggest a value for the lifetimes in an address
mandate in an organizations site, the DHCPv6 Server may send a Lease 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
than the lifetimes requested by the client.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 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
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
MUST assume the client does not want a new lease for that address,
and the server MAY provide that address to another client requesting
an address.
Expired message with a grace period to a DHCPv6 Client. This will be If the the client has a deprecation-lifetime for an address the
an asynchronous operation by the DHCPv6 Server to the DHCPv6 Client, processing of the lease SHOULD be as follows:
and the only case where the DHCPv6 request/response model is not used
in the protocol.
When a DHCPv6 Clients address for a network interface Lease expires, When the deprecation-lifetime of an address expires, the clients
it may attempt to complete all oustanding network connections using address becomes a deprecated-address. A deprecated address SHOULD
that address, but must not use that address for new network NOT be used as a source address in new communications. However, a
connections. 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].
3.3 DHCPv6 DNS Host Name Autoregistration Model An address is a deprecated-address until its invalidation-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.
If the clients deprecation-lifetime is zero for an address the
processing for the lease SHOULD be as follows:
There is no concept of a deprecated-address for a client if the
deprecation-lifetime is zero when provided to the client in a
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
3.5 DNS Host Name Autoregistration Model
DHCPv6 supports the autoregistration of DNS Host names and providing DHCPv6 supports the autoregistration of DNS Host names and providing
DNS Host Names with addresses for DHCPv6 Clients. Autoregistration DNS Host Names with addresses for clients. Autoregistration is
is supported by fields in DHCPv6, which the DHCPv6 Client may provide supported by the presence of the name field in DHCPv6, which the
to the DHCPv6 Server in a request. In addition a DHCPv6 Server may client may provide to the server in a request. In addition a server
provide a DNS Host Name with an IPv6 address to a DHCPv6 Client in a may provide a DNS Host Name with an IPv6 address to a client in a
response. response.
DHCPv6 only specifies the parameters and action to be taken, and not If the name-length field is zero, there is no name field contained in
the actual protocol or primitives to interact with DNS. The the packet.
functions that the DHCPv6 Server uses to interact with the DNS to
provide autoregistration is defined in Dynamic Updates to DNS [IPv6-
DYN-UPD].
This is not a Fully Qualified Domain Name (FQDN) but only the local- DHCPv6 only specifies the name-field, and not the actual protocol or
part label and then only the Host Name [RFC-1034&1035]. It is primitives to interact with DNS. The functions that the server uses
assumed the DHCPv6 Server implementation knows or can determine what to interact with the DNS to provide autoregistration is defined in
the domain name part is for any IPv6 subnet prefix for which it is Dynamic Updates to DNS [DYN-UPD]. DHCPv6 servers SHOULD support
providing an address. If a DHCPv6 Client wants to know its domain Dynamic Updates to DNS.
name then it will have to request this as specified in the DHCPv6
Options Specification [IPv6-DHCP-OPTIONS].
3.4 DHCPv6 Client/Server Model If the client provides a Host Name (HN) or a Fully Qualified Domain
Name (FQDN) [RFC 1034&1035]:
DHCPv6 supports a Transaction ID to uniquely identify a set of The server SHOULD perform a DNS query for the HN or FQDN IPv6 DNS
request/response messages between DHCPv6 Clients and Servers. AAAA resource record [IPv6-DNS]:
DHCPv6 supports an Interface Token to uniquely identify a network If the name is found and the address does not match the clients
interface on a DHCPv6 Client. address for the name provided by the client, the server SHOULD add
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).
DHCPv6 can support an extensible set of options as defined by a If the name is not found the client supplied name SHOULD be added
Configuration Type. These options are specified in a DHCPv6 Options to the DNS.
specification [IPv6-DHCP-OPTIONS].
The DHCPv6 Options provide a Configuration Type which defines the In either condition above the server MUST add the associated DNS
option requested and then returned. A Next Type field is provided inverse address mapping as an IP6.INT domain PTR record [IPv6-DNS]
which can be used by an application to know if there is more than one for this clients address and name.
option. If the Next Type field is NULL then this is the last option
present. The Length field provides the length of the data present
for that option. The Variable Configuration Data is the data to
provide that option.
DHCPv6 does not specify whether the DHCPv6 Server Configuration Data If the server returns a name after updating the DNS it MUST return
provided to DHCPv6 Clients is synchronous across the sites network a FQDN to the client.
information database (e.g. DNS), whether the DHCPv6 Server
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 If the client does not request a HN or FQDN from a server, the server
MAY provide, in its response with the address to a client, a FQDN the
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.
Configuration Data is duplicated across DHCPv6 Servers, or how the When a clients address invalidation-lifetime expires on the server,
DHCPv6 Configuration Data is pre-configured on a DHCPv6 Server. the server SHOULD delete the clients IPv6 AAAA record and IP6.INT
domain PTR record from the DNS.
DHCPv6 does not specify conditions or results when multiple DHCPv6 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
Servers are located on an IPv6 subnet. The DHCPv6 Client may respond
to DHCPv6 Servers it does not want to communicate with by sending a
REJECT_PACKET confirmation response to a DHCPv6 Server.
DHCPv6 does not specify a DHCPv6 Server-to-Server protocol. 3.6 Defining Optional Configuration-Data
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 Optional configuration-data MUST be specified for DHCPv6 as follows
and aligned on an integer multiple of 8 octets:
4. DHCPv6 Protocol Format option-type: 1 Octet
DHCPv6 Data Packet This field permits 254 options for DHCPv6 and will represent the
tag for the option. The values of 0 and 1 are used for pad
options discussed below.
option-length: 2 Octets
This field specifies the length of the configuration-data not
including the the option-type and and option-length fields.
option-data: Variable number of Octets
The option-data is the configuration-data that immediately follows
the option-length field.
If the server does not support an option-type requested it MUST
return the option-type and the option-length set to zero in the
response to the client.
A server implementation MUST start any options after the first option
returned to a client on an integer multiple of 8 octets. This is an
architectural REQUIREMENT, and the client when parsing options can
assume the next option, if it exists will begin on the next integer
multiple of 8 octets boundary.
This specification does not define any options. DHCPv6 options are
defined in XXXXXXXXX. It is permissible for options to also create
new message-types and message-codes as required.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
4. Datagram and Data Formats
4.1 Datagram
DHCPv6 Datagram
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Msg Request | | msg-type | msg-code | name-lgth | addr-count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Response | Addrs Avail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease Time | | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Token | | interface-token |
| (8 Octets) | | (8 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address | | client-address |
| (16 Octets) | | (16 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name | | server-address |
| (64 Octets) | | (16 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server IPv6 Address | | gateway-address |
| (16 Octets) | | (16 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config Type | Next Type | Length | | client-link-address |
| (16 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Configuration Data | | validation-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| deprecation-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| host-name |
| (variable octets 0-255) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-type | option-lgth | option-data (variable octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the field definitions below bit position 0 is the high-order bit in 4.2 Data Formats
the sequence of Octets for each field.
Msg Type : 1 Octet All fields in the datagram MUST be initialized to binary zeroes
The field defines the operation to be performed by the packet. by both the client and server messages unless otherwise noted
in Section 5. Client and Server processing of messages.
Bit 0 = ON: Server Message Operation msg-type : 1 Octet integer value (message-type)
Bit 1 = ON: Client Message Operation
Bit 2-7 RESERVED
Msg Request : 3 Octets Value Description
Bit 0 = ON: ADDRESS_REQUEST 1 - Client request for configuration data.
Bit 1 = ON: NAME_REQUEST 2 - Server response with configuration data.
Bit 2 = ON: CONFIG_REQUEST 3 - Client confirmation of server response.
Bit 3 = ON: ADDRESS_SUPPLIED 4 - Client rejection of server response.
Bit 4 = ON: LEASE_EXPIRED
Bit 5-24 RESERVED
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
Msg Response : 3 Octets msg-code : 1 Octet integer value (message-code)
Bit 0 = ON: ADDRESS_RETURNED
Bit 1 = ON: ADDRESS_ACCEPTED
Bit 2 = ON: ADDRESS_REJECTED
Bit 3 = ON: NAME_ACCEPTED
Bit 4 = ON: NAME_RETURNED
Bit 5 = ON: NAME_REJECTED
Bit 6 = ON: SERVER_ADDRESS
Bit 7 = ON: CONFIG_ACCEPTED
Bit 8 = ON: CONFIG_RETURNED
Bit 9 = ON: CONFIG_REJECTED
Bit 10 = ON: LEASE_ACCEPTED
Bit 11 = ON: LEASE_REJECTED
Bit 12 = ON: CONFIRM_PACKET
Bit 13 = ON: REJECT_PACKET
Bit 14-24 RESERVED
Addrs Avail : 1 Octet Value Description
Number of IPv6 addresses available to the DHCPv6 Client, that can be
provided by the DHCPv6 Server. Integer Number.
Transaction ID : 4 Octets 1 - Server Response - Client address-count is in error.
Identifies request/response messages and is a 32bit random 2 - Server Response - Dynamic Updates to DNS not supported.
generated number by the DHCPv6 Client. Integer Number.
Lease Time : 4 Octets name-lgth : 1 Octet integer value (name-length)
This field is used to provide a Lease time for an address and a
renewal time period for an address that is being reclaimed.
Integer Number. Absolute time in seconds.
Interface Token : 8 Octets addr-count : 1 Octet integer value (address-count)
This field is determined by the DHCPv6 Client and is a 64bit random
generated number. An Interface Token is defined by the DHCPv6 Client for
each network interface it configures on its Host. Integer Number.
IPv6 Address : 16 Octets transaction-ID : 4 Octets integer value
DHCPv6 Client IPv6 Address.
Host Name : 64 Octets interface-token : 4 Octets integer value
DHCPv6 Host Name. This is not the Fully Qualified Domain Name
(FQDN).
Server IPv6 Address : 16 Octets client-address : 16 Octets address
DHCPv6 Server IPv6 Address.
Configuration Type : 1 Octet server-address : 16 Octets address
This field defines the Configuration Data option in the packet.
The configuation types are specified in DHCPv6 Options
[IPv6-DHCP-OPTIONS].
Configuration Next Type : 1 Octet gateway-address : 16 Octets address
This field defines the Configuration Data Type that follows this
Configuration Data if multiple configuration requests are present.
A NULL value means that this is the only or last Configuration Data
Type provided.
Configuration Data Length : 2 Octets client-link-address : 16 Octets address
This field is the Length of the Configuration Data.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 validation-lifetime : 4 Octets integer value
Variable Configuration Data : 452 Octets deprecation-lifetime : 4 Octets integer value
This is a variable length field where configuration data will be
supplied as options for DHCPv6 protocol.
If the Configuration Data provided causes the DHCPv6 packet to exceed host-name : 0-255 Octets character(s) value(s)
576 Octets then the implementation should verify through Path MTU
Discovery [IPv6-SPEC&ICMP,PMTU] that the packet will be able to reach its
destination without Fragmentation, or use the IPv6 Fragmentation Extended
Header [IPv6-SPEC].
5. DHCPv6 Client/Server Processing option-type : 1 Octet integer value
5.1 DHCPv6 Client Transmission option-length : 1 Octet integer value
The DHCPv6 Client will set Client Msg Type to ON to transmit to option-data : Variable Octets variant value(s)
DHCPv6 Servers. UDP DHCPv6 Server Port (TBD) must be used to build
the sending packet in an implementation. A DHCPv6 Client may provide
multiple requests in a request packet and multiple responses in a
response packet, to a DHCPv6 Server in one packet.
If the DHCPv6 Client knows its IPv6 address it will be put in the INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
source address field of the IPv6 Header. Otherwise the DHCPv6
Clients link-local address [IPv6-ADDR] is used as the source address
field in the IPv6 Header.
If the DHCPv6 Client knows the address of a DHCPv6 Server it will put 5. Client/Server Processing
that address in the destination field of the IPv6 Header. Otherwise
a well known IPv6 multicast address using intra-link scope [IPv6-
ADDR] is used as the destination address field in the IPv6 Header
[This multicast address will have to be supplied by IANA for DHCPv6].
5.2 DHCPv6 Server Transmission 5.1 Client Transmission
The DHCPv6 Server will set Server Msg Type ON to transmit to DHCPv6 UDP DHCPv6 Server Port 546 MUST be used by the client to send UDP
Clients. UDP DHCPv6 Client Port (TBD) must be used to build the datagrams to the server.
sending packet in an implementation. A DHCPv6 Server may provide
multiple responses to a DHCPv6 Client in one packet.
The DHCPv6 Server will use the source address of the IPv6 Header from If the client knows its address it MUST be put in the source address
the DHCPv6 Client as the destination address in the DHCPv6 Server field of the IPv6 Header. Otherwise the clients link-local address
IPv6 Header address. The DHCPv6 Server IPv6 Header source addresses MUST be used as the source address field in the IPv6 Header [IPv6-
will be the IPv6 address of the DHCPv6 Server responding. ADDRCONF].
5.3 DHCPv6 Client Requests If the client knows the address of the server on its link it MUST put
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.
Msg Request field: The client MUST set msg-type to 1 to transmit a request to the
server.
If ADDRESS_REQUEST is set, then a request is being made for an IPv6 The client MUST set msg type to 3 to confirm the acceptance of packet
address and Lease. If the Lease field does not equal zero then the from a server response.
DHCPv6 Client is supplying a Lease time to the DHCPv6 Server. The DHCPv6
Client may also set ADDRESS_SUPPLIED and provide an IPv6 address to the
DHCPv6 Server for verification.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 The client MUST set msg type to 4 to reject a packet from a server
response.
A DHCPv6 Client must send an ADDRESS_REQUEST to the DHCPv6 Server The client MUST use UDP DHCPv6 Client Port 546 as the UDP port to
to renew its Lease before it expires. The DHCPv6 Client may request accept server responses in an implementation.
that the same address be used again by providing an IPv6 address and
having ADDRESS_SUPPLIED set in the request. If the DHCPv6 Clients
Lease on an address expires, then the DHCPv6 Server will expire the
Lease for that address.
If NAME_REQUEST is set, then a request is being made for a DNS Host Name. 5.2 Server Transmission
supplied by the DHCPv6 Client.
If CONFIG_REQUEST is set, then a request is being made for an IPv6 UDP DHCPv6 Client Port 546 MUST be used by the server to send UDP
Configuration Data return from the DHCPv6 Server. datagrams to the client.
Msg Response field: must be NULL. A server, on the same link as the client, MUST use the source address
in the IPv6 Header from the client as the destination address in the
servers response packet. Servers not on the same link are discussed
in Section 6 Relay-Agent Processing.
Addrs Avail field: must be NULL. The server MUST set msg type to 2 to transmit a response to a client.
Transaction ID field: must contain a random number generated Integer The server MUST use UDP DHCPv6 Server Port 547 as the UDP port to
determined by the DHCPv6 Client for this request packet. accept client requests in an implementation.
Lease Time field: may contain a Lease time requested by the DHCPv6 The server MUST join the DHCP Server/Relay-Agent mulicast group
Client or must be NULL. 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.
Interface Token field: must contain a random number generated Integer INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
to identify addresses associated with a DHCPv6 Clients network
interface.
IPv6 Address field: must contain an IPv6 Address if ADDRESS_SUPPLIED 5.3 Client/Server Bindings
or NAME_REQUEST is set, otherwise NULL.
Host Name field: must contain a Host Name if NAME_REQUEST is set, Client and server bindings MUST be maintained at least as a 4-tuple
otherwise NULL. consisting of the clients interface-token, address, validation-
lifetime, and deprecation-lifetime in an implementaiton. It is
critical for the interoperability of DHCPv6 that the clients bindings
remain consistent with the servers bindings across reboots.
Server IPv6 Address field: must be NULL. When a client sends a request it MUST enter in the addr-count field
the number of addresses that it has for a particular interface-token
in the clients bindings.
Configuration Type field: must contain a valid Configuration Type as When the server receives the client request, it MUST verify that the
defined in the DHCPv6 Options specification [IPv6-DHCP-OPTIONS], if addr-count field provided by the client matches the number of
CONFIG_REQUEST is set, otherwise the Configuration fields are not addresses the server has for that clients binding, for the
present in the packet. interface-token provided by the client. If the server has a
different addr-count than the client for a particular interface
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.
Configuration Next Type field: If CONFIG_REQUEST set, and there is Once the client receives a response with a msg-code set to 1 it MUST
more than one, then the value of the next configuration type should set addr-count to zero on subsequent requests to the server, for that
be put into this field, otherwise NULL. interface-token.
Configuration Data Length field: NULL. When a server receives a request from a client and the addr-count is
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.
Variable Configuration Data field: Not present in the packet. 5.4 Client Requests
5.4 DHCPv6 Client Responses The client sets the following fields for a request for
configuration-data:
The Transaction ID from the DHCPv6 Server response must match one of msg-type: Set to 1.
the DHCPv6 Clients Transaction IDs from a previous request.
Msg Request field: must be NULL. name-lgth: Set to the length of the host-name if provided.
Msg Response field: addr-count: Set to the number of addresses the client has for the
interface-token specified in this request.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 transaction-ID: Set to a unqiue integer value.
If ADDRESS_ACCEPTED is set, the DHCPv6 Client is informing the DHCPv6 interface-token: Set to a unqiue opaque identifier.
Server that it has received the address returned.
If CONFIG_ACCEPTED is set, the DHCPv6 Client is informing the DHCPv6 client-address: Set ONLY if the client is requesting a host name
Server that it has received the Configuration Data returned. for a particular address, else not set.
If NAME_ACCEPT is set, the DHCPv6 Client is informing the DHCPv6 validation-lifetime: Set to the value the client would like the
Server that it received the NAME_RETURNED returned, when the DHCPv6 server to use, else not set.
Client supplied a Host Name with NAME_REQUEST set.
If REJECT_PACKET is set, the DHCPv6 Client is rejecting a response deprecation-lifetime: Set to the value the client would like the
from a DHCPv6 Server. server to use, else not set.
Addrs Avail field: must be NULL. host-name: Set only if name-lgth is greater than zero otherwise
Transaction ID field: must contain a random number generated Integer INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
matching the DHCPv6 Server request or response.
Lease Time field: must be NULL. this field is not present.
Interface Token field: must contain a random number generated Integer option-type: Set to a future option request for configuration-
to identify addresses associated with a DHCPv6 Clients network data, otherwise the field is not present. Multiple option-types
interface. may be set adjacent to each other.
IPv6 Address field: must be NULL. 5.5 Server Response
Host Name field: must be NULL. The server sets the following fields for a response to a client for
configuration-data:
Server IPv6 Address field: must be NULL. msg-type: Set to 2.
Configuration Data Fields not present in the packet. msg-code: Set to 1 if addr-count not equal to servers bindings for
the clients specified interface-token. Set to 2 if the 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.
5.5 DHCPv6 Server Responses If the server determines that addr-count is not equal to its
bindings it stops all other DHCPv6 processing, hence, the
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.
The Transaction ID from a DHCPv6 Servers response must match one of Processing of msg-code set to 1 for the client and server is
the DHCPv6 Clients Transaction IDs from a previous request. done as specified in 5.3 Client/Server Bindings.
Msg Request field: must be NULL. name-lgth: Set to the length of the host-name if present.
Msg Response field: addr-count: Set to the same value specified by the client.
If ADDRESS_RETURNED is set, the DHCPv6 Server is providing the DHCPv6 transaction-ID: Set to the same value specified by the client.
Client with an IPv6 Address.
If ADDRESS_ACCEPTED is set, the DHCPv6 Server has accepted the address interface-token: Set to the same value specified by the client.
supplied by the DHCPv6 Client.
If ADDRESS_REJECTED is set, the DHCPv6 Server is not accepting the client-address: If the client-address from the request packet is
address provided by the DHCPv6 Client. 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.
Only one of the above settings must be present in a response to a DHCPv6 server-address: The server MUST set this field to its address in
Client request. The IPv6 address provided will either be the one all response packets.
presented by the DHCPv6 Client or an address provided by the DHCPv6
Server when ADDRESS_RETURNED is set.
If NAME_RETURNED is set, the DHCPv6 Server is providing a Host Name with validation-lifetime: The server sets this address to the
the address returned to the DHCPv6 Client either in response to a DHCPv6 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.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 deprecation-lifetime: The server sets this address to the
deprecation-lifetime of the servers configuration database. It is
implementation defined if the server will use the deprecation-
Client NAME_REQUEST or because it is implementation defined to provide INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
Host Names with ADDRESS_RETURNED set.
If NAME_REJECTED is set, the DHCPv6 Server is informing the DHCPv6 lifetime if specified by a client request packet.
Client that the NAME_REQUEST was rejected by DNS. The DHCPv6 Server
must also supply an address in the IPv6 Address field.
If CONFIG_RETURNED is set, the DHCPv6 Server is providing the host-name: The server returns a hostname or msg-code set to 2, if
Configuration Data requested. the name-lgth field is greater than zero. Processing of host-name
is specified in Section 3.5 DNS Host Name Autoregistration Model.
If CONFIG_REJECTED is set, the DHCPv6 Server is informing the DHCPv6 option-type: The server returns the same option-types specified by
Client that the Configuration Data requested is not supported. the client requests.
If LEASE_ACCEPTED is set, the DHCPv6 Server is informing the DHCPv6 option-lgth: The server returns the length of the configuration-
Client that the Lease presented has been accepted. The Lease Time field data or zeroes if the option is not supported.
will contain the Lease requested by the DHCPv6 Client.
If LEASE_REJECTED is set, the DHCPv6 Server is rejecting the Lease Time option-data: The server returns the configuration-data requested
provided by the DHCPv6 Client and will return a Lease time specified by the client.
by the DHCPv6 Server.
If SERVER_ADDRESS is set, the DHCPv6 Server is returning its address 5.6 Client Confirmations/Rejections
in the response. The DHCPv6 Server will do this when the destination
address in the IPv6 Header is an intra-link Multicast address, or has
a network prefix subnet value for which the DHCPv6 Server is
not a member.
If CONFIRM_PACKET is set, the DHCPv6 Server is informing the DHCPv6 The client sets the following fields for a confirmation or rejection
Client it has received a response to the DHCPv6 Server response to the after receiving configuration-data from the server. configuration-
DHCPv6 Clients initial request. This will be the only msg response data:
code set by the DHCPv6 Server in this response.
Addrs Avail field: If ADDRESS_RETURNED is set, the DHCPv6 Server is msg-type: Set to 3 if the client is confirming a servers response.
informing the DHCPv6 Client that it has an integer number of Set to 4 if the client is rejecting a servers response.
addresses available for the DHCPv6 Client less the address being
provided. When the DHCPv6 Client responds to this response with
ADDRESS_ACCEPTED the DHCPv6 Server must decrement the number of
addresses available for the DHCPv6 Client. If ADDRESS_ACCEPTED is
set, the DHCPv6 Server is informing the DHCPv6 Client that it has a
number of addresses available that can be used by the DHCPv6 Client.
Otherwise the Addrs Avail field is NULL.
Transaction ID field: must contain a random number generated Integer When the server receives a rejection msg-type 4 from a client
determined by the DHCPv6 Clients request packet. 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.
Lease Time field: must contain a Lease Time with any returned transaction-ID: Same value as specified in the servers response.
addresses that were requested, otherwise NULL.
Interface Token field: must contain a random number generated Integer interface-token: Same value as specified in the servers response.
to identify addresses associated with a DHCPv6 Clients network
interface.
IPv6 Address field: must contain an IPv6 Address. client-address: Same value as specified in the servers response.
Host Name field: must contain a Host Name if NAME_RETURNED is set 6. Relay-Agent Processing
otherwise NULL.
Server IPv6 Address field: must contain an IPv6 address if The relay-agent MUST use UDP DHCPv6 Server Port 547 as the UDP port
to accept client responses in an implementation.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 The relay-agent MUST join the DHCP Server/Relay-Agent mulicast group
well-known multicast address FF02:0:0:0:0:0:1:0 using link-local
scope [IPv6-ADDR], to listen for client requests.
SERVER_ADDRESS is set, otherwise NULL. When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it
MUST:
Configuration Type field: must contain a valid Configuration Type as If the gateway-address is NOT zero then the relay-agent MUST:
defined in the DHCPv6 Options [IPv6-DHCP-OPTIONS] if CONFIG_RETURN or
CONFIG_REJECTED is set, otherwise the Configuration fields are not
present in the packet.
Configuration Next Type field: If CONFIG_RETURNED or CONFIG_REJECTED Put the relay-agents IPv6 address in the gateway-address field
is set, and if there is more than one Congfiguration Type present, of the clients request packet.
the value of the next configuration type should be put into this
field, otherwise NULL.
Configuration Data Length field: If CONFIG_RETURNED is set, then this Put the the source address from the IPv6 Header of the clients
is the length of the Configuration Data present. If CONFIG_REJECTED
is set, then the DHCPv6 Server will set length to zero.
Variable Configuration Data field: Contains Configuration Data only INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
if CONFIG_RETURNED is set, otherwise there is no Configuration Data
present in the packet.
5.6 DHCPv6 Server Lease Expiration request packet in the client-link-address.
The DHCPv6 may send an asynchronous LEASE_EXPIRED message with a All relay-agents MUST:
grace period if an organizations network site needs to reclaim
addresses when their Lease has not expired.
Msg Request field: Put their relay-agent address as the source address for the
IPv6 Header.
LEASE_EXPIRED is set. Put the next relay-agent or known server address as the
destination address in the IPv6 Header.
Msg Response field: must be NULL. Forward the packet to the to the next hop relay-agent or known
server.
Addrs Avail field: must be NULL. When the remote server receives the client request from the relay-
agent it will know its a remote client request (not on the servers
link), because there is a gateway-address in the request. So servers
MUST test the gateway-address is not zero, to determine if the
clients request is from a remote link.
Transaction ID field: NULL. The server responds as specified in 5.5 Server Response, but uses the
gateway-address as the destination address in the IPv6 Header.
Lease Time field: must contain a grace period for the DHCPv6 Client When the relay-agent receives the remote servers response, it MUST
to renew a lease for an address. forward the packet to the client, by using the client-link-address as
the source address for the IPv6 Header.
Interface Token field: must contain a random number generated Integer INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
for the DHCPv6 Client IPv6 address.
IPv6 Address field: must contain an IPv6 Address being used for an Draft ***Open Issues***
Interface Token by a DHCPv6 Client.
Host Name field: must be NULL. 1. The present model uses UDP with a client request, server
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).
IPv6 Server Address field: must be NULL. This can be greatly alleviated by using TCP instead of UDP for the
transaction. This would have great benefits such as:
Configuration fields: not present in the packet. 1. Guranteed virtual link, hence if the transaction completes
the server and client know immediately upon return to the
application.
6. DHCPv6 Relay-Agent Processing 2. PATH MTU Discovery for TCP is inherent in an implementation
and the DHCPv6 application does not have to adjust for IPv6
fragmentation model.
When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it We can also use UDP to locate servers and TCP for the transaction.
should forward that request to a DHCPv6 Server as a DHCPv6 Client Msg
Type.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 2. Dynamic Updates to DNS need careful review for clarity and what
is required for just host name processing in DHCPv6.
The DHCPv6 Relay-Agent upon receiving a response from the DHCPv6 3. We need to determine the integration required with IPv6 Stateless
Server should forward that response to the DHCPv6 Client. Address Configuration when both stateless and statefull is being used
by a client host.
When the DHCPv6 Relay-Agent forwards the request to the DHCPv6 Server 4. In the Design Goals section should the MUSTs, SHOULDs, etc be
it puts the DHCPv6 Relay-Agent's IPv6 address in the source field of capitalized and REQUIRED? Its not in DHCPv4?
the IPv6 Header.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 5. Charlie Perkins will be doing our option spec for DHCPv6. We need
to make sure it synchs up with this spec.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
Change History
Changes from March 95 to July 95 Drafts:
Used integer values instead of bit values for type and code
fields.
Used message-type and message-code fields and rely on looking at
the fields in the datagram instead of multiple over-lapping
request/response codes.
Added address-count field processing to be specified by the client
as opposed to the server, and the processing for when client and
server address-counts become disjoint.
Added Requirements wording for MUST, SHOULD, MAY, etc.
Added Design Goals section.
Re-Defined transaction-ID and interface-token.
Added Client/Server Binding definition and processing section to
handle those bindings.
Added more terminology, definitions, and rationale.
Added model to support Dynamic Updates to DNS for Host Names.
Reduced the request/response model to 3 packets by not doing a
server confirm to a clients confirm to a servers response.
Added model to support like lifetime fields for lease management
to coordinate with IPv6 Stateless Address Configuration.
Added model and processing definitions for future DHCPv6 Options
Specification.
Added gateway-address and client-link-address for relay-agent
processing.
Removed excessive use of the acroynym DHCPv6 for section titles
and when referencing clients and servers.
Added Draft ***Open Issues*** Section for review by the DHC
Working Group.
Added Change History.
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995
Acknowledgements Acknowledgements
Brian Carpenter, Alex Conta, Jack McCann, Ralph Droms for providing The DHC Working Group for their time and input into the
input to the evolution of DHCPv6. specification. A special thanks for the consistent input, ideas, and
review by Ralph Droms, Thomas Narten, Jack Mccann, and Charlie
Perkins. A big warm and extended thanks to Sue Thomson, Yakov
Rehkter, and Phil Wells, who spent many hours in person and on the
phone with the author to get the work done.
References 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.
[IPv6-ADDR] The author would also like to thank Steve Deering and Bob Hinden, who
R. Hinden, Editor, "IP Version 6 Addressing Architecture" have consistently taken the time to discuss the more complex parts of
<draft-ietf-ipngwg-ipv6-addr-arch-00.txt> the IPv6 specifications.
Y. Rekhter, "An IPv6 Global Unicast Address Format" The author MUST also thank his employer for the opportunity to work
<draft-ietf-ipngwg-address-format-01.txt> on DHCPv6 and IPv6 in general.
[IPv6-SPEC] References
S. Deering and R. Hinden, Editors, "Internet Protocol Version 6
[IPv6] Specification" Internet Draft, March 1995
<draft-ietf-ipngwg-ipv6-spec-01.txt>
[IPv6-ICMP] [IPv6-SPEC]
A. Conta, S. Deering "ICMPv6 for the Internet Protocol S. Deering and R. Hinden, "Internet Protocol Version 6
Version 6 [IPv6]" Internet Draft, March 1995 [IPv6] Specification" Internet Draft, June 1995
<draft-ietf-ipngwg-icmp-02.txt> <draft-ietf-ipngwg-ipv6-spec-02.txt>
[PMTU] [IPv6-ADDR]
J. Mogul, S. Deering "Path MTU Discovery" R. Hinden, S. Deering, Editors, "IP Version 6 Addressing
RFC 1191, 11/16/90 Architecture"
<draft-ietf-ipngwg-ipv6-addr-arch-03.txt>
[IPv6-ADDRCONF] [IPv6-ADDRCONF]
S. Thomson, "IPv6 Stateless Address Configuration" S. Thomson, "IPv6 Stateless Address Configuration"
Internet Draft, March 1995 <draft-ietf-addrconf-ipv6-auto-01.txt> Internet Draft, June 1995 <draft-ietf-addrconf-ipv6-auto-02.txt>
W. A. Simpson "IPv6 Neighbor Discovery - Processing" [IPv6-ND]
<draft-simpson-ipv6-discov-process-01.txt> T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Neighbor
Discovery"
<draft-ietf-ipngwg-discovery-00.txt>
[IPv6-DNS]
S. Thompson and C. Huitema, "DNS Extensions to support IP
version 6", Internet Draft, March 1995
<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-DNS-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>
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
[IPv6-DHCP-OPTIONS]
<TBD>
[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]
R. Droms, "Dynamic Host Configuration Protocol"
RFC 1541 Proposed Standard, October 1993
Authors' Addresses Authors' Addresses
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
Yakov Rekhter
T.J. Watson Research Center, IBM Corporation
P.O. Box 570
Yorktown Heights, NY 10598
Phone: (914) 784-7361
Email: yakov@watson.ibm.com
Sue Thomson
Bellcore
445 South Street
Morristown, NJ 07960
Phone: (201) 829-4514
Email: set@thumper.bellcore.com
 End of changes. 

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