WDIFF

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

INTERNET-DRAFT J. Bound
DHC Working Group Digital Equipment Corp
Obsoletes: draft-ietf-dhc-dhcpv6-01.txt July 95 draft-ietf-dhc-dhcpv6-02.txt November 1995

Dynamic Host Configuration Protocol for IPv6

draft-ietf-dhc-dhcpv6-02.txt (DHCPv6)

draft-ietf-dhc-dhcpv6-03.txt

Status of this Memo

This document is a submission to the DHC Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the dhcp-v6@bucknell.edu mailing list.

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

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts 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 Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.

Abstract

DHCPv6

This document is an Internet application protocol protocol, for IP version 6
(IPv6), that uses specifies a Client/Server client/server model to communicate for communications
between hosts. DHCPv6 executes over the UDP
[RFC-768] transport protocol, hosts to dynamically configure parameters for a network, and
autoconfigure addresses within a stateful model. This document
supports the Internet Protocol Version 6
(IPv6) [IPv6-SPEC]. DHCPv6 is an IPv6 specification model for a statefull
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), Autoconfiguration,
where there are clear integration points between stateless and specifies the
format to add future Configuration Parameter options to the protocol
stateful address autoconfiguration for extensibility.

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

Expires December 1995 May 1996 [Page 1]

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

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Table of Contents:

1. Introduction................................................3
1.1 Requirements................................................3 Introduction.................................................3
1.1. Requirements...............................................3
2. Terminology and Definitions.................................5
2.1 Definitions..................................4
2.1. IPv6 Terminology............................................5
2.2 Terminology...........................................4
2.2. DHCPv6 Terminology..........................................6 Terminology.........................................6
3. Protocol Design Model.......................................8
3.1 Related Work in IPv6........................................8
3.2 Model........................................9
3.1. Design Goals................................................9
3.3 Goals...............................................9
3.2. Request/Response Model.....................................10
3.4 Model....................................10
3.3. Leased Address Model.......................................11
3.5 Model......................................11
3.3.1. Address Lifetimes.......................................11
3.3.2. Duplicate Address Detection.............................12
3.3.3. Releasing Infinite Lifetime Addresses...................13
3.4. DNS Host Name Autoregistration Model.......................12
3.6 Defining Optional Configuration-Data.......................13 Model......................13
4. Datagram Request/Response Processing.................................13
4.1. Processing when Server Address is not Known...............14
4.2. Processing when Server Address is Known...................16
4.3. Retransmission and Data Formats..................................14
4.1 Datagram...................................................14
4.2 Data Formats...............................................14 Configuation Variables.................16
5. Datagram and Field Definitions..............................18
5.1. Datagram..................................................18
5.2. Field Definitions.........................................19
6. Client/Server Message Formats...............................21
6.1. Client/Server Processing...................................16
5.1 UDP Ports, Multicast Group, and Addresses...21
6.2. Client Transmission........................................16
5.2 DISCOVER and CONF-REQUEST Messages.................21
6.3. Server Transmission........................................16
5.3 Client/Server Bindings.....................................17
5.4 CONF-RESPONSE Message..............................23
6.4. Client Requests............................................17
5.5 ACCEPT Message.....................................24
6.5. Server Response............................................18
5.6 SERVER-ACK Message.................................25
6.6. Client Confirmations/Rejections............................19
6. RELEASE Message....................................27
7. Relay-Agent Processing.....................................19
Draft ***Open Issues***........................................21 Processing......................................28
8. Security Considerations.....................................29
Appendix A - Related Work in IPv6..............................29
Change History.................................................22
Acknowledgements...............................................23
References.....................................................23 History.................................................31
Acknowledgements...............................................33
References.....................................................33
Authors' Addresses.............................................24 Address...............................................34

Expires December 1995 May 1996 [Page 2]

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

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

1. Introduction

DHCPv6 is an Internet application protocol protocol, for IP version 6 (IPv6),
that uses specifies a Client/Server client/server model to communicate for communications between hosts. DHCPv6 executes over the UDP
[RFC-768] transport protocol, hosts
to dynamically configure parameters for a network, and the Internet Protocol Version 6
(IPv6) [IPv6-SPEC]. autoconfigure
addresses within a stateful model. DHCPv6 is an IPv6 specification supports the model for a statefull
implementation of address autoconfiguration as referenced in
IPv6 Stateless Address Configuration [IPv6-ADDRCONF]. Autoconfiguration [IPv6-ADDRCONF], where there
are clear integration points between stateless and stateful address
autoconfiguration for IPv6.

DHCPv6 supports
mechanisms to autoconfigure host IPv6 addresseses, autoregister host
names dynamically in uses a set of request/response messages to support a
transaction processing model where a commit to the Domain Name System (DNS), data can be
verified by both the client and specifies server. This affords DHCPv6 the
ability in the
format to add future Configuration Parameter options to support dynamic updates to data located
within a sites network. In addition to the protocol
for extensibility.

The IPv6 new version capability of the Internet Protocol, verifying
commits to transactions a recovery mechanism is specified, should
commits need to be rolled back during the course of a DHCPv6
transaction being developed
with 128bit addresses. processed.

DHCPv6 supports optional configuration parameters and processing for
hosts through its companion document Options for the Dynamic Host
Configuration Protocol for IPv6 [DHCPv6-OPT].

The IPv6 addressing architecture Addressing Architecture [IPv6-ADDR] and stateless address configuration [IPv6-ADDRCONF] IPv6 Stateless
Address Autoconfiguration specifications provide new functionality
not present in the Internet Protocol IP version 4 (IPv4), which provide (IPv4). This new IPv6 functionality
provides inherent benefits to autoconfigure IPv6 addresses for host nodes.
In addition the IETF DNS Working Group has work in progress defined a method to
support Dynamic Updates to DNS [DYN-
UPD], [DYN-UPD], which can be used by a node
to add, delete, and change host node names dynamically.

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 used several of the architectural architecture principles in DHCP for IPv4 (DHCPv4) [DHCP-v4]. It from DHCPv4
[DHCP-v4], but it is not within beyond the scope of this document to compare and contrast DHCPv4
and compare DHCPv6 with DHCPv6.

1.1 Requirements

Throughout DHCPv4.

Section 2 provides definitions for terminology used throughout this document,
document. Section 3 provides a review of the words protocol design model
parts that are used to define inherent in the
significance specification. Section 4 provides the
request/response model and interaction between the set of messages
and the particular requirements are capitalized. These
words are:

o "MUST"

This word or semantics for those messages. Section 5 provides the adjective "REQUIRED" means
datagram packet format and field definitions for that datagram.
Section 6 provides the item is an
absolute requirement of this specification.

o "MUST NOT"

This phrase means message formats and field contents for
processing the client and server messages. Section 7 provides the
specification of how relay-agents and servers interact with clients,
when the server is not on the same link as the client. Section 8
provides the security specifications that can be used to support
security in DHCPv6. Appendix A provides a summary of related work in
IPv6 that will help put DHCPv6 in the context of IPv6 for the reader,
and is not part of this specification, but here for information
purposes.

1.1. Requirements

Throughout this document, the words that are used to define the
significance of the particular requirements are capitalized. These
words are:

Expires May 1996 [Page 3]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

o "MUST"

This word or the adjective "REQUIRED" means that the item is an
absolute requirement of this specification.

o "MUST NOT"

This phrase means the item is an absolute prohibition of this
specification.

o "SHOULD"

This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full impliciations implications should be understood and the case
carefully weighed before choosing a different course.

o "SHOULD NOT"

This phrase means that there may exist valid reasons in particular
circumstances when the listed behavior is acceptable or even

Expires December 1995 [Page 3]

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.

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 terminology from the IPv6
specification Protocol [IPv6-SPEC], IPv6
Addressing Architecture [IPv6-ADDR], Architecture, and IPv6 Statelss Stateless Address Configuration [IPv6-ADDRCONF] terminology Autoconfiguration
will be provided, and then the DHCPv6 terminology.

2.1

2.1. IPv6 Terminology

node:

IP - Internet Protocol Version 6 (IPv6). The terms
IPv4 and IPv6 are used only in contexts where
necessary to avoid ambiguity.

node - A device that implements IPv6.

router:

router - A node that forwards IPv6 packets not explicitly
addressed to itself.

host:

host - Any node that is not a router.

link:

upper-layer - A protocol layer immediately above IP. Examples are
transport protocols such as TCP and UDP, control
protocols such as ICMP, routing protocols such as
OSPF, and internet or lower-layer protocols being

Expires May 1996 [Page 4]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

"tunneled" over (e.g. encapsulated in) IP such as
IPX, Appletalk, or IP itself.

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 Ethernet
(simple or bridged); PPP links, X.25, Frame Relay,
or ATM networks; and internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself.

neighbors:

neighbors - Nodes attached to the same link.

interface:

interface - A nodes's node's attachment to the link.

address:

address - An IPv6 IP layer identifier for an interface or a set
of interfaces.

packet:

packet - An IPv6 IP header plus payload.

link MTU: The maximum transmission unit, i.e., maximum

communication
- Any packet size in
octets, exchange between nodes that can be conveyed requires
that the address of each node used in one piece over a link.

path MTU: The minimum link MTU the exchange
remain the same for the duration of all the links in a path between a
source node and packet
exchange. Examples are a destination node. TCP connection or UDP
request/response.

unicast address: 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: 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

link-layer identifier
- a single
link. On initialization of link-layer identifier for an interface, a host forms a interface. Examples
include IEEE 802 addresses for Ethernet links,
and E.164 addresses for ISDN links.

link-local address by concatenating
- An address having link-only scope that can be used
to reach neighboring nodes attached to the same link.
All interfaces have a well-known link-local prefix address.

preferred address
- An address assigned to a token
that an interface whose use by
upper layer protocols is unique per link. For example, in unrestricted. Preferred
addresses may be used as the case source or destination
address of a host attached packets sent from or to a link that uses IEEE 802 addresses, the token is an IEEE 802
address associated with the interface.

validation-lifetime: This

deprecated address
- An address assigned to an interface whose use is the
discouraged, but not forbidden. A deprecated
address lifetime for should no longer be used as a single source address provided
in new communications. but packets sent to a host. The validation-timer is in absolute time

Expires December 1995 May 1996 [Page 5]

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

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

and in seconds (e.g. 3 hours would have the value 10800).

deprecation-liftetime: This is the lifetime for a single

deprecated address the
host uses are delivered as expected.
A deprecated address may continue to begin be used as a
source address for the deprecation duration of an existing
communications.

valid address prior to
- A preferred or deprecated address. A valid address
may appear as the
validation-lifetime expiring, so that the host can determine if source or destination address of a
packet, and the internet routing system is expected to
be able to deliver packets sent to a valid address.

invalid address can receive
- An address that is not assigned to any interface. A
valid address becomes invalid when its valid
lifetime expires. Invalid addresses should not appear
as the source or destination of a new validation-lifetime. The deprecation- packet.

preferred lifetime
- The length of time that a valid address is in absolute preferred.
When the preferred lifetime expires, the address
becomes deprecated.

valid lifetime
- The length of time and the address remains in seconds (e.g. 3 hours would have the value 10800). valid
state. The deprecation-lifetime valid lifetime MUST be no greater than or
equal to the validation-lifetime.

deprecated-address: This preferred lifetime. When the valid
lifetime expires, the address becomes invalid.

interface token
- A link-dependent identifier for an interface that
is (at least) unique per link. Stateless Address
Autoconfiguration combines an interface token with
a single prefix to form an address. From an address that
autoconfiguration perspective, an interface token
is in the
deprecated state on a host because bit string of known length. The exact length
of an interface token and the deprecation-lifetime period
has expired.

invalid-address: This way it is created is
defined in a single address whose validation-lifetime
has expired.

2.2 separate link-specific document that
covers issues related to the transmission of IP
over a particular link type (e.g., [IPv6-ETHER]).
In many cases the token will be the same as the
link-layer address.

2.2. DHCPv6 Terminology

configuration-type: Configuration Type defines an optional

configuration parameters
- Is any parameter in the DHCPv6 protocol.

configuration-data: Configuration Data is information a host that can use be used by a node to
configure a host on a network, their network environment so that the host node can interoperate
with other hosts
communicate on a network. Configuration Data will vary in
length depending link or on the configuration type.

client: an internet.

client - A Client client is a host that initiates requests on a link
to obtain: addresses, DNS host name processing, dynamic updates to DNS, or configuration-data.

server:
other configuration parameters.

server - A Server server is a host node that responds to requests from
clients on a link to provide: addresses, DNS host name processing, dynamic
updates to DNS, or
configuration-data.

relay-agent: other configuration parameters.

Expires May 1996 [Page 6]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

relay-agent - A Relay-Agent relay-agent is a router node that listens on the a link for
clients
client requests, and then forwards the request packet to a
server on the network. The server will respond back
to the Relay-Agent, relay-agent, who will forward the reply response to
the client on the Relay-Agents relay-agents link.

message-type:

message-type - The Message-Type message-type defines the DHCPv6 protocol operation type for
this packet.

message-code:

message-flag - The Message-Code message-flag defines a an optional processing
notification for a message-
type DHCPv6. The message-flag can also
be used by the Options for DHCPv6 specification.

error-code - The error-code specifies errors from a client or
server.

name-length: The Name-Length defines error-code can also be used by the length of
Options for DHCPv6 specification.

total-addresses
- The total-addresses specifies the host name total number of
addresses being provided by a client or from a server for DNS Autoregistration of host
names.

interface-token: The Interface-Token to a client.
For each address there is specified by the client a preferred and valid
lifetime.

completed-transaction
- A completed-transaction is a unique opaque identifer for communications exchange
between a clients interface, client and must be
accessbile after a server, using the required set
of DHCPv6 request/response message-types, where the
final response message in the request/response set
has been received by the client reboots (e.g. IEEE 802 MAC address).

address-count: and by the server.

transaction-ID
- The address-count transaction-ID is an integer identifier specified
by the client with any
request sent to a server, and represents is used by the number client and server as
a transaction identifier to define the set of addresses
request/response messages between the client has received from a server and
server, for a specified interface-token.

Expires December 1995 [Page 6]

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

client-address: clients interface token.

client-link address
- The Client-Address is the field in the DHCPv6
protocol that contains the client-link address for specifies the clients interface-token.

server-address:
link-local address. The Server-Address client-link address
is the field in the DHCPv6
protocol that contains used by a relay-agent to respond to a client
on a link, after receiving a server response.

server address
- The server address specifies the address of for the
server responding to the
clients request.

gateway-address: a client.

gateway address
- The Gateway-Address is gateway address specifies the field in address of the DHCPv6
protocol that contains the relay-agents address, so
relay-agent for a server, that which 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 original relay-agent.

client 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 address specifies 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 address from a client who has multiple requests for the same interface-token.

host-name: The Host-Name is the name
server 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 used by a client.

binding - A binding in DHCPv6 is a an N-tuple that a client
and server MUST maintain in DHCPv6 for each completed transaction, a

Expires May 1996 [Page 7]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

completed-transaction, where N is the number of configuration-data identifiers
configuration parameters for a client. An
implementation MUST support at least a 4-tuple Binding 5-tuple
binding consisting of
the a clients interface-token, interface token,
client address, validation-lifetime, preferred lifetime and
deprecation-lifetime valid
lifetime for that address. An example of a completed
transaction in DHCPv6 is when the each 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, address, and is not prohibited by this
specification. the
transaction-ID.

Expires December 1995 May 1996 [Page 7]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 8]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 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 Any
conceptual models presented in IPv6 this specification that influenced the protocol design and the
design goals. The request/response protocol model is discussed and
the objective provide
implementation examples are not a requirement of this model in the design. The leased address
strategy and purpose is discussed. DHCPv6 protocol.

3.1. Design Goals

The objective of the
autoregistration following list gives general design goals for DNS Host Names is discussed DHCPv6.

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 the capabilities
that are possible in this specification. The client/server model is
discussed access
to prepare an implementor for the client/server processing
provided later in the specification. Then the local resources where desired.

Hosts should require no manual configuration. Each host should be
able to discover appropriate local configuration options
are defined parameters
without user intervention, and how they are used to build additional extensible
configuration-data incorporate those parameters into
its own configuration.

Networks should require no hand configuration 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], individual
hosts. Under normal circumstances, the IPv6 Addressing
Architecture [IPv6-ADDR], IPv6 Stateless Address Configuration
[IPv6-ADDRCONF], IPv6 Neighbor Discovery Processing [IPv6-ND], and
Dynamic Updates network manager should not
have to DNS [DYN-UPD]. These specifications afford enter any per-host configuration parameters.

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 should not require a server on each link. To allow for IPv4 is directly related to
DHCPv6.

The IPv6 Specification provides the base architecture
scale and design of
IPv6. economy, DHCPv6 must work across relay agents.

A key point for DHCPv6 implementors client must be prepared to receive multiple responses 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 request for the IPv6 header), 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 long much as there are no options prior
to the UDP datagram in possible be compatible with IPv6
Stateless Address Autoconfiguration.

DHCPv6 must support the packet. But, requirements of automated renumbering of
IPv6 does not addresses.

DHCPv6 servers should be able to support
fragmentation at routers and fragmentation must take place end-to-end
between hosts. If Dynamic Updates to DNS
[DYN-UPD].

It is NOT a design goal of DHCPv6 implementation needs to send specify a packet
greater than 536 octets it can either fragment the UDP datagram in
UDP or use Path MTU Discovery [IPv6-SPEC] server to determine the size of
the packet that will traverse a network path. server
protocol.

It is implementation
defined NOT a design goal of DHCPv6 to specify how this a server
configuration parameter database is accomplished in DHCPv6. maintained or determined.

The IPv6 Addressing Architecture Specification provides the address
scope that can be used in an IPv6 implementation, and following list gives design goals specific to the various
configuration architecture guidelines for network designers transmission of
the
IPv6 address space. Two advantages of IPv6 is network layer parameters.

Guarantee 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 specific network address to begin
communications to discover neighbors on the link, or as will not be
discussed later in the specification locate use by
more than one host at a DHCPv6 server or
relay-agent.

The IPv6 Stateless Address Configuration Specification (addrconf) time.

Expires December 1995 May 1996 [Page 8]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 9]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

defines how

Guarantee that client addresses that are not provided by DHCPv6
will not be added to a servers configuration parameter database or
the servers binding for a clients interface token.

Retain host can autoconfigure addresses based on neighbor
discovery router advertisements, and configuration parameters across client reboots. A
client should, whenever possible, be assigned the use of same
configuration parameters in response to a validation-lifetime
and request.

Retain host configuration across server reboots, and, whenever
possible, a deprecation-lifetime for addresses. In addition host should be assigned the addrconf
specification defines same configuration
parameters despite restarts of the protocol interaction for a host DHCPv6 mechanism,

Allow automatic assignment of configuration parameters to begin
stateless new
hosts to avoid hand configuration for new hosts.

Support fixed or statefull autoconfiguration. permanent allocation of configuration parameters
to specific hosts.

3.2. Request/Response Model

DHCPv6 is one vehicle uses a message-type to
perform statefull autoconfiguration. Compatibility with addrconf is define whether the packet originated
from a design goal DHCPv6 server or client. The set of packets used to complete
a DHCPv6 where possible.

IPv6 Neighbor Discovery (ND) is transaction are defined as the node discovery protocol in IPv6
(replaces request and enhances functions of IPv4 ARP Model). To truly
understand IPv6 response set.

The message types are as follows:

01 DISCOVER

The DISCOVER message is a DHCPv6 multicast packet from a client
to locate and addrconf it request configuration parameters on a network,
when the client does not know the servers address.

02 CONF-REQUEST

The CONF-REQUEST is strongly recommended that
implementors understand an IPv6 ND.

Dynamic Updates unicast packet from a client to DNS is a specification that supports
server, when the dynamic
update of DNS records for both IPv4 and IPv6. This will be discussed
further later in this section of client knows the specification. An implementor
cannot implement DHCPv6 without understanding Dyanmic Updates IPv6 unicast address of a
server, to DNS.

3.2 Design Goals request configuration parameters on a network.

03 CONF-RESPONSE

The following list gives general design goals for DHCPv6. Most
DHCPv4 Design Goals [DHCP-v4] are kept CONF-RESPONSE is an IPv6 unicast packet from a server in this specification.

DHCPv6 should be
response to a mechanism rather than client DISCOVER or CONF-REQUEST, which provides
the requested configuration parameters.

04 ACCEPT

The ACCEPT is a policy. DHCPv6 must
allow local system administrators control over client response to a server CONF-RESPONSE. When
the client used DISCOVER to locate a server and request
configuration parameters where desired; e.g., local system administrators on a network, the ACCEPT should be able
sent using the DHCPv6 multicast address, which also serves to enforce local policies concerning allocation and access
inform other servers that responded to local resources where desired.

Hosts should require no manual configuration. Each host should be
able the DISCOVER they were
not selected. When the client used CONF-RESPONSE to discover appropriate local request
configuration parameters
without user intervention and incorporate those parameters into
its own configuration.

Networks from a server whose address was known,
the ACCEPT 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 sent as possible be compatible with an IPv6
Stateless Address Configuration.

DHCPv6 servers should be able to support Dynamic Updates to DNS
[DYN-UPD].

It unicast packet. The
ACCEPT is NOT a design goal of DHCPv6 to specify a server also an implied acknowledgment to the server selected
that the client has received the servers configuration

Expires December 1995 May 1996 [Page 9]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 10]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

protocol.

parameters from the CONF-RESPONSE.

05 SERVER-ACK

The SERVER-ACK is NOT an IPv6 unicast packet sent by a design goal of DHCPv6 server to specify how
inform a server
configuration database is maintained or determined. client that it received an ACCEPT. The following list gives design goals specific SERVER-ACK is
used by the server to inform the transmission of client it has received an
acknowledgment that the network layer parameters.

Guarantee client has received the configuration
parameters from the server, and denotes a completed-transaction
to a server. The server at that point MUST commit its bindings
and any specific network address will not be in use by
more than one host at updates it may do for the client. The SERVER-ACK for
the client denotes a time.

Guarantee that completed-transaction. The client addresses at that are not provided
point MUST commit its bindings.

06 RELEASE

The RELEASE is used by DHCPv6
will not be added to a servers configuration database or the
servers binding client for a clients interface-token.

Retain host configuration across host reboot. A two reasons:

1. To inform the server that the client should,
whenever possible, be assigned did not receive the same configuration-data in
response
SERVER-ACK required to each request.

Retain host configuration across complete the client transaction,
and the server reboots, and, whenever
possible, a host should be assigned the same configuration
parameters despite restarts delete that binding and any
updates it may have done on behalf of the DHCPv6 mechanism,

Allow automatic assignment of configuration parameters to new
hosts to avoid hand configuration for new hosts.

Support fixed client.

2. To inform the server that the client is releasing a
particular address or permanent allocation set of configuration parameters
to specific hosts.

Clients must addresses, even though the
lifetimes for those addresses may not assume that have become
invalid.

The processing and algorithms for the request/response set of
message-types will be discussed in section 4.0.

3.3. Leased Address Model

The leased address model specifies a set of lifetimes associated with
addresses returned by the server. These lifetimes are updated meant to
support site renumbering, and are completely compatible with the DNS,
unless
leasing model in IPv6 Stateless Address Autoconfiguration.

The DHCPv6 philosophy is that the server provides client has the responsibility to
renew a host-name with lease for an address that is about to expire, or request a
client.

3.3 Request/Response Model

DHCPv6 uses
new address or the same address before the lease actually expires.
If the client does not request a message type to define whether new lease for an address, the packet orginated
from server
MUST assume the client does not want a DHCPv6 Server or Client. new lease for that address.
The 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)
2. Response with configuration-data or error found (server).
3. Confirmation Response or reject (client).

The time out period for a client or server MAY provide that address to wait for a response
MUST NOT exceed 3 minutes. When a another client or server times out waiting
for a response requesting an
address, after all other addresses available to a packet sent, the implementation MUST NOT commit
any binding based on the configuration-data sent in the 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.

3.4 Leased have been
exhausted.

3.3.1. Address Model Lifetimes

An address returned to a client has a validation-lifetime preferred and
deprecation-lifetime. valid lifetime.
The lifetimes represent the lease for addresses provided to the
client, from the server.

The client MAY request a single
address value for the lifetimes returned by a client. The server
server, but the client MUST provide use the lifetimes provided by the server

Expires May 1996 [Page 11]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

response.

When an address for a validation-lifetime
and SHOULD provide client interface becomes deprecated the
processing of the lease MUST be as follows:

When the preferred lifetime of an address expires, the clients
address becomes a deprecation-lifetime to deprecated address. A deprecated address can be
used as a client source address in new communications and existing
communications. But a server
response packet to deprecated address means the node will soon
have an address whose valid lifetime will expire, when this
happens the address cannot be used in any communications.

An address is a clients request for deprecated until its valid lifetime expires at
which point the address becomes an invalid address.

The client may suggest An invalid
address MUST NOT be used as a value for the lifetimes source address in outgoing
communications, and MUST NOT be recognized as a valid destination
address for incoming communications.

Once an address is deprecated an implementation SHOULD request a
new lease or address for that interface.

If the clients preferred lifetime is zero for an address the address
is immediately deprecated.

Implementors of DHCPv6 would find it beneficial to coordinate the use
of the preferred lifetime and valid lifetime for layers below the
DHCPv6 application layer with their implementation of Stateless
Address Autoconfiguration. It is suggested that implementations use
the same modules to configure addresses for stateless and stateful
address autoconfiguration. Implementors might want to consider an
option to stop all new communications for a deprecated address, to
support a very robust renumbering strategy, but this cannot be the
default behavior.

3.3.2. Duplicate Address Detection

DHCPv6 clients MUST support Duplicate Address Detection as specified
in IPv6 Stateless Address Autoconfiguration. This will provide a high
guarantee that DHCPv6 client addresses are not duplicated on a link.

It is an option for a server to inform the client it does not have to
perform Duplicate Address Detection by the server setting a value of
01 in the message-flag in client responses. In this case it is
assumed that the server implementation is providing the guarantee
that the client addresses returned are unique on the link. It is
implementation defined how a server verifies the uniqueness of client
addresses on a link.

A conceptual model of an implementation for DHCPv6 duplicate address
detection is that the client DHCPv6 module, which supports updating
the network interfaces for a host, would use the same application
configuration interface for DHCPv6 as is used for IPv6 Stateless
Address Autoconfiguration on an IPv6 conforming implementation. An
implementation can integrate and reuse the same modules in the
network operating system kernel to spawn duplicate address detection,
address lifetime processing, and the processing of deprecated and
invalid addresses for existing and new connections.

Expires May 1996 [Page 12]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

3.3.3. Releasing Infinite Lifetime Addresses

DHCPv6 specifies no behavior which would require a client to listen
for asynchronous messages from servers on a well known UDP port. The
reason for this is that minimal implementations may not be able to
support such a feature in a client. But DHCPv6 does permit the
client to request an infinite lease for addresses. The problem in
this case is that though the server has permitted an infinite lease
for a client it may later be required that the client give up that
lease or the addresses, for some organizational reason.

This specification leaves it as implementation defined how this
problem is solved in a DHCPv6 network environment.

One solution to the problem is to define an SNMP MIB for DHCPv6
clients that when set by a network management agent causes a client
to revalidate all of its addresses with the DHCPv6 server or issue a
RELEASE to the server.

3.4. DNS Host Name Autoregistration Model

It is important that DHCPv6 provide a server implementation set of
options for Dynamic Updates to DNS (DYNDNS), to support the
autoregistration of addresses to names in IPv6. DYNDNS SHOULD be
supported as a set of options in DHCPv6 as specified in the Options
for DHCPv6 specification. The minimum requirements to support DYNDNS
in DHCPv6 are as follows:

1. Clients SHOULD be able to request or change names for
addresses.

2. Servers SHOULD be able to provide names for addresses
provided to a client.

3. If servers support DYNDNS then they MUST support the
following:

a) Create, Update, and Delete of IPv6 AAAA Records
[IPv6-DNS] as specified in DYNDNS [DYN-UPD].

b) Create, Update, and Delete of IPv6 IP6.INT Domain PTR
records for any IPv6 AAAA addresses defined in a client
DYNDNS request, or that the server automatically generated
for a client.

4. Request/Response Processing

The request/response processing for DHCPv6 is transaction based and
uses a best-effort set of messages to guarantee a completed-
transaction. The case where the client does not know the servers
address is depicted, and then the case where the client does know the
servers address is depicted. Then the timeout and retransmission
guidelines and configuration variables are discussed.

Expires May 1996 [Page 13]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

4.1. Processing when Server Address is not Known

The processing for the DHCPv6 request/response model when the client
does not know the server address is as follows:

Server Client Server
(not selected) (selected)

DHCPv6 uses the UDP [RFC-768] protocol to communicate between clients
and servers. UDP is not reliable, but DHCPv6 must provide some
reliabilty between clients and servers. The network trade-off is
time versus the reliability that the completed set of
request/response messages were received by both the client and the

Expires May 1996 [Page 14]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

server to define a server, or leave them as zero. completed-transaction.

The client MUST use the
lifetimes provided request/response set is always started by a client either with a
DISCOVER when the server response if client does not know the values are different
than servers address, or a
CONF-REQUEST when the lifetimes requested by client does know the client. servers address. The DHCPv6 philosophy
second message is from the server and is that the CONF-RESPONSE. The
client has then acknowledges the responsibility to
renew a lease for servers CONF-RESPONSE with an address that ACCEPT.
At this point in the flow all data has been received and additional
messages are defined to insure the transaction is about completed, and to expire, or request
provide a
new address method of recovery if either the client or server do not
receive the same address before messages to complete the lease actually expires.
If transaction.

The server after receiving the client does not request ACCEPT sends a new lease for SERVER-ACK, which is an address,
acknowledgment to the client the server
MUST assume has received the client does not want a new lease for clients
ACCEPT. At that address,
and point the time vs reliability trade-off in DHCPv6 is
for the server MAY provide that address to another commit its bindings, and perform any updates as a
result of the client requesting
an address. messages (e.g. Update DNS). If the the client has a deprecation-lifetime for an address
receives the
processing of SERVER-ACK, then the lease SHOULD be as follows:

When client can commit its bindings.
But if the deprecation-lifetime of an address expires, client does not receive the clients
address becomes a deprecated-address. A deprecated address SHOULD
NOT be used as a source address in new communications. However, a
deprecated-address SHOULD continue to be used as a source address
if SERVER-ACK then it is in use in existing communications. Implementors of
DHCPv6 SHOULD coordinate should send
the use of server a RELEASE to inform the validation-lifetime server that any bindings should be
deleted and
deprecation-lifetime any updates for layers below the client should be rolled back. The
client RELEASE provides the final recovery check in the DHCPv6 application layer
with their implementation
request/response set to complete a transaction.

Retransmission of IPv6 Stateless Address Configuration
[IPv6-ADDRCONF].

An address messages 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 discussed in outgoing
communications, and MUST NOT be recognized as a valid destination
address section 4.3.

The ACCEPT in incoming communications.

If the clients deprecation-lifetime flow above is zero for a multicast packet which serves an address
overloaded function, to respond to the
processing for selected server, and to inform
other servers on the lease SHOULD be as follows:

There network the client is no concept of a deprecated-address not selecting them.

Expires May 1996 [Page 15]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

4.2. Processing when Server Address is Known

The processing for a client if the
deprecation-lifetime is zero DHCPv6 request/response model when provided to the client in a
does knows the server response. address is as follows (all packets are
Unicast):

Client Server

The address for the client processing above 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 same as
a valid destination address was discussed 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 4.1, except the autoregistration of DNS Host names and providing
DNS Host Names with addresses for clients. Autoregistration
CONF-REQUEST is
supported used by the presence of the name field in DHCPv6, which the client may provide to request configuration parameters
from the server in a request. In addition a server
may provide server, and the CONF-REQUEST and ACCEPT are unicast packets.

4.3. Retransmission and Configuation Variables

Configuration variables for a DNS Host Name with an IPv6 address to DHCPv6 implementation that MUST be
configurable by a client or server are as follows:

Retranstimer - The time in seconds that a
response.

If the name-length field is zero, there is no name field contained in
the packet. DHCPv6 only specifies the name-field, and not the actual protocol client or
primitives to interact with DNS. server
should wait before retransmitting a message.

Expires May 1996 [Page 16]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Default: 3 seconds.

Maxretrans - The functions maximum retransmissions that the a DHCPv6 client
or server uses
to interact with the DNS to provide autoregistration is defined in
Dynamic Updates to DNS [DYN-UPD]. should retransmit, before logging a
DHCPv6 servers SHOULD support
Dynamic Updates System Error to DNS.

If the client provides user.

Default: 3 retransmissions.

The problem with retransmissions occurs when they are continually
received by a Host Name (HN) client or a Fully Qualified Domain
Name (FQDN) [RFC 1034&1035]:

The server SHOULD perform a DNS query for the HN (e.g. duplicate bindings or updates).

To support informing a client or FQDN IPv6 DNS
AAAA resource record [IPv6-DNS]:

If the name is found and the address does not match the clients
address for the name provided by the client, the server SHOULD add
this address to the DNS name record (multiple addresses that a retransmission is
being done a second set of message-types are supported for names at this time in DNS and the DHCPv6 as
follows:

20 - DISCOVER-Retrans
21 - CONF-REQUEST-Retrans
22 - CONF-RESPONSE-Retrans
23 - ACCEPT-Retrans
24 - SERVER-ACK-Retrans
25 - RELEASE-Retrans

When a client may want or server retransmits a DHCPv6 packet at the
application layer over UDP, they MUST change the message-type to
use the
same name for multiple addresses on an interface).

If the name is not found message-type with the client supplied name Retrans suffix.

A response to a retransmission SHOULD be added
to 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 after updating the DNS it MUST return duplicate of a FQDN previous
response to the client.

If the client does not request a HN or FQDN from a server, the server
MAY provide, server. It is implementation defined how
this is accomplished.

One method of retransmitting duplicates in its response with the address an implementation
conceptually is to a client, a FQDN the
client can use the 5-Tuple binding for that address. The server MUST NOT provide a client with a or server generated FQDN, unless to
search for a previous response. At a minimum the associated IPv6 AAAA
record client interface
token and IP6.INT domain PTR record exists transaction-ID will be present in the DNS.

When all messages; hence a clients
binding can be searched (whether committed or in process) to verify
if a previous response has been sent.

Expires May 1996 [Page 17]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

5. Datagram and Field Definitions

5.1. Datagram

DHCPv6 Datagram

Expires December 1995 May 1996 [Page 12]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 18]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

3.6 Defining Optional Configuration-Data

Optional configuration-data

5.2. Field Definitions

All fields in the datagram MUST be specified for DHCPv6 as follows initialized to binary zeroes by
both the client and aligned on an server messages unless otherwise noted in Section
6.

msg-type - 1 octet integer multiple of 8 octets:

option-type: value (message-type)

Value Description

01 DISCOVER
02 CONF-REQUEST
03 CONF-RESPONSE
04 ACCEPT
05 SERVER-ACK
06 RELEASE
07-19 RESERVED
20 DISCOVER-Retrans
21 CONF-REQUEST-Retrans
22 CONF-RESPONSE
23 ACCEPT-Retrans
24 SERVER-ACK-Retrans
25 RELEASE-Retrans
26-255 RESERVED

msg-flag - 1 Octet

This field permits 254 options for DHCPv6 and will represent the
tag for the option. The values of 0 and octet integer value (message-flag)

Value Description

01 Server - Duplicate Address Detection not Required.
02-255 RESERVED

error-code - 1 octet integer value

Value Description

01 Server - Addresses are used for pad
options discussed below.

option-length: 2 Octets

This field specifies the length of the configuration-data not
including the available at this time.
02 Server - Address not known by the option-type and and option-length fields.

option-data: Variable Server
03-255 RESERVED

total-addrs - 1 octet integer value (total-addresses)

RESERVED - 2 octets Reserved for future use.

transaction-ID - 2 octets integer value

interface token - 8 octets link-dependent identifier

server address - 16 octets address

gateway address - 16 octets address

client-link address - 16 octets link-local address

preferred lifetime - 4 octets integer value in seconds

valid lifetime - 4 octets integer value in seconds

Expires May 1996 [Page 19]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

client address - 16 octets address

options - variable number of Octets

The option-data is the configuration-data that immediately follows
the option-length field.

If the octets [DHCPv6-OPT]

Expires May 1996 [Page 20]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

6. Client/Server Message Formats

6.1. Client/Server UDP Ports, Multicast Group, and Addresses

A client MUST transmit all messages over UDP using UDP Server Port 547.

A server does not support an option-type requested it or relay-agent MUST
return the option-type and the option-length set to zero in the
response to the client. transmit all messages over UDP using UDP
Client Port 546.

A client MUST receive all messages over UDP using UDP Client Port 546.

A server implementation or relay-agent MUST start any options after receive all messages over UDP using UDP
Server Port 547.

A server or relay-agent MUST join the first option
returned to a client DHCPv6 Server/Relay-Agent
multicast group well-known multicast address FF02:0:0:0:0:0:1:0.

Servers on an integer multiple of 8 octets. This is an
architectural REQUIREMENT, and the client when parsing options can
assume same link as the next option, if it exists will begin on client MUST use the next integer
multiple of 8 octets boundary.

This specification does not define any options. DHCPv6 options are
defined source address in XXXXXXXXX. It is permissible for options to also create
new message-types and message-codes
the IPv6 header from the client as required.

Expires December 1995 [Page 13]

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

4. Datagram and Data Formats

4.1 Datagram

DHCPv6 Datagram

4.2 Data Formats

All fields the destination address in the datagram MUST be initialized
servers response packet. Servers that respond to binary zeroes
by both relay-agents and
relay-agent processing are discussed in section 7.

In the cases where a client and or server must retransmit messages unless otherwise noted
in Section 5. Client and Server processing of messages. the
msg-type : 1 Octet integer value (message-type)

Value Description

1 - Client request for configuration data.
2 - Server response codes in this section are used as stated in section 4.3 with configuration data.
3 -
the values that represent the Retrans suffix for the msg-types.

6.2. Client confirmation of DISCOVER and CONF-REQUEST Messages

msg-type:

If the client does not know the server response.
4 - Client rejection of address or wants to locate a new
server response.

Expires December 1995 [Page 14]

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

msg-code : 1 Octet integer value (message-code)

Value Description

1 - Server Response - Client address-count is in error.
2 - Server Response - Dynamic Updates to DNS not supported.

name-lgth : 1 Octet integer value (name-length)

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

transaction-ID : 4 Octets integer value

interface-token : 4 Octets integer value

client-address : 16 Octets receive configuration parameters the client sets the msg-type
to DISCOVER. In this case the client MUST use as the destination
IP address

server-address : 16 Octets the DHCPv6 Server/Relay-Agent multicast address

gateway-address : 16 Octets
FF02:0:0:0:0:0:1:0.

If the client knows the server address

client-link-address : 16 Octets the client sets the msg-type to
CONF-REQUEST. In this case the client MUST use as the destination
IP 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 integer value

option-length : 1 Octet integer value

option-data : Variable Octets variant value(s) the server address.

msg-flag:

Set to binary zeroes.

error-code:

Set to binary zeroes.

total-addrs:

Set to the number of addresses the client is requesting.

transaction-ID:

Expires December 1995 May 1996 [Page 15]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 21]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

5. Client/Server Processing

5.1 Client Transmission

UDP DHCPv6 Server Port 546 MUST be used by

Set to an integer value.

interface token:

Set to a unique link dependent identifier for the clients interface.

server address:

Set to binary zeroes for DISCOVER.
Set to server address for CONF-REQUEST.

gateway address:

Set to binary zeroes.

client-link address:

Set to the clients link-local address for the link on which the client
transmitted the packet.

preferred lifetime:

Set to send UDP
datagrams binary zeroes if the client is not requesting a lifetime.
Set to the server.

If number of seconds the client knows its address it MUST be put in wants for the source lifetime.
Set to all 1's (oxffffffff) if the client wants an infinite lifetime.

The client must provide a preferred lifetime for each address
field
requested.

valid lifetime:

Set to binary zeroes if the client is not requesting a lifetime.
Set to the number of seconds the IPv6 Header. Otherwise client wants for the clients link-local lifetime.
Set to all 1's (oxffffffff) if the client wants an infinite lifetime.

The client must provide a valid lifetime for each address
MUST
requested. The valid lifetime must be used as greater than or equal to the source address field in
preferred lifetime.

client address:

Set to binary zeroes if the IPv6 Header [IPv6-
ADDRCONF].

If client is not requesting a renewal for an
existing address it received from a server.
Set to an address the client knows previously received from a server when the address
client is requesting a new set of lifetimes for the server on its link it address.

A client MUST put
that address in the destination NOT provide a server with an address field of that was not given
to the client by a server. DHCPv6 does not permit a server to create
leases for manual configured addresses, or update leases for addresses
created by IPv6 Header.
Otherwise Stateless Address Autoconfiguration.

options:

See Options for DHCPv6 specification [DHCPv6-OPT].

Expires May 1996 [Page 22]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

6.3. Server CONF-RESPONSE Message

msg-type:

Set msg-type to CONF-RESPONSE.

msg-flag:

Set to 01 if the client MUST put server knows addresses provided are verified to be
unique, otherwise set to binary zeroes.

error-code:

Set to 01 if the DHCP Server/Relay-Agent well-known
multicast address FF02:0:0:0:0:0:1:0 using link-local scope [IPv6-
ADDR] as server cannot provide any addresses to the client at
this time.
Set to 02 if the destination server detects an address field in from the IPv6 Header.

The client MUST set msg-type to 1 to transmit a request it did not
provide to the
server.

The client MUST set msg type to 3 client.

total-addrs:

Set to confirm the acceptance number of packet
from a addresses the server response.

The client MUST set msg type is returning the client.

transaction-ID:

Set to 4 the value the client provided in the DISCOVER or CONF-REQUEST
msg-type.

interface token:

Set to reject a packet from a server
response.

The client MUST use UDP DHCPv6 Client Port 546 unique link dependent identifier for the clients interface as
provided in the UDP port to
accept clients DISCOVER or CONF-REQUEST msg-type.

server responses in an implementation.

5.2 Server Transmission

UDP DHCPv6 Client Port 546 MUST be used by address:

The address of the server to send UDP
datagrams responding.

gateway address:

Set to the client.

A server, on same value that existed when the server received the packet.

client-link address:

Set to the same link as value that existed when the client, MUST use server received the source address
in packet.

preferred lifetime:

Set to the IPv6 Header from value requested by the client as or the destination address in value required by the
servers response packet. Servers not on
server.

valid lifetime:

Set to the same link are discussed
in Section 6 Relay-Agent Processing. value requested by the client or the value required by the
server.

The server valid lifetime MUST set msg type to 2 to transmit a response be greater than or equal to a client.

The server MUST use UDP DHCPv6 Server Port 547 as the UDP port to
accept preferred
lifetime.

client requests in address:

Expires May 1996 [Page 23]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Set to an implementation.

The address provided by the server MUST join if 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 is not know attempting
to renew existing addresses, meaning the address of fields from the client
have a value of binary zeroes.

If the error-code is set to 02 the server on will only return the addresses
that the clients link.

Expires December 1995 [Page 16]

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

5.3 Client/Server Bindings

Client and server bindings MUST can verify were provided by the server. If no addresses
could be maintained at least as a 4-tuple
consisting of verified the clients interface-token, address, validation-
lifetime, total-addrs field, lifetimes, and deprecation-lifetime in an implementaiton. It client address
will be set to binary zeroes. In the case as far as the server is
critical for
concerned the interoperability of DHCPv6 that the clients bindings
remain consistent with transaction is completed and the servers bindings across reboots.

When server will not
expect a client sends ACCEPT message to its CONF-RESPONSE message.

options:

See Options for DHCPv6 specification [DHCPv6-OPT].

6.4. Client ACCEPT Message

msg-type:

Set msg-type to ACCEPT.

If the client sent a DISCOVER to request it MUST enter in configuration parameters on the addr-count field
link, then the number of addresses that it has for a particular interface-token
in client should use as the clients bindings.

When IP destination address the server receives DHCPv6
Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0.

If the client request, it MUST verify that sent a CONF-REQUEST to request configuration parameters on
the
addr-count field provided by link, then the client matches should use as the number of
addresses IP destination address the server has for that clients binding, for
address in the
interface-token provided by CONF-RESPONSE from the client. server.

If the server has a
different addr-count than the client for a particular interface
token, sees an error-code of 02 and the total-addrs field is
zero, the server MUST send a response to cannot process any of the addresses requested and the
client setting msg-code should not send an ACCEPT to 1 informing the server. If the client addr-count at sees an
error-code of 02 and total-addrs does not equal zero it means the server is
dropped addresses that it could not in synch
with locate requested by the client.

Once the client receives a response with a msg-code set

msg-flag:

Set to 1 it MUST
set addr-count binary zeroes.

error-code:

Set to zero on subsequent requests binary zeroes.

total-addrs:

Set to 1.

transaction-ID:

Set to the server, for integer value that
interface-token.

When a server receives a request from a the client and used on its initial DISCOVER or
CONF-REQUEST msg-type to the addr-count is
set server.

interface token:

Set to zero, but the client has a binding unique link dependent identifier for the clients interface
that interface-token, was used for the server MUST reissue clients initial DISCOVER or CONF-REQUEST msg-type

Expires May 1996 [Page 24]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

to the configuration-data in those bindings server.

server address:

Set to the client.

5.4 Client Requests

The client sets address provided by the following fields for a request for
configuration-data:

msg-type: servers CONF-RESPONSE.

gateway address:

Set to 1.

name-lgth: binary zeroes.

client-link address:

Set to the length of clients link-local address for the host-name if provided.

addr-count: link on which the client
transmitted the packet.

preferred lifetime:

Set to the number of addresses the client has first or only preferred lifetime returned for an address by
the
interface-token specified in this request.

transaction-ID: server.

valid lifetime:

Set to a unqiue integer value.

interface-token: Set the first or only valid lifetime returned for an address by the
server.

The valid lifetime MUST be greater than or equal to a unqiue opaque identifier.

client-address: Set ONLY if the preferred
lifetime.

client is requesting a host name
for a particular address, else not set.

validation-lifetime: address:

Set to the value first or only address provided by the server.

If the client would like did receive more than one address and lifetime, it MUST
store this data in an implementation defined manner, so that it can
issue a complete RELEASE for all addresses provided from the server to use, else
CONF-RESPONSE, if necessary later. But the ACCEPT does not set.

deprecation-lifetime: Set need to carry
all those addresses to acknowledge the value servers CONF-RESPONSE packet in
an ACCEPT.

options:

No options are present.

6.5. Server SERVER-ACK Message

msg-type:

Set msg-type to SERVER-ACK.

If the client would like sent the ACCEPT to acknowledge a servers CONF-RESPONSE
message on the DHCPv6 Server/Relay-Agent multicast address
FF02:0:0:0:0:0:1:0, the server MUST look at the server address in the
packet to use, else not set.

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

Expires December 1995 [Page 17]

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

this field the ACCEPT is not present.

option-type: Set to a future option request for configuration-
data, otherwise them or not.

If the field message is not present. Multiple option-types
may be set adjacent for a particular server then this is an indirect
message to each other.

5.5 Server Response

The that particular server sets the following fields client is not accepting them as

Expires May 1996 [Page 25]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

their server for this transaction, and MUST NOT send a response SERVER-ACK to a client for
configuration-data:

msg-type: the
clients ACCEPT.

msg-flag:

Set to 2.

msg-code: binary zeroes.

error-code:

Set to 1 if addr-count not equal binary zeroes.

total-addrs:

Set to servers bindings for
the clients specified interface-token. 1.

transaction-ID:

Set to 2 if the server
cannot support Dynamic Updates to DNS because integer value that the client requested
a host-name for an address provided, used on its initial DISCOVER or from the servers set of
addresses.

If the server determines that addr-count is not equal
CONF-REQUEST msg-type 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 server.

interface token:

Set to 1 and MUST put all
other values supplied by the clients request in unique link dependent identifier for the response
packet except clients interface
that was used for the clients initial DISCOVER or CONF-REQUEST msg-type and msg-code fields.

Processing of msg-code set
to 1 for the client and server.

server is
done as specified in 5.3 Client/Server Bindings.

name-lgth: address:

Set to the length of servers address.

gateway address:

Set to the host-name if present.

addr-count: same value that existed when the server received the packet.

client-link address:

Set to the same value specified that existed when the server received the packet.

preferred lifetime:

Set to the value provided by the client.

transaction-ID:

valid lifetime:

Set to the same value specified provided by the client.

interface-token:

The valid lifetime MUST be greater than or equal to the preferred
lifetime.

client address:

Set to the same value specified address provided by the client.

client-address: If the client-address from the request packet is
zero

At this point the server sets MUST commit the client-address configuration parameters
provided to the next available
address for this interface-token. If there is a client-address in client from the request packet servers CONF-RESPONSE.

options:

Expires May 1996 [Page 26]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

No options are present.

6.6. Client RELEASE Message

msg-type:

Set msg-type to RELEASE.

If the client is requesting had sent an ACCEPT to the server and received a host-name SERVER-ACK
for this
address, and that message then the server client MUST return commit the address configuration
parameters provided by the
client if the server supports Dynmic Updates to DNS, servers CONF-RESPONSE and has
updated a RELEASE message
is not required. But if the DNS with client did not receive a host-name for that address.

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

validation-lifetime: The server sets this address to the
validation-lifetime of clients ACCEPT, then the servers configuration database. It is
implementation defined if client MUST issue a RELEASE
to the server will use server.

If the validiation-
lifetime if specified by a client request packet.

deprecation-lifetime: The server sets this no longer needs an address or has been notified to return
an address to the
deprecation-lifetime of the servers configuration database. It is
implementation defined if the server will use server, then the deprecation-

Expires December 1995 [Page 18]

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

lifetime if specified by a client request packet.

host-name: The server returns SHOULD issue a hostname or msg-code set RELEASE to 2, if the name-lgth field is greater than zero. Processing
server.

msg-flag:

Set to binary zeroes.

error-code:

Set to binary zeroes.

total-addrs:

Set to the total number of host-name addresses the client is specified in Section 3.5 DNS Host Name Autoregistration Model.

option-type: The server returns releasing. In the same option-types specified by
case of a RELEASE where the client requests.

option-lgth: The server returns did not receive the length of SERVER-ACK this
value MUST equal the configuration-
data or zeroes if total number of addresses for the option is not supported.

option-data: The server returns servers
CONF-RESPONSE.

transaction-ID:

Set to the configuration-data requested
by integer value that the client.

5.6 Client Confirmations/Rejections

The client sets used on its initial DISCOVER or
CONF-REQUEST msg-type to the following fields server.

interface token:

Set to the unique link dependent identifier for a confirmation the clients interface
that was used for the clients initial DISCOVER or rejection
after receiving configuration-data from CONF-REQUEST msg-type
to the server. configuration-
data:

msg-type:

server address:

Set to 3 if binary zeroes.

gateway address:

Set to binary zeroes.

client-link address:

Set to the clients link-local address for the link on which the client is confirming a servers response.

Expires May 1996 [Page 27]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

transmitted the packet.

preferred lifetime:

Set to 4 if the client is rejecting a servers response.

When valid lifetime returned for an address by the server receives a rejection msg-type 4 from a client server.

valid lifetime:

Set to the server MUST assume valid lifetime returned for an address by the client is using another server.

The
server then MUST remove any bindings for that client it may
have created, and valid lifetime MUST delete any DNS HN be greater than or FQDN records it may
have added on behalf of equal to the client.

transaction-ID: Same value as specified in preferred
lifetime.

client address:

Set to the servers response.

interface-token: Same value as specified in address provided by the servers response.

client-address: Same value as specified server.

The client will return the number of addresses and associated lifetimes
provided in the servers response.

6. CONF-RESPONSE.

options:

No options are present.

7. Relay-Agent Processing

The relay-agent MUST use UDP DHCPv6 Server Port 547 as the UDP port to
accept client responses in an implementation.

The relay-agent MUST join the DHCP Server/Relay-Agent mulicast multicast group
well-known multicast address FF02:0:0:0:0:0:1:0 using link-local
scope [IPv6-ADDR], to listen for client requests. FF02:0:0:0:0:0:1:0.

When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it MUST:

If the gateway-address gateway address is NOT zero then the relay-agent MUST:

Put MUST:

Put the relay-agents IP address in the gateway address field of
the clients request packet.

All relay-agents MUST:

Put their relay-agent address as the source address for the IP
header.

Put the next relay-agent or known server address as the
destination address in the IP header.

Forward the packet to the to the next hop relay-agent or
known server.

When the remote server receives the client request from the relay-agent
it will know its a remote client request (not on the relay-agents IPv6 servers link),
because there is a gateway address in the gateway-address field
of the clients request packet.

Put the request. So servers MUST
verify the source gateway address from the IPv6 Header of is not zero, to determine if the clients request
is from a remote link.

Expires December 1995 May 1996 [Page 19]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 28]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

request packet

The server responds as specified in section 6.0, but uses the
gateway address as the destination address in the IP header.

When the client-link-address.

All relay-agents MUST:

Put their 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 for the
IPv6 IP Header.

Put

8. Security Considerations

Security for DHCPv6 can be used as specified in [IPv6-SA], [IPv6-AUTH],
and [IPv6-ESP], which are implementation requirements for IPv6.

Appendix A - Related Work in IPv6

The related work in IPv6 that would best serve an implementor to study
is the next relay-agent IPv6 Specification [IPv6-SPEC], the IPv6 Addressing Architecture
[IPv6-ADDR], IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF],
IPv6 Neighbor Discovery Processing [IPv6-ND], and Dynamic Updates to DNS
[DYN-UPD]. These specifications afford DHCPv6 to build upon the IPv6
work to provide both robust stateful autoconfiguration and
autoregistration of DNS Host Names.

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 known server address
greater (in IPv4 the requirement is 68 octets). This means that a
UDP datagram of 536 octets will always pass through an internet (less 40
octets for the IPv6 header), as long as there are no IP options prior to
the
destination address UDP datagram in the packet. But, IPv6 Header.

Forward the packet to the 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 next hop relay-agent UDP datagram in UDP
or known
server.

When the remote server receives use Path MTU Discovery [IPv6-SPEC] to determine the client request from size of the relay-
agent it
packet that will know its a remote client request (not on the servers
link), because there is traverse a gateway-address in the request. So servers
MUST test the gateway-address network path. It is not zero, to determine if the
clients request implementation defined
how this is from a remote link.

The server responds as specified accomplished in 5.5 Server Response, but uses the
gateway-address as DHCPv6.

The IPv6 Addressing Architecture Specification provides the destination address
scope that can be used in the an IPv6 Header.

When the relay-agent receives the remote servers response, it MUST
forward the packet to implementation, and the client, by using various
configuration architecture guidelines for network designers of the client-link-address as 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 source nodes environment. This means that a host immediately can configure
an IPv6 address at initialization for an interface, before communicating in
any manner on the IPv6 Header.

Expires December 1995 [Page 20]

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

Draft ***Open Issues***

1. link. The present model uses UDP with host can then use a well-known multicast address
to begin communications to discover neighbors on the link, or as was
discussed in the specification to locate a client request, DHCPv6 server
response, and then client confirmation or rejection. relay-agent.

The server will
set state or remove state IPv6 Stateless Address Autoconfiguration Specification (addrconf)
defines how a host can autoconfigure addresses based on this model. There is always neighbor discovery
router advertisements, and the
possibility use of a validation lifetime to support
renumbering of addresses on the classic transactional error when Internet. In addition the client-to-
server response is not received by addrconf
specification defines the server, protocol interaction for a host to begin stateless
or stateful autoconfiguration. DHCPv6 is one vehicle to perform stateful
autoconfiguration. Compatibility with addrconf is a design goal of DHCPv6

Expires May 1996 [Page 29]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

where possible.

IPv6 Neighbor Discovery (ND) is the client assumes
the server received the response node discovery protocol in IPv6
(replaces and enhances functions of IPv4 ARP Model). To truly
understand IPv6 and addrconf it did not (see is strongly recommended that
implementors understand IPv6 ND.

Dynamic Updates to DNS is a specification that supports the draft).

This can be greatly alleviated by using TCP instead
dynamic update of UDP DNS records for both IPv4 and IPv6. DHCPv6 can use
the
transaction. This would have great benefits such as:

1. Guranteed virtual link, hence if the transaction completes
the server dynamic updates to DNS to now integrate addresses and client know immediately upon return name space to the
application.

2. PATH MTU Discovery for TCP is inherent
not only support autoconfiguration, but also autoregistration in an implementation IPv6.

Expires May 1996 [Page 30]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Change History

Changes from July 95 to November 95 Drafts:

Refined request/response codes and the DHCPv6 application does not have processing to support transaction
processing model.

Permit multiple addresses and lifetimes in a request and response.

Moved Dynamic Updates to DNS as an Option to be defined in that
specification.

Settled on using UDP as it supports DHCP client server model as opposed
to adjust TCP which has overhead for IPv6
fragmentation this model.

We can also use UDP

Reformatted specification to locate servers support analysis, packet formats, and TCP for the transaction.

2. Dynamic Updates
processing in their own sections to DNS need careful review make it easier for clarity and what implementors to
read.

Removed address count as it is required not necessary for just host name processing in DHCPv6.

3. We need synchronization.

Added error-code, msg-flag, and total-addrs fields.

Made transaction-ID 2 octets.

Updated terminology to determine the integration required coordinate with IPv6 Stateless Address Configuration when both stateless and statefull is being used
by a client host.

4. In the Design Goals section should the MUSTs, SHOULDs, etc be
capitalized and REQUIRED? Its not
Autoconfiguration.

Added more implementation notes.

Moved IPv6 Related Work to an Appendix.

Fixed various bugs in DHCPv4?

5. Charlie Perkins the spec from DHC WG input.

Added Security reference pointers.

Removed options format, which will be doing our option spec for DHCPv6. We need
to make sure it synchs up with this in the options spec.

Expires December 1995 [Page 21]

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

Change History

Added retransmission configuration variables, msg-types, and logic.

Changes from March 95 to July 95 Drafts:

Used integer values instead of bit values for type and code fields.

Used message-type and message-code fields and rely on looking at
the fields in the datagram instead of multiple over-lapping
request/response codes.

Added address-count field processing to be specified by the
client as opposed to the server, and the processing for when
client and server address-counts become disjoint.

Added Requirements wording for MUST, SHOULD, MAY, etc.

Added Design Goals section.

Re-Defined

Redefined transaction-ID and interface-token.

Expires May 1996 [Page 31]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

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

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

Expires December 1995 May 1996 [Page 22]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 32]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Acknowledgements

The DHC Working Group for their time and input into the specification.
A special thanks for the consistent input, ideas, and review by (in
alphabetical order) Brian Carpenter, Ralph Droms, Thomas Narten, Jack
Mccann, and Charlie
Perkins. A big warm and extended thanks to Perkins, Yakov Rekhter, Matt Thomas, 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.

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

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

The author MUST also thank his employer for the opportunity and funding
to work on DHCPv6 and IPv6 in general. general as an individual in the IETF.

References

[DHCPv6-OPT]
C. Perkins, "Options for the Dynamic Host Configuration
Protocol for IPv6 (ODHCPv6)" Internet Draft, November 1995
<draft TBD>

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

[IPv6-ADDR]
R. Hinden, S. Deering, Editors, "IP Version 6 Addressing Architecture"
Internet Draft, June 1995
<draft-ietf-ipngwg-ipv6-addr-arch-03.txt>

[IPv6-ADDRCONF]
S. Thomson, T. Narten, "IPv6 Stateless Address Configuration" Autoconfiguration"
Internet Draft, June November 1995 <draft-ietf-addrconf-ipv6-auto-02.txt>
<draft-ietf-addrconf-ipv6-auto-05.txt>

[IPv6-ND]
T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Neighbor Discovery"
Internet Draft, June September 1995
<draft-ietf-ipngwg-discovery-00.txt>
<draft-ietf-ipngwg-discovery-02.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 May 1996 [Page 23]

INETERNET-DRAFT draft-ietf-dhc-dhcpv6-02.txt July 33]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

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

[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>

[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

[IPv6-Ether]
M. Crawford, "A Method for the Transmission of IPv6 Packets over
Ethernet Networks", Internet Draft, October 1995
<draft-ietf-ipngwg-ethernet-ntwrks-01.txt>

[IPv6-SA]
R. Atkinson, "Security Architecture for the Internet Protocol"
RFC 1825, August 1995

[IPv6-AUTH]
R. Atkinson, "IP Authentication Header"
RFC 1826, August 1995

[IPv6-ESP]
R. Atkinson, "IP Encapsulating Security Payload (ESP)"
RFC 1827, August 1995

Authors' Addresses Address

Jim Bound
Digital Equipment Corporation
110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062
Phone: (603) 881-0400
Email: bound@zk3.dec.com

Expires December 1995 May 1996 [Page 24] 34]

----