WDIFF

draft-ietf-dhc-dhcpv6-01.txt --> draft-ietf-dhc-dhcpv6-02.txt

Dynamic Host Configuration Protocol for IPv6

draft-ietf-dhc-dhcpv6-01.txt

draft-ietf-dhc-dhcpv6-02.txt

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Discussion for

Distribution of this draft will take place on host-
conf@sol.cs.bucknell.edu. document is unlimited.

Abstract

The Dynamic Host Configuration

DHCPv6 is an Internet application protocol that uses a Client/Server
model to communicate between hosts. DHCPv6 executes over the UDP
[RFC-768] transport protocol, and the Internet Protocol for Version 6
(IPv6) [IPv6-SPEC]. DHCPv6 is an IPv6 (DHCPv6): provides specification for a
mechanism statefull
implementation of address autoconfiguration as referenced in IPv6
Stateless Address Configuration [IPv6-ADDRCONF]. DHCPv6 supports
mechanisms to autoconfigure inter-link Host host IPv6 addresseses [IPv6-
ADDR], provides parameters to addresseses, autoregister [DYN-DNS-UPD] and receive host
names dynamically in the Domain Name System (DNS) [RFC-1034&1035] Host names, (DNS), and provides a
mechanism specifies the
format to specify additional configuration add future Configuration Parameter options to the protocol
for extensibility.

The work on this protocol will take place in the
protocol. 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.

Expires September December 1995 [Page 1]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

Table of Contents:

1. Introduction................................................3
1.1 Requirements................................................3
2. Terminology.................................................3
3. Terminology and Definitions.................................5
2.1 IPv6 Terminology............................................5
2.2 DHCPv6 Terminology..........................................6
3. Protocol Design Model................................4 Model.......................................8
3.1 DHCPv6 Protocol Request/Response Model......................4 Related Work in IPv6........................................8
3.2 DHCPv6 Design Goals................................................9
3.3 Request/Response Model.....................................10
3.4 Leased Address Model.................................4
3.3 DHCPv6 Model.......................................11
3.5 DNS Host Name Autoregistration Model.................5
3.4 DHCPv6 Client/Server Model..................................5 Model.......................12
3.6 Defining Optional Configuration-Data.......................13
4. DHCPv6 Protocol Format......................................7 Datagram and Data Formats..................................14
4.1 Datagram...................................................14
4.2 Data Formats...............................................14
5. DHCPv6 Client/Server Processing.............................9 Processing...................................16
5.1 DHCPv6 Client Transmission..................................9 Transmission........................................16
5.2 DHCPv6 Server Transmission..................................9 Transmission........................................16
5.3 DHCPv6 Client Requests......................................9 Client/Server Bindings.....................................17
5.4 DHCPv6 Client Responses....................................10 Requests............................................17
5.5 DHCPv6 Server Responses....................................11 Response............................................18
5.6 DHCPv6 Server Lease Expiration.............................13 Client Confirmations/Rejections............................19
6. DHCPv6 Relay-Agent Processing..............................13
Acknowledgements...............................................15
References.....................................................15 Processing.....................................19
Draft ***Open Issues***........................................21
Change History.................................................22
Acknowledgements...............................................23
References.....................................................23
Authors' Addresses.............................................16 Addresses.............................................24

Expires September December 1995 [Page 2]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

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
model to communicate between Hosts. hosts. DHCPv6 executes over the UDP
[RFC-768] transport protocol, and the IPv6 Internet Protocol Version 6
(IPv6) [IPv6-SPEC]. DHCPv6 will need to request Server and Client Ports
from IANA.

DHCPv6 is the an IPv6 specification for a statefull
implementation of address autoconfiguration as defined referenced in IPv6
Stateless Address Configuration [IPv6-ADDRCONF].

2. Terminology

Configuration Data: 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 Data is information a Host can use Parameter options to configure a Host on a network so that the Host can interoperate protocol
for extensibility.

The IPv6 new version of the Internet Protocol, is being developed
with other Hosts on a network.

DHCPv6 Client: A DHCPv6 Client is a Host that initiates requests on a
network 128bit addresses. The IPv6 addressing architecture [IPv6-ADDR]
and stateless address configuration [IPv6-ADDRCONF] specifications
provide new functionality not present in the Internet Protocol
version 4 (IPv4), which provide inherent benefits to obtain Configuration Data from a DHCPv6 server.

DHCPv6 Server: A DHCPv6 Server is 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 Host that responds node to requests
from add, delete, and change host
names dynamically.

DHCPv6 clients uses the enhancements in IPv6 and DNS to provide Configuration Data.

DHCPv6 Relay-Agent: A DHCPv6 Relay-Agent define an efficient
protocol, and is a not required to support any IPv4 protocol for
backward compatibility. DHCPv6 Server that
listens on does use many of the network architectural
principles in DHCP for DHCPv6 Clients requesting Configuration
Data, and then relays IPv4 (DHCPv4) [DHCP-v4]. It is not within the request
scope of this document to a DHCPv6 Server compare and contrast DHCPv4 with DHCPv6.

1.1 Requirements

Throughout this document, the reply
back words that are used to define the DHCPv6 Client.

Transaction ID -
significance of the particular requirements are capitalized. These
words are:

o "MUST"

This word or the adjective "REQUIRED" means that the item is used to uniquely identify a set an
absolute requirement of DHCPv6
request/response messages between DHCPv6 Servers and Clients. The
Transaction ID is generated by this specification.

o "MUST NOT"

This phrase means the DHCPv6 Client requests.

Interface-Token: An Interface Token item is used to uniquely identify a
DHCPv6 Client network interface.

Lease: an absolute prohibition of this
specification.

o "SHOULD"

This is word or the address lifetime for a single address provided adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full impliciations should be understood and the case
carefully weighed before choosing a DHCPv6 Client.

Expired Lease: An Expired Lease is one where different course.

o "SHOULD NOT"

This phrase means that there may exist valid reasons in particular
circumstances when the Lease duration of an
address has ended listed behavior is acceptable or because it has been mandated by a DHCPv6 Server
to a DHCPv6 Client. even

Expires September December 1995 [Page 3]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

3. DHCPv6 Protocol Design Model

3.1 DHCPv6 Protocol Request/Response Model

DHCPv6 uses a message type to define whether

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.

Expires December 1995 [Page 4]

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

Expires December 1995 [Page 5]

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.

Expires December 1995 [Page 6]

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.

Expires December 1995 [Page 7]

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 orginated
from
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)

Expires December 1995 [Page 8]

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 Server or Client, 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 message code for configuration parameters. Some installations may
include multiple, overlapping DHCPv6 servers to define
the operation requested, 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 message response design goal of DHCPv6 to define either specify a server to server

Expires December 1995 [Page 9]

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 request 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 confirmation/rejection message type to define whether the packet orginated
from a response. DHCPv6 Server or Client.

The request/response model is message types are as follows:

01 - client-configuration-request
02 - client-confirm-response
03 - client-reject-response
04 - server-configuration-response

Request/Response Model States

1. Request (Client) (client)
2. Response with configuration data (Server). configuration-data or error found (server).
3. Confirmation Response with accept or reject (Client).
4. Confirmation Response for accept (Server). (client).

The time out period for a DHCPv6 Host client or server to wait for a response is
implementation defined.
MUST NOT exceed 3 minutes. When a DHCPv6 Host client or server times out waiting
for a response to a packet sent, the Host should not implementation MUST NOT commit
any state binding based on the content of configuration-data sent in the packet sent. packet. It
is implementation defined if the client or server packet is

Expires December 1995 [Page 10]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995

retransmitted.

A DHCPv6 packet will only contain one

3.4 Leased Address Model

An address returned to a client has a validation-lifetime and one name, depending
on
deprecation-lifetime. The lifetimes represent the message type, request, and response codes in lease for a packet.
Because IPv6 supports multiple addresses per interface the DHCPv6
Server may also inform the DHCPv6 Client that there are multiple
addresses available single
address 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
configuration option [IPv6-DHCP-OPTIONS]. A design objective of
DHCPv6 is to avoid fragmentation in IPv6, when possible. If the
DHCPv6 packet exceeds 576 octets then UDP must perform Path MTU
Discovery [PMTU]. client. The support of multiple names server MUST provide a validation-lifetime
and addresses can be SHOULD provide a configuration option in DHCPv6.

If the DHCPv6 Host cannot match up any of the specified parameters,
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

A DHCPv6 address returned deprecation-lifetime to a DHCPv6 Client has client in a Lease time. A
design objective of DHCPv6 is to support Dynamic Readdressing. To
accomplish this objective, addresses must be able server
response packet to be reclaimed by a network site. Hence, all addresses must be Leased clients request for an address.

The client may suggest a value for the lifetimes in DHCPv6. an address
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.

The DHCPv6 Client philosophy is that the client has the responsibility to
renew a Lease lease for an address that is about to expire expire, or request a
new address with or the same address before the lease actually expires.
If the client does not request a Lease
time.

In new lease for an address, the case where it is necessary server
MUST assume the client does not want a new lease for that address,
and the server MAY provide that address to Expire another client requesting
an address.

If the the client has a Lease because deprecation-lifetime for an address the
processing of the lease SHOULD be as follows:

When the deprecation-lifetime of a
mandate in an organizations site, address expires, the DHCPv6 Server may send clients
address becomes a Lease

Expires September 1995 [Page 4]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995

Expired message with deprecated-address. A deprecated address SHOULD
NOT be used as a grace period source address in new communications. However, a
deprecated-address SHOULD continue to be used as a source address
if it is in use in existing communications. Implementors of
DHCPv6 Client. This will be
an asynchronous operation by SHOULD coordinate the DHCPv6 Server to use of the DHCPv6 Client, validation-lifetime and the only case where
deprecation-lifetime for layers below the DHCPv6 request/response model application layer
with their implementation of IPv6 Stateless Address Configuration
[IPv6-ADDRCONF].

An address is not 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 the protocol.

When outgoing
communications, and MUST NOT be recognized as a DHCPv6 Clients 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 network interface Lease expires,
it may attempt client if the
deprecation-lifetime is zero when provided to complete all oustanding network connections using
that address, but must not use that 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 for new network
connections.

3.3 DHCPv6 in outgoing communications, and MUST NOT be recognized as
a valid destination address in incoming communications.

Expires December 1995 [Page 11]

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
DNS Host Names with addresses for DHCPv6 Clients. clients. Autoregistration is
supported by fields the presence of the name field in DHCPv6, which the DHCPv6 Client
client may provide to the DHCPv6 Server server in a request. In addition a DHCPv6 Server server
may provide a DNS Host Name with an IPv6 address to a DHCPv6 Client client in a
response.

If the name-length field is zero, there is no name field contained in
the packet.

DHCPv6 only specifies the parameters and action to be taken, name-field, and not the actual protocol or
primitives to interact with DNS. The functions that the DHCPv6 Server server uses
to interact with the DNS to provide autoregistration is defined in
Dynamic Updates to DNS [IPv6-
DYN-UPD].

This is not [DYN-UPD]. DHCPv6 servers SHOULD support
Dynamic Updates to DNS.

If the client provides a Host Name (HN) or a Fully Qualified Domain
Name (FQDN) but only [RFC 1034&1035]:

The server SHOULD perform a DNS query for the local-
part label and then only HN or FQDN IPv6 DNS
AAAA resource record [IPv6-DNS]:

If the Host Name [RFC-1034&1035]. It name is
assumed found and the DHCPv6 Server implementation knows or can determine what address does not match the clients
address for the domain name part is provided by the client, the server SHOULD add
this address to the DNS name record (multiple addresses are
supported for any IPv6 subnet prefix names at this time in DNS and the client may want to
use the same name for which it is
providing multiple addresses on an address. interface).

If a DHCPv6 Client wants the name is not found the client supplied name SHOULD be added
to know its the DNS.

In either condition above the server MUST add the associated DNS
inverse address mapping as an IP6.INT domain PTR record [IPv6-DNS]
for this clients address and name.

If the server returns a name then after updating the DNS it will have MUST return
a FQDN to the client.

If the client does not request this as specified a HN or FQDN from a server, the server
MAY provide, in its response with the DHCPv6
Options Specification [IPv6-DHCP-OPTIONS].

3.4 DHCPv6 Client/Server Model

DHCPv6 supports a Transaction ID address to uniquely identify a set of
request/response messages between 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.

When a clients address invalidation-lifetime expires on the server,
the server SHOULD delete the clients IPv6 AAAA record and IP6.INT
domain PTR record from the DNS.

Expires December 1995 [Page 12]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995

3.6 Defining Optional Configuration-Data

Optional configuration-data MUST be specified for DHCPv6 Clients as follows
and Servers.

DHCPv6 supports an Interface Token to uniquely identify a network
interface aligned on a DHCPv6 Client.

DHCPv6 can support an extensible set integer multiple of 8 octets:

option-type: 1 Octet

This field permits 254 options as defined by a
Configuration Type. These options are specified in a DHCPv6 Options
specification [IPv6-DHCP-OPTIONS].

The for DHCPv6 Options provide a Configuration Type which defines the
option requested and then returned. A Next Type field is provided
which can be used by an application to know if there is more than one
option. If will represent the Next Type field is NULL then this is
tag for the last option
present. option. The Length values of 0 and 1 are used for pad
options discussed below.

option-length: 2 Octets

This field provides specifies the length of the data present
for that option. The configuration-data not
including the the option-type and and option-length fields.

option-data: Variable Configuration Data number of Octets

The option-data is the data to
provide configuration-data that option.

DHCPv6 immediately follows
the option-length field.

If the server does not specify whether support an option-type requested it MUST
return the DHCPv6 Server Configuration Data
provided option-type and the option-length set to DHCPv6 Clients is synchronous across zero in the sites network
information database (e.g. DNS), whether
response to the DHCPv6 Server

Expires September 1995 [Page 5]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995

Configuration Data is duplicated across DHCPv6 Servers, or how client.

A server implementation MUST start any options after the
DHCPv6 Configuration Data is pre-configured on first option
returned to a DHCPv6 Server.

DHCPv6 does not specify conditions or results when multiple DHCPv6
Servers are located client on an IPv6 subnet. The DHCPv6 Client may respond
to DHCPv6 Servers 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 want to communicate with by sending a
REJECT_PACKET confirmation response to a DHCPv6 Server.

DHCPv6 does not specify a define any options. DHCPv6 Server-to-Server protocol. options are
defined in XXXXXXXXX. It is permissible for options to also create
new message-types and message-codes as required.

Expires September December 1995 [Page 6] 13]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

4. DHCPv6 Protocol Format

DHCPv6 Datagram and Data Packet Formats

4.1 Datagram

DHCPv6 Datagram

In
| option-type | option-lgth | option-data (variable octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2 Data Formats

All fields in the field definitions below bit position 0 is datagram MUST be initialized to binary zeroes
by both the high-order bit client and server messages unless otherwise noted
in
the sequence Section 5. Client and Server processing of Octets for each field.

Msg Type messages.

msg-type : 1 Octet
The field defines the operation to be performed by the packet.

Bit 0 = ON: Server Message Operation
Bit integer value (message-type)

Value Description

1 = ON: - Client Message Operation
Bit 2-7 RESERVED

Msg Request : 3 Octets

Bit 0 = ON: ADDRESS_REQUEST
Bit 1 = ON: NAME_REQUEST
Bit request for configuration data.
2 = ON: CONFIG_REQUEST
Bit - Server response with configuration data.
3 = ON: ADDRESS_SUPPLIED
Bit - Client confirmation of server response.
4 = ON: LEASE_EXPIRED
Bit 5-24 RESERVED - Client rejection of server response.

Expires September December 1995 [Page 7] 14]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

Msg Response

msg-code : 3 Octets
Bit 0 = ON: ADDRESS_RETURNED
Bit 1 = ON: ADDRESS_ACCEPTED
Bit Octet integer value (message-code)

Value Description

1 - Server Response - Client address-count is in error.
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 - Server Response - Dynamic Updates to DNS not supported.

name-lgth : 1 Octet
Number of IPv6 addresses available to the DHCPv6 Client, that can be
provided by the DHCPv6 Server. Integer Number.

Transaction ID integer value (name-length)

addr-count : 1 Octet integer value (address-count)

transaction-ID : 4 Octets
Identifies request/response messages and is a 32bit random
generated number by the DHCPv6 Client. Integer Number.

Lease Time integer value

interface-token : 4 Octets
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 integer value

client-address : 8 16 Octets
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 address

server-address : 16 Octets
DHCPv6 Client IPv6 Address.

Host Name address

gateway-address : 64 16 Octets
DHCPv6 Host Name. This is not the Fully Qualified Domain Name
(FQDN).

Server IPv6 Address address

client-link-address : 16 Octets
DHCPv6 Server IPv6 Address.

Configuration Type address

validation-lifetime : 4 Octets integer value

deprecation-lifetime : 4 Octets integer value

host-name : 0-255 Octets character(s) value(s)

option-type : 1 Octet
This field defines the Configuration Data option in the packet.
The configuation types are specified in DHCPv6 Options
[IPv6-DHCP-OPTIONS].

Configuration Next Type integer value

option-length : 1 Octet
This field defines the Configuration Data Type that follows this
Configuration Data if multiple configuration requests are present.
A NULL integer value means that this is the only or last Configuration Data
Type provided.

Configuration Data Length

option-data : 2 Variable Octets
This field is the Length of the Configuration Data. variant value(s)

Expires September December 1995 [Page 8] 15]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

Variable Configuration Data : 452 Octets
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
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

5.1 DHCPv6 Client Transmission

The DHCPv6 Client will set Client Msg Type to ON to transmit to
DHCPv6 Servers.

UDP DHCPv6 Server Port (TBD) must 546 MUST be used to build by the sending packet in an implementation. A DHCPv6 Client may provide
multiple requests in a request packet and multiple responses in a
response packet, client to a DHCPv6 Server in one packet. send UDP
datagrams to the server.

If the DHCPv6 Client client knows its IPv6 address it will MUST be put in the source address
field of the IPv6 Header. Otherwise the DHCPv6
Clients clients link-local address [IPv6-ADDR] is
MUST be used as the source address field in the IPv6 Header. Header [IPv6-
ADDRCONF].

If the DHCPv6 Client client knows the address of a DHCPv6 Server the server on its link it will MUST put
that address in the destination address field of the IPv6 Header.
Otherwise
a well known IPv6 the client MUST put the DHCP Server/Relay-Agent well-known
multicast address FF02:0:0:0:0:0:1:0 using intra-link link-local scope [IPv6-
ADDR] is used as the destination address field in the IPv6 Header
[This multicast address will have IPv6 Header.

The client MUST set msg-type to 1 to transmit a request to the
server.

The client MUST set msg type to be supplied by IANA for DHCPv6].

5.2 DHCPv6 Server Transmission 3 to confirm the acceptance of packet
from a server response.

The DHCPv6 Server will client MUST set Server Msg Type ON msg type to transmit 4 to DHCPv6
Clients. reject a packet from a server
response.

The client MUST use UDP DHCPv6 Client Port (TBD) must be used to build 546 as the
sending packet UDP port to
accept server responses in an implementation. A DHCPv6

5.2 Server may provide
multiple responses to a Transmission

UDP DHCPv6 Client in one packet.

The DHCPv6 Server will Port 546 MUST be used by the server to send UDP
datagrams to the client.

A server, on the same link as the client, MUST use the source address of
in the IPv6 Header from the DHCPv6 Client client as the destination address in the DHCPv6 Server
IPv6 Header address.
servers response packet. Servers not on the same link are discussed
in Section 6 Relay-Agent Processing.

The server MUST set msg type to 2 to transmit a response to a client.

The server MUST use UDP DHCPv6 Server IPv6 Header source addresses
will be Port 547 as the UDP port to
accept client requests in an implementation.

The server 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, that do not know
the IPv6 address of a server on the DHCPv6 Server responding. clients link.

Expires December 1995 [Page 16]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995

5.3 DHCPv6 Client/Server Bindings

Client Requests

Msg Request field:

If ADDRESS_REQUEST is set, then and server bindings MUST be maintained at least as a request 4-tuple
consisting of the clients interface-token, address, validation-
lifetime, and deprecation-lifetime in an implementaiton. It is being made
critical for an IPv6
address and Lease. If the Lease 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 does not equal zero then
the
DHCPv6 Client is supplying number of addresses that it has for a Lease time to particular interface-token
in the clients bindings.

When the server receives the client request, it MUST verify that the
addr-count field provided by the client matches the number of
addresses the server has for that clients binding, for the
interface-token provided by the DHCPv6 Server. The DHCPv6
Client may also set ADDRESS_SUPPLIED and provide an IPv6 address to client. If the
DHCPv6 Server server has a
different addr-count than the client for verification.

Expires September 1995 [Page 9]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995

A DHCPv6 Client must a particular interface
token, the server MUST send an ADDRESS_REQUEST a response to the DHCPv6 Server client setting msg-code
to renew its Lease before it expires. The DHCPv6 Client may request
that 1 informing the same address be used again by providing an IPv6 address and
having ADDRESS_SUPPLIED set client addr-count at the server is not in synch
with the request. If client.

Once the DHCPv6 Clients
Lease client receives a response with a msg-code set to 1 it MUST
set addr-count to zero on an address expires, then the DHCPv6 Server will expire subsequent requests to the
Lease server, for that address.

If NAME_REQUEST is set, then
interface-token.

When a server receives a request is being made for from a DNS Host Name.
supplied by client and the DHCPv6 Client.

If CONFIG_REQUEST addr-count is set, then
set to zero, but the client has a request is being made binding for an IPv6
Configuration Data return from that interface-token,
the DHCPv6 Server.

Msg Response field: must be NULL.

Addrs Avail field: must be NULL.

Transaction ID field: must contain a random number generated Integer
determined by server MUST reissue the DHCPv6 configuration-data in those bindings to
the client.

5.4 Client Requests

The client sets the following fields for this request packet.

Lease Time field: may contain a Lease time requested by request for
configuration-data:

msg-type: Set to 1.

name-lgth: Set to the DHCPv6
Client or must be NULL.

Interface Token field: must contain a random number generated Integer length of the host-name if provided.

addr-count: Set to identify the number of addresses associated with a DHCPv6 Clients network
interface.

IPv6 Address field: must contain an IPv6 Address if ADDRESS_SUPPLIED
or NAME_REQUEST is set, otherwise NULL.

Host Name field: must contain a Host Name if NAME_REQUEST is set,
otherwise NULL.

Server IPv6 Address field: must be NULL.

Configuration Type field: must contain a valid Configuration Type as
defined in the DHCPv6 Options specification [IPv6-DHCP-OPTIONS], if
CONFIG_REQUEST is set, otherwise client has for the Configuration fields are not
present
interface-token specified in this request.

transaction-ID: Set to a unqiue integer value.

interface-token: Set to a unqiue opaque identifier.

client-address: Set ONLY if the packet.

Configuration Next Type field: If CONFIG_REQUEST set, and there client is
more than one, then requesting a host name
for a particular address, else not set.

validation-lifetime: Set to the value of the next configuration type should
be put into this field, otherwise NULL.

Configuration Data Length field: NULL.

Variable Configuration Data field: Not present in client would like the packet.

5.4 DHCPv6 Client Responses

The Transaction ID from
server to use, else not set.

deprecation-lifetime: Set to the DHCPv6 Server response must match one of value the DHCPv6 Clients Transaction IDs from a previous request.

Msg Request field: must be NULL.

Msg Response field: client would like the
server to use, else not set.

host-name: Set only if name-lgth is greater than zero otherwise

Expires September December 1995 [Page 10] 17]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

If ADDRESS_ACCEPTED

this field is set, not present.

option-type: Set to a future option request for configuration-
data, otherwise the DHCPv6 Client field is informing the DHCPv6 not present. Multiple option-types
may be set adjacent to each other.

5.5 Server that it has received Response

The server sets the address returned.

If CONFIG_ACCEPTED is set, following fields for a response to a client for
configuration-data:

msg-type: Set to 2.

msg-code: Set to 1 if addr-count not equal to servers bindings for
the DHCPv6 Client is informing clients specified interface-token. Set to 2 if the DHCPv6
Server that it has received server
cannot support Dynamic Updates to DNS because the Configuration Data returned.

If NAME_ACCEPT is set, client requested
a host-name for an address provided, or from the DHCPv6 Client is informing servers set of
addresses.

If the DHCPv6
Server server determines that addr-count is not equal to its
bindings it received the NAME_RETURNED returned, when the stops all other DHCPv6
Client supplied a Host Name with NAME_REQUEST set.

If REJECT_PACKET is set, processing, hence, the DHCPv6 Client is rejecting a response
from a DHCPv6 Server.

Addrs Avail field: must
server would not be NULL.

Transaction ID field: must contain a random number generated Integer
matching in the DHCPv6 Server request or response.

Lease Time field: must be NULL.

Interface Token field: must contain a random number generated Integer situation of setting msg-code to identify addresses associated with a DHCPv6 Clients network
interface.

IPv6 Address field: must be NULL.

Host Name field: must be NULL.

Server IPv6 Address field: must be NULL.

Configuration Data Fields not present
both 1 and 2. The server sets msg-code to 1 and MUST put all
other values supplied by the clients request in the packet.

5.5 DHCPv6 Server Responses

The Transaction ID from a DHCPv6 Servers response must match one
packet except the msg-type and msg-code fields.

Processing of msg-code set to 1 for the DHCPv6 Clients Transaction IDs from a previous request.

Msg Request field: must be NULL.

Msg Response field:

If ADDRESS_RETURNED client and server is set,
done as specified in 5.3 Client/Server Bindings.

name-lgth: Set to the DHCPv6 Server is providing length of the DHCPv6
Client with an IPv6 Address. host-name if present.

addr-count: Set to the same value specified by the client.

transaction-ID: Set to the same value specified by the client.

interface-token: Set to the same value specified by the client.

client-address: If ADDRESS_ACCEPTED the client-address from the request packet is set,
zero the DHCPv6 Server has accepted server sets the address
supplied by client-address to the DHCPv6 Client. next available
address for this interface-token. If ADDRESS_REJECTED there is set, a client-address in
the DHCPv6 Server request packet the client is not accepting requesting a host-name for this
address, and the server MUST return the address provided by the DHCPv6 Client.

Only one of
client if the above settings must be present in a response server supports Dynmic Updates to DNS, and has
updated the DNS with a DHCPv6
Client request. host-name for that address.

server-address: The IPv6 server MUST set this field to its address provided in
all response packets.

validation-lifetime: The server sets this address to the
validation-lifetime of the servers configuration database. It is
implementation defined if the server will either be use the one
presented validiation-
lifetime if specified by the DHCPv6 Client or an a client request packet.

deprecation-lifetime: The server sets this address provided by to the DHCPv6
Server when ADDRESS_RETURNED is set.

If NAME_RETURNED is set,
deprecation-lifetime of the DHCPv6 Server servers configuration database. It is providing a Host Name with
implementation defined if the address returned to server will use the DHCPv6 Client either in response to a DHCPv6 deprecation-

Expires September December 1995 [Page 11] 18]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

Client NAME_REQUEST

lifetime if specified by a client request packet.

host-name: The server returns a hostname or because it is implementation defined msg-code set to provide
Host Names with ADDRESS_RETURNED set.

If NAME_REJECTED is set, 2, if
the DHCPv6 Server name-lgth field is informing the DHCPv6
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 greater than zero. Processing of host-name
is set, specified in Section 3.5 DNS Host Name Autoregistration Model.

option-type: The server returns the DHCPv6 Server is providing same option-types specified by
the
Configuration Data requested.

If CONFIG_REJECTED is set, client requests.

option-lgth: The server returns the DHCPv6 Server is informing length of the DHCPv6
Client that configuration-
data or zeroes if the Configuration Data requested option is not supported.

If LEASE_ACCEPTED is set,

option-data: The server returns the DHCPv6 Server is informing configuration-data requested
by the DHCPv6 client.

5.6 Client that the Lease presented has been accepted. Confirmations/Rejections

The Lease Time field
will contain client sets the Lease requested by following fields for a confirmation or rejection
after receiving configuration-data from the DHCPv6 Client.

If LEASE_REJECTED server. configuration-
data:

msg-type: Set to 3 if the client is set, confirming a servers response.
Set to 4 if the DHCPv6 Server client is rejecting a servers response.

When the Lease Time
provided by server receives a rejection msg-type 4 from a client
the DHCPv6 Client server MUST assume the client is using another server. The
server then MUST remove any bindings for that client it may
have created, and will return a Lease time MUST delete any DNS HN or FQDN records it may
have added on behalf of the client.

transaction-ID: Same value as specified
by in the DHCPv6 Server.

If SERVER_ADDRESS is set, servers response.

interface-token: Same value as specified in the DHCPv6 Server is returning its address servers response.

client-address: Same value as specified in the servers response.

6. Relay-Agent Processing

The relay-agent MUST use UDP DHCPv6 Server will do this when Port 547 as the destination
address UDP port
to accept client responses in the IPv6 Header is an intra-link Multicast address, or has
a network prefix subnet value implementation.

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 which the client requests.

When a DHCPv6 Server is
not Relay-Agent hears a request from a member. DHCPv6 Client it
MUST:

If CONFIRM_PACKET is set, the DHCPv6 Server gateway-address is informing NOT zero then the DHCPv6
Client it has received a response to relay-agent MUST:

Put the DHCPv6 Server response to relay-agents IPv6 address in the
DHCPv6 Clients initial request. This will be gateway-address field
of the only msg response
code set by clients request packet.

Put the DHCPv6 Server in this response.

Addrs Avail field: If ADDRESS_RETURNED is set, the DHCPv6 Server is
informing source address from the DHCPv6 Client that it has an integer number IPv6 Header of
addresses available the clients

Expires December 1995 [Page 19]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995

request packet in the client-link-address.

All relay-agents MUST:

Put their relay-agent address as the source address for the DHCPv6 Client less
IPv6 Header.

Put the next relay-agent or known server address being
provided. When as the DHCPv6 Client responds
destination address in the IPv6 Header.

Forward the packet to this response with
ADDRESS_ACCEPTED the DHCPv6 Server must decrement to the number of
addresses available for next hop relay-agent or known
server.

When the DHCPv6 Client. If ADDRESS_ACCEPTED is
set, remote server receives the DHCPv6 Server is informing client request from the DHCPv6 Client that relay-
agent it has will know its a
number of addresses available that can be used by the DHCPv6 Client.
Otherwise remote client request (not on the Addrs Avail field servers
link), because there is NULL.

Transaction ID field: must contain a random number generated Integer
determined by gateway-address in the DHCPv6 Clients request packet.

Lease Time field: must contain a Lease Time with any returned
addresses that were requested, otherwise NULL.

Interface Token field: must contain a random number generated Integer request. So servers
MUST test the gateway-address is not zero, to identify addresses associated with a DHCPv6 Clients network
interface.

IPv6 Address field: must contain an IPv6 Address.

Host Name field: must contain a Host Name determine if NAME_RETURNED the
clients request is set
otherwise NULL. from a remote link.

The server responds as specified in 5.5 Server Response, but uses the
gateway-address as the destination address in the IPv6 Address field: must contain an IPv6 Header.

When the relay-agent receives the remote servers response, it MUST
forward the packet to the client, by using the client-link-address as
the source address if for the IPv6 Header.

Expires September December 1995 [Page 12] 20]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

SERVER_ADDRESS is set, otherwise NULL.

Configuration Type field: must contain

Draft ***Open Issues***

1. The present model uses UDP with a valid Configuration Type as
defined in the DHCPv6 Options [IPv6-DHCP-OPTIONS] if CONFIG_RETURN client request, server
response, and then client confirmation or
CONFIG_REJECTED is set, otherwise the Configuration fields are not
present in the packet.

Configuration Next Type field: If CONFIG_RETURNED rejection. The server will
set state or CONFIG_REJECTED
is set, and if there remove state based on this model. There is more than one Congfiguration Type present, always the value
possibility of the next configuration type should be put into this
field, otherwise NULL.

Configuration Data Length field: If CONFIG_RETURNED is set, then this classic transactional error when the client-to-
server response is not received by the server, or the length 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 Configuration Data present. If CONFIG_REJECTED
is set, then
transaction. This would have great benefits such as:

1. Guranteed virtual link, hence if the DHCPv6 Server will set length transaction completes
the server and client know immediately upon return to zero.

Variable Configuration Data field: Contains Configuration Data only
if CONFIG_RETURNED is set, otherwise there the
application.

2. PATH MTU Discovery for TCP is no Configuration Data
present inherent in an implementation
and the packet.

5.6 DHCPv6 Server Lease Expiration

The DHCPv6 may send an asynchronous LEASE_EXPIRED message with a
grace period if an organizations network site needs to reclaim
addresses when their Lease has application does not expired.

Msg Request field:

LEASE_EXPIRED is set.

Msg Response field: must be NULL.

Addrs Avail field: must be NULL.

Transaction ID field: NULL.

Lease Time field: must contain a grace period have to adjust for IPv6
fragmentation model.

We can also use UDP to locate servers and TCP for the DHCPv6 Client transaction.

2. Dynamic Updates to renew a lease DNS need careful review for an address.

Interface Token field: must contain a random number generated Integer clarity and what
is required for just host name processing in DHCPv6.

3. We need to determine the DHCPv6 Client IPv6 address.

IPv6 Address field: must contain an integration required with IPv6 Stateless
Address Configuration when both stateless and statefull is being used for an
Interface Token
by a DHCPv6 Client.

Host Name field: must be NULL.

IPv6 Server Address field: must client host.

4. In the Design Goals section should the MUSTs, SHOULDs, etc be NULL.

Configuration fields:
capitalized and REQUIRED? Its not present in DHCPv4?

5. Charlie Perkins will be doing our option spec for DHCPv6. We need
to make sure it synchs up with this spec.

Expires December 1995 [Page 21]

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 packet.

6. DHCPv6 Relay-Agent Processing

When a DHCPv6 Relay-Agent hears 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 request from
server confirm to a DHCPv6 Client it
should forward that request 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 Server as a Options
Specification.

Added gateway-address and client-link-address for relay-agent
processing.

Removed excessive use of the acroynym DHCPv6 Client Msg
Type. for section titles
and when referencing clients and servers.

Added Draft ***Open Issues*** Section for review by the DHC
Working Group.

Added Change History.

Expires September December 1995 [Page 13] 22]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March draft-ietf-dhc-dhcpv6-02.txt July 1995

Acknowledgements

The DHCPv6 Relay-Agent upon receiving a response from DHC Working Group for their time and input into the DHCPv6
Server should forward that response to
specification. A special thanks for the DHCPv6 Client.

When 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 DHCPv6 Relay-Agent forwards
phone with the request author to get the DHCPv6 Server
it puts work done.

Sue Thomson and Yakov Rehkter were co-authors on the DHCPv6 Relay-Agent's IPv6 address in first
specification, and with the source field author have since March 1994 kept a
consistent view and belief that autoregistration MUST be part of the IPv6 Header.

Expires September 1995 [Page 14]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995

Acknowledgements

Brian Carpenter, Alex Conta, Jack McCann, Ralph Droms for providing
input
Next Generation Internet Protocol version 6 and integrated into
autoconfiguration.

The author would also like to thank Steve Deering and Bob Hinden, who
have consistently taken the time to discuss the evolution more complex parts of DHCPv6.

References

[IPv6-ADDR]
R. Hinden, Editor, "IP Version 6 Addressing Architecture"
Internet Draft, March 1995
<draft-ietf-ipngwg-ipv6-addr-arch-00.txt>

Y. Rekhter, "An
the IPv6 Global Unicast Address Format"
Internet Draft, March 1995
<draft-ietf-ipngwg-address-format-01.txt> specifications.

The author MUST also thank his employer for the opportunity to work
on DHCPv6 and IPv6 in general.

References

[IPv6-SPEC]
S. Deering and R. Hinden, Editors, "Internet Protocol Version 6
[IPv6] Specification" Internet Draft, March June 1995
<draft-ietf-ipngwg-ipv6-spec-01.txt>

[IPv6-ICMP]
A. Conta,
<draft-ietf-ipngwg-ipv6-spec-02.txt>

[IPv6-ADDR]
R. Hinden, S. Deering "ICMPv6 for the Internet Protocol Deering, Editors, "IP Version 6 [IPv6]" Addressing
Architecture"
Internet Draft, March June 1995
<draft-ietf-ipngwg-icmp-02.txt>

[PMTU]
J. Mogul, S. Deering "Path MTU Discovery"
RFC 1191, 11/16/90
<draft-ietf-ipngwg-ipv6-addr-arch-03.txt>

[IPv6-ADDRCONF]
S. Thomson, "IPv6 Stateless Address Configuration"
Internet Draft, March June 1995 <draft-ietf-addrconf-ipv6-auto-01.txt> <draft-ietf-addrconf-ipv6-auto-02.txt>

[IPv6-ND]
T. Narten, E. Nordmark, and W. A. Simpson Simpson, "IPv6 Neighbor Discovery - Processing"
Discovery"
Internet Draft, November 1994
<draft-simpson-ipv6-discov-process-01.txt> June 1995
<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]
P. Mockapetris, "Domain Names - implementation and specification"
STD-13, 11/01/87

Expires December 1995 [Page 23]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 1995

[RFC-1035]
P. Mockapetris, "Domain Names - concepts and facilities"
STD-13, 11/01/87

[DYN-DNS-UPD]

[DYN-UPD]
S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain
Name System (DNS)" Internet Draft, March 1995
<draft-ietf-dnsind-dynDNS-01.txt>

Expires September 1995 [Page 15]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995

[IPv6-DHCP-OPTIONS]
<TBD>

[RFC-768]
J. Postel, "User Datagram Protocol"
STD-6, 08/28/80.

[DHCP-v4]
R. Droms, "Dynamic Host Configuration Protocol"
RFC 1541 Proposed Standard, October 1993

Authors' Addresses

Jim Bound
Digital Equipment Corporation
110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062
Phone: (603) 881-0400
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

Expires September December 1995 [Page 16] 24]

----