WDIFF

draft-ietf-dhc-dhcpv6-15.txt --> draft-ietf-dhc-dhcpv6-16.txt

Internet Engineering Task Force J. Bound
INTERNET DRAFT Compaq Computer Corp.
DHC Working Group M. Carney
Obsoletes: draft-ietf-dhc-dhcpv6-14.txt draft-ietf-dhc-dhcpv6-15.txt Sun Microsystems, Inc
C. Perkins
Nokia Research Center
5 May
R. Droms(ed.)
Cisco Systems
22 November 2000

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-15.txt
draft-ietf-dhc-dhcpv6-16.txt

Status of This Memo

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

Distribution of this memo is unlimited.

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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."

The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.

Abstract

The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables
DHCP servers to pass configuration parameters using extensions such as IPv6 network
addresses to IPv6 nodes. It offers the capability of automatic
allocation of reusable network addresses and additional configuration
flexibility. This protocol is a stateful counterpart to ``IPv6
Stateless Address Autoconfiguration'' [15], [14], and can be used

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page i]

Internet Draft DHCP for IPv6 22 November 2000

separately or concurrently with the latter to obtain configuration
parameters.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page i] ii]

Internet Draft DHCP for IPv6 5 May 22 November 2000

Contents

Status of This Memo i

Abstract i

1. Introduction 1

2. Terminology 2
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3

3. DHCP Constants 5 4
3.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 5
3.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. DHCP message types . . . . . . . . . . . . . . . . . . . 6 5
3.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 8 7
3.4.1. Generic Error Values . . . . . . . . . . . . . . 8 7
3.4.2. Server-specific Error Values . . . . . . . . . . 8 7
3.5. Configuration Variables . . . . . . . . . . . . . . . . . 8

4. Requirements 9 8

5. Background 9

6. Design Goals 11 10

7. Non-Goals 11

8. Overview 12 11
8.1. How does a node know to use DHCP? . . . . . . . . . . . . 12 11
8.2. How does a client find out about DHCP agents? . . . . . . 12 11
8.3. What if the client and server(s) are on different links? 12 11
8.4. How does a client request configuration parameters from
servers? . . . . . . . . . . . . . . . . . . . . . . . 13 12
8.5. What are releasable resources, How do clients and when are they used? . servers identify and manage addresses? 13
8.6. Can a client release its releasable resources assigned addresses before the lease
expires? . . . . . . . . . . . . . . . . . . . . . . . 14 13
8.7. What if the client determines one or more of its releasable resource is assigned
addresses are already being used by another client? . . . . . . . . 14 13
8.8. How are clients notified of server configuration changes? 14 13

9. Message Formats 15 and Identity Associations 14
9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 15 14
9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 16 15
9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 18 16

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page ii] iii]

Internet Draft DHCP for IPv6 5 May 22 November 2000

9.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 19 17
9.5. DHCP Release Message Format . . . . . . . . . . . . . . . 20 18
9.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 22 18
9.7. DHCP Reconfigure-reply Message Format . . . . . . . . . . 23 18
9.8. DHCP Reconfigure-init Message Format . . . . . . . . . . 24 19
9.9. Relay-forward message . . . . . . . . . . . . . . . . . . 20
9.10. Server-forward message . . . . . . . . . . . . . . . . . 20
9.11. Identity association . . . . . . . . . . . . . . . . . . 21

10. DHCP Server Solicitation and Subnet Prefix Discovery 25 21
10.1. Solicit Message Validation . . . . . . . . . . . . . . . 25 21
10.2. Advertise Message Validation . . . . . . . . . . . . . . 25 21
10.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26 22
10.3.1. Creation and sending of the Solicit message . . . 26 22
10.3.2. Time out and retransmission of Solicit Messages . 27 22
10.3.3. Receipt of Advertise messages . . . . . . . . . . 27 23
10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 28 23
10.4.1. Relaying of Solicit messages . . . . . . . . . . 28 23
10.4.2. Relaying of Advertise messages . . . . . . . . . 28 24
10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28 24
10.5.1. Receipt of Solicit messages . . . . . . . . . . . 28 24
10.5.2. Creation and sending of Advertise messages . . . 29 24

11. DHCP Client-Initiated Configuration Exchange 29 25
11.1. Request Message Validation . . . . . . . . . . . . . . . 29 25
11.2. Reply Message Validation . . . . . . . . . . . . . . . . 30 26
11.3. Release Message Validation . . . . . . . . . . . . . . . 31 26
11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 26
11.4.1. Creation and sending of Request messages . . . . 32 27
11.4.2. Time out and retransmission of Request Messages . 33 27
11.4.3. Receipt of Reply message in response to a Request 33 28
11.4.4. Creation and sending of Release messages . . . . 33 28
11.4.5. Time out and retransmission of Release Messages . 34 29
11.4.6. Receipt of Reply message in response to a Release 35
11.5. Relay Behavior . 29
11.4.7. When a client should send a Request message . . . 29
11.4.8. Initialization . . . . . . . . . . . . . . . . . 35
11.5.1. Relaying 29
11.4.9. Confirming the validity of IPv6 addresses . . . . 29
11.4.10. Extending the lifetimes on IPv6 addresses . . . . 30
11.5. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 31
11.5.1. Relaying of Request or Release messages . . . . . 35 31
11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35 31
11.6.1. Receipt of Request messages . . . . . . . . . . . 35 31
11.6.2. Receipt of Release messages . . . . . . . . . . . 36 31
11.6.3. Creation and sending of Reply messages . . . . . 36 32

12. DHCP Server-Initiated Configuration Exchange 37 33
12.1. Reconfigure Message Validation . . . . . . . . . . . . . 37 33
12.2. Reconfigure-reply Message Validation . . . . . . . . . . 38 33
12.3. Reconfigure-init Message Validation . . . . . . . . . . . 38 33

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page iv]

Internet Draft DHCP for IPv6 22 November 2000

12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 38 33
12.4.1. Creation and sending of Reconfigure messages . . 39 34
12.4.2. Time out and retransmission of Reconfigure
messages . . . . . . . . . . . . . . . . . 40 34
12.4.3. Receipt of Reconfigure-reply messages . . . . . . 40 34
12.4.4. Creation and sending of Reconfigure-init messages 40

Bound, Carney, Perkins Expires 1 November 2000 [Page iii]

Internet Draft DHCP for IPv6 5 May 2000 34
12.4.5. Time out and retransmission of Reconfigure-init
messages . . . . . . . . . . . . . . . . . 41 35
12.4.6. Receipt of Request messages . . . . . . . . . . . 41 35
12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 41 35
12.5.1. Receipt of Reconfigure messages . . . . . . . . . 42
12.5.2. Creation and sending of Reconfigure-reply messages 42
12.5.3. Receipt of Reconfigure-init messages . . . . . . 43
12.5.4. 35
12.5.2. Creation and sending of Request messages . . . . 43
12.5.5. 36
12.5.3. Time out and retransmission of Request messages . 43
12.5.6. 36
12.5.4. Receipt of Reply messages . . . . . . . . . . . . 43 36

13. Using DHCP for network renumbering 43
13.1. Passive Renumbering . . . . . . . . . . . . . . . . . . . 44
13.2. Active Renumbering . . . . . . . . . . . . . . . . . . . 44 36

14. DHCP Client Implementator Implementor Notes 44 37
14.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 45 37
14.2. Advertise Message and Configuration Parameter Caching . . 45 37
14.3. Time out and retransmission variables . . . . . . . . . . 45 37
14.4. Server Preference . . . . . . . . . . . . . . . . . . . . 45 38

15. DHCP Server Implementator Implementor Notes 46 38
15.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 46 38
15.2. Reconfigure Reconfigure-init Considerations . . . . . . . . . . . . . . . 46 38
15.3. Server Preference . . . . . . . . . . . . . . . . . . . . 46 39
15.4. Request Message Transaction-ID Cache . . . . . . . . . . 47 39

16. DHCP Relay Implementator Implementor Notes 47 39

17. Open Issues for Working Group Discussion 47 39
17.1. Trade-offs: Optional fields in DHCP messages Authentication . . . . . . 47
17.2. Use DHCPv4 authentication or the current DHCPv6 method? . 48
17.3. The Reconfigure Message and Subnet Prefix Extensions . . 48
17.4. ``R'' bit in Request message not needed? . . . . . . . . 48

18. Security Considerations 48

19. Year . . . . 39
17.2. DHCP-DNS interaction . . . . . . . . . . . . . . . . . . 39
17.3. Release vs. Decline . . . . . . . . . . . . . . . . . . 40
17.4. Request messages . . . . . . . . . . . . . . . . . . . . 40
17.5. Use of term ``agent'' . . . . . . . . . . . . . . . . . . 40
17.6. Use of terms ``subnet'' and ``network'' . . . . . . . . . 40

18. Security 40

19. Year 2000 considerations 49 41

20. IANA Considerations 49 41

21. Acknowledgements 50

A. Comparison between DHCPv4 and DHCPv6 50

B. Full Copyright Statement 52

Chair's Address 55

Bound, Carney, Perkins Expires 1 November 2000 [Page iv]

Internet Draft Acknowledgments 41

22. DHCP for IPv6 5 May 2000

Author's Address 55 options 42
22.1. Format of DHCP options . . . . . . . . . . . . . . . . . 42

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page v]

Internet Draft DHCP for IPv6 5 May 22 November 2000

1. Introduction

This document describes DHCP for IPv6 (DHCP), a UDP [14] client /
server protocol designed to reduce the cost of management of IPv6
nodes in environments where network managers require more control
over the allocation of network resources more varied than that
offered by ``IPv6 Stateless Autoconfiguration'' [15]. The DHCP is a
stateful counterpart to stateless autoconfiguration. Note that both
stateful and stateless autoconfiguration can be used concurrently in
the same environment, leveraging the strengths of both mechanisms

22.2. Identity association option . . . . . . . . . . . . . . . 43
22.3. Option request option . . . . . . . . . . . . . . . . . . 44
22.4. Client message option . . . . . . . . . . . . . . . . . . 45
22.5. Server message option . . . . . . . . . . . . . . . . . . 45
22.6. Retransmission parameter option . . . . . . . . . . . . . 46
22.7. Authentication option . . . . . . . . . . . . . . . . . . 46

23. Changes in order to reduce the cost of ownership and management of network
nodes.

The DHCP reduces the cost of ownership by centralizing the management this draft 46
23.1. Order of network sections . . . . . . . . . . . . . . . . . . . . 47
23.2. Reconfigure message . . . . . . . . . . . . . . . . . . . 47
23.3. Releasable resources such as IP addresses, routing information, OS
installation information, directory service information, and other
such information on a few DHCP servers, rather than distributing such
information in local configuration files among each network node.
The . . . . . . . . . . . . . . . . . . 47
23.4. DHCP is designed to be easily extended to carry new configuration
parameters through the addition of new DHCP ``extensions'' message header . . . . . . . . . . . . . . . . . . . 47
23.5. Design goals . . . . . . . . . . . . . . . . . . . . . . 47
23.6. Overview . . . . . . . . . . . . . . . . . . . . . . . . 47
23.7. Message formats, 9 . . . . . . . . . . . . . . . . . . . 47
23.8. Solicit and Advertise messages, (section 10) . . . . . . 48
23.9. Prefix advertisement . . . . . . . . . . . . . . . . . . 48
23.10. Identity Associations . . . . . . . . . . . . . . . . . . 48
23.11. Extensions renamed options; defined to
carry this information. See in this document's companion specification,
``Extensions for the Dynamic Host Configuration Protocol for
IPv6'' [2] for specifications of existing extensions as well as
information on the process by which an interested party might specify
new extensions.

Those readers familiar with DHCP for IPv4 [7] will find DHCP for IPv6
provides a superset of features, and benefits from the additional
features of IPv6 and freedom from BOOTP [5]-backward compatibility
constraints. For more information about the differences between DHCP
for IPv6 and DHCP for IPv4, see Appendix A.

This document is organized as follows. Section 2 defines terminology
used throughout this document. Section 3 defines constant values
used by DHCP. Section 4 briefly discusses requirement levels.
Section 5 points the reader to helpful background specifications
covering related IPv6 protocols. Section 6 discusses the design
goals that influenced DHCP. Section 7 identifies some of the
non-goals of this specification. Section 8 gives a high level
overview of DHCP, its message types, and identifies DHCP functional
entities (client, relay, server). Section 9 describes in detail the
format of each DHCP message type. Section 10 discusses DHCP server
solicitation and subnet prefix discovery. Section 11 discusses DHCP
client-initiated configuration information exchange. Section 12
discusses DHCP server-initiated configuration information exchange.
Section 13 describes how DHCP can be used to renumber networks.
Section 14 presents helpful notes for DHCP client implementators.
Section 15 presents helpful notes for DHCP server implementors.

Bound, Carney, Perkins Expires 1 November 2000 [Page 1]

Internet Draft DHCP for IPv6 5 May 2000

Section 16 presents helpful notes for DHCP relay implementors.
Section 18 discusses security considerations for DHCP.
2. Terminology

2.1. IPv6 Terminology

IPv6 terminology relevant to this specification from the IPv6
Protocol [6], IPv6 Addressing Architecture [8], and IPv6 Stateless
Address Autoconfiguration [15] is included below.

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

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.

host Any node that is not a router.

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

interface
A node's attachment to a link.

link A communication facility or medium over which nodes
can communicate at the link layer, i.e., the layer
immediately below IP. Examples are Ethernet (simple or
bridged); Token Ring; PPP links, X.25, Frame Relay, or
ATM networks; and Internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself.

link-layer identifier
a link-layer identifier for an interface. Examples
include IEEE 802 addresses for Ethernet or Token Ring
network interfaces, and E.164 addresses for ISDN links.

link-local address
An IP address having link-only scope, indicated by
Bound, Carney, Perkins Expires 1 November 2000 [Page 2]

Internet Draft DHCP for IPv6 5 May 2000

having the subnet prefix (FE80::0000/64), that can be
used to reach neighboring nodes attached to the same
link. Every interface has a link-local address.

message A unit of data carried in a packet, exchanged between
DHCP agents and clients.

neighbor A node attached to the same link.

node A device that implements IP.

packet An IP header plus payload.

prefix A bit string that consists of some number of initial
bits of an address.

router A node that forwards IP packets not explicitly
addressed to itself.
2.2. DHCP Terminology

Terminology specific to DHCP can be found below.
abort status
A status value returned to the application that has
invoked a DHCP client operation, indicating anything
other than success.

agent address
The address of a neighboring DHCP Agent on the same
link as the DHCP client.

binding A binding (or, client binding) is a group of server
data records indexed by <client's link-local address,
subnet prefix> containing the releasable resource data
which a DHCP server has assigned to a client.

Note that the transaction-ID from the Request message
that produced the assignment of the releasable resource
is also stored in the server data record including the
releasable resource identifier.

DHCP Dynamic Host Configuration Protocol for IPv6. The
terms DHCPv4 and DHCPv6 are used only in contexts where
it is necessary to avoid ambiguity.
Bound, Carney, Perkins Expires 1 November 2000 [Page 3]

Internet Draft DHCP for IPv6 5 May 2000

configuration parameter
An element of the configuration information set on the
server and delivered to the client using DHCP. Such
parameters may be used to carry information to be used
by a node to configure its network subsystem and enable
communication on a link or internetwork, for example.

DHCP client (or client)
A node that initiates requests on a link to obtain
configuration parameters from one or more DHCP servers.

DHCP domain
A chunk of network topology managed by DHCP and
operated by a single administrative entity.

DHCP server (or server)
A server is a node that responds to requests from
clients, and may or may not be on the same link as the
client(s).

DHCP relay (or relay)
A node that acts as an intermediary to deliver DHCP
messages between clients and servers, and is on the
same link as a client.

DHCP agent (or agent)
Either a DHCP server on the same link as a client, or a
DHCP relay.

Releasable resource
Any configuration resource allocated by a server for
a finite period of time. As of this writing, the
only example of such a resource is the IP address.
Releasable resources are carried in extensions
allocated out of the 1--8192 range.

solicit-ID
An unsigned integer generated by the client and
inserted into its DHCP Solicit messages, and echoed
back to the client by the server in its resultant DHCP
Advertise message(s). The client uses the solicit-ID
to match received Advertise messages to Solicit
messages it has generated.

transaction-ID
An unsigned integer to match responses with replies
initiated either by a client or server. Servers
Bound, Carney, Perkins Expires 1 November 2000 [Page 4]

Internet Draft DHCP for IPv6 5 May 2000

allocate their transaction-IDs from the range of
0--1023, and clients allocate their transaction-IDs
from the range of 1024--65535. Limiting clients and
servers to different ranges prevents transaction-ID
collisions (e.g. client and server happen to use the
same transaction-ID for unrelated transactions (e.g.
client Request, server Reconfigure-init).
3. DHCP Constants

This section describes various program and networking constants used
by DHCP.
3.1. Multicast Addresses

The DHCP makes use of the following multicast addresses:

All DHCP Agents address: FF02::1:2
This link-local multicast address is used by clients to
communicate with the on-link agent(s) when they do not
know those agents' link-local address(es). All agents
(servers and relays) are members of this multicast
group.

All DHCP Servers address: FF05::1:3
This site-local multicast address is used by clients or
relays to communicate with server(s), either because
they want to send messages to all servers or because
they do not know the server(s) unicast address(es).
Note that in order for a client to use this address,
it must have an address of sufficient scope to be
reachable by the server(s). All servers within the
site are members of this multicast group.
3.2. UDP ports

The DHCP uses the following destination UDP [14] port numbers. While
source ports MAY be arbitrary, client implementations SHOULD permit
their specification through a local configuration parameter to
facilitate the use of DHCP through firewalls.

546 Client port. Used by agents to send messages to
clients. Also used by servers to send messages to
relays.
Bound, Carney, Perkins Expires 1 November 2000 [Page 5]

Internet Draft DHCP for IPv6 5 May 2000

547 Agent port. Used by clients to send messages to
agents. Also used by relays to send messages to
servers.
3.3. DHCP message types

The DHCP defines the following message types. More detail on these
message types can be found in Section 9. Message types 0 and 9--255
are reserved and MUST be silently ignored.

01 DHCP Solicit

The DHCP Solicit (or Solicit) message is used by clients to
locate servers and (optionally) learn about the subnet prefixes
on the client's link for networks that are managed by DHCP.
This message is multicast using the All-DHCP-Agents address.
Relay(s) forward Solicits as necessary to off-link servers.

Section 9.1 contains more details about the Solicit message.

02 DHCP Advertise

The DHCP Advertise (or Advertise) message is used by servers
responding to Solicits. This message is unicast to the
client's link-local address (if the server and client are
on the same link) or unicast to the relay through which the
Solicit was sent for final delivery to the client.

Section 9.2 contains more details about the Advertise message.

03 DHCP Request

The DHCP Request (or Request) message is used by clients to
request configuration parameters from servers. This message
is unicast to the server if the client has an address with
sufficient scope to be reachable by the server, otherwise it
is unicast to the on-link relay through which the Advertise
message was relayed.

Section 9.3 contains more details about the Request message.

04 DHCP Reply

The DHCP Reply (or Reply) message is used by servers responding
to Request and Release messages. In the case of responding to
a Request message, the Reply contains configuration parameters
destined for the client. This message is unicast to the client
if the client has an address of sufficient scope that is
Bound, Carney, Perkins Expires 1 November 2000 [Page 6]

Internet Draft DHCP for IPv6 5 May 2000

reachable by the server. Otherwise, it is unicast to the relay
through which the Request or Release message was sent for final
delivery to the client.

Section 9.4 contains more details about the Reply message.

05 DHCP Release

The DHCP Release (or Release) message is used by clients to
return one or more instances of releasable resources (e.g. IP
addresses) to servers. This message is unicast to the server
if the client will have an address of sufficient scope after
the Release operation to receive a Reply message. Otherwise,
the Release message is sent through the relay. The server will
acknowledge the receipt of the Release message by sending the
client a Reply message.

Section 9.5 contains more details about the Release message.

06 DHCP Reconfigure

The DHCP Reconfigure (or Reconfigure) message is sent by
servers to client(s). It contains new or updated configuration
parameters for use by the client(s). This message may be
unicast or multicast to the client(s).

Section 9.6 contains more details about the Reconfigure
message.

07 DHCP Reconfigure-reply

The DHCP Reconfigure-reply (or Reconfigure-reply) message is
unicast by client(s) to the server to acknowledge the receipt
of a Reconfigure message.

Section 9.7 contains more details about the Reconfigure-reply
message.

08 DHCP Reconfigure-init

The DHCP Reconfigure-init (or Reconfigure-init) message is set
by server(s) to inform client(s) that the server(s) has new or
updated configuration parameters, and that the client(s) are
to initiate a Request/Reply transaction with the server(s) in
order to receive the updated information.

Section 9.8 contains more details about the Reconfigure-init
message.

Bound, Carney, Perkins Expires 1 November 2000 [Page 7]

Internet Draft DHCP for IPv6 5 May 2000

3.4. Error Values

This section describes error values exchanged between DHCP
implementations.
3.4.1. Generic Error Values

The following symbolic names are used between client and server
implementations to convey error conditions. The following table
contains the actual numeric values for each name. Note that the
numeric values do not start at 1, nor are they consecutive. The
errors are organized in logical groups.

3.4.2. Server-specific Error Values

3.5. Configuration Variables

This section presents a table of client and server configuration
variables and the default or initial values for these variables. The
client-specific variables MAY be configured on the server and MAY be
delivered to the client through the ``DHCP Retransmission Parameter
Extension''carried in a Reply message. This extension is documented
in the ``extensions document'' [2].

Bound, Carney, Perkins Expires 1 November 2000 [Page 8]

4. Requirements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [3].

This document also makes use of internal conceptual variables
to describe protocol behavior and external variables that an
implementation must allow system administrators to change. The
specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demostrate
protocol behavior. An implementation is not required to have them in
the exact form described here, so long as its external behavior is
consistent with that described in this document.
5. Background

Related work in IPv6 that would best serve an implementor to study
is the IPv6 Specification [6], the IPv6 Addressing Architecture [8],
IPv6 Stateless Address Autoconfiguration [15], IPv6 Neighbor
Discovery Processing [12], and Dynamic Updates to DNS [17]. These
specifications enable DHCP 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 DHCP implementors to understand is that IPv6
requires that every link in the Internet have an MTU of 1280 octets
or greater (in IPv4 the requirement is 68 octets). This means that
a UDP packet of 536 octets will always pass through an internetwork

Bound, Carney, Perkins Expires 1 November 2000 [Page 9]

Internet Draft DHCP for IPv6 5 May 2000

(less 40 octets for the IPv6 header), as long as there are no IP
options prior to the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a
packet greater than 1500 octets it can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [10]
to determine the size of the packet that will traverse a network
path.

DHCP clients use Path MTU discovery when they have an address of
sufficient scope to reach the DHCP server. If a DHCP client does not
have such an address, that client MUST fragment its packets if the
resultant message size is greater than the minimum 1280 octets.

Path MTU Discovery for IPv6 is supported for both UDP and TCP and
can cause end-to-end fragmentation when the PMTU changes for a
destination.

The IPv6 Addressing Architecture specification [8] defines 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 are that support
for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin
communications to discover neighbors on the link. For instance, a
client can send a Solicit message and locate a server or relay.

IPv6 Stateless Address Autoconfiguration [15] (Addrconf) specifies
procedures by which a node may autoconfigure addresses based on
router advertisements [12], and the use of a valid lifetime to
support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. The DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with addrconf is a design
requirement of DHCP (see Section 6).

IPv6 Neighbor Discovery [12] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [13]. To understand
IPv6 and Addrconf it is strongly recommended that implementors
understand IPv6 Neighbor Discovery.

Dynamic Updates to DNS [17] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space
to not only support autoconfiguration, but also autoregistration
in IPv6. The security model to be used with DHCPv6 should conform
as closely as possible to the authentication model outlined in
RFC2402 [9].
Bound, Carney, Perkins Expires 1 November 2000 [Page 10]

Internet Draft DHCP for IPv6 5 May 2000

6. Design Goals

- DHCP is a mechanism rather than a policy. Network administrators
set their administrative policies through the configuration
parameters they place upon the DHCP servers in the DHCP domain
they're managing. DHCP is simply used to deliver parameters
according to that policy to each of the DHCP clients within the
domain.

- DHCP is compatible with IPv6 stateless autoconf [15].

- DHCP does not require manual configuration of network parameters
on DHCP clients, except in cases where such configuration is
needed for security reasons. A node configuring itself using
DHCP should require no user intervention.

- DHCP does not require a server on each link. To allow for scale
and economy, DHCP must work across DHCP relays.

- DHCP coexists with statically configured, non-participating nodes
and with existing network protocol implementations.

- DHCP clients can operate on a link without IPv6 routers present.

- DHCP will provide the ability to renumber network(s) when
required by network administrators [4].

- A DHCP client can make multiple, different requests for
configuration parameters when necessary from one or more DHCP
servers at any time. DHCP will provide enough information
to enable a DHCP server to keep track of a DHCP client's
configuration state.

- DHCP will contain the appropriate time out and retransmission
mechanisms to efficiently operate in environments with high
latency and low bandwidth characteristics.
7. Non-Goals

This specification explicitly does not cover the following:

- Specification of a DHCP server to server protocol.

- How a DHCP server stores its DHCP data.

- How to manage a DHCP domain or DHCP server.
Bound, Carney, Perkins Expires 1 November 2000 [Page 11]

Internet Draft DHCP for IPv6 5 May 2000

- How a DHCP relay is configured or what sort of information it may
log.
8. Overview

This section provides a general overview of the interaction
between the functional entities of DHCP. The overview is organized
as a series of questions and answers. Details of DHCP such
as message formats and retransmissions are left to sections 9,
10, 11, 12, 14, 15, and 16.
8.1. How does a node know to use DHCP?

An unconfigured node determines that it is to use DHCP for
configuration of an interface by detecting the presence (or absence)
of routers on the link. If router(s) are present, the node examines
router advertisements to determine if DHCP should be used to
configure the interface. If there are no routers present, then
the node MUST use DHCP to configure the interface. Detail on
this process can be found in neighbor discovery [12] and stateless
autoconfiguration [15].
8.2. How does a client find out about DHCP agents?

The client forms a Solicit message, and multicasts it to the
FF02::1:2(All DHCP Agents) address. Server(s) receiving the Solicit
respond with Advertise message(s). If requested in the client's
Solicit message, the Advertise message(s) can include one or more
subnet prefix extensions [2], informing the client of subnet prefixes
for the networks(s) managed by the server(s) on the client's link.
Now that the client knows the IP address(es) of agents(s) on the
link, it can request configuration parameters from servers.
8.3. What if the client and server(s) are on different links?

Use of DHCP in such environments requires one or more DHCP relays
be set up on the client's link, because a client may only have a
link-local address. Relays pick up the Solicit and Request messages
from the client and forward them to some set of servers within the
DHCP domain. A relay will include one of its own addresses (of
sufficient scope) of the interface on the same link as the client.
The relay also includes the subnet prefix length of that address
in the client's messages. Servers receiving the forwarded traffic
use this information to aid in selecting configuration parameters
appropriate to the client's link. The servers also use the relay's
Bound, Carney, Perkins Expires 1 November 2000 [Page 12]

Internet Draft DHCP for IPv6 5 May 2000

address as the destination to forward client-destined messages
for final delivery by the relay. Relays forward client messages
to servers using some combination of the FF05::1:3(All Servers)
site-local multicast address, some other (perhaps a combination)
of site-local multicast addresses set up within the DHCP domain to
include the servers in that domain, or a list of unicast addresses
for servers. The network administrator makes relay configuration
decisions based upon the topological requirements (scope) of the
DHCP domain they are managing. Note that if the DHCP domain spans
more than the site-local scope, then the relays MUST be configured
with global addresses for the client's link so as to be reachable by
servers outside the relays' site-local environment.
8.4. How does a client request configuration parameters from servers?

To request configuration parameters, the client forms a Request
message, and sends it to the server either directly (client has an
address of sufficient scope) or indirectly (through the on-link
relay). The client MAY include a Extension Request Extension [2]
along with other extensions to request specific information from the
server. Note that the client MAY form multiple Request messages
and send each of them to different servers to request potentially
different information (perhaps based upon what was advertised) in
order to satisfy its needs. As a client's needs may change over time
(perhaps based upon an application's requirements), the client may
form additional Request messages to request additional information as
it is needed.

The server(s) respond with Reply messages containing the requested
configuration parameters, which can include status information
regarding the information requested by the client. The Reply MAY
also include additional information, such as a reconfiguration event
multicast group for the client to join to monitor reconfiguration
events, as described in section 8.8.

The receipt of a Reply from a server concludes the basic
request/reply transaction of the protocol.
8.5. What are releasable resources, . . 48
23.12. Transaction-ID ranges . . . . . . . . . . . . . . . . . . 48
23.13. Release messages and when are they used?

A releasable resource is configuration information leased to a client
by a server for some finite period of time. When negotiating for a
releasable resource, the client relays . . . . . . . . . . . . . . . 48
23.14. Discovering relay agents . . . . . . . . . . . . . . . . 48

A. Comparison between DHCPv4 and server agree upon a finite period
of time the client may use the resource. The client MAY request a
renewal of the lease on the resource at any time. The length of time
of the lease (and whether it is renewable) are server-based policy
tunables. The client MUST stop using the resource when the lease on DHCPv6 49

B. Full Copyright Statement 51

Chair's Address 54

Author's Address 54

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 13] vi]

Internet Draft DHCP for IPv6 5 May 22 November 2000

the resource expires. The server MUST NOT reallocate an assigned
resource before either its lease expires or the client releases the
resource.

See the ``extensions document'' [2]

1. Introduction

This document describes DHCP for more information about
releasable resources.
8.6. Can IPv6 (DHCP), a UDP [13] client release its releasable resources before
/ server protocol designed to reduce the lease
expires?

A client forms a Release message, including extensions carrying cost of management of
IPv6 nodes in environments where network managers require more
control over the
resource(s) allocation of IPv6 addresses and configuration
of network stack parameters than that offered by ``IPv6 Stateless
Autoconfiguration'' [14]. DHCP is a stateful counterpart to
stateless autoconfiguration. Note that both stateful and stateless
autoconfiguration can be released. The client sends the Release to used concurrently in the
server which leased same environment,
leveraging the resource(s) strengths of both mechanisms in order to reduce the client initially. If that
server cannot be reached after a certain number
cost of attempts (see
section 3.5), the client can abandon the Release attempt. In this
case, ownership and management of network nodes.

DHCP reduces the resource(s) will be reclaimed cost of ownership by centralizing the server(s) when the
client's lease(s) expire.
8.7. What if the client determines its releasable resource management
of network resources such as IP addresses, routing information, OS
installation information, directory service information, and other
such information on a few DHCP servers, rather than distributing such
information in local configuration files among each network node.
DHCP is already
being used by another client?

If the client determines designed to be easily extended to carry new configuration
parameters through a releasable resource-specific
manner that the resource it was assigned by the server is already addition of new DHCP ``options'' defined to
carry this information. (What were called ``extensions'' in use by another client, the client -15
draft are now called ``options''; see section 23.11.)

Those readers familiar with DHCP for IPv4 [6] will form find DHCP for IPv6
provides a Release message,
including the extension carrying the in-use resource. The
extension's status field MUST be set to the extension-specific value
reflecting the ``in use'' status superset of features, and benefits from the resource. additional
features of IPv6 and freedom from BOOTP [4]-backward compatibility
constraints. For example, if more information about the releasable resource differences between DHCP
for IPv6 and DHCP for IPv4, see Appendix A.

This document is an IP address, organized as follows. Section 2 defines terminology
used throughout this document. Section 3 defines constant values
used by DHCP. Section 4 briefly discusses requirement levels.
Section 5 points the client
uses Duplicate Address Detection (DAD) reader to verify that the IP address
is not in use. If helpful background specifications
covering related IPv6 protocols. Section 6 discusses the client determines design
goals that influenced DHCP. Section 7 identifies some of the IP address is
already in use, it forms
non-goals of this specification. Section 8 gives a Release high level
overview of DHCP, its message including the IP address
extension containing the appropriate status value types, and sends it to the
server. See the ``extensions document''for details on identifies DHCP functional
entities (client, relay, server). Section 9 describes in detail
the IP address
extension. [2].
8.8. How are clients notified format of each DHCP message type. Section 10 discusses DHCP
server configuration changes?

There are two possibilities. Either the clients discover the new
information when they revisit the server(s) to request additional solicitation. Section 11 discusses DHCP client-initiated
configuration information / renew the lease on a releasable resource,
or through a server-initiated event known as a reconfigure event.

The reconfiguration feature of exchange. Section 12 discusses DHCP offers network administrators
the opportunity to update
server-initiated configuration information on exchange. Section 14
presents helpful notes for DHCP clients
whenever necessary. If client implementors. Section 15
presents helpful notes for DHCP server implementors. Section 16
presents helpful notes for DHCP relay implementors. Section 18
discusses security considerations for DHCP.

Section 23 describes the information to be updated is not changes between this version of the DHCPv6
specification and draft-ietf-dhc-dhcpv6-15.txt.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 14] 1]

Internet Draft DHCP for IPv6 5 May 22 November 2000

client-specific, the server will form a Reconfigure message and add
the new or changed configuration information

2. Terminology

2.1. IPv6 Terminology

IPv6 terminology relevant to it. The Reconfigure
may be unicast this specification from the IPv6
Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless
Address Autoconfiguration [14] is included below.

address An IP layer identifier for an interface or multicast (to a preassigned multicast set of
interfaces.

unicast address
An identifier for
this purpose) to one or more client(s) a single interface. A packet sent
to which the new or updated
information needs a unicast address is delivered to be directed. The client(s) will acknowledge the
receipt of the Reconfigure message interface
identified by forming that address.

multicast address
An identifier for a Reconfigure-reply
message and unicasting it set of interfaces (typically
belonging to the server. If the configuration
information change is different for each client (e.g. nodes). A packet sent to a change in
subnet prefix, perhaps, which would affect the IP
multicast address releasable
resource(s)), the server will form is delivered to all interfaces
identified by that address.

host Any node that is not a Reconfigure-init message router.

IP Internet Protocol Version 6 (IPv6). The terms IPv4 and
unicast / multicast as needed
IPv6 are used only in contexts where it is necessary to the client(s).
avoid ambiguity.

interface
A Reconfigure-init
is a trigger which will cause the client(s) node's attachment to initiate a standard
Request/Reply exchange with link.

link A communication facility or medium over which nodes
can communicate at the server in order to acquire link layer, i.e., the new layer
immediately below IP. Examples are Ethernet (simple or
bridged); Token Ring; PPP links, X.25, Frame Relay, or
ATM networks; and Internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself.

link-layer identifier
a link-layer identifier for an interface. Examples
include IEEE 802 addresses for Ethernet or
updated resources.
9. Message Formats

All reserved fields in a message MUST be transmitted as zeroes Token Ring
network interfaces, and
ignored by the receiver of the message.
9.1. DHCP Solicit Message Format

A client multicasts a DHCP Solicit message to the FF02::1:2(All DHCP
agents) E.164 addresses for ISDN links.

link-local address over
An IP address having link-only scope, indicated by
having the interface to prefix (FE80::0000/64), that can be configured to locate one or
more servers which are configured to provide configuration parameters used
to reach neighboring nodes on attached to the client's same link.

Unless otherwise noted, the value of all fields are set by the
client.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 1 |C|P| reserved | prefix-len | solicit-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's
Every interface has a link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C If set, the client requests that all servers receiving
the message deallocate the releasable resources (e.g.
IP addresses) associated with the client's binding. address.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 15] 2]

Internet Draft DHCP for IPv6 5 May 22 November 2000

P If set, the client requests that all servers receiving
the

message SHOULD return a list A unit of subnet prefix
extensions identifying the networks on data carried in a packet, exchanged between
DHCP agents and clients.

neighbor A node attached to the client's
link same link.

node A device that the server(s) are configured to manage.

reserved 0

prefix-len implements IP.

packet An unsigned 7 IP header plus payload.

prefix A bit number (0-127) non-zero prefix-len is
the string that consists of some number of leftmost initial
bits of the agent's IPv6 address
which make up the subnet prefix. The prefix-len field
is set by the relay if the relay receives the Solicit
message and an address.

router A node that forwards it IP packets not explicitly
addressed to itself.

2.2. DHCP Terminology

Terminology specific to DHCP can be found below.

abort status
A status value returned to one or more servers.

solicit-ID
An unsigned 9 bit number (0-511) generated by the application that has
invoked a DHCP client used to identify this Solicit message.

client's link-local operation, indicating anything
other than success.

agent address
The IP link-local address of the client interface
through which the client will issue the Solicit
message.

relay-address
Set by the client to be zero. If received by a relay,
set by the relay to the site-local IP address of the
interface neighboring DHCP Agent on which the relay received the client's
Solicit message. Note that if same
link as the DHCP domain crosses
site boundaries, the relay MUST place a globally-scoped
address in this field. client.

binding A binding (or, client MUST send the Solicit message to the All-DHCP-Agents
multicast group (see section 3.1), setting the relay-address to zero.
9.2. DHCP Advertise Message Format

A server sends an Advertise message in response to binding) is a client's
Solicit message. The Advertise message notifies the client group of the
server's IP address. If the server is so configured
data records indexed by <prefix, UUID> containing the network
administrator and the client requests it through the ``P'' bit in
its Solicit message,
server's information about the server SHOULD add a list of subnet prefix
extensions addresses and other
information assigned to the Advertise message IA.

DHCP Dynamic Host Configuration Protocol for IPv6. The
terms DHCPv4 and DHCPv6 are used only in contexts where
it is necessary to notify the client avoid ambiguity.

configuration parameter

An element of the
networks it manages configuration information set on the client's link.

When
server and delivered to the client using DHCP. Such
parameters may be used to carry information to be used
by a node to configure its network subsystem and server are enable
communication on different links, the server sends
the Advertise message back through the relay whence the corresponding
Solicit came. The solicit-ID is copied from the client's Solicit a link or internetwork, for example.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 16] 3]

Internet Draft DHCP for IPv6 5 May 22 November 2000

Message. The value of all fields in the Advertise message are filled
in by the server and not changed in any way by any intervening relay.

solicit-ID An unsigned 9 bit number (0-511) used

DHCP client (or client)
A node that initiates requests on a link to identify
this Advertise message. Copied obtain
configuration parameters from the client's
Solicit message.

preference An octet (unsigned) indicating one or more DHCP servers.

DHCP domain
A chunk of network topology managed by DHCP and
operated by a server's willingness
to provide service single administrative entity.

DHCP server (or server)
A server is a node that responds to the client.

client's link-local address
The IP link-local address of the client interface requests from which the client issued
clients, and may or may not be on the Solicit message.

relay-address
The IP address of same link as the
client(s).

DHCP relay interface (or relay)
A node that acts as an intermediary to deliver DHCP
messages between clients and servers, and is on the
same link as the a client. Copied from the client's
Solicit. If the

DHCP agent (or agent)
Either a DHCP server is on the same link as the a client, then this field MUST be zero.

server-address
The site-local IP address or a
DHCP relay.

Identity association (IA)
A collection of addresses assigned to a client. Each
IA has an associated UUID. A server identifies an IA by
the tuple (prefix, UUID), where ``prefix'' is a prefix
assigned to the link to which the client is attached,
An IA may have 0 or more addresses associated with it.

Releasable resource
(Removed; see section 23.3.)

transaction-ID
An unsigned integer to match responses with replies
initiated either by a client or server. If

UUID
A universally unique identifier for a client.

DISCUSSION:

Rules for choosing a UUID are TBD.

3. DHCP Constants

This section describes various program and networking constants used
by DHCP.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 4]

Internet Draft DHCP for IPv6 22 November 2000

3.1. Multicast Addresses

DHCP makes use of the following multicast addresses:

All DHCP
domain crosses site boundaries, then Agents address: FF02::1:2
This link-local multicast address is used by clients to
communicate with the on-link agent(s) when they do not
know those agents' link-local address(es). All agents
(servers and relays) are members of this multicast
group.

All DHCP Servers address: FF05::1:3
This site-local multicast address
MUST be globally-scoped.

extensions See the ``extensions document'' for details [2].

See Sections 14.4 and 15.3 for information about how is used by clients and or
relays to communicate with server(s), either because
they want to send messages to all servers handle or because
they do not know the preference field.
Bound, Carney, Perkins Expires 1 November 2000 [Page 17]

Internet Draft DHCP server(s) unicast address(es).
Note that in order for IPv6 5 May 2000

9.3. DHCP Request Message Format

A client sends a Request message to request configuration parameters
from a server. It MAY append appropriate extensions [2].

When a client reboots, to use this address,
it often does not must have a valid IP an address of sufficient scope for the server to communicate with be
reachable by the client. In
such cases, server(s). All servers within the
site are members of this multicast group.

3.2. UDP ports

DHCP uses the following destination UDP [13] port numbers. While
source ports MAY be arbitrary, client MUST NOT unicast implementations SHOULD permit
their specification through a local configuration parameter to
facilitate the use of DHCP through firewalls.

546 Client port. Used by agents to send messages to
clients. Also used by servers to send messages to
relays.

547 Agent port. Used by clients to send messages to
agents. Also used by relays to send messages to
servers.

3.3. DHCP message types

DHCP defines the following message types. More detail on these
message types can be found in Section 9. Message types 0 and 9--255
are reserved and MUST be silently ignored.

01 DHCP Solicit

The DHCP Solicit (or Solicit) message is used by clients
to locate servers. This message is multicast using the server
because the server could not return a response

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 5]

Internet Draft DHCP for IPv6 22 November 2000

All-DHCP-Agents address. Relay(s) forward Solicits as
necessary to off-link servers.

Section 9.1 contains more details about the client. Solicit message.

02 DHCP Advertise

The
client MUST send the DHCP Advertise (or Advertise) message to the server indirectly, is used by using the
on-link relay. The client MUST fill in servers
responding to Solicits. This message is unicast to the relay
client's link-local address field with (if the on-link relay's IP address.

If server and client are
on the Request message is being formed in response same link) or unicast to a
Reconfigure-init message from the server, then relay through which the transaction ID
used must be copied from
Solicit was sent for final delivery to the Reconfigure-init.

All fields in client.

Section 9.2 contains more details about the Advertise message.

03 DHCP Request

The DHCP Request (or Request) message are entered is used by clients to
request configuration parameters from servers. This message is
multicast using the client.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 3 |C|R| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C If set, the client requests the server to remove
all releasable resources associated with the client
binding, except those releasable resources provided All-DHCP-Agents address. Relay(s) forward
Requests as
extensions.

R If set, necessary to off-link servers.

Section 9.3 contains more details about the client has rebooted Request message.

04 DHCP Reply

The DHCP Reply (or Reply) message is used by servers responding
to Request and requests that Release messages. In the
server clear any transaction-ID cache entries case of responding to
a Request message, the Reply contains configuration parameters
destined for the client.

reserved 0
Bound, Carney, Perkins Expires 1 November 2000 [Page 18]

Internet Draft DHCP for IPv6 5 May 2000

transaction-ID
An unsigned integer identifier used This message is unicast to identify this
request.

client's link-local address
The link-local address of the client interface from
which
if the client will issue the Request message.

relay-address
The IP has an address of a relay's interface, copied from an
Advertise message. If sufficient scope that is
reachable by the server server. Otherwise, it is on unicast to the same link
as relay
through which the client, then this field MUST BE zero.

server-address Request or Release message was sent for final
delivery to the client.

Section 9.4 contains more details about the Reply message.

05 DHCP Release

The DHCP Release (or Release) message is used by clients to
return one or more IP address addresses to servers. The server will
acknowledge the receipt of the server to which Release message by sending the
client a Reply message.

Section 9.5 contains more details about the client's
Request Release message.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 6]

Internet Draft DHCP for IPv6 22 November 2000

06 DHCP Reconfigure

07 DHCP Reconfigure-reply

Removed; see section 23.2.

08 DHCP Reconfigure-init

The DHCP Reconfigure-init (or Reconfigure-init) message is directed, copied from an Advertise
message.

extensions
See the ``extensions document'' [2].

A DHCP client selects set
by server(s) to inform client(s) that the transaction-ID from server(s) has new or
updated configuration parameters, and that the range of
1024--65535 used client(s) are
to identify its Request. In contrast, initiate a
transaction-ID from Request/Reply transaction with the range of 0--1023is selected by a DHCP server server(s) in
order to identify a Reconfigure-init. In the latter case, receive the transaction
ID from updated information.

Section 9.8 contains more details about the Reconfigure-init is copied by the client into its Request
message.

When the

3.4. Error Values

This section describes error values exchanged between DHCP
implementations.

3.4.1. Generic Error Values

The following symbolic names are used between client sets the `C' bit and adds extensions documenting
the releasable resources the client wishes to keep, the server is
expected
implementations to deallocate all other releasable resources not listed. convey error conditions. The server SHOULD examine following table
contains the included extensions to check whether actual numeric values for each name. Note that the client is still authorized to use them.
9.4. DHCP Reply Message Format

A server sends a Reply message
numeric values do not start at 1, nor are they consecutive. The
errors are organized in response logical groups.

_______________________________________________________________
|Error_Name___|Error_ID|_Description_________________________|_
|Success______|00______|_Success_____________________________|_
|UnspecFail___|16______|_Failure,_reason_unspecified_________|_
|AuthFailed___|17______|_Authentication_failed_or_nonexistent|_
|PoorlyFormed_|18______|_Poorly_formed_message_______________|_
|Unavail______|19______|_Addresses_unavailable_______________|_

3.4.2. Server-specific Error Values

The following symbolic names are used by server implementations to a client's Request
message or Release message.

If a Request message is received which
convey error conditions to clients. The following table contains a non-zero relay
address field, then the
actual numeric values for each name.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 7]

Internet Draft DHCP for IPv6 22 November 2000

_______________________________________________________________
|Error_Name____|Error_ID|_Description________________________|_
|NoBinding_____|20______|_Client_record_(binding)_unavailable|_
|InvalidSource_|21______|_Invalid_Client_IP_address__________|_
|NoServer______|23______|_Relay_cannot_find_Server_Address___|_
|ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_

3.5. Configuration Variables

This section presents a table of client could not unicast and server configuration
variables and the Request message
to default or initial values for these variables. The
client-specific variables MAY be configured on the server and thus had MAY be
delivered to use a on-link relay. In that case, the
server unicasts client through the ``DHCP Retransmission Parameter
Option'' in a Reply message message. This option is TBD.

______________________________________________________________
|Parameter__________|Default|_Description___________________|_
|MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg__|_
|MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg__|_
|ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)_____|_
|ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)________|_
|SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)__|_
|REP_MSG_TIMEOUT____|250____|_REQ_Retrans_timer_(msecs)_____|_
|REQ_MSG_ATTEMPTS___|10_____|_MAX_Request_attempts__________|_
|REL_MSG_ATTEMPTS___|5______|_MAX_Release_attempts__________|_
|RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)_________|_
|REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts__________|_
|REC_REP_MIN________|5______|_Minimum_pause_interval_(secs)_|_
|REC_REP_MAX________|7200___|_Maximum_pause_interval_(secs)_|_
|REC_THRESHOLD______|100____|_%_of_required_clients_________|_
|SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)|_

4. Requirements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to the relay address found be interpreted as described in the
Request message.

If a Release message [2].

This document also makes use of internal conceptual variables
to describe protocol behavior and external variables that an
implementation must allow system administrators to change. The
specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demonstrate
protocol behavior. An implementation is received which contains a non-zero relay
address field, then the client will not have an IP address of
sufficient scope after the Release required to receive have them in
the Reply message. In exact form described here, so long as its external behavior is
consistent with that described in this document.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 19] 8]

Internet Draft DHCP for IPv6 5 May 22 November 2000

this case, the server unicasts the Reply message

5. Background

Related work in IPv6 that would best serve an implementor to study
is the relay address
found in IPv6 Specification [5], the Release message.

All IPv6 Addressing Architecture [7],
IPv6 Stateless Address Autoconfiguration [14], IPv6 Neighbor
Discovery Processing [11], and Dynamic Updates to DNS [16]. These
specifications enable DHCP to build upon the fields in 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 DHCP Reply message are set by implementors to understand is that IPv6
requires that every link in the DHCP server.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 4 |R| status | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay-address (if present) |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R If set, Internet have an MTU of 1280 octets
or greater (in IPv4 the ``relay-address'' field requirement is present.

status 68 octets). This 7-bit field contains one means that
a UDP packet of 536 octets will always pass through an internetwork
(less 40 octets for the values in IPv6 header), as long as there are no IP
options prior to the
errors table UDP header in section 3.4.

transaction-ID
Copied from the client's Request or Release.

client's link-local address
Copied from packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a
packet greater than 1500 octets it can either fragment the client's Request UDP packet
into fragments of 1500 octets or Release message.

relay-address
The IP less, or use Path MTU Discovery [9]
to determine the size of the packet that will traverse a network
path.

DHCP clients use Path MTU discovery when they have an address of a relay's interface, copied from
sufficient scope to reach the
Request or Release message. DHCP server. If a DHCP client does not
have such an address, that client MUST fragment its packets if the server
resultant message size is on greater than the
same link as minimum 1280 octets.

Path MTU Discovery for IPv6 is supported for both UDP and TCP and
can cause end-to-end fragmentation when the client, then PMTU changes for a
destination.

The IPv6 Addressing Architecture specification [7] defines the ``R'' bit is not set
address scope that can be used in an IPv6 implementation, and this field the
various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is not present.

extensions
See required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin
communications to discover neighbors on the ``extensions document'' [2].
9.5. DHCP Release Message Format

A link. For instance, a
client sends can send a Release Solicit message to and locate a server when it wishes to return
one or more releasable resources to the server relay.

IPv6 Stateless Address Autoconfiguration [14] (Addrconf) specifies
procedures by which allocated
them. This can occur either because the client no longer needs the
resource(s) or the client has determined through a resource-specific
manner that node may autoconfigure addresses based on
router advertisements [11], and the resource(s) are already in use of a valid lifetime to
support renumbering of addresses on the Internet. In addition the
protocol interaction by different which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 20] 9]

Internet Draft DHCP for IPv6 5 May 22 November 2000

client(s). The client communicates the reason for the premature
release

stateful autoconfiguration. Compatibility with addrconf is a design
requirement of DHCP (see Section 6).

IPv6 Neighbor Discovery [11] is the resource node discovery protocol in the status field IPv6
which replaces and enhances functions of the resource's
extension. See ``extensions document'' [2] for more details.

When a client sends a Release message, ARP [12]. To understand
IPv6 and Addrconf it needs to have a valid IP
address with sufficient scope is strongly recommended that implementors
understand IPv6 Neighbor Discovery.

Dynamic Updates to allow access by the target server.
If such an address DNS [16] is not available, a relay is used. Only those
releasable resources identified by extensions are released. If no
extensions are included in the Release message, then all releasable
resources associated with specification that supports the client's binding are to be released.

The values of all fields
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the Release message are set by the
client. The DHCP server acknowledges the Release message by sending
a Reply message.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 5 |R| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R If set, the ``X-address'' field contains the address of
relay. If dynamic updates to DNS to integrate addresses and name space
to not set, only support autoconfiguration, but also autoregistration
in IPv6. The security model to be used with DHCPv6 should conform
as closely as possible to the ``X-address'' field contains authentication model outlined in
RFC2402 [8].

6. Design Goals

- DHCP is a
non-local scope client address.

reserved 0

transaction-ID
An unsigned integer identifier mechanism rather than a policy. Network administrators
set their administrative policies through the configuration
parameters they place upon the DHCP servers in the DHCP domain
they're managing. DHCP is simply used to identify this
Release message.

client's link-local address
The client's link-local address for deliver parameters
according to that policy to each of the interface
from which DHCP clients within the client issued
domain.

- DHCP is compatible with IPv6 stateless autoconf [14].

- DHCP does not require a server on each link. To allow for scale
and economy, DHCP must work across DHCP relays.

- DHCP coexists with statically configured, non-participating nodes
and with existing network protocol implementations.

- DHCP clients can operate on a link without IPv6 routers present.

- DHCP will provide the Release message (and ability to which the releasable resources are bound renumber network(s) when
required by network administrators [3].

- A DHCP client can make multiple, different requests for
configuration parameters when necessary from one or more DHCP
servers at the
server). any time.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 21] 10]

Internet Draft DHCP for IPv6 5 May 22 November 2000

server-address
The IP address of the server which allocated the
resource.

X-address
If the ``R'' bit is set,

- DHCP will contain the ``X-address'' field
contains appropriate time out and retransmission
mechanisms to efficiently operate in environments with high
latency and low bandwidth characteristics.

7. Non-Goals

This specification explicitly does not cover the IP address following:

- Specification of the a DHCP server to server protocol.

- How a DHCP server stores its DHCP data.

- How to manage a DHCP domain or DHCP server.

- How a DHCP relay interface on the
same link as is configured or what sort of information it may
log.

8. Overview

This section provides a general overview of the client. If interaction
between the ``R'' bit functional entities of DHCP. The overview is not set,
this field contains organized
as a non-link-local IP address series of the
client questions and answers. Details of DHCP such
as message formats and retransmissions are left to sections 9,
10, 11, 12, 14, 15, and 16.

8.1. How does a node know to use DHCP?

An unconfigured node determines that it is to use DHCP for
configuration of an interface from which the the client issued the
Release message.

extensions See by detecting the ``extensions document'' [2].

A client selects presence (or absence)
of routers on the transaction-ID from link. If router(s) are present, the range of
1024--65535 node examines
router advertisements to determine if DHCP should be used to identify
configure the Release message.

A client interface. If there are no routers present, then
the node MUST NOT specify an IP address in use DHCP to configure the client-address field
that it is releasing interface. Detail on
this process can be found in neighbor discovery [11] and stateless
autoconfiguration [14].

8.2. How does a client find out about DHCP agents?

(Section removed, see 23.6

8.3. What if the extensions field.
9.6. client and server(s) are on different links?

Use of DHCP Reconfigure Message Format

A server sends a Reconfigure message when it wishes to inform in such environments requires one or more clients of new or updated values for configuration parameters.
The new configuration parameters are carried in the extensions
portion of DHCP relays
be set up on the Reconfigure message. Note that client's link, because a Reconfigure message
MUST NOT carry releasable resource extensions.

Reconfigure messages can ONLY be sent to clients which client may only have
established an IP address of sufficient scope as to be directly
reachable by the server.

Clients acknowledge Reconfigure messages with Reconfigure-reply
messages.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 6 | reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0 a

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 22] 11]

Internet Draft DHCP for IPv6 5 May 22 November 2000

transaction-ID
An unsigned integer identifier

link-local address. Relays receive the Solicit and Request messages
from the client and forward them to some set of servers within the
DHCP domain. The client message is forwarded verbatim as the payload
in a message from the relay to the range server. A relay will include
one of
0--1023 chosen by its own addresses (of sufficient scope) from the server interface
on the same link as the client, as well as the prefix length of
that address, in its message to identify the server. Servers receiving
the forwarded traffic use this
Reconfigure message.

server-address information to aid in selecting
configuration parameters appropriate to the client's link. The IP
servers also use the relay's address as the destination to forward
client-destined messages for final delivery by the relay.

Relays forward client messages to servers using some combination of
the FF05::1:3(All Servers) site-local multicast address, some other
(perhaps a combination) of site-local multicast addresses set up
within the DHCP server issuing domain to include the
Reconfigure message. servers in that domain, or a
list of unicast addresses for servers. The network administrator
makes relay configuration decisions based upon the topological
requirements (scope) of the DHCP domain they are managing. Note
that if the DHCP domain spans more than the site-local scope, then
the relays MUST be of sufficient scope configured with global addresses for the client's
link so as to be reachable by all clients.

extensions
See servers outside the ``extensions document'' [2].
9.7. DHCP Reconfigure-reply Message Format

A relays' site-local
environment.

8.4. How does a client sends request configuration parameters from servers?

To request configuration parameters, the client forms a Reconfigure-reply message Request
message, and sends it to acknowledge receipt the server either directly (client has an
address of sufficient scope) or indirectly (through the on-link
relay). The client MAY include a Reconfigure message Option Request Option 22.3 (ORO)
along with other options to request specific information from a server.

A Reconfigure-reply message can only be sent if the
server. Note that the client has an IP
address MAY form multiple Request messages
and send each of sufficient scope them to contact the server. No interaction
with different servers to request potentially
different information (perhaps based upon what was advertised) in
order to satisfy its needs. As a relay client's needs may change over time
(perhaps based upon an application's requirements), the client may
form additional Request messages to request additional information as
it is possible.

All fields in needed.

The server(s) respond with Reply messages containing the DHCP Reconfigure-reply message are entered requested
configuration parameters, which can include status information
regarding the information requested by the client.

status
This 7-bit field contains one of the values from The Reply MAY
also include additional information, such as a reconfiguration event
multicast group for the
errors table client to join to monitor reconfiguration
events, as described in section 3.4.

transaction-ID
An unsigned integer identifier copied from the server's
Reconfigure message. 8.8.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 23] 12]

Internet Draft DHCP for IPv6 5 May 2000

client's link-local address
The client's link-local address for for IPv6 22 November 2000

8.5. How do clients and servers identify and manage addresses?

Servers and clients manage addresses in groups called ``identity
associations.'' Each identity associations is identified using
a unique identifier. An identity association may contain one or
more IPv6 addresses. DHCP servers assign addresses to identity
associations. DHCP clients use the addresses in an identity
association to configure interfaces. There is always at least one
identity association per interface from
which the client issued the Reconfigure-reply message.

server-address
Copied from the Reconfigure message.
9.8. DHCP Reconfigure-init Message Format

A server sends that a Reconfigure-init message when it client wishes to notify
one or more clients configure.
Each address in an IA has its own preferred and valid lifetime. Over
time, the server may change the characteristics of new the addresses in
an IA; for example, by changing the preferred or updated values valid lifetime for configuration
parameters available on
an address in the server.

Reconfigure-init messages IA. The server may also add or delete addresses
from an IA; for example, deleting old addresses and adding new
addresses to renumber a client. A client can ONLY be sent request the current
list of addresses assigned to clients which have
established an IP address IA from a server through an exchange
of sufficient scope as to be directly
reachable by protocol messages.

8.6. Can a client release its assigned addresses before the server. lease
expires?

A ``Reconfigure-init'' serves as client forms a trigger which will cause Release message, including options identifying
the
clients IA to initiate a Request/Reply exchange with be released. The client sends the server in order Release to receive the new information.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 8 | reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable server
which assigned the addresses to the client initially. If that
server cannot be reached after a certain number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0

transaction-ID
An unsigned integer identifier of attempts (see
section 3.5), the client can abandon the Release attempt. In this
case, the address(es) in the range IA will be reclaimed by the server(s)
when the lifetimes on the addresses expire.

8.7. What if the client determines one or more of
0--1023 chosen its assigned addresses
are already being used by another client?

If the client determines through a mechanism like Duplicate Address
Detection [14] that the server to identify this
Reconfigure-init message.

server-address
The IP address of it was assigned by the DHCP server issuing is
already in use by another client, the
Reconfigure-init message. client will form a Release
message, including the option carrying the in-use address. The
option's status field MUST be set to the value reflecting the ``in
use'' status of sufficient scope the address.

8.8. How are clients notified of server configuration changes?

There are two possibilities. Either the clients discover the new
information when they revisit the server(s) to be reachable by all clients.

extensions SHOULD only include an ERE and/or authentication
extensions. No request additional
configuration information SHOULD be / extend the lifetime on an address. or
through a server-initiated event known as a reconfigure event.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 [Page 24]

Internet Draft DHCP for IPv6 5 May 2000

included. See the ``extensions document'' [2] for more
information about extensions.
10. DHCP Server Solicitation and Subnet Prefix Discovery

This section describes how a client locates agents (relays and
servers) and how it can learn about the networks on its link that are
managed by these servers. May 2001 [Page 13]

Internet Draft DHCP for IPv6 22 November 2000

The behavior reconfiguration feature of client, server, and relay
implementations is discussed, along with DHCP offers network administrators
the messages they use.
10.1. Solicit Message Validation

Clients MUST silently discard any received Solicit messages.

Agents MUST discard any received Solicit messages if opportunity to update configuration information on DHCP clients
whenever necessary. To signal the ``client's
link-local address'' field does not contain need for client reconfiguration,
the server will unicast a valid link-local
address.

Servers MUST discard each received Solicit Reconfigure-init message which meet the
following criteria:

o to each
client individually. The ``relay-address'' field does not contain an address of
sufficient scope server may use multicast to signal the
reconfiguration to multiple clients simultaneously. (Note that
there is reachable by no mechanism defined in the server.

o The ``relay-address'' field is non-zero, but prefix-len protocol to guarantee that
every client actually performs a reconfiguration in response to a
multicast reconfigure-init message.) A Reconfigure-init is zero.

An error a trigger
which will cause the client(s) to initiate a standard Request/Reply
exchange with the server in order to acquire the new or updated
addresses.

9. Message Formats and Identity Associations

All reserved fields in a message MAY MUST be logged transmitted as zeroes and
ignored by the agent. The logging receiver of
such messages SHOULD be controlled by the message.

DISCUSSION:

Each DHCP message has an agent implementation
configuration flag.
10.2. Advertise Message Validation

Servers MUST silently discard any received Advertise messages.

Clients MUST discard any Advertise identical fixed format header; some
messages that meet any of also allow a variable format area for options. Not
all fields in the
following criteria:

o The ``Solicit-ID'' header are used in every message. In this
section, every field value does is included in every message format
diagram and fields that are not match the value the
client used in its Solicit message.

o The ``client's link-local address'' field value does not match
the link-local address of the interface upon which a message are marked
as ``unused''. As an alternative, the client
sent unused fields could
be labeled ``unused'' in the format diagram.

9.1. DHCP Solicit message.

Relays MUST discard any Advertise messages that meet any of the
following criteria: Message Format

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 25] 14]

Internet Draft DHCP for IPv6 5 May 22 November 2000

o The ``relay-address'' field does not contain the relay's address
on the same link as the client.

o The ``client's link-local address'' field does not contain a
valid link-local address.
10.3. Client Behavior

Clients use the Solicit message primarily to discover DHCP servers
configured to serve networks on the link containing the client.
Optionally, the client MAY set the ``P'' bit which has the effect
of requesting that the server return subnet prefix extensions
identifying the networks on the client's link the server is
configured to manage.
10.3.1. Creation and sending of the Solicit message

When creating a Solicit message,

preference
(unused) MUST be 0

transaction-ID
An unsigned integer generated by the client SHOULD start out with
a buffer initialized with zeroed octets. The client sets the
``msg-type'' field to 1, and places the used to
identify this Solicit message.

client-link-local-address
The link-local address of the interface it wishes to configure in the link-local address field.

If for which the
client is prepared to process multiple using DHCP.

server-address (unused) MUST be 0

9.2. DHCP Advertise messages
in response to its Solicit message, the client will set the
Solicit-ID field to 1. Every time the client initiates a new server
solicitation attempt (not Message Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 2 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

preference An unsigned integer indicating a retransmission), the client increments
the Solicit-ID by one. If the 9-bit field rolls over server's willingness
to 0, then the
client sets the Solicit-ID provide service to 1. A client which will only accept
the first Advertise message it receives leaves the Solicit-ID field
initialized client.

transaction-ID An unsigned integer used to zero.

The ``C'' bit of the Solicit message is set by the client when the
client has no cached knowledge of previous DHCP configuration for the
interface. Setting identify this bit requests that the server release any
information assigned to the client for the networks on Advertise
message. Copied from the client's
link.

If the client desires to learn Solicit message.

client-link-local-address
The IP link-local address of the networks managed by DHCP on
the link its client interface is attached to, it sets
from which the ``P'' bit in client issued the Solicit message.

server-address
The client transmits IP address of the Solicit message to server. If the FF02::1:2 (All DHCP
Agents) multicast address, destination port 547. The source port
selection can be arbitrary, although it SHOULD be possible using a
client configuration facility to set a specific source port value. domain

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 26] 15]

Internet Draft DHCP for IPv6 5 May 22 November 2000

10.3.2. Time out and retransmission of Solicit Messages

The client's first Solicit message on the interface

crosses site boundaries, then this address MUST be delayed
by a random amount of time between the interval of MIN_SOL_DELAY
globally-scoped.

options Options are described elsewhere in this document

See Sections 14.4 and
MAX_SOL_DELAY. This random delay desynchronizes 15.3 for information about how clients which start
at the same time (e.g., after a power outage).

The client waits ADV_MSG_TIMEOUT, collecting Advertise messages.
If no Advertise messages are received, the client retransmits
the Solicit, and doubles the ADV_MSG_TIMEOUT value. This process
continues until either one or more Advertise messages are received or
ADV_MSG_TIMEOUT reaches
servers handle the ADV_MSG_MAX value. Thereafter, Solicits
are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
made, at which time preference field.

9.3. DHCP Request Message Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 3 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

preference
(unused) MUST be 0

transaction-ID
An unsigned integer generated by the client stops trying to DHCP configure the
interface. An event external to DHCP is required used to restart the DHCP
configuration process.

Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 3.5.
10.3.3. Receipt of Advertise messages

Upon receipt
identify this Request message.

client-link-local-address
The link-local address of one or more validated Advertise messages, the client
selects one or more Advertise messages based upon interface from
which the following
criteria.

- Those Advertise messages with client will issue the highest server preference
value (see section 14.4) are preferred over all other Advertise
messages.

- Within a group Request message.

server-address
The IP address of Advertise messages with the same server
preference value, a client MAY select those servers whose to which the the client's
Request message is directed, copied from an Advertise messages advertise information of interest
message.

options
Options are described elsewhere in this document.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 16]

Internet Draft DHCP for IPv6 22 November 2000

9.4. DHCP Reply Message Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 4 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

preference An unsigned integer indicating a server's willingness
to provide service to the client. For example, one server may be advertising

transaction-ID
An unsigned integer used to identify this Reply
message. Copied from the
availability of IP addresses on networks which have an client's Request message.

client-link-local-address
The link-local address
scope of interest to the client.

Once a client has selected Advertise message(s), interface for which the
client will
typically store information about each server, such as relay is using DHCP.

server-address
The IP address
and prefix length, server preference value, networks advertised,
when the advertisement was received, and so on. Depending on the
requirements of the client's invoking user, the client MAY initiate a
configuration exchange with server. If the server(s) immediately, or MAY defer DHCP domain
crosses site boundaries, then this exchange until later. address MUST be
globally-scoped.

options
Options are described elsewhere in this document.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 27] 17]

Internet Draft DHCP for IPv6 5 May 22 November 2000

10.4. Relay Behavior

For this discussion, the Relay is assumed to have been configured
with some list of server destination addresses, which may be unicast,
the FF05::1:3 (All

9.5. DHCP Servers) multicast address, or some other
multicast address selected Release Message Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 5 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

preference (unused) MUST be 0

transaction-ID
An unsigned integer generated by the network administrator.
10.4.1. Relaying of Solicit messages

When a Relay receives a valid Solicit message, it places the IP client used to
identify this Release message.

P (unused) MUST be 0

client-link-local-address
The client's link-local address of for the interface upon from
which it received the Solicit message
in the ``relay-address'' field of client issued the Solicit. Release message.

server-address
The Relay also places
the number of bits of that make up the subnet prefix for this IP address
in the ``prefix-len'' field of the Solicit.

The Relay then forwards this Solicit to the list of server
destination addresses that it assigned the
addresses.

options See section 22.

9.6. DHCP Reconfigure Message Format

The Reconfigure message has been configured with.
10.4.2. Relaying of Advertise messages

When a Relay receives a valid Advertise message, it unicasts the deleted (see section 23.2).

9.7. DHCP Reconfigure-reply Message Format

The Reconfigure-reply message to the link-local address found in the ``client's link-local
address'' field has been deleted (see section 23.2).

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 18]

Internet Draft DHCP for IPv6 22 November 2000

9.8. DHCP Reconfigure-init Message Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 8 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

preference (unused) MUST be 0

transaction-ID
An unsigned integer generated by way of the appropriate network interface.
10.5. Server Behavior

For this discussion, the Server is assumed to have been configured in
an implementation specific manner. This configuration is assumed server to
contain all network topology information for the DHCP domain, as well
as any necessary authentication information.
10.5.1. Receipt of Solicit messages

Upon the receipt identify
this Reconfigure-init message

client-link-local-address
(unused) MUST be 0

server-address
The IP address of a valid Solicit message, the server first
identifies the client's location within the DHCP domain. If server issuing the
``relay-address'' and / or ``prefix-len'' fields
Reconfigure-init message. MUST be of the Solicit are
zeroed, then the client is attached sufficient scope
to the same link as the server.
If these fields are non-zero, then the client exists on the same link
as the network identified be reachable by these two fields.

If administrative policy permits the server to respond to a client on
that link, the server will generate and send all clients.

options SHOULD only include an Advertise message to
the client. ``Options request option''
(ORO) and/or authentication options. No configuration
information SHOULD be included. See section 22 more
information about options.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 28] 19]

Internet Draft DHCP for IPv6 5 May 22 November 2000

10.5.2. Creation and sending of Advertise messages

When creating an Advertise message, the server SHOULD start out
with a buffer initialized with zeroed octets. The server sets the
``msg-type'' field to

9.9. Relay-forward message

0 1 2 and copies the values of the following fields
from the client's Solicit to the Advertise message:

o solicit-ID

o client's link-local address

o 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type TBD | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| relay-address |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type TBD

prefix-length
The server places one of its IP addresses (determined through
administrator setting) in the ``server-address'' field of the
Advertise message. The server initializes the ``preference''
field from its configuration information. See section 15.3 for a
description length of server preference.

If the client requests subnet prefix extensions (by setting the ``P''
bit in its Solicit) and the server implements and is configured to
provide prefix extensions, the server will generate and insert a
subnet prefix extension for each network on the client's link it is
configured to manage.

If address in the
``relay-address'' field of the Advertise message is zero, then
the server unicasts the Advertise message directly field.

relay-address
An address assigned to the client
using the ``client's link-local address'' field value as destination
address. If the ``relay-address'' field is non-zero, then the server
unicasts interface through which the Advertise
message directly to the relay using the
``relay-address'' field value as from the destination address.
11. DHCP Client-Initiated Configuration Exchange

A client initiates a configuration exchange with one or more servers
it has found through DHCP server solicitation whenever requested to
do so by the application layer in order to acquire configuration
information of interest.
11.1. Request Message Validation

Clients MUST silently discard any received Request messages.

Agents was received.

options MUST discard any Request messages in which the ``client's
link-local address'' field does not contain include a valid link-local
address. ``Client message option''; see
section 22.4.

9.10. Server-forward message

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type TBD | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| relay-address |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type TBD

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 29] 20]

Internet Draft DHCP for IPv6 5 May 22 November 2000

Relays MUST discard any received Request messages

prefix-length
The length of the prefix in the address in which the
``relay-address'' field value does not match any of field.

relay-address
An address identifying the relay's
addresses.

Servers MUST discard any received Request message interface through which meets any of the following criteria:

o The ``server-address'' field value does not match any of
message from the
server's addresses.

o If server should be forwarded; copied
from the ``relay-address'' field ``client-forward'' message.

options MUST include a ``Server message option''; see
section 22.5.

9.11. Identity association

An ``identity-association'' (IA) is set, a construct through which a
server and that field's value
does not contain an address a client can identify, group and manage IPv6 addresses.
Each IA consists of sufficient scope as to a UUID and a list of associated IPv6 addresses
(the list may be
reachable by empty). A client associates an IA with one of
its interfaces and uses the IA to obtain IPv6 addresses for that
interface from a server.

10. DHCP Server Solicitation

This section describes how a client locates servers. The ``extensions'' field contains an authentication extension, behavior of
client, server, and relay implementations is discussed, along with
the server cannot successfully authenticate messages they use.

(Prefix advertisements have been deleted; see 23.9.)

10.1. Solicit Message Validation

Clients MUST silently discard any received Solicit messages.

Agents MUST silently discard any received Solicit messages if
the client.
11.2. Reply ``client-link-local-address'' field does not contain a valid
link-local address.

10.2. Advertise Message Validation

Servers MUST silently discard any received Reply Advertise messages.

Clients MUST discard any Reply message Advertise messages that meets meet any of the
following criteria:

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 21]

Internet Draft DHCP for IPv6 22 November 2000

o The ``transaction-ID'' ``Transaction-ID'' field value does not match the value the
client used in its Request or Release Solicit message.

o The ``client's link-local address'' ``client-link-local-address'' field value does not match the
link-local address of the interface upon which the client sent in its Request or Release
the Solicit message.

o The Reply

10.3. Client Behavior

Clients use the Solicit message contains an authentication extension, to discover DHCP servers configured
to serve addresses on the link to which the client is attached.

(Prefix advertisement by servers has been deleted; see section 23.9.)

10.3.1. Creation and sending of the
client's attempt Solicit message

The client sets the ``msg-type'' field to 1, and places the
link-local address of the interface it wishes to configure in the
``client-link-local-address'' field. The client sets all other
fields to zero.

The client sends the Solicit message to authenticate the FF02::1:2 (All DHCP
Agents) multicast address, destination port 547. The source port
selection can be arbitrary, although it SHOULD be possible using a
client configuration facility to set a specific source port value.

10.3.2. Time out and retransmission of Solicit Messages

The client's first Solicit message fails.

Relays on the interface MUST discard any Reply message that meets any be delayed
by a random amount of time between the interval of MIN_SOL_DELAY and
MAX_SOL_DELAY. This random delay desynchronizes clients which start
at the same time (e.g., after a power outage).

o The ``R'' bit isn't set.

o The ``relay-address'' field value does not contain ADV_MSG_MAX value. Thereafter, Solicits
are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
made, at which time the relay's
address on client stops trying to DHCP configure the same link as
interface. An event external to DHCP is required to restart the client.

o The ``client's link-local address'' field value does not contain
a valid link-local address. DHCP
configuration process.

Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 3.5.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 30] 22]

Internet Draft DHCP for IPv6 5 May 22 November 2000

11.3. Release Message Validation

Clients MUST silently discard any received Release messages.

Agents MUST discard any Release message that meets any

10.3.3. Receipt of the
following criteria:

o The ``transaction-ID'' field contains a value not in the
1024--65535 range.

o The ``client's link-local address'' field does not contain a
valid link-local address.

Relays MUST discard any received Release message that meets any Advertise messages

Upon receipt of one or more validated Advertise messages, the client
selects one or more Advertise messages based upon the following criteria:

o The ``R'' bit is not set.

o The ``X-address'' field
criteria.

- Those Advertise messages with the highest server preference
value does not match any (see section 14.4) are preferred over all other Advertise
messages.

- Within a group of Advertise messages with the relay's
addresses.

Servers MUST discard any received Release message which meets any same server
preference value, a client MAY select those servers whose
Advertise messages advertise information of interest to
the following criteria:

o The ``X-address'' field does not contain client. For example, one server may be advertising the
availability of IP addresses which have an address of sufficient scope as of
interest to be reachable by the server.

o The ``extensions'' field contains an authentication extension,
and the server cannot successfully authenticate the client.
11.4. Client Behavior

Once a client has selected Advertise message(s), the client will generate one or more Request messages
typically store information about each server, such as server
preference value, addresses advertised, when prompted by the application layer in order to acquire configuration information.
A advertisement was
received, and so on. Depending on the requirements of the client's
invoking user, the client may MAY initiate such an a configuration exchange automatically in order with
the server(s) immediately, or MAY defer this exchange until later.

10.4. Relay Behavior

For this discussion, the Relay may be configured to
acquire use a list of
server destination addresses, which may include unicast addresses,
the FF05::1:3 (All DHCP Servers) multicast address, or other
multicast addresses selected by the necessary network parameters to communicate with nodes
off-link. administrator. If
the Relay has not been explicitly configured, it will use the
FF05::1:3 (All DHCP Servers) multicast address as the default.

10.4.1. Relaying of Solicit messages

When a Relay receives a valid Solicit message, it constructs a
Relay-forward message. The client uses Solicit message is carried as the server and
payload of a ``client-message'' option. The relay places an address information
from previous Advertise message(s) for use in delivering Request
message(s). Note that a client may request configuration information
from one or more servers at any time.

A client uses the Release interface on which the Solicit message was received in the management of releasable
resources when:

o The client has determined through a resource-specific manner
``relay-address'' field and the prefix length for that address in
the resource assigned by ``prefix-length'' field. The Relay then sends the Relay-forward
message to the list of server is already in use by a
different client. destination addresses that it has been
configured with.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 31] 23]

Internet Draft DHCP for IPv6 5 May 22 November 2000

o The client has been instructed to release the resource prior to
the lease expiration time since it is no longer needed.
11.4.1. Creation and sending

10.4.2. Relaying of Request Advertise messages

When creating a Request message, the client SHOULD start out with relay receives a buffer initialized with zeroed octets. The client sets the
``msg-type'' field to 3, and places the link-local address of the
interface Relay-reply message, it wishes to associate with extracts the configuration information
with in server
message from the ``client's link-local address'' field.

Unless ``server-message'' option and forwards the Request server
message is created in response to a
Reconfigure-init message, the client generates a transaction
ID address in the range of 1024--65535 and inserts this value client-link-local-address field in
the
``transaction-ID'' field. server message. The client places the address of relay forwards the destination server in the
``server-address'' field.

If the client is not on the same link as the destination
server, the client places message through
the appropriate relay's address interface identified in the ``relay-address'' field.

If field in the client
Relay-reply message.

10.5. Server Behavior

For this discussion, the Server is acquiring assumed to have been configured in
an implementation specific manner. This configuration is assumed to
contain all network topology information on the interface for the first time, the client SHOULD set the ``C'' bit in DHCP domain, as well
as any necessary authentication information.

10.5.1. Receipt of Solicit messages

If the
header. How server receives a Solicit message, the client determines if this is the first configuration
attempt must be on the interface is implementation-specific. A client may
implement
same link as the server. If the server receives a cache of configuration information on Relay-forward
message containing a per-interface
basis; if that cache does not exist, that Solicit message, the client would set must be on the
``C'' bit. Clients
link to which do not implement caching of per-interface
configuration information MUST always set the ``C'', prefix identified by the ``relay-address'' and include
any extensions carrying releasable resources received from earlier
configuration exchanges
``prefix-length'' fields in the extensions Relay-forward message is assigned.
The server records the ``relay-address'' field of from the Request. Relay-forward
message and extracts the solicit message from the ``client-message''
option.

If administrative policy permits the server to respond to a client has determined through an implementation-specific
manner on
that link, the client implementation itself has restarted, it MUST
set server will generate and send an Advertise message to
the ``R'' bit in client.

10.5.2. Creation and sending of Advertise messages

The server sets the header. After ``msg-type'' field to 2 and copies the first successful exchange
with values
of the server, following fields from the client MUST NOT set client's Solicit to the ``R'' bit Advertise
message:

o transaction-ID

o client-link-local-address

The server places one of its IP addresses (determined through
administrator setting) in subsequent
Request messages.

Client considerations for extensions are now considered (see the
``extensions document'', [2] ``server-address'' field of the
Advertise message. The server sets the ``preference'' field
according to its configuration information. See section 15.3 for more details). a
description of server preference.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 24]

Internet Draft DHCP for IPv6 22 November 2000

If the client already has an IP address Solicit message was received in a Relay-forward message, the
server constructs a Relay-reply message with the Advertise message
in the payload of sufficient scope a ``server-message'' option. The server unicasts
the Relay-reply message to the address in the ``relay-address'' field
from the Relay-forward message.

If the Solicit message was received directly reach by the server, then the client SHOULD unicast
server unicasts the Request Advertise message directly to the server. Otherwise, if client using
the server is off-link, ``client-link-local-address'' field value as the client
unicasts destination
address. The Advertise message MUST be unicast through the Request interface
on which the Solicit message was received.

DISCUSSION:

(From Ted Lemon) There is a danger in using Solicit versus
DHCPDISCOVER: in the Solicit paradigm, the client has to
choose the appropriate relay.

Bound, Carney, Perkins Expires 1 November 2000 [Page 32]

Internet Draft DHCP for IPv6 5 May 2000

11.4.2. Time out and retransmission of Request Messages

The client waits REP_MSG_TIMEOUT milliseconds, collecting
Reply messages. If no Reply messages are received, server before it knows if the client
retransmits DHCP server
will give it an IP address, or which addresses the Request with server is
willing to assign to the client. It may be that there are
two or more DHCP servers owned by the same transaction-ID, administrative
domain, and doubles both are theoretically willing to give the REP_MSG_TIMEOUT value, and waits again. The
client continues
this process until a Reply is received or REQUEST_MSG_ATTEMPTS
unsuccessful attempts have been made, at which time the addresses, but only one actually has any addresses to
give.

11. DHCP Client-Initiated Configuration Exchange

A client MUST
abort uses the Request-Reply message exchange to acquire
configuration attempt. information of interest. The client SHOULD report may initiate the abort
status
configuration exchange as part of the operating system configuration
process or when requested to do so by the application layer.

Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
are documented in section 3.5.
11.4.3. Receipt of Reply message in response to a Request

Upon

A client uses the receipt of a valid Reply message, Release-Reply message exchange to indicate to the
DHCP server that the client extracts will no longer be using the
configuration information contained addresses in
the Reply. If released IA.

11.1. Request Message Validation

Clients MUST silently discard any received Request messages.

Agents MUST discard any Request messages in which the ``status''
``client-link-local-address'' field contains does not contain a non-zero value, the client reports the error status
to valid
link-local address.

Servers MUST discard any received Request message which meets any of
the application layer.

If following criteria:

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 25]

Internet Draft DHCP for IPv6 22 November 2000

o The ``server-address'' field value does not match any of the extensions
server's addresses.

o The ``options'' field contains one or more ``Reconfigure Multicast
Address'' extensions (see ``extensions document'', ``Reconfigure
Multicast Address Extension'' section [2]), an authentication option, and the client
server cannot successfully authenticate the client.

11.2. Reply Message Validation

Servers MUST join
these multicast groups, and silently discard any received Reply messages.

Clients MUST monitor discard any Reply message that meets any of the UDP 546 port for
Reconfigure or Reconfigure-init messages on
following criteria:

o The ``transaction-ID'' field value does not match the networks configured
by DHCP.

If value the configuration information returned
client used in its Request or Release message.

o The ``client-link-local-address'' field value does not match the
link-local address of the interface upon which the client sent in
its Request or Release message.

o The Reply message contains
releasable resources, then an authentication option, and the client MUST take over lease management
of
client's attempt to authenticate the resource. A client message fails.

Relays MUST NOT request releasable resources
unless it is prepared to appropriately manage discard any Relay-reply message in which the resource lease.
11.4.4. Creation and sending of Release messages

When creating
``client-link-local-address'' in the encapsulated Reply message does
not contain a valid link-local address.

11.3. Release message, Message Validation

Clients MUST silently discard any received Release messages.

Agents MUST discard any Release message in which the client SHOULD start out with
``client-link-local-address'' field does not contain a buffer initialized with zeroed octets. The client sets valid
link-local address.

Servers MUST discard any received Release message in which the
``msg-type''
``options'' field to 5, contains an authentication option, and places the link-local address of the
interface server
cannot successfully authenticate the configuration information it wishes client.

11.4. Client Behavior

A client will generate one or more Request messages to release is
associated with in the ``client's link-local address'' field.

The acquire
configuration information. A client generates a transaction ID in the range of
1024--65535 and inserts this value may initiate such an exchange
automatically in order to acquire the ``transaction-ID''
field. necessary network parameters
to communicate with nodes off-link. The client includes extensions containing uses the releasable resources it
is releasing server
address information from previous Advertise message(s) for use in the ``extensions'' field. The appropriate ``status''

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 33] 26]

Internet Draft DHCP for IPv6 5 May 22 November 2000

field in the extensions MUST be set to indicate

constructing Request message(s). Note that a client may request
configuration information from one or more servers at any time.

A client uses the reason for Release message in the
release. management of IAs when:

o The client places the IP address has determined through DAD or some other method that
one or more of the server who allocated addresses assigned by the
resource(s) server in the ``server-address'' field.

If the client will have an appropriately scoped IP address after the
release transaction IA is completed, the client clears the ``R'' bit
and places this address
already in the ``X-address'' field. If the use by a different client.

o The client
will not have an appropriately scoped IP address after the has been instructed to release
transaction is completed, the IA prior to the IA
expiration time since it is no longer needed.

11.4.1. Creation and sending of Request messages

The client sets the ``R'' bit ``msg-type'' field to 3, and places the
link-local address of the appropriate relay interface it wishes to acquire
configuration information for in the ``X-address'' ``client-link-local-address''
field.

If the client is configured to use authentication, the

The client generates the appropriate authentication extension, and adds a transaction ID inserts this
extension to value in the ``extensions''
``transaction-ID'' field. Note that

The client places the authentication
extension MUST be address of the last extension destination server in the ``extensions''
``server-address'' field. See the ``extension document'' for

The client adds any appropriate options, including one or more details about the
authentication extension [2].

If IA
options (if the ``R'' bit client is set, then requesting that the server assign it some
network addresses). If the client does include any IA options,
it MUST unicast the Release
to the relay indicated in include the ``X-address'' field. Otherwise, list of addresses the client unicasts the Release message directly to currently has
associated with that IA. If the server indicated
in client is requesting configuration of
a new IA, the ``server-address'' field.
11.4.5. list of addresses MUST be empty.

11.4.2. Time out and retransmission of Release Request Messages

The client waits REP_MSG_TIMEOUT milliseconds, collecting server will respond to the Request message with a Reply
messages.
message. If no Reply messages are received, message is received within REP_MSG_TIMEOUT
milliseconds, the client retransmits the Release, Request with the same
transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits
again. The client continues this process until a Reply is received
or
REL_MSG_ATTEMPTS REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
which time the client SHOULD MUST abort the release configuration attempt. The
client SHOULD return report the abort status to the application, if an application
initiated the release.

Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented in section 3.5.

Note that if the client fails to release the resource, the resource
will be reclaimed by the server when the lease associated with it
expires. to the application layer.

Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
are documented in section 3.5.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 34] 27]

Internet Draft DHCP for IPv6 5 May 22 November 2000

11.4.6.

11.4.3. Receipt of Reply message in response to a Release Request

Upon the receipt of a valid Reply message, the client can consider extracts the
Release event successful, and SHOULD return
configuration information contained in the successful Reply. If the ``status''
field contains a non-zero value, the client reports the error status
to the application layer, if an application initiated the release.
11.5. Relay Behavior

11.5.1. Relaying of Request or Release messages

When a Relay receives a valid Request or Release message, it forwards
it to layer.

The client records the IP address found T1 and T2 times for each IA in the ``server-address'' field of Reply
message. The client records any addresses included with IAs in
the Reply message.
11.6. Server Behavior

For this discussion, The client updates the Server is assumed to have been configured preferred and valid
lifetimes for the addresses in an implementation specific manner with configuration of interest
to clients. Such configuration information MAY contain releasable
resources such as IP addresses.
11.6.1. Receipt of Request messages

Upon the receipt of a valid Request message IA from a the lifetime information
in the IA option. The client leaves any addresses that the server
can respond to, (implementation-specific administrative policy
satisfied) client
has associated with the server scans IA that are not included in the extensions field.

If IA option
unchanged.

Management of the specific configuration information is detailed in
the definition of each option, in section 22.

11.4.4. Creation and sending of Release messages

The client has set sets the ``C'' bit, ``msg-type'' field to 5, and places the server MUST release all
releasable resources currently
link-local address of the interface associated with the client's binding
that do not appear configuration
information it wishes to release in the ``extensions'' ``client-link-local-address''
field.

If the

The client has set generates a transaction ID and places this value in the ``R'' bit,
``transaction-ID'' field.

The client includes options containing the server MUST delete any
transaction-ID cache entries IAs it is maintaining for this client, if
the server implements such a cache.

Server considerations for extensions are now evaluated (see releasing in the
``extensions document'', [2] for more details).

If
``options'' field. The appropriate ``status'' field in the configuration information to options
MUST be returned set to indicate the reason for the release.

The client
includes releasable resources, places the IP address of the server checks if a binding
already exists for that allocated the client.
address(es) in the ``server-address'' field.

If so, the server examines client is configured to use authentication, the
data records within client
generates the binding appropriate authentication option, and adds this option
to determine if the client's
Request is a retransmission of an earlier Request or a new Request.
Releasable resource identifiers are stored within ``options'' field. Note that the binding with authentication option MUST
be the transaction-ID used by last option in the ``options'' field. See section 22.7 for
more details about the authentication option.

(The client always forwards Release messages to request the resource's
assignment. If the transaction-ID's match, this is server through a retransmission
relay; see section 11.5.)

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 35] 28]

Internet Draft DHCP for IPv6 5 May 22 November 2000

11.4.5. Time out and the server simply return the contents retransmission of the client's binding
which satisfy its request. Release Messages

If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the transaction-ID's do not match, client retransmits the server records Release, doubles the additional resources it REP_MSG_TIMEOUT
value, and waits again. The client continues this process until a
Reply is assigning in the
existing binding with received or REL_MSG_ATTEMPTS unsuccessful attempts have been
made, at which time the new Request's transaction-ID.

If client SHOULD abort the release attempt.
The client does not have SHOULD return the abort status to the application, if an existing binding,
application initiated the server creates a
binding release.

Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented in section 3.5.

Note that if the client and records fails to release the resources it is assigning in
this binding along with IA, the transaction-ID from addresses
assigned to the IA will be reclaimed by the client's Request.

The server then constructs a Reply message and sends it to when the
client.
11.6.2. lease
associated with it expires.

11.4.6. Receipt of Reply message in response to a Release messages

Upon the receipt of a valid Release Reply message, the server performs a
lookup to find the client's binding. If the binding is found, the
server examines the binding to see if the resource(s) identified by
the client in can consider the
Release message's extensions field are in fact
assigned to the client. If they are, the server deletes these
resources from the client's binding, making them available to other
clients.

The server then generates a Reply message. If a binding was
found event successful, and SHOULD return the resources presented to the server were deleted from
the client's binding, the server sets the ``status'' field successful status to
``Success''. If no binding is found,
the server sets application layer, if an application initiated the ``status''
field to ``NoBinding''(section 3.4).
11.6.3. Creation and sending of Reply messages release.

11.4.7. When creating a Reply message, the server SHOULD start out with client should send a buffer initialized with zeroed octets. Request message

The server sets the
``msg-type'' field to 4 and copies the values description of the following fields
from Request/Reply message exchange in this section
makes no assumptions about the client's Request timing or Release to the Reply message:

o transaction-ID

o client's link-local address

o If state of the client's client when
it initiates a Request/Reply message is exchange. Sections 11.4.8
through 11.4.10 describe when a Request with client MAY initiate a non-zero
``relay-address'' field value, the server sets the ``R'' bit in
the Reply Request/Reply
message exchange. The procedures for timeout and copies the ``relay-address'' field value from the retransmission of
Request to the Reply. messages are described in section 11.4.2.

11.4.8. Initialization

If the client's message is a Release client has no valid IPv6 addresses of sufficient scope to
communicate with a DHCP server, it may a Request message to obtain
new addresses. The client includes one or more IAs in the ``R'' bit set, Request
message, to which the server sets assigns new addresses. The server then
returns to IA(s) to the ``R'' bit client in the a Reply and
sets message.

11.4.9. Confirming the ``relay-agent'' field validity of IPv6 addresses

Whenever a client may have moved to the contents a new link, its IPv6 addresses
may no longer be valid. Examples of the Release's
X-address field. times when a client may have
moved to a new link include:

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 36] 29]

Internet Draft DHCP for IPv6 5 May 22 November 2000

o The server sets the ``status'' field appropriately (see the table
in section 3.4) based upon the results of processing the client's
request.

If configured to do so, client reboots

o The client is physically disconnected from a server will include ``Reconfigure Multicast
Address'' extensions (see ``extensions document'', ``Reconfigure
Multicast Address Extension'' [2]), in Reply messages sent in
response to wired connection

o The client returns from sleep mode

o The client using a wireless technology changes cells

In any situation when a Request, informing the client of one or more multicast
groups it should join may have moved to facilitate the receipt of Reconfigure or
Reconfigure-init messages.

If the DHCP domain is using authentication, the server will generate
an authentication extension with a new link, the appropriate settings and add
that extension as
client MUST initiate a Request/Reply message exchange. The client
includes any IAs, along with the last extension addresses associated with those IAs,
in the ``extensions'' field of
the Reply its Request message.

If The server returns the ``relay-address'' field IAs with updated list
of addresses and associated lifetimes.

11.4.10. Extending the Reply message is zero, then lifetimes on IPv6 addresses

IPv6 addresses assigned to a client through an IA use the same
preferred and valid lifetimes as IPv6 addresses obtained through
stateless autoconfiguration. The server unicasts assigns preferred and valid
lifetimes to the Reply directly IPv6 addresses it assigns to an IA. To extend those
lifetimes, the client using the ``client's
link-local address'' field value as destination address. If sends a Request to the
``relay-address'' field is non-zero, then server containing an
``IA option'' for the IA and its associated addresses. The server unicasts
determines new lifetimes for the
Reply directly addresses in the IA according to
the relay using server's administrative configuration. The server may also add
new addresses to the ``relay-address'' field value
as IA. The server remove addresses from the destination address.

If IA by
setting the preferred and valid lifetimes of those addresses to zero.

The server implements a transaction-ID cache, controls the server would add
an entry for time at which the client to this cache.
12. DHCP Server-Initiated Configuration Exchange

A contacts the server initiates a configuration exchange
to extend the lifetimes on behalf of assigned addresses through the
administrator of T1 and
T2 parameters assigned to an IA. If the DHCP domain. An administrator may initiate such server does not assign an exchange when new networks are added
explicit value to the domain T1 or existing
networks are T2 for an IA, T1 defaults to be renumbered. Other examples include changes in 0.5 times the location of directory servers, addition of new services such as
printing, and availability
shortest preferred lifetime of new software (system or application).
12.1. Reconfigure Message Validation

Agents MUST silently discard any received Reconfigure messages.

Clients MUST discard address assigned to the IA and
T2 defaults to 0.875 times the shortest preferred lifetime of any Reconfigure
address assigned to the IA.

At time T1 for an IA, the client initiates a Request/Reply message that meets
exchange to extend the lifetimes on any of addresses in the
following criteria:

o IA. The ``transaction-ID'' field value is not within
client includes an IA option with all addresses currently assigned
to the 0--1023 range.

o IA in its Request message. The Reconfigure client unicasts this Request
message contains to the server that originally assigned the addresses to the
IA.

At time T2 for an authentication extension, and IA (which will only be reached if the client's attempt server to authenticate
which the Request message fails. was sent at time T1 has not responded),
the client initiates a Request/Reply message exchange. The client
includes an IA option with all addresses currently assigned to the
IA in its Request message. The client multicasts this message to
the FF02::1:2 (All DHCP Agents) multicast address.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 37] 30]

Internet Draft DHCP for IPv6 5 May 22 November 2000

12.2. Reconfigure-reply Message Validation

Clients and Relays MUST silently discard any received
Reconfigure-reply messages.

Servers MUST discard any Reconfigure-reply message that meets any

11.5. Relay Behavior

11.5.1. Relaying of
the following criteria:

o Request or Release messages

When a Relay receives a valid Request or Release message, it
constructs a Relay-forward message. The ``transaction-ID'' field value client message is not that same value carried
as the
server used in its Reconfigure message.

o payload of a ``client-message'' option. The ``server-address'' field value does not match relay places an
address from the value interface on which the
server placed in its Reconfigure message.
12.3. Reconfigure-init Message Validation

Agents MUST silently discard any client message was received Reconfigure-init messages.

Clients MUST discard any Reconfigure-init messages
in the ``relay-address'' field and the prefix length for that meets any of
address in the following criteria:

o ``prefix-length'' field. The ``transaction-ID'' field value is not within Relay then forwards the 0--1023 range.

o The Reconfigure-init
Relay-forward message contains an authentication
extension, and the client's attempt to authenticate the message
fails.
12.4. list of server destination addresses
that it has been configured with.

11.6. Server Behavior

For this discussion, the server Server is assumed to have a
implementation-specific interface by which been configured in
an administrator
may initiate a reconfiguration event implementation specific manner with some set configuration of interest to
clients.

There are two methods

11.6.1. Receipt of Request messages

Upon the receipt of initiating a reconfiguration event. Each
has its advantages:

Reconfigure with payload
This method uses valid Request message from a client the Reconfigure message. Items
to be changed are included as extensions in server
can respond to, (implementation-specific administrative policy
satisfied) the
``extensions'' server scans the options field.

The server then constructs a Reply message and sends it to the
client.

DISCUSSION:

This method MUST NOT section needs text about managing IAs and determining
options to be used returned to reconfigure releasable resources. Examples client.

11.6.2. Receipt of
information which can be reconfigured using this
method Release messages

Upon the receipt of a valid Release message, the server examines the
IAs and the addresses in the IAs for validity. If the IAs in the
message are DNS domain in a binding for the client and servers, NTP servers, the addresses in the IAs
have been assigned by the server to those IA, the server deletes
the addresses from the IAs and makes the addresses available for
assignment to other
name service parameters. clients.

The server then generates a Reply message. If all of the IAs were
valid and
sends the Reconfigure message; clients respond with
Reconfigure-reply messages. addresses successfully released,, the server sets the
``status'' field to ``Success''. If any of the IAs were invalid or
if any of the addresses were not successfully released, the server

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 38] 31]

Internet Draft DHCP for IPv6 5 May 22 November 2000

Reconfigure Trigger
This method uses

releases none of the Reconfigure-init message. When
a client receives a Reconfigure-init message, it
initiates a Request/Reply exchange with addresses in the server.
Any kind of resource can be reconfigured using this
method, including releasable resources. An example message and sets the ``status''
field to ``NoBinding''(section 3.4).

DISCUSSION:

What is the behavior of the server relative to a ``partially
released'' IA; i.e., an releasable resource is IA for which some but not all
addresses are released?

Can a client send an IP address.

A server empty IA to release all addresses in
the IA?

If the IA becomes empty - all addresses are released - can send Reconfigure
the server discard any record of the IA?

11.6.3. Creation and Reconfigure-init messages only to
those clients who have an address sending of sufficient scope Reply messages

DISCUSSION:

XXX - This section needs to be reachable
by fixed (see section 11.6.1).

The server sets the server. Thus, those clients who have not requested an IP
address ``msg-type'' field to 4 and are off-link cannot be reconfigured by copies the server.

Before initiating a reconfigure process, values
of the following fields from the client's Request or Release to the
Reply message:

o transaction-ID

o client's link-local address

o server-address

The server SHOULD be
configured with a REC_THRESHOLD threshold value which represents sets the percentage of clients successfully reconfigured before ``status'' field appropriately (see the
reconfigure process is considered a success. See table
in section 3.5 for 3.4) based upon the
default setting results of REC_THRESHOLD. Note that processing the client's
request.

If the Request or Release message from the client was originally
received by the server, the server MUST be able unicasts the Reply message to determine the set of clients that should receive the reconfigure,
link-local address in order to determine when the reconfigure process is complete.
12.4.1. Creation and sending of Reconfigure messages

When creating a Reconfigure message, ``client-link-local-address'' field.

If the server SHOULD start out
with message was originally received in a buffer initialized with zeroed octets. The Forward-request or
Forward-release message from a relay, the server sets places the
``msg-type'' Reply
message in the options field to 6. The server generates of a transaction-ID
from the 0--1023 range Response-reply message and inserts it in unicasts
the ``transaction-ID''
field. The server places its message to the relay's address (of appropriate scope) in from the
``server-address'' field.

The server then generates extensions original message.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 32]

Internet Draft DHCP for IPv6 22 November 2000

12. DHCP Server-Initiated Configuration Exchange

A server initiates a configuration exchange on behalf of the non-releasable resources
administrator of the DHCP domain. An administrator may initiate such
an exchange when new links are added to the domain or existing links
are to be changed and places them renumbered. Other examples include changes in the ``extensions'' field.

If location
of directory servers, addition of new services such as printing, and
availability of new software (system or application).

DISCUSSION:

Changed ``networks'' to ``links'' here (ed.). Why would
adding new links cause a server-initiated configuration
exchange?

12.1. Reconfigure Message Validation

Reconfigure messages have been deleted; see section 23.2.

12.2. Reconfigure-reply Message Validation

Reconfigure-reply messages have been deleted; see section 23.2.

12.3. Reconfigure-init Message Validation

Agents MUST silently discard any received Reconfigure-init messages.

Clients MUST discard any Reconfigure-init messages that do
not contain an authentication option or that fail the DHCP domain is using authentication, client's
authentication check.

12.4. Server Behavior

For this discussion, the server will generate is assumed to have a
implementation-specific interface by which an authentication extension administrator
may initiate a reconfiguration event with the appropriate settings and add
that extension as the last extension in the ``extensions'' field some set of
the Reconfigure message.

The clients.

A server multicasts the Reconfigure sends a Reconfigure-init message to one or more
Reconfigure Multicast Addresses previously sent as extensions trigger a client to the
clients. Note that
initiate immediately a Request/Reply message exchange with the
server. A server MAY unicast Reconfigure message(s) can send Reconfigure-init messages only to
specific those
clients by walking its list who have an address of bindings sufficient scope to determine the
unicast address(es) of the clients. Whether or not be reachable by
the Reconfigure
is multicast or unicast is an implementation detail.

A server waits for Reconfigure-reply messages from server. Thus, those clients confirming
that they who have received not requested an IP address
and are off-link cannot be reconfigured by the Reconfigure. server.

DISCUSSION:

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 39] 33]

Internet Draft DHCP for IPv6 5 May 22 November 2000

12.4.2. Time out and retransmission of Reconfigure messages

The server waits RECREP_MSG_TIMEOUT milliseconds, collecting
Reconfigure-reply messages. If all the expected Reconfigure-reply
messages are received, then the reconfigure process is successful.
If some or all of the expected Reconfigure-reply

It would be possible to forward Reconfigure-init messages are not
received, then
through relays if the server retransmits the Reconfigure, and doubles records the RECREP_MSG_TIMEOUT value, client's link-local
address and waits again. The server continues
this process until all Reconfigure-reply messages are received or
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time
the server SHOULD abort the reconfigure process. The server SHOULD
log the result of relay's address from the reconfigure process.

Default and initial values for RECREP_MSG_TIMEOUT client's Request
message.

12.4.1. Creation and
REC_MSG_ATTEMPTS are documented in sending of Reconfigure messages

Reconfigure messages have been deleted; see section 3.5. 23.2.

12.4.2. Time out and retransmission of Reconfigure messages

12.4.3. Receipt of Reconfigure-reply messages

Upon receipt of a valid Reconfigure-reply message, the server
removes that client from the list of clients it is expecting a
Reconfigure-reply message from.

12.4.4. Creation and sending of Reconfigure-init messages

When creating a Reconfigure-init message, the server SHOULD start
out with a buffer initialized with zeroed octets.

The server sets the ``msg-type'' field to 8. The server generates
a transaction-ID
from the 0--1023 range and inserts it in the ``transaction-ID'' field.
The server places its address (of appropriate scope) in the
``server-address'' field.

The server MAY generate include an ERE extension ORO option to inform the client of what
information has been changed or new information that has been added.

If the DHCP domain is using authentication, the

The server will generate MUST include an authentication extension option with the appropriate
settings and add that extension option as the last extension option in the ``extensions'' ``options''
field of the Reconfigure-init message.

Typically, the server will not provide more than an ERE ORO and / or
Authentication extension, option, since it will provide the new configuration
information as part of the Request/Reply transaction triggered by the
Reconfigure-init message.

The server multicasts may either unicast the Reconfigure-init message to one
client or multicast the message to one or more Reconfigure Multicast
Addresses previously sent as extensions options to the clients. Note that a The server MAY
may unicast Reconfigure-init
Bound, Carney, Perkins Expires 1 November 2000 [Page 40]

Internet Draft DHCP for IPv6 5 May 2000

message(s) messages to specific clients by walking its list of bindings more than one client
concurrently; for example, to
determine reliably reconfigure all clients, the
server will unicast address(es) of the clients. Whether or not the a Reconfigure-init is multicast or unicast is an implementation detail.

A message to each client.

If the server unicasts to one or more clients, it waits for a Request
message from each client those clients confirming that
they have it has received the
Reconfigure-init and are thus initiating a Request/Reply transaction
with the server. The server. The server can determine that a Request message is
in response to a Reconfigure-init because the transaction-ID in the
Request will be the same value as was used in the Reconfigure-init
message.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 34]

Internet Draft DHCP for IPv6 22 November 2000

If the server multicasts the Reconfigure-init message, it must use
some TBD authentication mechanism that can authenticate the server to
multiple clients. There is no reliability mechanism for multicast
Reconfigure-init messages. A server might use multicast in the
case where it does not have a list of its clients; for example, a
server can determine that a Request message is in response distributes configuration information to clients using
stateless autoconfiguration might not keep a Reconfigure-init because
the transaction-ID in the Request will be the same value as was used
in the Reconfigure-init message. list of clients it has
communicated with.

12.4.5. Time out and retransmission of Reconfigure-init messages

The server uses

It the same algorithm and configuration values for
sending Reconfigure-init messages as it server does with Reconfigure
messages. See Section 12.4.2 for this algorithm.
12.4.6. Receipt of Request messages

Upon receipt of not receive a valid Request message with from the same transaction-ID
as client
in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
the Reconfigure-init messages it sent, message, doubles the RECREP_MSG_TIMEOUT
value and waits again. The server removes that
client from continues this process until
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point
the list server SHOULD abort the reconfigure process.

Default and initial values for RECREP_MSG_TIMEOUT and
REC_MSG_ATTEMPTS are documented in section 3.5.

12.4.6. Receipt of clients it is expecting to initiate a
Request/Reply transaction. Request messages

The server generates and sends Reply message(s) to the client as
described in section 11.6.3, including in the ``extension'' ``option'' field new
values for configuration parameters. If the extensions include
releasable resources, the server will include two extensions for each
resource - one with the original values with the lease times set to
zero, and another with new values and lease times. Note that the
server can terminate the client's ability to use a resource simply by
including only the first extension value.

12.5. Client Behavior

A client MUST always monitor UDP port 546 for Reconfigure and Reconfigure-init
messages on interfaces upon which it has acquired DHCP parameters.
Since the results of a reconfiguration event may affect application
layer programs, the client SHOULD log these events, and MAY notify
these programs of the change through an implementation-specific
interface.

Bound, Carney, Perkins Expires 1 November 2000 [Page 41]

Internet Draft DHCP for IPv6 5 May 2000

12.5.1. Receipt of Reconfigure Reconfigure-init messages

Upon receipt of a valid Reconfigure message, the client extracts
the configuration parameters contained in the ``extensions''
field, and notifies the application layer that new values for these
parameters are available. The Reconfigure-init message, the client then generates and sends
initiates a
Reconfigure-reply message to Request/Reply transaction with the server.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 35]

Internet Draft DHCP for IPv6 22 November 2000

12.5.2. Creation and sending of Reconfigure-reply Request messages

When creating responding to a Reconfigure-reply message, Reconfigure-init, the client SHOULD start
out with a buffer initialized with zeroed octets. The client sets
the ``msg-type'' field to 7, creates and places the link-local address of
the interface upon which it received
sends the Reconfigure Request message in exactly the ``client's link-local address'' field. The client copies the
values of same manner as outlined in
section 11.4.1 with the following fields from the Reconfigure message to the
Reconfigure-reply message:

o differences:

transaction-ID

o server-address
The client sets the ``status'' field appropriately (see copies the table
in section 3.4) based upon transaction-ID from the results of processing
Reconfigure-init message into the server's
reconfigure-reply. Request message.

IAs
The client places the address of the destination server in the
``server-address'' field.

If includes IA options containing the client is configured to use authentication, addresses
the client
generates the appropriate authentication extension, and adds this
extension currently has assigned to those IAs for the ``extensions'' field. Note that the authentication
extension MUST be the last extension in
interface through which the ``extensions'' field. Reconfigure-init message was
received.

Pause before sending Request
The client delays the pauses before sending of the Reconfigure-reply by some Request for
a random value selected in within the range of REC_REP_MIN and
REC_REP_MAX seconds. This delay helps reduce the load on
load on the server generated by processing large
numbers of triggered Request messages from a multicast
Reconfigure-init message.

12.5.3. Time out and retransmission of Request messages

The client uses the same variables and retransmission algorithm as it
does with Request messages generated as part of a client-initiated
configuration exchange. See section 11.4.2 for details.

12.5.4. Receipt of Reply messages

Upon the receipt of a valid Reply message, the client extracts the server generated by
processing large numbers
contents of Reconfigure-reply messages.

Default and initial values for REC_REP_MIN the ``option'' field, and REC_REP_MAX are
documented in section 3.5. sets (or resets) configuration
parameters appropriately. The client unicasts the Reconfigure-reply to records and updates the address identified
lifetimes for any addresses specified in IAs in the ``server-address'' field. Sending Reply message.
If the Reconfigure-reply
completes configuration parameters changed were requested by the reconfiguration process for
application layer, the client. client notifies the application layer of the
changes using an implementation-specific interface.

13. Using DHCP for network renumbering

This section has been deleted (to be moved to ``Notes about DHCP''
doc?).

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 42] 36]

Internet Draft DHCP for IPv6 5 May 22 November 2000

12.5.3. Receipt of Reconfigure-init messages

Upon receipt

14. DHCP Client Implementor Notes

This section provides helpful information for the client implementor
regarding their implementations. The text described here is not part
of the protocol, but rather a valid Reconfigure-init message, discussion of implementation features
we feel the implementor should consider during implementation.

14.1. Primary Interface

Since configuration parameters acquired through DHCP can be
interface-specific or more general, the client
initiates implementor SHOULD
provide a Request/Reply transaction with mechanism by which the server.
12.5.4. Creation and sending of Request messages

When responding client implementation can be
configured to a Reconfigure-init, specify which interface is the primary interface. The
client creates and
sends SHOULD always query the Request message in exactly DHCP data associated with the same manner as outlined primary
interface for non-interface specific configuration parameters. An
implementation MAY implement a list of interfaces which would be
scanned in
section 11.4.1 with order to satisfy the general request. In either case, the following differences:

transaction-ID
The client copies
first interface scanned is considered the transaction-ID from primary interface.

By allowing the
Reconfigure-init message into specification of a primary interface, the Request message.

Pause before sending Request
The client pauses before sending the Request
implementor identifies which interface is authoritative for
a random value
non-interface specific parameters, which prevents configuration
information ambiguity within the range REC_REP_MIN and
REC_REP_MAX seconds, as outlined in section 12.5.2.
12.5.5. Time out client implementation.

14.2. Advertise Message and retransmission of Request messages

The Configuration Parameter Caching

If the hardware the client uses is running on permits it, the same variables and retransmission algorithm as it
does with Request messages generated as part of implementor
SHOULD provide a client-initiated
configuration exchange. See section 11.4.2 cache for details.
12.5.6. Receipt of Reply Advertise messages

Upon the receipt of and a valid Reply message, the client extracts
the contents cache of the ``extension'' field, and sets (or resets)
configuration parameters appropriately. If the
configuration parameters changed were requested by received through DHCP. Providing these
caches prevents unnecessary DHCP traffic and the application layer, subsequent load
this generates on the
client notifies servers. The implementor SHOULD provide a
configuration knob for setting the application layer amount of time the changes using an
implementation-specific interface. If the resources changed cache(s) are
releasable,
valid.

14.3. Time out and retransmission variables

Note that the client makes time out and retransmission variables outlined
in section 3.5 can be configured on the appropriate adjustments server and sent to its
management of the leases of these resources.
13. Using DHCP for network renumbering

An administrator can use DHCP to renumber links within her DHCP
domain client
through two techniques, passive renumbering and active
renumbering. the use of the ``DHCP Retransmission Parameter Option'',
which is documented in section 22.6. A client implementation SHOULD
be able to reset these variables using the values from this option.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 43] 37]

Internet Draft DHCP for IPv6 5 May 22 November 2000

13.1. Passive Renumbering

The administrator can configure her servers to return relatively
short preferred and valid lifetimes

14.4. Server Preference

A client MUST wait for the IP addresses she
makes available to clients. When she determines that she'd like
to renumber SRVR_PREF_WAIT seconds after sending a network, she configures her servers through an
implementation-specific manner DHCP
Solicit message to disallow collect Advertise messages and compare their
preferences (see section 15.3), unless it receives an Advertise
message with a preference of 255. If the extension client receives an
Advertise message with a preference of 255, then the IP
address lifetimes client MAY act
immediately on that Advertise without waiting for any more additional
Advertise messages.

15. DHCP Server Implementor Notes

This section provides helpful information for the original network, server implementor.

15.1. Client Bindings

A server implementation MUST use the IA's UUID and adds the new network prefix
specification from which the client sent its Request message(s) as an
index for finding configuration data parameters assigned to the server's database. client.
While it isn't critical to keep track of the other parameters
assigned to a client, the server MUST keep track of the addresses it
has assigned to an IA.

The clients on server should periodically scan its bindings for addresses whose
leases have expired. When the original network will fail server finds expired addresses, it
MUST delete the assignment of those addresses, thereby making these
addresses available to acquire lifetime
extensions other clients.

The client bindings MUST be stored in non-volatile storage.

The server implementation should provide policy knobs to control
whether or not the lifetimes on their IP addresses, and will request and acquire
IP assigned addresses from are renewable, and
by how long.

15.2. Reconfigure-init Considerations

A server implementation MUST provide an interface to the new network when
administrator for initiating reconfigure-init events.

A server implementation may provide a mechanism for allowing the valid lifetime
specification of how many clients comprise a reconfigure multicast
group. This enables the
original IP addresses approaches expiration.

When administrator to control the lifetimes hit a server
takes when a reconfigure-init event occurs.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 38]

Internet Draft DHCP for all of the IP addresses on the original
network expire, the network can be considered renumbered.
13.2. Active Renumbering IPv6 22 November 2000

15.3. Server Preference

The administrator can force server implementation SHOULD allow the renumbering setting of networks in her DHCP
domain a server
preference value by using the reconfigure feature of DHCP. She instructs her
servers of the network renumbering through an implementation-specific
interface. administrator. The servers in the domain will generate Reconfigure-init
messages, which will cause the clients to initiate a Request/Reply
transaction server preference
variable is an unsigned single octet value (0--255), with the server. The servers will include two IP address
extensions for each IP address lowest
preference being changed. The first will contain
the original IP address, with the preferred 0 and valid lifetimes set
to zero. The second will contain the new IP address, highest 255. Clients will choose higher
preference servers over those with non-zero
preferred and valid lifetimes.

A server implementation MAY permit the administrator lower preference values. If you
don't choose to implement this feature in your server, you MUST set
the
original IP address lifetimes to some small value greater than zero,
to allow applications running on the client to orderly transfer server preference field to 0 in the new network over time.
14. DHCP Client Implementator Notes Advertise messages generated
by your server.

15.4. Request Message Transaction-ID Cache

In order to improve performance, a server implementation MAY include
an in memory transaction-ID cache. This section provides helpful information for the client implementor
regarding their implementations. The text described here cache is not part
of indexed by client
binding and transaction-ID, and enables the protocol, but rather server to quickly
determine whether a discussion of implementation features
we feel the implementor should consider during implementation.

Bound, Carney, Perkins Expires 1 November 2000 [Page 44]

Internet Draft DHCP for IPv6 5 May 2000

14.1. Primary Interface

Since configuration parameters acquired through DHCP can be
interface-specific Request is a retransmission or more general, a new Request
without the client cost of a database lookup. If an implementor chooses to
implement this cache, then they SHOULD provide a mechanism by which the client implementation can be
configured configuration knob
to specify which interface is tune the primary interface. The
client SHOULD always query lifetime of the cache entries.

16. DHCP data associated with the primary
interface for non-interface specific configuration parameters. An Relay Implementor Notes

A relay implementation MAY implement SHOULD allow the specification of a list of interfaces which would be
scanned
destination addresses for forwarded messages. This list MAY contain
any mixture of unicast addresses and multicast addresses.

If a relay receives an ICMP message in order response to satisfy the general request. In either case, a DHCP message it
has forwarded, it SHOULD log this event.

17. Open Issues for Working Group Discussion

This section contains some items for discussion by the
first interface scanned working group.

17.1. Authentication

Authentication is considered the primary interface.

By allowing the specification of a primary interface, the client
implementor identifies which interface not discussed in this document.

17.2. DHCP-DNS interaction

Interaction among DHCP servers, clients and DNS servers is authoritative not
discussed in this document.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 39]

Internet Draft DHCP for
non-interface specific parameters, IPv6 22 November 2000

17.3. Release vs. Decline

Should there be a separate Decline message through which prevents configuration
information ambiguity within the client implementation.
14.2. Advertise Message and Configuration Parameter Caching

If the hardware
informs the client server that it has discovered an address that is running on permits it, in use
by some other host?

17.4. Request messages

In DHCPv4, there has been much confusion about overloading
DHCPREQUEST with the implementor
SHOULD provide a cache actions of initial address allocation
(INIT), address confirmation (INIT-REBOOT), and extending leases
(RENEW/REBIND).

The model for Advertise DHCPv6 messages and a cache described in section 11 also uses one
type of message, Request, in each of
configuration parameters received through DHCP. Providing these
caches prevents unnecessary DHCP traffic and the subsequent load scenarios in sections 11.4.8
through 11.4.10. The DHCPv6 specification in this generates on document does not
differentiate the servers. The implementor SHOULD provide actions taken by a
configuration knob for setting server based on different times
at which a client might initiate a Request/Reply exchange with a
server. That is, the amount description of time the cache(s) are
valid.
14.3. Time out and retransmission variables

Note that the client time out and retransmission variables outlined server actions in section 3.5 can be configured 11.6.1
does not differentiate among Requests received from clients based on
the server and sent to the client behavior described in sections 11.4.8 through the use 11.4.10.

It may be necessary to define different server behaviors for each of
the ``DHCP Retransmission Parameter Extension'',
which is documented client scenarios. For example, in the ``extensions document'' [2]. A client
implementation SHOULD be able address-reconfirmation
scenario (section 11.4.9), servers cannot safely assign new addresses
to reset these variables using a client. The reconfirmation Request is broadcast to multiple
servers, which cannot coordinate the
values from assignment of any addresses.
Therefore, in this extension.
14.4. Server Preference

A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
Solicit message scenario, servers can only acknowledge or deny the
validity of addresses but cannot allocate any new addresses.

17.5. Use of term ``agent''

The term ``agent'', taken to collect Advertise messages and compare their
preferences (see section 15.3), unless it receives an Advertise
message with a preference mean ``relay agent or server'', may be
confusing. ``relay agent or server'' might be clearer.

17.6. Use of 255. If terms ``subnet'' and ``network''

The term ``subnet'' has been eliminated from the client receives an
Advertise message with document. The term
``network'' is no longer used to describe a preference link, collection of 255, then the client MAY act
immediately on that Advertise without waiting for any more additional
Advertise messages. links
or collection of IPv6 addresses.

18. Security

This document references an ``authentication option'' which is TBD.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 45] 40]

Internet Draft DHCP for IPv6 5 May 22 November 2000

15. DHCP Server Implementator Notes

This section provides helpful information for the server implementor.
15.1. Client Bindings

A server implementation can use the client's link-local address
and the subnet prefix specification from which the client sent its
Request message(s) as an index for finding configuration parameters
assigned to

DISCUSSION:

Based on the client. While it isn't critical to keep track discussion of which clients were given information (resources) that isn't
releasable, it IS critical for security issues at the server to keep track of which
client it has assigned releasable resources. The server MUST
include
8/31/00 design team teleconference and subsequent
DHC WG mailing list discussion, DHCPv6 will use
the transaction-ID security model from DHCPv4, as described in
draft-ietf-dhc-authentication-15.txt.

19. Year 2000 considerations

Since all times are relative to the client's Request along with current time of the releasable resource identifier(s) transaction,
there is no problem within the binding. DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the current year.

20. IANA Considerations

This is
done so document defines message types 1--8 to be received by UDP at
port numbers 546 and 547. Additional message types may be defined in
the future.

Section 3.1 lists several multicast addresses used by DHCP.

This document also defines several status codes that are to
be returned with the server can detect whether a client Request is a
retransmission of an earlier Request or an entirely new Request. Reply and Reconfigure-reply messages (see
sections 9.4 and 9.7). The server should periodically scan its bindings non-zero values for releasable
resources whose leases have expired. When the server finds expired
resource assignments, it MUST delete these assignments, thereby
making these resources available to other clients.

The client bindings MUST be stored status codes
which are currently specified are shown in non-volatile storage.

The server implementation should provide policy knobs to control
whether or not the lease on a releasable resource table in section 3.4.

There is renewable, a DHCPv6 option described in section 22.6, which allows
clients and
by how long.
15.2. Reconfigure Considerations

A server implementation MUST provide an interface servers to the
administrator exchange values for initiating reconfigure events.

A server implementation may provide some of the timing
and retransmission parameters defined in section 3.5. Adding new
parameters in the future would require extending the values by which
the parameters are indicated in the DHCP option. Since there needs
to be a mechanism for allowing list kept, the
specification default values for each parameter should also
be stored as part of how many clients comprise a reconfigure multicast
group. This enables the administrator list.

All of these protocol elements may be specified to control assume new values
at some point in the hit a server
takes when a reconfigure event occurs.
15.3. Server Preference

The server implementation SHOULD allow future. New values should be approved by the setting
process of IETF Consensus [10].

21. Acknowledgments

Thanks to the DHC Working Group for their time and input into the
specification. Ralph Droms and Thomas Narten have had a server
preference value by major
role in shaping the administrator. The server preference
variable is an unsigned single octet value (0--255), with continued improvement of the lowest
preference being 0 protocol by their
careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald
Maguire, and Mike Carney for their studied review as part of the highest 255. Clients will choose higher
preference servers over those with lower preference values. If you

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 46] 41]

Internet Draft DHCP for IPv6 5 May 22 November 2000

don't choose to implement this feature in your server, you MUST set
the server preference field to 0 in

Last Call process. Thanks also for the Advertise messages generated
by your server.
15.4. Request Message Transaction-ID Cache

In order to improve performance, a server implementation MAY include
an in memory transaction-ID cache. This cache is indexed by client
binding consistent input, ideas, and transaction-ID,
review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
Rekhter, Matt Thomas, Sue Thomson, and enables the server Phil Wells.

Thanks to quickly
determine whether a Request is a retransmission or a new Request
without Steve Deering and Bob Hinden, who have consistently
taken the cost of a database lookup. If an implementor chooses to
implement this cache, then they SHOULD provide a configuration knob time to tune discuss the lifetime more complex parts of the cache entries.
16. IPv6
specifications.

22. DHCP Relay Implementator Notes

A relay implementation SHOULD allow the specification of a list of
destination addresses for Solicit messages. This list MAY contain
any mixture of unicast addresses options

Options are used to carry additional information and multicast addresses.

If a relay receives an ICMP message parameters
in response to a DHCP message it
has forwarded, it SHOULD log this event.
17. Open Issues for Working Group Discussion

This messages. Every option shares a common base format, as
described in section contains some items for discussion by 22.1.

this document describes the working group.
17.1. Trade-offs: Optional fields in DHCP messages

You'll notice that the message formats have changed. In particular,
some options defined as part of the optional fields are now required. This will increase the
size of base
DHCP messages specification. Other options may be defined in some cases, consuming network bandwidth and
memory on the future in a
separate document.

22.1. Format of DHCP client (an issue for small devices such as PDAs).

The changes were made for options

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code
An unsigned integer identifying the specific option type
carried in this option.

option-len
An unsigned integer giving the following reasons:

o Fields that were used most length of the time were made required.

o Some fields that were optional were either made required or added
to messages which previously didn't have them. This was done data in
this option in bytes.

option-data
The data for
robustness reasons (receivers can validate that the message is
for them, and in option; the case format of clients, know which interface this data depends
on the
message is intended for).

o Simplicity. definition of the option.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 47] 42]

Internet Draft DHCP for IPv6 5 May 22 November 2000

Please look at the messages as they are now defined, and let us know
your opinion.
17.2. Use DHCPv4 authentication or

22.2. Identity association option

The identity association option is used to carry an identity
association, the current DHCPv6 method?

Now that parameters associated with the DHCPv4 authentication draft is in last call, should
we use IA and the technique described in that document addresses
assigned to provide
authentication for DHCPv6, or should we continue with the
authentication technique currently documented in IA.

The format of the extensions
draft?
17.3. IA option is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IA UUID |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addrs | IPv6 address |
+-+-+-+-+-+-+-+-+ (16 octets) |
| |
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | pref. len | preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref. lifetime (cont.) | valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid lifetime (cont.) | IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code
TBD

option-len
Variable; equal to 17 + num-addrs*25

IA UUID
The Reconfigure Message and Subnet Prefix Extensions unique identifier for this IA; chosen by the client

T1 The drafts currently specify that Releasable resources (such as an IP
address) can only be reconfigured using time at which the client contacts the server from
which the Reconfigure-init trigger
message. This was done for simplicity (enables clients addresses in the IA were obtained to perform
DAD on extend
the new address and return lifetimes of the appropriate result addresses assigned to the
server) using IA.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 43]

Internet Draft DHCP for IPv6 22 November 2000

T2 The time at which the same mechanism as a standard Request/Reply/Release
exchange. This method also makes no assumptions about client contacts any available
server to extend the
charactistics lifetimes of the releasable resource.

However, for IP addresses with interface IDs, one could send out
two IP assigned
to the IA.

num-addrs
An unsigned integer giving the number of addresses
carried in this IA option (MAY be zero).

IPv6 address extensions, one
An IPv6 address assigned to this IA.

preferred lifetime
The preferred lifetime for the old prefix and one associated IPv6 address.

valid lifetime
The valid lifetime for the
new, and cause clients to change the prefix associated IPv6 address.

The ``IPv6 address'', ``preferred lifetime'' and thus renumber over
time. This scheme avoids the added DHCP Request traffic - clients
acknowledge with a Reconfigure-reply message.
17.4. ``R'' bit ``valid lifetime''
fields are repeated for each address in Request message not needed?

Now that the transaction-ID is stored along with IA option (as determined
by the releasable
resource identifier in a client's binding, ``num-addrs'' field).

DISCUSSION:

The details of the transaction-ID cache
becomes format and the selection of an optional feature IA's UUID
are TBD.

DISCUSSION:

An IA has no explicit ``lifetime'' or ``lease length'' of
its own. When the DHCP server implementation, not a
requirement lifetimes of all of the protocol. Should we do away with the ``R'' bit?
18. Security Considerations

Clients and servers often addresses in an
IA have to authenticate the messages they
exchange. For instance, a server may wish to be certain that a
Request originated from the client identified by the <link-local
address, subnet-prefix> fields included within the Request message
header. Conversely, it is quite often essential for a client to
be certain that expired, the configuration parameters IA can be considered as having expired.
T1 and addresses it has
received were sent T2 are included to it by an authoritative server. Similarly, give servers explicit control over
when a client recontacts the server should only accept about a Release message which seems to be from
one of its clients, if it has some assurance that the client actually specific IA.

22.3. Option request option

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 48] 44]

Internet Draft DHCP for IPv6 5 May 22 November 2000

did transmit the Release message. Again, a client might wish to only
accept Reconfigure or Reconfigure-init messages that are certain to
have originated from a server with authority

option-code TBD.

option-len
Variable; equal to issue them.

The IPv6 Authentication Header can provide security for DHCPv6
messages when both endpoints have a suitable IP address. However,
a client often has only a link-local address, and such an address
is not sufficient for a server which is off-link. In those
circumstances the relay is involved, so that the DHCP message MUST
have twice the relay's address number of option codes
carried in this option.

option-data
A list of the IP destination address field, even
though option codes for the options requested in
this option.

22.4. Client message option

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP client aims message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code TBD

option-len
Variable; equal to deliver the length of the forwarded DHCP
client message.

option-data
The message received from the client; forwarded verbatim
to the server. The
DHCP Client-Server Authentication Extension [2] is intended to be
used in these circumstances.

Note that, if a client receives a

22.5. Server message option

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP server message which fails
authentication, it should continue to wait |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code TBD

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 45]

Internet Draft DHCP for another message which
might be correctly authenticated just as if the failed message had
never arrived; however, receiving such failed messages SHOULD be
logged.
19. Year IPv6 22 November 2000 considerations

Since all times are relative

option-len
Variable; equal to the current time of the transaction,
there is no problem within the DHCPv6 protocol related to any
hardcoded dates or two-digit representation length of the current year.
20. IANA Considerations

This document defines forwarded DHCP
server message.

option-data
The message types 1--8 to be received by UDP at
port numbers 546 and 547. Additional message types may be defined in from the future.

Section 3.1 lists several multicast addresses used by DHCP.

This document also defines several status codes that are server; forwarded verbatim
to
be returned with the Reply and Reconfigure-reply messages (see
sections 9.4 and 9.7). client.

22.6. Retransmission parameter option

option-code
An unsigned integer identifying the specific option type
carried in this option.

option-len
An unsigned integer giving the length of the data in
this option in bytes.

option-data
The non-zero values data for these status codes
which are currently specified are shown in the table option; the format of this data depends
on the definition of the option.

22.7. Authentication option

The authentication option is TBD.

23. Changes in this draft

This section 3.4.

There is a describes the changes between this version of the DHCPv6 extension [2] which allows clients
specification and servers to
exchange values draft-ietf-dhc-dhcpv6-15.txt.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 46]

Internet Draft DHCP for some IPv6 22 November 2000

23.1. Order of sections

New sections have been added at the timing and retransmission parameters
defined end of this document to minimize
changes in section 3.5. Adding new parameters numbering. Those sections will be rearranged in the a
future would
require extending revision.

23.2. Reconfigure message

DHCP Reconfigure and Reconfigure-reply messages and the values by which associated
mechanisms have been removed from this draft of the parameters specification.

23.3. Releasable resources

``Releasable resources'' have been removed from this draft.

23.4. DHCP message header

A common fixed DHCP message header has been defined. Not all fields
are indicated used in all messages.

23.5. Design goals

The second sentence in the 8th design goal bullet has been removed.

23.6. Overview

Section 8.2 (DHCP agents) has been removed. DHCP extension. Since there needs clients no longer
need to be a list kept, know about specific DHCP agents.

Section 8.3 has been modified to reflect the default
values for each parameter should also be stored as part new encapsulating
mechanism through which relays forward client messages to servers.

Section 8.6 and 8.7 have been modified to describe ``identity
associations''.

Section 8.8 has been modified to reflect the deletion of
``reconfigure'' and ``reconfigure-reply'' messages.

23.7. Message formats, 9

Message formats have been changed. All messages share a common fixed
message header followed by options. The various control bits (``P'',
``C'') have been removed from the list. message header.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 49] 47]

Internet Draft DHCP for IPv6 5 May 22 November 2000

All

23.8. Solicit and Advertise messages, (section 10)

The description of these protocol elements may be specified to assume new values
at some point in the future. message exchanges have been changed to
reflect:

- New values should be approved by the
process relay behavior - encapsulated client messages

- Use of IETF Consensus [11].
21. Acknowledgements

Thanks to the DHC Working Group for their time and input into the
specification. Ralph Droms and Thomas Narten have had a major
role IAs

23.9. Prefix advertisement

Servers no longer advertise prefixes.

23.10. Identity Associations

Section 9.11 describes IAs in shaping the continued improvement detail. A definition of the protocol by their
careful reviews. Many thanks ``IA'' has
been added to Matt Crawford, Erik Nordmark, Gerald
Maguire, and Mike Carney for their studied review as part section 2. The description of messages exchanges
have been extended to include IAs. The IA option is defined in
section 22.2

23.11. Extensions renamed options; defined in this document

``extensions'' are now called ``options''; the
Last Call process. Thanks also for the consistent input, ideas, options referenced in
this document are defined in section 22.

23.12. Transaction-ID ranges

Solicit, Advertise, Request, Reply, Release and
review Reconfigure-init
messages all use an unsigned 16-bit integer ``Transaction-ID''.
Transaction-IDs generated by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.

Thanks clients are considered to Steve Deering be chosen from
a different namespace than those chosen by servers. There is no
need to restrict clients and Bob Hinden, who have consistently
taken the time servers to discuss select Transaction-IDs from
specific ranges to avoid conflicts.

23.13. Release messages and relays

Release/Reply messages are forwarded through relays. This mechanism
eliminates the more complex parts need for an 'R' bit.

23.14. Discovering relay agents

Clients no longer learn the identity of relay agents. When the
client only has a link-local address (e.g., the client has no

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 48]

Internet Draft DHCP for IPv6
specifications. 22 November 2000

assigned addresses), it now multicasts Request message, which is then
forwarded by a relay agent on the same link.

A. Comparison between DHCPv4 and DHCPv6

This appendix is provided for readers who will find it useful to see
a model and architecture comparison between DHCPv4 [7, [6, 1] and DHCPv6.
There are three key reasons for the differences:

o IPv6 inherently supports a new model and architecture for
communications and autoconfiguration of addresses.

o DHCPv6 benefits from the new IPv6 features.

o New features were added to support the expected evolution and
the existence of more complicated Internet network service
requirements.

IPv6 Architecture/Model Changes:

o The link-local address permits a node to have an address
immediately when the node boots, which means all clients have a
source IP address at all times to locate an on-link server or
relay.

o The need for BOOTP compatibility and the broadcast flag have been
removed.

o Multicast and address scoping in IPv6 permit the design of
discovery packets that would inherently define their range by the
multicast address for the function required.
Bound, Carney, Perkins Expires 1 November 2000 [Page 50]

Internet Draft DHCP for IPv6 5 May 2000

o Stateful autoconfiguration has to coexist and integrate with
stateless autoconfiguration supporting Duplicate Address
Detection and the two IPv6 lifetimes, to facilitate the dynamic
renumbering of addresses and the management of those addresses.

o Multiple addresses per interface are inherently supported in
IPv6.

o Some DHCPv4 options are unnecessary now because the configuration
parameters are either obtained through IPv6 Neighbor Discovery or
the Service Location protocol [16]. [15].

DHCPv6 Architecture/Model Changes:

o The message type is the first byte in the packet.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 49]

Internet Draft DHCP for IPv6 22 November 2000

o IPv6 Address allocations are now handled in a message extension option as
opposed to the message header.

o Client/Server bindings are now mandatory and take advantage of
the client's link-local address to always permit communications
either directly from an on-link server, or from a off-link server
through an on-link relay.

o Servers are discovered by a client Solicit, followed by a server
Advertise message

o The client will know if the server is on-link or off-link.

o The on-link relay may locate off-link server addresses from
system configuration or by the use of a site-wide multicast
packet.

o ACKs and NAKs are not used.

o The server assumes the client receives its responses unless it
receives a retransmission of the same client request. This
permits recovery in the case where the network has faulted.

o Clients can issue multiple, unrelated Request messages to the
same or different servers.

o The function of DHCPINFORM is inherent in the new packet design;
a client can request configuration parameters other than IPv6
addresses in the optional extension option headers.

o Clients MUST listen to their UDP port for the new Reconfigure
message from servers.

Bound, Carney, Perkins Expires 1 November 2000 [Page 51]

Internet Draft DHCP for IPv6 5 May 2000

o New extensions options have been defined.

With the changes just enumerated, we can support new user features,
including

o Configuration of Dynamic Updates to DNS

o Address deprecation, for dynamic renumbering.

o Relays can be preconfigured with server addresses, or use of
multicast.

o Authentication

o Clients can ask for multiple IP addresses.

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 50]

Internet Draft DHCP for IPv6 22 November 2000

o Addresses can be reclaimed using the Reconfigure-init message.

o Integration between stateless and stateful address
autoconfiguration.

o Enabling relays to locate off-link servers.

B. Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Bound, Carney, Perkins Expires 1 November 2000 [Page 52]

Internet Draft DHCP for IPv6 5 May 2000
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

References

[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. Request for Comments (Draft Standard) 2132,
Internet Engineering Task Force, March 1997.

[2] J. Bound, M. Carney, and C. Perkins. Extensions for the Dynamic
Host Configuration Protocol for IPv6.
draft-ietf-dhc-dhcpv6ext-12.txt, May 2000. (work in progress).

[3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.

[4]

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 51]

Internet Draft DHCP for IPv6 22 November 2000

[3] S. Bradner and A. Mankin. The Recommendation for the IP Next
Generation Protocol. Request for Comments (Proposed Standard)
1752, Internet Engineering Task Force, January 1995.

[5]

[4] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for
Comments 951, Internet Engineering Task Force, September 1985.

[6]

[5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.

[7]

[6] R. Droms. Dynamic Host Configuration Protocol. Request for
Comments (Draft Standard) 2131, Internet Engineering Task Force,
March 1997.

[8]

[7] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
Request for Comments (Proposed Standard) 2373, Internet
Engineering Task Force, July 1998.

[9]

[8] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.

[10]

[9] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for
IP version 6. Request for Comments (Proposed Standard) 1981,
Internet Engineering Task Force, August 1996.

[11]

[10] T. Narten and H. Alvestrand. Guidelines for Writing an IANA
Considerations Section in RFCs. Request for Comments (Best
Current Practice) 2434, Internet Engineering Task Force, October
1998.
Bound, Carney, Perkins Expires 1 November 2000 [Page 53]

Internet Draft DHCP for IPv6 5 May 2000

[12]

[11] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998.

[13]

[12] D. C. Plummer. Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware. Request for Comments
(Standard) 826, Internet Engineering Task Force, November 1982.

[14]

[13] J. Postel. User Datagram Protocol. Request for Comments
(Standard) 768, Internet Engineering Task Force, August 1980.

[15]

[14] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard) 2462,
Internet Engineering Task Force, December 1998.

[16]

Bound, Carney, Perkins, Droms (ed.) Expires 1 May 2001 [Page 52]

Internet Draft DHCP for IPv6 22 November 2000

[15] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. Request for Comments (Proposed Standard)
2165, Internet Engineering Task Force, June 1997.

[17]

[16] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic
Updates in the Domain Name System (DNS UPDATE). Request for
Comments (Proposed Standard) 2136, Internet Engineering Task
Force, April 1997.

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 54] 53]

Internet Draft DHCP for IPv6 5 May 22 November 2000

Chair's Address

The working group can be contacted via the current chair:

Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Cisco Systems
300 Apollo Drive
Chelmsford, MA 01824

Phone: (570) 577-1145 (978) 244-4733
E-mail: droms@bucknell.edu rdroms@cisco.com

Author's Address

Questions about this memo can be directed to:

Jim Bound
Compaq Computer Corporation
Mail Stop: ZK03-3/U14
110 Spitbrook Road
Nashua, NH 03062
USA
Phone: +1-603-884-0400
Email: bound@zk3.dec.com

Mike Carney
Sun Microsystems, Inc
Mail Stop: UMPK17-202
901 San Antonio Road
Palo Alto, CA 94303-4900
USA
Phone: +1-650-786-4171
Email: mwc@eng.sun.com

Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502

Bound, Carney, Perkins Perkins, Droms (ed.) Expires 1 November 2000 May 2001 [Page 55] 54]
----