WDIFF

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

Internet Engineering Task Force J. Bound
INTERNET DRAFT Compaq Computer Corp.
DHC Working Group C. Perkins M. Carney
Obsoletes: draft-ietf-dhc-dhcpv6-13.txt draft-ietf-dhc-dhcpv6-14.txt Sun Microsystems Laboratories
25 February 1999 Microsystems, Inc
C. Perkins
Nokia Research Center
5 May 2000
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-14.txt
draft-ietf-dhc-dhcpv6-15.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 (DHCPv6) for IPv6 (DHCP) enables
DHCP servers to pass configuration information, via extensions, parameters using extensions 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 the IPv6 ``IPv6 Stateless Address
Autoconfiguration protocol,
Autoconfiguration'' [15], and can be used separately or together concurrently
with the latter to obtain configuration information. parameters.

Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page i]

Internet Draft DHCP Version 6 25 February 1999 for IPv6 5 May 2000
Contents
Status of This Memo i

Abstract i

1. Introduction 1

2. Terminology and Definitions 2
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCPv6 DHCP Terminology . . . . . . . . . . . . . . . . . . . 3
2.3. Specification Language . . 3

3. DHCP Constants 5
3.1. Multicast Addresses . . . . . . . . . . . . . . . 4
2.4. Error Values . . . . 5
3.2. UDP ports . . . . . . . . . . . . . . . . . . 4

3. Protocol Design Model 4
3.1. Design Goals . . . . . . 5
3.3. DHCP message types . . . . . . . . . . . . . . . . 4
3.2. DHCP Messages . . . 6
3.4. Error Values . . . . . . . . . . . . . . . . . . . 5
3.3. Request/Response Processing Model . . . 8
3.4.1. Generic Error Values . . . . . . . . . 7

4. DHCP Message Formats and Field Definitions 8
4.1. DHCP Solicit Message Format . . . . . 8
3.4.2. Server-specific Error Values . . . . . . . . . . 8
4.2. DHCP Advertise Message Format
3.5. Configuration Variables . . . . . . . . . . . . . . 9
4.3. DHCP Request Message Format . . . 8

4. Requirements 9

5. Background 9

6. Design Goals 11

7. Non-Goals 11

8. Overview 12
8.1. How does a node know to use DHCP? . . . . . . . . . . . . 10
4.4. 12
8.2. How does a client find out about DHCP Reply Message Format . agents? . . . . . . 12
8.3. What if the client and server(s) are on different links? 12
8.4. How does a client request configuration parameters from
servers? . . . . . . . . . 12
4.5. DHCP Release Message Format . . . . . . . . . . . . . . 13
8.5. What are releasable resources, and when are they used? . 13
4.6. DHCP Reconfigure Message Format
8.6. Can a client release its releasable resources before the lease
expires? . . . . . . . . . . . . . . 15

5. DHCP Client Considerations 16
5.1. Verifying Resource Allocations After Restarts . . . . . . 16
5.2. Sending DHCP Solicit Messages . . . 14
8.7. What if the client determines its releasable resource is
already being used by another client? . . . . . . . . 14
8.8. How are clients notified of server configuration changes? 14

9. Message Formats 15
9.1. DHCP Solicit Message Format . . . 16
5.3. Receiving DHCP Advertise Messages . . . . . . . . . . . . 17
5.4. Sending 15
9.2. DHCP Request Messages Advertise Message Format . . . . . . . . . . . . . . 18
5.5. Receiving 16
9.3. DHCP Reply Messages Request Message Format . . . . . . . . . . . . . . 20
5.6. Sending . 18
Bound, Carney, Perkins Expires 1 November 2000 [Page ii]

Internet Draft DHCP Release Messages for IPv6 5 May 2000

9.4. DHCP Reply Message Format . . . . . . . . . . . . . . 20
5.7. Receiving . . 19
9.5. DHCP Reconfigure Messages Release Message Format . . . . . . . . . . . 21
5.8. Interaction with Stateless Address Autoconfiguration . . 22

6. DHCP Server Considerations 23
6.1. Receiving . . 20
9.6. DHCP Solicit Messages Reconfigure Message Format . . . . . . . . . . . . . 23
6.2. Sending 22
9.7. DHCP Advertise Messages Reconfigure-reply Message Format . . . . . . . . . . 23
9.8. DHCP Reconfigure-init Message Format . . . . . . . . . . 24
6.3.

10. DHCP Request Server Solicitation and Reply Subnet Prefix Discovery 25
10.1. Solicit Message Processing Validation . . . . . . . . . 24
6.3.1. Processing for Extensions to DHCP Request and Reply
Messages . . . . . . 25
10.2. Advertise Message Validation . . . . . . . . . . . . . . 25
6.3.2.
10.3. Client Requests to Deallocate Unknown Resources Behavior . . . . . . . . 26
6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 26
6.5. Sending DHCP Reconfigure Messages
10.3.1. Creation and sending of the Solicit message . . . 26
10.3.2. Time out and retransmission of Solicit Messages . 27
10.3.3. Receipt of Advertise messages . . . . . . . . . . 27

Bound, Perkins Expires 25 August 1999 [Page ii]

Internet Draft DHCP Version 6 25 February 1999

6.6. Client-Resource timeouts
10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 28

7. DHCP Relay Considerations
10.4.1. Relaying of Solicit messages . . . . . . . . . . 28
7.1. DHCP
10.4.2. Relaying of Advertise messages . . . . . . . . . 28
10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28
10.5.1. Receipt of Solicit messages . . . . . . . . . . . 28
10.5.2. Creation and DHCP sending of Advertise Message Processing messages . . . 28
7.2. 29

11. DHCP Client-Initiated Configuration Exchange 29
11.1. Request Message Processing Validation . . . . . . . . . . . . . . . 29
7.3. DHCP
11.2. Reply Message Processing Validation . . . . . . . . . . . . . . . . 30

8. Retransmission
11.3. Release Message Validation . . . . . . . . . . . . . . . 31
11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31
11.4.1. Creation and Configuration Variables 30

9. Security Considerations sending of Request messages . . . . 32
11.4.2. Time out and retransmission of Request Messages . 33

10. Year 2000 considerations
11.4.3. Receipt of Reply message in response to a Request 33

11. IANA Considerations
11.4.4. Creation and sending of Release messages . . . . 33
11.4.5. Time out and retransmission of Release Messages . 34
11.4.6. Receipt of Reply message in response to a Release 35
11.5. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 35
11.5.1. Relaying of Request or Release messages . . . . . 35
11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35
11.6.1. Receipt of Request messages . . . . . . . . . . . 35
11.6.2. Receipt of Release messages . . . . . . . . . . . 36
11.6.3. Creation and sending of Reply messages . . . . . 36

12. Acknowledgements 34

A. Changes DHCP Server-Initiated Configuration Exchange 37
12.1. Reconfigure Message Validation . . . . . . . . . . . . . 37
12.2. Reconfigure-reply Message Validation . . . . . . . . . . 38
12.3. Reconfigure-init Message Validation . . . . . . . . . . . 38
12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 38
12.4.1. Creation and sending of Reconfigure messages . . 39
12.4.2. Time out and retransmission of Reconfigure
messages . . . . . . . . . . . . . . . . . 40
12.4.3. Receipt of Reconfigure-reply messages . . . . . . 40
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

12.4.5. Time out and retransmission of Reconfigure-init
messages . . . . . . . . . . . . . . . . . 41
12.4.6. Receipt of Request messages . . . . . . . . . . . 41
12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 41
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. Creation and sending of Request messages . . . . 43
12.5.5. Time out and retransmission of Request messages . 43
12.5.6. Receipt of Reply messages . . . . . . . . . . . . 43

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

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

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

16. DHCP Relay Implementator Notes 47

17. Open Issues for Working Group Discussion 47
17.1. Trade-offs: Optional fields in DHCP messages . . . . . . 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 2000 considerations 49

20. IANA Considerations 49

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 DHCP for IPv6 5 May 2000

Author's Address 55
Bound, Carney, Perkins Expires 1 November 2000 [Page v]

Internet Draft DHCP for IPv6 5 May 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
in order to reduce the cost of ownership and management of network
nodes.

The DHCP reduces the cost of ownership by centralizing the 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.
The DHCP is designed to be easily extended to carry new configuration
parameters through the addition of new DHCP ``extensions'' defined to
carry this information. See 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 this revision 34

B. Related 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 Specifications 35

C. Comparison between DHCPv4 Version 6 (IPv6). The terms IPv4 and DHCPv6 37

D. Full Copyright Statement 40

Chair's Address 43

Author's Address 43
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 25 August 1999 1 November 2000 [Page iii] 2]

Internet Draft DHCP Version 6 25 February 1999

1. Introduction

The Dynamic Host Configuration Protocol (DHCPv6, or in this
document usually DHCP) provides configuration parameters for IPv6 5 May 2000

having the subnet prefix (FE80::0000/64), that can be
used to Internet
nodes. DHCP consists of reach neighboring nodes attached to the same
link. Every interface has a protocol for delivering node-specific
configuration parameters from link-local address.

message A unit of data carried in a packet, exchanged between
DHCP server to a client, agents and
extensions for allocation 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 network addresses and other related
parameters some number of initial
bits of an address.

router A node that forwards IP packets not explicitly
addressed to IPv6 [7] nodes. itself.
2.2. DHCP uses a client-server model, where designated Terminology

Terminology specific to DHCP servers
automatically allocate network addresses and deliver configuration
parameters can be found below.
abort status
A status value returned to dynamically configurable clients. Throughout the
remainder application that has
invoked a DHCP client operation, indicating anything
other than success.

agent address
The address of this document, a neighboring DHCP Agent on the term "server" refers to same
link as the DHCP client.

binding A binding (or, client binding) is a node
providing initialization parameters by way group of server
data records indexed by <client's link-local address,
subnet prefix> containing the releasable resource data
which a DHCP protocol,
and the term "client" refers server has assigned to a node requesting initialization
parameters client.

Note that the transaction-ID from a DHCP server.

DHCPv6 uses the Request and Reply messages to support a client/server
processing model whereby both client and server are assured message
that
requested configuration parameters have been received and accepted
by produced the client. DHCP supports optional configuration parameters and
processing for nodes through extensions described assignment of the releasable resource
is also stored in its companion
document ``Extensions for the server data record including the
releasable resource identifier.

DHCP Dynamic Host Configuration Protocol for
IPv6'' [15]. IPv6. The IPv6 Addressing Architecture [9]
terms DHCPv4 and IPv6 Stateless Address
Autoconfiguration [20] specifications provide new features not
available in IP version 4 (IPv4) [18], which DHCPv6 are used to simplify
and generalize the operation of DHCP clients. This document only in contexts where
it is
intended to complement those specifications for clients attached necessary to
the kinds of avoid ambiguity.
Bound, Carney, Perkins Expires 1 November 2000 [Page 3]

Internet media Draft DHCP for which those specifications apply. In
particular, IPv6 5 May 2000

configuration parameter
An element of the specification in this document does not necessarily
apply configuration information set on the
server and delivered to nodes which do not enjoy the client using DHCP. Such
parameters may be used to carry information to be used
by a bidirectional link node to the
Internet.

Section 2 provides definitions configure its network subsystem and enable
communication on a link or internetwork, for terminology used throughout
this document. Section 3 provides an overview 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 the protocol
design model network topology managed by DHCP and
operated by a single administrative entity.

DHCP server (or server)
A server is a node that guided the design choices in responds to requests from
clients, and may or may not be on the specification;
section 3.2 briefly describes same link as the protocol
client(s).

DHCP relay (or relay)
A node that acts as an intermediary to deliver DHCP
messages between clients and their
semantics. Section 4 provides the message formats and field
definitions used for each message. Sections 5, 6, and 7 specify
how clients, servers, and relays respectively interact. The timeout
and retransmission guidelines is on the
same link as well 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 variables resource allocated by a server for
DHCP protocol operations
a finite period of time. As of this writing, the
only example of such a resource is the IP address.
Releasable resources are discussed in Section 8. Appendix B
summarizes related work carried in IPv6 that will provide helpful context;
it is not part extensions
allocated out of this specification, but included for informational
purposes. Appendix C discusses the differences between DHCPv4 1--8192 range.

solicit-ID
An unsigned integer generated by the client and
DHCPv6.
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 25 August 1999 1 November 2000 [Page 1] 4]

Internet Draft DHCP Version 6 25 February 1999

2. Terminology for IPv6 5 May 2000

allocate their transaction-IDs from the range of
0--1023, and Definitions

Relevant terminology clients allocate their transaction-IDs
from the IPv6 Protocol [7], IPv6 Addressing
Architecture [9], range of 1024--65535. Limiting clients and IPv6 Stateless Address Autoconfiguration [20]
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 given, followed used by DHCPv6 terminology.

2.1. IPv6 Terminology 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 An IP layer identifier for an interface is used by clients or a set of
interfaces.
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
An identifier address(es).
Note that in order for a single interface. A packet sent client to a unicast use this address,
it must have an address is delivered of sufficient scope to the interface
identified be
reachable by that address. the server(s). All servers within the
site are members of this multicast address
An identifier for 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 set of interfaces (typically
belonging local configuration parameter to different nodes). A packet sent
facilitate the use of DHCP through firewalls.

546 Client port. Used by agents to a
multicast address is delivered send messages to all interfaces
identified
clients. Also used by that address.

host Any node that is not a router.

IP servers to send messages to
relays.
Bound, Carney, Perkins Expires 1 November 2000 [Page 5]

Internet Protocol Version 6 (IPv6). The terms IPv4 and Draft DHCP for IPv6 are 5 May 2000

547 Agent port. Used by clients to send messages to
agents. Also used only in contexts where it is necessary by relays to
avoid ambiguity.

interface
A node's attachment send messages to a link.

link A communication facility or medium over which nodes
can communicate at the link layer, i.e.,
servers.
3.3. DHCP message types

The DHCP defines 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, following message types. More detail on these
message types can be found in Section 9. Message types 0 and E.164 addresses for ISDN links.

link-local address
An IP address having link-only scope, indicated 9--255
are reserved and MUST be silently ignored.

01 DHCP Solicit

The DHCP Solicit (or Solicit) message is used by
having clients to
locate servers and (optionally) learn about the routing prefix (FE80::0000/64), subnet prefixes
on the client's link for networks that can be 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 reach neighboring nodes attached Solicits. This message is unicast to the same
link. Every interface has a
client's link-local address.

Bound, Perkins Expires 25 August 1999 [Page 2]

Internet Draft 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 Version 6 25 February 1999

message A unit of data carried in a packet, exchanged between Request

The DHCP agents and clients.

neighbor A node attached Request (or Request) message is used by clients to
request configuration parameters from servers. This message
is unicast 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 server if the client has an address.

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

2.2. DHCPv6 Terminology

agent 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 address DHCP Reply (or Reply) message is used by servers responding
to Request and Release messages. In the case of responding to
a neighboring DHCP Agent on Request message, the same
link as Reply contains configuration parameters
destined for the DHCP client.

binding A binding (or, This message is unicast to the client binding) containing
if the data
which a DHCP server maintains for each client has an address of its clients
(see Section 6).

resource-server association
An association between a resource and a sufficient scope that is
Bound, Carney, Perkins Expires 1 November 2000 [Page 6]

Internet Draft DHCP server,
maintained for IPv6 5 May 2000

reachable by the client server. Otherwise, it is unicast to the relay
through which received that resource
from that 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 server.

configuration parameter
Any parameter that can be Release

The DHCP Release (or Release) message is used by a node clients to configure
its network subsystem and enable communication on a
link
return one or internetwork.

DHCP more instances of releasable resources (e.g. IP
addresses) to servers. This message is unicast to the server
if the client (or client)
A node that initiates requests on a link will have an address of sufficient scope after
the Release operation to obtain
configuration parameters.

DHCP 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 server)
A server Reconfigure) message is a node that responds sent by
servers to requests from
clients, and may client(s). It contains new or updated configuration
parameters for use by the client(s). This message may not be on
unicast or multicast to the same link as as client(s).

Section 9.6 contains more details about the client. Reconfigure
message.

07 DHCP relay (or relay)
A node that acts as an intermediary to deliver Reconfigure-reply

The DHCP
messages between clients and servers, and Reconfigure-reply (or Reconfigure-reply) message is on
unicast by client(s) to the
same link as a client.

Bound, Perkins Expires 25 August 1999 [Page 3]

Internet Draft DHCP Version 6 25 February 1999

DHCP agent (or agent)
Either a DHCP server on to acknowledge the same link as a client, or receipt
of a Reconfigure message.

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

08 DHCP relay.

transaction-ID
An unsigned integer to match responses with replies
initiated either Reconfigure-init

The DHCP Reconfigure-init (or Reconfigure-init) message is set
by a client or server. Clients MUST
use integers from 1 server(s) to 1000, and servers use integers
greater than 1000 for transaction-ID's.

2.3. Specification Language

In this document, inform client(s) that the words MUST, MUST NOT, SHOULD, SHOULD NOT, server(s) has new or
updated configuration parameters, and
MAY that the client(s) are used
to signify the requirements of initiate a Request/Reply transaction with the specification, server(s) in
accordance with RFC 2119 [2].

2.4.
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 specification document uses 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 known
to DHCP clients and servers, as used for instance are organized in the status field
of the DHCP Reply message (see section 4.4). logical groups.

3.4.2. Server-specific Error Values

The following symbolic names have are used by server implementations to
convey error conditions to clients. The following table contains the
actual numeric values listed below:

Error Name ErrorID
================================
PoorlyFormed 18
Unavail 19
NoBinding 20
InvalidSource 21
NoServer 23
ICMPError 64

3.5. Configuration Variables

This section is provided presents a table of client and server configuration
variables and the default or initial values for implementors to understand these variables. The
client-specific variables MAY be configured on the DHCPv6
protocol design model from an architectural perspective. Goals server and
conceptual models are presented MAY be
delivered to the client through the ``DHCP Retransmission Parameter
Extension''carried in this section.

3.1. Design Goals

The following list gives general design goals for this DHCP
specification. a Reply message. This extension is documented
in the ``extensions document'' [2].

Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 4] 8]

Internet Draft DHCP Version 6 25 February 1999

- DHCP should be a mechanism rather than a policy. DHCP must allow
local system administrators control over configuration parameters
where desired; e.g., local system administrators should be able
to enforce local policies concerning allocation and access to
local resources where desired.

- DHCP must not require manual configuration of DHCP clients,
except as dictated by security requirements. Each node should be
able to obtain appropriate local configuration parameters without
user intervention.

4. Requirements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and economy, DHCP must work across DHCP relays.

- In some installations, clients on certain subnets can be served
by more than one DHCP server, improving reliability and/or
performance. Therefore, a DHCP client must be prepared to
receive multiple (possibly different) responses OPTIONAL, when they appear in this
document, are to a DHCP Solicit
message.

- DHCP 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 coexist with statically configured, non-participating
nodes allow system administrators to change. The
specific variable names, how their values change, and with existing network how their
settings influence protocol implementations.

- DHCPv6 must be compatible 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 [20].

- A DHCPv6 Client implementation may be started in [15], IPv6 Neighbor
Discovery Processing [12], and Dynamic Updates to DNS [17]. These
specifications enable DHCP to build upon the absence IPv6 work to provide
both robust stateful autoconfiguration and autoregistration of
any DNS
Host Names.

The IPv6 routers on Specification provides the client's link.

- DHCP base architecture must support automated renumbering and design of IP
addresses [3].

-
IPv6. A key point for DHCP servers should be able to support Dynamic Updates implementors to
DNS [22].

- 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 servers must be able to support multiple for IPv6 addresses 5 May 2000

(less 40 octets for
each client.

On the other hand, 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 server implementation needs to server protocol is NOT part of
this specification. Furthermore, it is NOT send a design goal
packet greater than 1500 octets it can either fragment the UDP packet
into fragments of DHCP to
specify how a server configuration parameter database is maintained 1500 octets or determined. Methods for configuring DHCP servers are outside less, or use Path MTU Discovery [10]
to determine the
scope size of this document.

3.2. the packet that will traverse a network
path.

DHCP Messages

Each clients use Path MTU discovery when they have an address of
sufficient scope to reach the DHCP message contains server. If a type, which defines DHCP client does not
have such an address, that client MUST fragment its function within packets if the protocol. Formats
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 messages are found PMTU changes for a
destination.

The IPv6 Addressing Architecture specification [8] defines the
address scope that can be used in section 4, with

Bound, Perkins Expires 25 August 1999 [Page 5]

Internet Draft DHCP Version 6 25 February 1999 an initial description IPv6 implementation, and discussion. Processing details the
various configuration architecture guidelines for these
DHCP messages network designers
of the IPv6 address space. Two advantages of IPv6 are specified in Sections 5, 6, that support
for multicast is required, and 7. The message
types are as follows:

01 DHCP Solicit

The DHCP 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 is an IP multicast message sent by and locate a
client to one or more agents, server or forwarded relay.

IPv6 Stateless Address Autoconfiguration [15] (Addrconf) specifies
procedures by which a relay node may autoconfigure addresses based on
router advertisements [12], and the use of a valid lifetime to one
support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or
more servers.

02 DHCP Advertise stateful
autoconfiguration is specified. The DHCP Advertise is an IP unicast message sent by one vehicle to perform
stateful autoconfiguration. Compatibility with addrconf is a design
requirement of DHCP
Agent (see Section 6).

IPv6 Neighbor Discovery [12] is the node discovery protocol in response 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 client's DHCP Solicit message.

03 specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP Request can use
the dynamic updates to DNS to integrate addresses and name space
to not only support autoconfiguration, but also autoregistration
in IPv6. The DHCP Request is an IP unicast message sent by a client security model to a
server be used with DHCPv6 should conform
as closely as possible to request configuration parameters on a network.

04 the authentication model outlined in
RFC2402 [9].
Bound, Carney, Perkins Expires 1 November 2000 [Page 10]

Internet Draft DHCP Reply

The for IPv6 5 May 2000

6. Design Goals

- DHCP Reply is an IP unicast message sent by a server in
response to mechanism rather than a client's DHCP Request, or by policy. Network administrators
set their administrative policies through the relay that
relayed that client's DHCP Request. Extensions [15] to configuration
parameters they place upon the DHCP Reply describe the resources that servers in the server has committed
and allocated to this client, and may contain other information
for use by this client.

05 DHCP Release

The domain
they're managing. DHCP Release is an IP unicast message sent by a client simply used to deliver parameters
according to
inform the server that policy to each of the client is releasing resources.

06 DHCP Reconfigure

The DHCP Reconfigure is an IP unicast or multicast message sent
by a server to inform one or more clients that within the server has
new
domain.

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

- DHCP does not require manual configuration information of importance to the client.
Each client is expected to initiate a new network parameters
on DHCP Request clients, except in
response to the Reconfiure message. cases where such configuration is
needed for security reasons. A node configuring itself using
DHCP message types should require no user intervention.

- DHCP does not defined here (msg-types 0 and 7-255) are
reserved require a server on each link. To allow for scale
and SHOULD be silently ignored.

Bound, Perkins Expires 25 August 1999 [Page 6]

Internet Draft economy, DHCP Version 6 25 February 1999

3.3. Request/Response Processing Model

The request/response processing for DHCPv6 is transaction based must work across DHCP relays.

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

- DHCP clients can operate on a set of best-effort messages to complete link without IPv6 routers present.

- DHCP will provide the transaction.

To find a server, a client sends a ability to renumber network(s) when
required by network administrators [4].

- A DHCP Solicit client can make multiple, different requests for
configuration parameters when necessary from the interface
which it wishes one or more DHCP
servers at any time. DHCP will provide enough information
to configure. The client then awaits enable a DHCP
Advertise message containing an IP address server to keep track of a DHCP server.
Transactions are started by a client with a client's
configuration state.

- DHCP Request, which may
be issued after will contain the client knows 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 server's address. The server
then unicasts following:

- Specification of a DHCP Reply, possibly via a relay. At this point in
the flow all data has been transmitted and is presumed server to have been
received. To provide server protocol.

- How a method of recovery if either the client or DHCP server does not receive stores its messages, the client retransmits each DHCP Request message until it elicits the corresponding data.

- How to manage a DHCP Reply, domain or until it can be reasonably certain that the desired DHCP server server.
Bound, Carney, Perkins Expires 1 November 2000 [Page 11]

Internet Draft DHCP for IPv6 5 May 2000

- How a DHCP relay is unavailable, configured or what sort of information it determines that it does not want may
log.
8. Overview

This section provides a response
(i.e., it MAY abort general overview of the transaction). The timeout and retransmission
guidelines and configuration variables are discussed in Section 8.

DHCP uses UDP [17] to communicate interaction
between clients and servers. UDP
is not reliable, but the DHCP retransmission scheme just described
provides reliability between clients and servers. functional entities of DHCP. The following
well-known multicast addresses are used by overview is organized
as a series of questions and answers. Details of DHCP agents such
as message formats and clients:

FF02:0:0:0:0:0:1:2
All 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 Agents (servers and relays) MUST join the
link-local All-DHCP-Agents multicast group at for
configuration of an interface by detecting the address
FF02:0:0:0:0:0:1:2.

FF05:0:0:0:0:0:1:3
All DHCP servers MUST join presence (or absence)
of routers on the site-local
All-DHCP-Servers multicast group at link. If router(s) are present, the address
FF05:0:0:0:0:0:1:3.

FF05:0:0:0:0:0:1:4
All node examines
router advertisements to determine if DHCP relays MUST join should be used to
configure the site-local All-DHCP-Relays
multicast group at interface. If there are no routers present, then
the address FF05:0:0:0:0:0:1:4.

A DHCP server or agent node MUST transmit all messages to use DHCP clients to configure the interface. Detail on
UDP port 546. A
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 MUST transmit all messages to forms a DHCP
agent over UDP using port 547. A DHCP server MUST transmit all
messages Solicit message, and multicasts it to the
FF02::1:2(All DHCP relays over UDP on port 546. The source port for
DHCP messages is arbitrary.

For Agents) address. Server(s) receiving the proper operation of Solicit
respond with Advertise message(s). If requested in the DHCP protocol to operate within a
network where client's
Solicit message, the Advertise message(s) can include one or more firewallsare used, DHCP transactions sent
to
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 addresses address(es) of DHCP servers at UDP destination ports 546 agents(s) on the
link, it can request configuration parameters from servers.
8.3. What if the client and
547 will need to be permitted.

Bound, Perkins Expires 25 August 1999 [Page 7]

Internet Draft DHCP Version 6 25 February 1999

4. server(s) are on different links?

Use of DHCP Message Formats and Field Definitions

All reserved fields in such environments requires one or more DHCP relays
be set up on the client's link, because a message MUST be transmitted as zeroes client may only have a
link-local address. Relays pick up the Solicit and
ignored by Request messages
from the receiver client and forward them to some set of servers within the message.

4.1.
DHCP Solicit Message Format domain. A client transmits a DHCP Solicit message over relay will include one of its own addresses (of
sufficient scope) of the interface to be
configured, to obtain one or more server addresses. Unless otherwise
noted, on the value of all fields are set by same link as the client.

C If set,
The relay also includes the client requests subnet prefix length of that all servers address
in the client's messages. Servers receiving the message deallocate forwarded traffic
use this information to aid in selecting configuration parameters
appropriate to the resources associated with client's link. The servers also use the client. If set, relay's
Bound, Carney, Perkins Expires 1 November 2000 [Page 12]

Internet Draft DHCP for IPv6 5 May 2000

address as the client SHOULD provide a saved
agent-address destination to locate the clients binding forward client-destined messages
for final delivery by a
server.

prefix-size A nonzero prefix-size is the number of leftmost bits relay. Relays forward client messages
to servers using some combination of the agent's IPv6 address which make up the routing
prefix. The prefix-size field is FF05::1:3(All Servers)
site-local multicast address, some other (perhaps a combination)
of site-local multicast addresses set by up within the DHCP relay
if the relay receives the solicitation and forwards it domain to one
include the servers in that domain, or more DHCP Servers.

reserved 0

client's link-local address
The IP link-local address a list of unicast addresses
for servers. The network administrator makes relay configuration
decisions based upon the client interface from
which topological requirements (scope) of the client issued
DHCP domain they are managing. Note that if the DHCP Request message

relay-address
Set by domain spans
more than the client site-local scope, then the relays MUST be configured
with global addresses for the client's link so as to be zero. If received reachable by
servers outside the relays' site-local environment.
8.4. How does a DHCP
relay, set by client request configuration parameters from servers?

To request configuration parameters, the relay client forms a Request
message, and sends it to the IP server either directly (client has an
address of sufficient scope) or indirectly (through the

Bound, Perkins Expires 25 August 1999 [Page 8]

Internet Draft DHCP Version 6 25 February 1999

interface on which the relay received on-link
relay). The client MAY include a Extension Request Extension [2]
along with other extensions to request specific information from the client's DHCP
Solicit message

saved agent-address
If present,
server. Note that the IP address 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 agent's interface
retained by application's requirements), the client from a previous DHCP
transaction.

A client SHOULD send a DHCP Solicit message 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 All-DHCP-Agents client. The Reply MAY
also include additional information, such as a reconfiguration event
multicast group (see section 3.3), setting for the relay-address client to
zero. Any relay receiving the solicitation MUST forward it join to the
All-DHCP-Servers multicast group. In that case, the relay MUST copy
a non-link-local address monitor reconfiguration
events, as described in section 8.8.

The receipt of its interface a Reply from which the client's
solicitation was received into the relay-address field. Servers
receiving a server concludes the solicitation then send their advertisements to basic
request/reply transaction of the
prospective client.

4.2. DHCP Advertise Message Format protocol.
8.5. What are releasable resources, and when are they used?

A DHCP agent sends a DHCP Advertise message releasable resource is configuration information leased to inform a prospective client about the IP address of
by a server to which a DHCP Request
message may be sent. for some finite period of time. When negotiating for a
releasable resource, the client and server are on different
links, the server sends the advertisement back through agree upon a finite period
of time the relay
whence client may use the solicitation came. resource. The value client MAY request a
renewal of all fields in the DHCP
Adverstise message are filled in by lease on the DHCP Server and not changed
by resource at any DHCP Relay.

S If set, time. The length of time
of the server-address lease (and whether it is present.

reserved 0 renewable) are server-based policy
tunables. The client MUST stop using the resource when the lease on
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 9] 13]

Internet Draft DHCP Version 6 25 February 1999

preference An octet (unsigned) indicating a server's willingness
to provide service to for IPv6 5 May 2000

the client (see Section 5.3).

client's link-local address resource expires. The IP link-local address of server MUST NOT reallocate an assigned
resource before either its lease expires or the client interface
from which releases the client issued
resource.

See the DHCP Request message

agent-address
The IP address of ``extensions document'' [2] for more information about
releasable resources.
8.6. Can a DHCP Agent interface on client release its releasable resources before the same
link as lease
expires?

A client forms a Release message, including extensions carrying the client.

server-address
If present,
resource(s) to be released. The client sends the IP address of Release to the DHCP
server

extensions See [15].

Suppose which leased the resource(s) to the client initially. If that a
server on the same link as cannot be reached after a client issues certain number of attempts (see
section 3.5), the
DHCP Advertise in response to a DHCP Solicit message sent to client can abandon the
All-DHCP-Agents multicast address. Then Release attempt. In this
case, the agent-address resource(s) will be an
IP address of one of reclaimed by the server's interfaces on server(s) when the same link as
client's lease(s) expire.
8.7. What if the client determines its releasable resource is already
being used by another client?

If the client determines through a releasable resource-specific
manner that the resource it was assigned by the server is already
in use by another client, and the `S' bit client will form a Release message,
including the extension carrying the in-use resource. The
extension's status field MUST be set to zero, indicating the absence extension-specific value
reflecting the ``in use'' status of the server-address in resource.

For example, if the DHCP Advertise message. See section 5.3
for information about how clients handle releasable resource is an IP address, the preference field.

The server MUST copy client
uses Duplicate Address Detection (DAD) to verify that the client's link-local IP address into
is not in use. If the
advertisement which client determines that the IP address is sent
already in response to use, it forms a DHCP Solicit. Both
server-address (if present) and agent-address of the DHCP Advertise Release message MUST have sufficient scope including the IP address
extension containing the appropriate status value and sends it to be reachable by the client.
Moreover,
server. See the agent-address of any DHCP Advertise message sent by a
relay MUST NOT be a link-local address. In situations where there ``extensions document''for details on the IP address
extension. [2].
8.8. How are no routers sending Router Advertisements, then a DHCP clients notified of server MUST
be configured on configuration changes?

There are two possibilities. Either the same link as prospective clients. The DHCPv6
protocol design does not apply to situations where clients discover the client is
unable to route messages to a server not on new
information when they revisit the same link.

4.3. DHCP Request Message Format

In order server(s) to request additional
configuration parameters from information / renew the lease on a server, releasable resource,
or through a client
sends server-initiated event known as a reconfigure event.

The reconfiguration feature of DHCP Request message, and MAY append extensions [15]. offers network administrators
the opportunity to update configuration information on DHCP clients
whenever necessary. If the client does information to be updated is not know any server address, it MUST first obtain
one by multicasting a
Bound, Carney, Perkins Expires 1 November 2000 [Page 14]

Internet Draft DHCP Solicit message (see Section 4.1).
Typically, when a client reboots, it does not have a valid IP address
of sufficient scope for IPv6 5 May 2000

client-specific, the server to communicate with the client.
In such cases, will form a Reconfigure message and add
the client MUST NOT send new or changed configuration information to it. The Reconfigure
may be unicast or multicast (to a preassigned multicast address for
this purpose) to one or more client(s) to which the message directly new or updated
information needs to be directed. The client(s) will acknowledge the server because
receipt of the server could not return any response Reconfigure message by forming a Reconfigure-reply
message and unicasting it to the
client; server. If the configuration
information change is different for each client MUST send (e.g. a change in
subnet prefix, perhaps, which would affect the message to IP address releasable
resource(s)), the local relay server will form a Reconfigure-init message and
insert the relay-address
unicast / multicast as needed to the agent-address in the message header.

Bound, Perkins Expires 25 August 1999 [Page 10]

Internet Draft DHCP Version 6 25 February 1999

Otherwise, client(s). A Reconfigure-init
is a trigger which will cause the client MAY omit client(s) to initiate a standard
Request/Reply exchange with the server-address server in order to acquire the DHCP Request
message; new or
updated resources.
9. Message Formats

All reserved fields in this case, the client a message MUST clear the S-bit be transmitted as zeroes and send
ignored by the receiver of the message.
9.1. DHCP Solicit Message Format

A client multicasts a DHCP Solicit message directly to the server, using the server's FF02::1:2(All DHCP
agents) address as over the IP
destination address in interface to be configured to locate one or
more servers which are configured to provide configuration parameters
to nodes on the IP header. In either case, client's link.

Unless otherwise noted, the value of all fields in
the DHCP Request message are entered 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 = 3 |C|S|R| rsvd 1 |C|P| reserved | transaction-ID prefix-len | solicit-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent-address relay-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address |
| (16 octets, if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C If set, the client requests the server to remove that all servers receiving
the message deallocate the releasable resources (e.g.
IP addresses) associated with the client binding, except
those resources provided as extensions.

S If set, the server-address is present

R client's binding.

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

Internet Draft DHCP for IPv6 5 May 2000

P If set, the client has rebooted and requests that all servers receiving
the message SHOULD return a list of its previous transaction-IDs be expunged and made
available for re-use.

rsvd subnet prefix
extensions identifying the networks on the client's
link that the server(s) are configured to manage.

reserved 0

transaction-ID
A

prefix-len
An unsigned integer identifier 7 bit number (0-127) non-zero prefix-len is
the number of leftmost 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 forwards it to one or more servers.

solicit-ID
An unsigned 9 bit number (0-511) generated by the
client used to identify this
Request. Solicit message.

client's link-local address
The IP link-local address of the client interface from
through which the client issued will issue the DHCP Request message

agent-address
The IP address of an agent's interface, copied from a
DHCP Advertisement Solicit
message.

Bound, Perkins Expires 25 August 1999 [Page 11]

Internet Draft DHCP Version 6 25 February 1999

server-address

relay-address
Set by the client to be zero. If present, received by a relay,
set by the relay to the site-local IP address of the server
interface on which should
receive the relay received the client's DHCP Request
Solicit message.

extensions See [15].

When the client sets the `C' bit and adds extensions, Note that if the server
is expected to deallocate all other resources not listed in DHCP domain crosses
site boundaries, the
extension. The resources explicitly requested relay MUST place a globally-scoped
address in extensions to the
Request message SHOULD be reallocated by the server to the client,
assuming the client is still authorized to receive them.

The transaction-ID is selected by the this field.

A client to be greater than or
equal to 1024, unless the DHCP Request is sent in response to a
Reconfigure msg (see section 4.6). In that case, MUST send the transaction-ID
is copied from Solicit message to the transaction-ID in All-DHCP-Agents
multicast group (see section 3.1), setting the Reconfigure message.

4.4. relay-address to zero.
9.2. DHCP Reply Advertise Message Format

The

A server sends one DHCP Reply an Advertise message in response to every DHCP
Request or DHCP Release received. a client's
Solicit message. The Advertise message notifies the client of the
server's IP address. If the request comes with server is so configured by the `S'
bit set, network
administrator and the client could not directly send requests it through the Request to ``P'' bit in
its Solicit message, the server
and had to use SHOULD add a neighboring relay agent. In that case, list of subnet prefix
extensions to the Advertise message to notify the client of the
networks it manages on the client's link.

When the client and server are on different links, the server sends back
the DHCP Reply with Advertise message back through the `L' bit set, and relay whence the DHCP Reply corresponding
Solicit came. The solicit-ID is addressed to the agent-address found in copied from the client's Solicit

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

Internet Draft DHCP Request message.
ALl the for IPv6 5 May 2000

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

L If set, the client's link-local address is present

Bound, Perkins Expires 25 August 1999 [Page 12]

Internet Draft DHCP Version 6 25 February 1999

status One of the following decimal values:

0 Success
16 Failure, reason unspecified
17 Authentication failed or nonexistent
18 Poorly formed Request or Release
19 Resources unavailable
20 Client record unavailable
21 Invalid client IP address in Release
23 Relay cannot find Server Address
64 Server unreachable (ICMP error)

transaction-ID and length) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0

solicit-ID An unsigned integer identifier 9 bit number (0-511) used to identify
this
Reply, and copied Advertise message. Copied from the client's Request.
Solicit message.

preference An octet (unsigned) indicating a server's willingness
to provide service to the client.

client's link-local address
If present, the
The IP link-local address of the client interface
from which the client issued the corresponding DHCP Request Solicit message.

extensions
See [15].

relay-address
The IP address of the `L' bit is set, relay interface on the client's link-local address is present
in same
link as the Reply message. Then client. Copied from the Reply is sent by client's
Solicit. If the server to is on the
relay's address which was specified same link as the agent-address in the DHCP
Request message, and the relay uses the link-local
client, then this field MUST be zero.

server-address
The site-local IP address to deliver
the Reply message to of the client. The transaction-ID in server. If the DHCP
Reply is copied by
domain crosses site boundaries, then this address
MUST be globally-scoped.

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

See Sections 14.4 and 15.3 for information about how clients and
servers handle the client Request message.

4.5. preference field.
Bound, Carney, Perkins Expires 1 November 2000 [Page 17]

Internet Draft DHCP Release for IPv6 5 May 2000

9.3. DHCP Request Message Format

The DHCP Release

A client sends a Request message is sent without the assistance of any DHCP
relay. to request configuration parameters
from a server. It MAY append appropriate extensions [2].

When a client sends a Release message, reboots, it is assumed to often does not have a valid IP address of
sufficient scope for the server to communicate with the client. In
such cases, the client MUST NOT unicast the message to the server
because the server could not return a response to the client. The
client MUST send the message to the server indirectly, by using the
on-link relay. The client MUST fill in the relay address field with sufficient scope to allow access to
the target server. on-link relay's IP address.

If parameters are specified the Request message is being formed in response to a
Reconfigure-init message from the extensions,
only those parameters are released. The values of all server, then the transaction ID
used must be copied from the Reconfigure-init.

All fields
of in the DHCP Release Request message are entered by the Client. The DHCP
server acknowledges the Release message by sending a DHCP Reply
(Sections 4.4, 6.3).

Bound, Perkins Expires 25 August 1999 [Page 13]

Internet Draft DHCP Version 6 25 February 1999 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 |D| 3 |C|R| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent-address relay-address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-address server-address |
| (16 octets, if present) octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type 5

D
C If the `D' flag is set, the client instructs requests the server to send the DHCP Reply directly back to remove
all releasable resources associated with the client,
instead of using client
binding, except those releasable resources provided as
extensions.

R If set, the given agent-address client has rebooted and link-local
address to relay requests that the Reply message.
server clear any transaction-ID cache entries for the
client.

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

Internet Draft DHCP for IPv6 5 May 2000

transaction-ID
A
An unsigned integer identifier used to identify this
Release, and copied into the Reply.
request.

client's link-local address
The IP link-local address of the client interface from
which the the client issued will issue the DHCP Release message

agent-address Request message.

relay-address
The IP address of a relay's interface, copied from an
Advertise message. If the server is on the same link
as the client, then this field MUST BE zero.

server-address
The IP address of the agent interface for server to which the the client's
Request message is directed, copied from an Advertise
message.

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

A DHCP client selects the transaction-ID from the range of
1024--65535 used to identify its Request. In contrast, a
transaction-ID from the IP
address to be released.

client-address
The IP address range of 0--1023is selected by a DHCP server
to identify a Reconfigure-init. In the client interface latter case, the transaction
ID from which the Reconfigure-init is copied by the client issued the DHCP Release into its Request
message. The
client-address field is present whenever

When the `D' client sets the `C' bit and adds extensions documenting
the releasable resources the client wishes to keep, the server is
set, even if it is equal
expected to deallocate all other releasable resources not listed.
The server SHOULD examine the link-local address. included extensions See [15]

It is an error (status code ``InvalidSource'' (see Section 2.4)) to
include within check whether
the client is still authorized to use them.
9.4. DHCP Reply Message Format

A server sends a Reply message in response to a client's Request
message or Release message.

If a Request message both the `D' bit and an IP

Bound, Perkins Expires 25 August 1999 [Page 14]

Internet Draft DHCP Version 6 25 February 1999

address extension is received which has the IP contains a non-zero relay
address used as field, then the client-address
field of client could not unicast the DHCP Release Request message header.

4.6. DHCP Reconfigure Message Format

DHCP Reconfigure messages can only be sent
to clients which have
established an IP address which routes the server and thus had to use a on-link relay. In that case, the link at which they are
reachable, hence
server unicasts the DHCP Reconfigure Reply message is sent without to the
assistance of any DHCP relay. When relay address found in the
Request message.

If a server sends Release message is received which contains a Reconfigure
message, non-zero relay
address field, then the receivers are assumed to client will not have a valid an IP address with of
sufficient scope to be accessible by the server. Only the parameters
which are specified in after the extensions Release to receive the Reconfigure message need
be requested again by Reply message. In
Bound, Carney, Perkins Expires 1 November 2000 [Page 19]

Internet Draft DHCP for IPv6 5 May 2000

this case, the client. A Reconfigure server unicasts the Reply message can either
be unicast or multicast by to the server. The client will extract relay address
found in the
extensions provided by Release message.

All the fields in the server and send a DHCP Request Reply message to are set by the server using those extensions (see section 5.7). 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 = 6 |N| reserved 4 |R| status | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-address client's link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... relay-address (if present) |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

N The `N' flag indicates that the client should not
expect a DHCP Reply in response to the DHCP Request
it sends as a result of the DHCP Reconfigure message.

reserved 0

transaction-ID
A unsigned integer identifier used to identify this
Reconfigure, to by copied into the following DHCP
Request message that will be transmitted by the
client.

server-address
The IP address of the DHCP server issuing the DHCP
Reconfigure message.

extensions See [15]

Bound, Perkins Expires 25 August 1999 [Page 15]

Internet Draft DHCP Version 6 25 February 1999

5. DHCP Client Considerations

A node which is not a DHCP agent MUST silently discard any DHCP
Solicit, DHCP Request, or DHCP Release message it receives.

5.1. Verifying Resource Allocations After Restarts

A client MAY retain its configured parameters and resources across
client system reboots and program restarts. Any client wishing
to use this feature MUST also maintain state for the address of
its DHCP agent address. When the client restarts, the client MUST
also formulate a DHCP Request message to verify that its configured
parameters
| extensions (variable number and resources are still valid. This Request message MUST
have the `C' bit length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R If set, to clean up stale client binding information
at the server which may no longer be in use by the client; stale
information ``relay-address'' field is that which present.

status
This 7-bit field contains one of the client does not include values in extensions
to such request messages.

If the server does not respond to the DHCP Request message after
REQUEST_MSG_MIN_RETRANS (see
errors table in section 8), the client may still
use any resources whose lifetimes have not yet expired. In such
cases, however, 3.4.

transaction-ID
Copied from the client MUST begin to search for another server
by multicasting a DHCP Solicit message with client's Request or Release.

client's link-local address
Copied from the `C' bit set (see
section 5.2). client's Request or Release message.

relay-address
The client SHOULD log a DHCP System Error.

This also handles the case wherein a client restarts on a new
network, where its IP address is no longer valid. In this situation,
when the client receives of a new IP address and the old IP address
is no longer needed, relay's interface, copied from the client MUST release its old IP address by
issuing a DHCP
Request or Release message with message. If the appropriate extension if it
can communicate with its previous server.

A mobile client (that server is not stationary on a network) SHOULD keep its
agent-address, and possibly the relevant server address, along with
all resource-server associations [15] on non-volatile storage. This
will allow
same link as the client to release resources with client, then the ``R'' bit is not set
and this field is not present.

extensions
See the ``extensions document'' [2].
9.5. DHCP Solicit or
Release messages if it enters a different network location before
releasing its resources.

5.2. Sending DHCP Solicit Messages Release Message Format

A client MUST have the address of sends a server Release message to send a Request message.
The client SHOULD locate a DHCP server by multicasting a DHCP Solicit
message when it wishes to return
one or more releasable resources to the All-DHCP-Agents link-local multicast address (see
Section 3.3), setting server which allocated
them. This can occur either because the Hop Limit == 1. If there are client no DHCP
servers on longer needs the same link as
resource(s) or the node, then client has determined through a DHCP relay MUST be resource-specific
manner that the resource(s) are already in use by different
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 16] 20]

Internet Draft DHCP Version 6 25 February 1999

present if solicitations sent from for IPv6 5 May 2000

client(s). The client communicates the reason for the premature
release of the resource in the status field of the resource's
extension. See ``extensions document'' [2] for more details.

When a client's link-local client sends a Release message, it needs to have a valid IP
address with sufficient scope to allow access by the target server.
If such an address 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 the client's binding are to be handled.

When sending a released.

The values of all fields of the Release message are set by the
client. The DHCP Solicit message, server acknowledges the Release message by sending
a client MUST set 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 Relay
Address ``X-address'' field to 16 octets of zeros, and zero contains the prefix-size field. address of
relay. If a client reboots and does not have a valid IP address, it SHOULD
set the `C' bit in the DHCP Solicit message it sends when restarting.
By setting the `C' bit in set, the solicitation, ``X-address'' field contains a
non-local scope client requests that
all address.

reserved 0

transaction-ID
An unsigned integer identifier used to identify this
Release message.

client's link-local address
The client's link-local address for the DHCP servers that receive interface
from which the solicitation should clean up
their client records that match its link-local address.

If a client sends a DHCP Solicit message after it reboots, the
solicitation SHOULD be delayed after reception of issued the first Router
Advertisement [14] Release message (see section 5.8), by at least some random
amount of time between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see
section 8). This delay is intended to help stagger requests to
DHCP servers (and avoid link-layer collisions) after a power outage
causes many nodes
to reboot all at once. Each subsequent DHCP
Solicit message that is issued before receiving an advertisement
MUST be delayed by twice the amount by which the previous DHCP
Solicit message was delayed, plus a small random delay between
MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds.

5.3. Receiving DHCP Advertise Messages

After a client has received a DHCP Advertise message, it has releasable resources are bound at the
address of a server for subsequent
server).

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

Internet Draft DHCP Request messages. for IPv6 5 May 2000

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

X-address
If the `S' ``R'' bit is zero, set, the DHCP Advertise message was transmitted by a server ``X-address'' field
contains the IP address of the relay interface on the
same link as the client, and client. If the ``R'' bit is not set,
this field contains a non-link-local IP address of the
client uses interface from which the agent-address
as the server's address; otherwise, client issued the server's
Release message.

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

A client selects the transaction-ID from the range of
1024--65535 used to identify the Release message.

A client MUST NOT specify an IP address is
located in the server-address field. If the server-address client-address field
that it is a
multicast address, releasing in the advertisement MUST be silently discarded. extensions field.
9.6. DHCP Reconfigure Message Format

A server MAY append extensions sends a Reconfigure message when it wishes to its advertisements; this might
allow inform one or
more clients of new or updated values for configuration parameters.
The new configuration parameters are carried in the client to select extensions
portion of the configuration Reconfigure message. Note that best meets its
needs from among several prospective servers.

Unless a DHCP Advertisement is received with a preference equal
to 255 (see Section 4.2), the client Reconfigure message
MUST wait CLIENT_ADV_WAIT
seconds after issuing NOT carry releasable resource extensions.

Reconfigure messages can ONLY be sent to clients which 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
Bound, Carney, Perkins Expires 1 November 2000 [Page 22]

Internet Draft DHCP Solicit message for IPv6 5 May 2000

transaction-ID
An unsigned integer identifier in order to receive the Advertisement with the highest preference. After waiting for
that period range of time, a client MUST select
0--1023 chosen by the highest preference server as the target to identify this
Reconfigure message.

server-address
The IP address of its the DHCP request. If a client receives an
advertisement with a preference server issuing the
Reconfigure message. MUST be of 255, it does not have sufficient scope to wait for
any more advertisements.

Bound, Perkins Expires 25 August 1999 [Page 17]

Internet Draft be
reachable by all clients.

extensions
See the ``extensions document'' [2].
9.7. DHCP Version 6 25 February 1999

If a Reconfigure-reply Message Format

A client sends a DHCP Request to a highly preferred server but
fails Reconfigure-reply message to receive acknowledge receipt of
a DHCP reply Reconfigure message from that server after following the
retransmission algorithm in section 8, the client MUST then try to
send a DHCP Request to a less preferred server.

A Reconfigure-reply message can only be sent if the client is free has an IP
address of sufficient scope to cache contact the server. No interaction
with a relay is possible.

All fields in the result of any DHCP Advertisement it
receives. Reconfigure-reply message are entered by the
client.

status
This is purely a potential performance enhancement,
because 7-bit field contains one of the results might change over time. A client may not get
a DHCP Reply if it uses a cached server-address, and values from the
errors table in that case
SHOULD multicast another DHCP Solicit message.

5.4. Sending DHCP Request Messages

A client obtains configuration information section 3.4.

transaction-ID
An unsigned integer identifier copied from a server by sending
a DHCP Request message. The client MUST know the server's address
before sending the Request message, and the client MUST have acquired
a (possibly identical)
Reconfigure message.

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

Internet Draft DHCP agent address. If the client and server
are on the same link, for IPv6 5 May 2000

client's link-local address
The client's link-local address for the agent-address used by interface from
which the client MUST be issued the same as Reconfigure-reply message.

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

A DHCP Request server sends a Reconfigure-init message MUST
NOT when it wishes to notify
one or more clients of new or updated values for configuration
parameters available on the server.

Reconfigure-init messages can ONLY be sent to any multicast address, since otherwise multiple DHCP
servers would possibly allocate resources clients which have
established an IP address of sufficient scope as to be directly
reachable by the client server.

A ``Reconfigure-init'' serves as a trigger which will cause the
clients to initiate a Request/Reply exchange with the server in response order
to receive the same Request, 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 number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0

transaction-ID
An unsigned integer identifier in the client would have no way to know which
servers had made the allocations, if any packets were lost due to
collisions, etc.

If range of
0--1023 chosen by the DHCP server is off-link, and the client has no valid to identify this
Reconfigure-init message.

server-address
The IP address of sufficient scope, then the client MUST include the
server-address and set the `S' bit in the DHCP Request message. In
this case, the IP destination address in server issuing the IP header will
Reconfigure-init message. MUST be a DHCP
relay address.

Otherwise, if the client has a valid IP address of sufficient scope
and knows the IP address of a candidate server, it MUST send the
Request message directly
to be reachable by all clients.

extensions SHOULD only include an ERE and/or authentication
extensions. No configuration information SHOULD be

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

Internet Draft DHCP for IPv6 5 May 2000

included. See the server without requiring the services
of the local ``extensions document'' [2] for more
information about extensions.
10. DHCP relay.

If Server Solicitation and Subnet Prefix Discovery

This section describes how a client wishes to instruct a server to deallocate all unknown
previous resources, configuration information, locates agents (relays and bindings
associated with its agent-address
servers) and link-local address, how it
sets the `C' bit in can learn about the DHCP Request. A client MAY send in
such a Request even when it networks on its link that are
managed by these servers. The behavior of client, server, and relay
implementations is no longer attached to discussed, along with 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 the link on ``client's
link-local address'' field does not contain a valid link-local
address.

Servers MUST discard each received Solicit message which meet the relay-address
following criteria:

o The ``relay-address'' field does not contain an address of
sufficient scope that is attached. reachable by the server.

o The `C' bit allows better
reclamation ``relay-address'' field is non-zero, but prefix-len is zero.

An error message MAY be logged by the agent. The logging of available resources when a client lost records for
its resource-server associations and might not otherwise
such messages SHOULD be able to
release controlled by an agent implementation
configuration flag.
10.2. Advertise Message Validation

Servers MUST silently discard any received Advertise messages.

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

o The ``Solicit-ID'' field value does not match the value the associated resources.

When a
client reboots and loses used in its previous state, Solicit message.

o The ``client's link-local address'' field value does not match
the server
should no longer keep track link-local address of the interface upon which the XID-TIMEOUT binding cache client
sent the Solicit message.

Relays MUST discard any Advertise messages that meet any of the
following criteria:
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 18] 25]

Internet Draft DHCP Version 6 25 February 1999

transaction IDs (see section 6) associated with that previous state.
In order to inform for IPv6 5 May 2000

o The ``relay-address'' field does not contain the server that relay's address
on the client no longer wishes
any association to be maintained between used transaction-IDs and
previous transactions, same link as the client SHOULD set client.

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

Clients use the `R' bit in its Solicit message primarily to discover DHCP
Request.

In any case, after choosing a transaction-ID which is numerically
greater than its last recorded transaction-ID, and filling in servers
configured to serve networks on the
appropriate fields of link containing the DHCP Request message, client.
Optionally, the client MAY append
various DHCP Extensions to set the message. These extensions denote
specific requests by ``P'' bit which has the client; for example, a client may request
a particular IP address, or request effect
of requesting that the server send an update
containing the client's new IP address to a Domain Name Server. When
all desired return subnet prefix extensions have been applied,
identifying the client sends networks on the DHCP
Request client's link the server is
configured to manage.
10.3.1. Creation and sending of the appropriate agent.

For each pending DHCP Request Solicit message

When creating a Solicit message, the client SHOULD start out with
a buffer initialized with zeroed octets. The client MUST maintain sets the
following information:

- The transaction-ID
``msg-type'' field to 1, and places the link-local address of the request message,
- The server-address,
- The agent-address (which can be
interface it wishes to configure in the same as link-local address field.

If the server-address),
- The time at which client is prepared to process multiple Advertise messages
in response to its Solicit message, the next retransmission client will be attempted, and
- All extensions appended set the
Solicit-ID field to 1. Every time the request message.

If a client does not receive a DHCP Reply message (Section 5.5) with
the same transaction-ID as initiates a pending DHCP Request message within
REPLY_MSG_TIMEOUT (see section 8) seconds, or if the received DHCP
Reply message contains new server
solicitation attempt (not a DHCP Authentication extension which fails
to provide the correct authentication information, retransmission), the client MUST
retransmit increments
the Request with Solicit-ID by one. If the same transaction-ID and continue to
retransmit according 9-bit field rolls over to 0, then the rules in Section 8. If (after following
those rules)
client sets the Solicit-ID to 1. A client has not received a Reply message, which will only accept
the first Advertise message it SHOULD
start over again by multicasting a new DHCP receives leaves the Solicit-ID field
initialized to zero.

The ``C'' bit of the Solicit message to find a
different server.

If is set by the client receives an ICMP error message in response to such a
DHCP Request, it likewise SHOULD start over again by multicasting a
new when the
client has no cached knowledge of previous DHCP Solicit message, configuration for the
interface. Setting this bit requests that the server release any
information assigned to find a different server. the client for the networks on the client's
link.

If the client transmits a DHCP Request in response desires to a learn of the networks managed by DHCP
Reconfigure message, further processing on
the link its interface is as specified attached to, it sets the ``P'' bit in
Section 5.7. the
Solicit message.

The client can continue transmits the Solicit message to operate with its existing
configuration information and resources until it receives the
corresponding FF02::1:2 (All DHCP Reply from the server.
Agents) multicast address, destination port 547. The same retransmission
rules apply as for any other DHCP Request message from the client.
When the `N' bit is set, source port
selection can be arbitrary, although it SHOULD be possible using a DHCP Request sent in response
client configuration facility to set a DHCP
Reconfigure message will not elicit a DHCP Reply message from the
server. specific source port value.
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 19] 26]

Internet Draft DHCP Version 6 25 February 1999

5.5. Receiving DHCP Reply for IPv6 5 May 2000

10.3.2. Time out and retransmission of Solicit Messages

When

The client's first Solicit message on the interface MUST 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).

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 the ADV_MSG_MAX value. Thereafter, Solicits
are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
made, at which time the client receives a stops trying to DHCP Reply message, it MUST check whether configure the transaction-ID
interface. An event external to DHCP is required 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 of one or more validated Advertise messages, the Reply message matches client
selects one or more Advertise messages based upon the transaction-ID following
criteria.

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

- Within a group of Advertise messages with the same server
preference value, a pending DHCP Request message. If no match is found, client MAY select those servers whose
Advertise messages advertise information of interest to
the Reply
message MUST client. For example, one server may be silently discarded.

If advertising the Reply message is acceptable,
availability of IP addresses on networks which have an address
scope of interest to the client.

Once a client processes each
Extension [15], extracting has selected Advertise message(s), the relevant configuration client will
typically store information about each server, such as relay address
and parameters for its network operation. The client can determine prefix length, server preference value, networks advertised,
when all extensions in the Reply have been processed by using advertisement was received, and so on. Depending on the UDP
Length field
requirements of the Reply. Some extensions in the Reply may have
status codes, which indicate to client's invoking user, the client MAY initiate a
configuration exchange with the reason server(s) immediately, or MAY defer
this exchange until later.

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

Internet Draft DHCP for failure
when IPv6 5 May 2000

10.4. Relay Behavior

For this discussion, the server was unable Relay is assumed to honor have been configured
with some list of server destination addresses, which may be unicast,
the FF05::1:3 (All DHCP Servers) multicast address, or some other
multicast address selected by the request. If network administrator.
10.4.1. Relaying of Solicit messages

When a Relay receives a valid Solicit message, it places the server is
unable to honor IP
address of the request interface upon which it received the Solicit message
in an extension included by the client,
that extension may simply be omitted from ``relay-address'' field of the Reply. Solicit. The server MAY Relay also provide places
the client with configuration parameters number of bits of that make up the client did
not specifically request.

Some configuration information extracted from subnet prefix for this address
in the extensions to ``prefix-len'' field of the
DHCP Reply message MUST remain associated with Solicit.

The Relay then forwards this Solicit to the list of server
destination addresses that sent
the message. The particular extensions that require this extra
measure it has been configured with.
10.4.2. Relaying of association with Advertise messages

When a Relay receives a valid Advertise message, it unicasts the server are indicated
message to the link-local address found in the DHCP
Extensions document [15]. These "resource-server" associations are
used when sending DHCP Release messages.

5.6. Sending DHCP Release Messages

If a client wishes to ask ``client's link-local
address'' field by way of the server appropriate network interface.
10.5. Server Behavior

For this discussion, the Server is assumed to release have been configured in
an implementation specific manner. This configuration is assumed to
contain all network topology information and
resources relevant to the client, for the client SHOULD send a DHCP
Release message without domain, as well
as any extensions; this is preferable to sending
a DHCP Request message with the `C' bit set and no extensions. If a
client wishes to retain some necessary authentication information.
10.5.1. Receipt of its network configuration parameters,
but determines that others are no longer needed, it SHOULD enable Solicit messages

Upon the server to release allocated resources which are no longer in
use by sending receipt of a valid Solicit message, the server first
identifies the client's location within the DHCP Release message to domain. If the server,
``relay-address'' and including
extensions to identify / or ``prefix-len'' fields of the Solicit are
zeroed, then the unneeded items. The client consults its
list of resource-server associations in order is attached to determine which
server should receive the desired Release message. The Release
MUST be transmitted to same link as the server that provided server.
If these fields are non-zero, then the configuration
parameters.

Suppose a client wishes exists on the same link
as the network identified by these two fields.

If administrative policy permits the server to release resources which were granted respond to
it at another IP address. Further, suppose that the a client has an
IP address on
that will still be valid after link, the server performs the
operations requested in the extensions to the DHCP Release message, will generate and which has sufficient scope send an Advertise message to be reachable from
the server. In
that case, and only then, the client MUST set the `D' bit in the DHCP client.
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 20] 28]

Internet Draft DHCP Version 6 25 February 1999

Release message (see section 4.5). This instructs for IPv6 5 May 2000

10.5.2. Creation and sending of Advertise messages

When creating an Advertise message, the server to
send SHOULD start out
with a buffer initialized with zeroed octets. The server sets the DHCP Reply directly back
``msg-type'' field to 2 and copies the client at values of the latter valid following fields
from the client's Solicit to the Advertise message:

o solicit-ID

o client's link-local address

o relay-address

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

If the DHCP Reply back through client requests subnet prefix extensions (by setting the agent-address included ``P''
bit in its Solicit) and the DHCP
Release.

5.7. Receiving DHCP Reconfigure Messages

Each client implementation MUST support listening at UDP port 546 server implements and is configured to
receive possible DHCP Reconfigure messages; in cases where
provide prefix extensions, the client
knows that no Reconfigure message server will ever be issued, generate and insert a
subnet prefix extension for each network on the client MAY
be client's link it is
configured to avoid executing this supported feature. Any DHCP
Reconfigure manage.

If the ``relay-address'' field of the Advertise message received with a transaction-ID greater than or
equal to 1024 MUST be silently discarded.

In some cases, is zero, then
the IP address at which server unicasts the client listens will be a
multicast address sent Advertise message directly to the client by
using the server in an extension
to an earlier DHCP Reply message. ``client's link-local address'' field value as destination
address. If the client does not listen for
DHCP Reconfigure messages, it ``relay-address'' field is possible that non-zero, then the client will not
receive notification that its server has deallocated
unicasts the client's
IP address and/or other resources allocated Advertise message directly to the client. See
discussion in 6.5. The relay using the
``relay-address'' field value as the destination address.
11. DHCP Client-Initiated Configuration Exchange

A client MAY receive initiates a prefix update for configuration exchange with one or more of their addresses and then MUST use that prefix for those
addresses.

If a client receives a DHCP Reconfigure message, servers
it is a request for has found through DHCP server solicitation whenever requested to
do so by the client application layer in order to send acquire configuration
information of interest.
11.1. Request Message Validation

Clients MUST silently discard any received Request messages.

Agents MUST discard any Request messages in which the ``client's
link-local address'' field does not contain a new valid link-local
address.

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

Internet Draft DHCP for IPv6 5 May 2000

Relays MUST discard any received Request to the server messages in which sent the
Reconfigure message. Unless the `N' bit is set,
``relay-address'' field value does not match any of the client relay's
addresses.

Servers MUST
await a DHCP Reply with a matching transaction-ID, retransmitting
(as specified in section 8) until discard any received Request message which meets any of
the Reply is received. following criteria:

o The server
sending the Reconfigure message MAY be different than ``server-address'' field value does not match any of the server
which sent a DHCP Reply message containing
server's addresses.

o If the original configuration
information.

Reconfigure messages MAY ``relay-address'' field is set, and that field's value
does not contain an address of sufficient scope as to be retransmitted
reachable by the server.

o The ``extensions'' field contains an authentication extension,
and the server with cannot successfully authenticate the same
transaction-ID.

When a client receives a retransmitted unicast Reconfigure client.
11.2. Reply Message Validation

Servers MUST silently discard any received Reply messages.

Clients MUST discard any Reply message
within XID_TIMEOUT that meets any of the last received Reconfigure message with
following criteria:

o The ``transaction-ID'' field value does not match the
same transaction-ID, value the
client MUST reformulate exactly the same
DHCP used in its Request message and retransmit or Release message.

o The ``client's link-local address'' field value does not match
the request message to link-local address of the server
again. In this way, interface upon which the server can make use of client
sent in its Request or Release message.

o The Reply message contains an authentication extension, and the retransmission
algorithm
client's attempt to ensure that a client has received authenticate the Reconfigure
message.

When a client receives a retransmitted multicast Reconfigure message
within XID_TIMEOUT fails.

Relays MUST discard any Reply message that meets any of the last received Reconfigure message with following
criteria:

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

o The ``relay-address'' field value does not contain the relay's
address on the same transaction-ID, link as the client MUST client.

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

Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 21] 30]

Internet Draft DHCP Version 6 25 February 1999

message if RECONF_MULTICAST_REQUEST_WAIT (see section 8) has not
expired. If RECONF_MULTICAST_REQUEST_WAIT has expired then the
client for IPv6 5 May 2000

11.3. Release Message Validation

Clients MUST reformulate exactly the same DHCP Request message and
retransmit the Request silently discard any received Release messages.

Agents MUST discard any Release message to the server again, and then reset
RECONF_MULTICAST_REQUEST_WAIT to its default value or the value that
was provided from a retransmission extension [15] provided by the
server. In this way, the server can make use meets any of the retransmission
algorithm to ensure that all affected clients have received the
multicast Reconfigure message.

For each Extension which is present in the Reconfigure message, the
client MUST append
following criteria:

o The ``transaction-ID'' field contains a matching Extension to its Request message, which
it formulates to send to the server specified value not in the server-address
field of the message.
1024--65535 range.

o The client also copies ``client's link-local address'' field does not contain a transaction-ID from
the Reconfigure
valid link-local address.

Relays MUST discard any received Release message into the Request message. Processing for that meets any of
the
Request following criteria:

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

o The ``X-address'' field value does not match any of the same as specified in Section 5.4, except:

- the client retransmits as stated above in this section

- the client never needs a Relay to send relay's
addresses.

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

o The ``X-address'' field does not contain an address of sufficient
scope as to be reachable by the DHCP
Server

- the client MUST NOT set the `S' or `R' bits

- if server.

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

A client will not get a Reply from the
server

- if generate one or more Request messages when prompted by
the application layer in order to acquire configuration information.
A client receives an ICMP error message it should abort the
Reconfigure transaction and log may initiate such an error message. The client
MUST NOT transmit a DHCP Solicit message exchange automatically in order to rediscover
the IP address of the DHCP Server.

Resources held by
acquire the necessary network parameters to communicate with nodes
off-link. The client which are not identified by Extensions
in uses the server's Reconfigure message are not affected.

A server and relay address information
from previous Advertise message(s) for use in delivering Request
message(s). Note that a client may ask its request configuration information
from one or more servers at any time.

A client to join a multicast group for uses the
purpose of receiving DHCP Reconfigure messages. When a Reconfigure Release message is delivered to in the client by way management of the selected multicast
address, the releasable
resources when:

o The client MUST delay its further response for has determined through a random
amount of time uniformly distributed within the interval between
RECONF_MMSG_MIN_RESP and RECONF_MMSG_MAX_RESP seconds (see
section 8). This will minimize the likelihood resource-specific manner
that the server will
be flooded with DHCP Request messages.

5.8. Interaction with Stateless Address Autoconfiguration

Please refer to the Stateless Address Autoconfiguration Protocol
specification [20] for details regarding resource assigned by the actions taken server is already in use by clients a
different client.

Bound, Carney, Perkins Expires 25 August 1999 Expires 1 November 2000 [Page 22] 31]

Internet Draft DHCP Version 6 25 February 1999

upon receiving Router Advertisements with changing values for IPv6 5 May 2000

o The client has been instructed to release the `M'
and `O' bits.

6. DHCP Server Considerations

A node which resource prior to
the lease expiration time since it is not no longer needed.
11.4.1. Creation and sending of Request messages

When creating a Request message, the client or relay MUST ignore any DHCP Advertise,
DHCP Reply, or DHCP Reconfigure message it receives.

A server maintains SHOULD start out with
a collection of buffer initialized with zeroed octets. The client records, called
``bindings''. Each binding is uniquely identifiable by sets the ordered
pair <link-local address, agent-address>, since
``msg-type'' field to 3, and places the link-local address of the
interface it wishes to associate with the configuration information
with in the ``client's link-local address'' field.

Unless the Request message is guaranteed created in response to be unique [20] on a
Reconfigure-init message, the link identified by client generates a transaction
ID in the
agent-address and prefix. An implementation MUST support bindings
consisting range of at least a client's link-local address, agent-address,
preferred lifetime 1024--65535 and valid lifetime [20] for each inserts this value in the
``transaction-ID'' field.

The client address.

A server MAY, at places the discretion address of the network administrator, be
configured so that destination server in the
``server-address'' field.

If the client bindings are identified by is not on the client's
link-local address, without need to use same link as the additional information
supplied by destination
server, the agent-address.

A client binding may be used to store any other information,
resources, and places the appropriate relay's address in the
``relay-address'' field.

If the client is acquiring configuration data which will be associated with information on the interface
for the first time, the
client. A server MUST retain its clients' bindings across server
reboots, and, whenever possible, a client should be assigned SHOULD set the
same configuration parameters despite server system reboots and DHCP
server program restarts. A server MUST support fixed or permanent
allocation of configuration parameters to specific clients.

In addition to ``C'' bit in the
header. How the client binding a server must maintain an
XID_TIMEOUT binding cache to determine determines if a previous transaction-ID this is being retransmitted by the first configuration
attempt on the interface is implementation-specific. A client may
implement a client. An implementation of an
XID_TIMEOUT binding cache MUST support at least of configuration information on a tuple consisting per-interface
basis; if that cache does not exist, that client would set the
``C'' bit. Clients which do not implement caching of per-interface
configuration information MUST always set the client's link-local address, agent-address prefix, IPv6 address, ``C'', and XID_TIMEOUT value when include
any extensions carrying releasable resources received from earlier
configuration exchanges in the cache entry can be deleted (see
Section 8).

6.1. Receiving DHCP Solicit Messages extensions field of the Request.

If the DHCP Solicit message was received at client has determined through an implementation-specific
manner that the All-DHCP-Servers
multicast address, client implementation itself has restarted, it MUST
set the server ``R'' bit in the header. After the first successful exchange
with the server, the client MUST check to make sure that NOT set the
relay-address is present, and is not a link-local address. ``R'' bit in subsequent
Request messages.

Client considerations for extensions are now considered (see the
``extensions document'', [2] for more details).

If the
relay-address is not present, or if it is a link-local address, client already has an IP address of sufficient scope to
directly reach the server MUST silently discard server, then the packet. Note that client SHOULD unicast the Request
to the server. Otherwise, if the
client sends a DHCP Solicit message from a link-local address, server is off-link, the
multicast destination will be client
unicasts the All-DHCP-Agents address, not Request message to the
All-DHCP-Servers address. appropriate relay.

Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 23] 32]

Internet Draft DHCP Version 6 25 February 1999

When the `C' bit is set in 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, the solicitation, client
retransmits the server deallocates
all resources that match Request with the link-local address same transaction-ID, and saved
agent-address in the solicitation message, if a binding for doubles
the REP_MSG_TIMEOUT value, and waits again. The client can be found. If continues
this process until a Reply is received or REQUEST_MSG_ATTEMPTS
unsuccessful attempts have been made, at which time the client binding cannot be found MUST
abort the server configuration attempt. The client SHOULD continue report the abort
status to process the Solicit message.

As an optimization, a server processing a Solicit 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 from relays
MAY check in response to a Request

Upon the prefix receipt of a valid Reply message, the IP source address in the IP header to
determine whether client extracts the server has received
configuration information contained in the Solicit from multiple
relays on Reply. If the same link. The prefix-size ``status''
field in contains a non-zero value, the solicitation
enables client reports the server to ascertain when two relay addresses belong error status
to the same link.

6.2. Sending DHCP Advertise Messages

Upon receiving and verifying application layer.

If the correctness of a DHCP Solicit
message, a server constructs a DHCP Advertise message and transmits
it on extensions field contains one or more ``Reconfigure Multicast
Address'' extensions (see ``extensions document'', ``Reconfigure
Multicast Address Extension'' section [2]), the same link as client MUST join
these multicast groups, and MUST monitor the solicitation was received from. When UDP 546 port for
Reconfigure or Reconfigure-init messages on the
solicitation is received at networks configured
by DHCP.

If the All-DHCP-Servers multicast address, configuration information returned in the server SHOULD delay Reply contains
releasable resources, then the transmission of its advertisement
for a random amount client MUST take over lease management
of time between SERVER_MIN_ADV_DELAY and
SERVER_MAX_ADV_DELAY (see section 8).

If the relay-address is nonzero, the server resource. A client MUST copy NOT request releasable resources
unless it into is prepared to appropriately manage the
agent-address field resource lease.
11.4.4. Creation and sending of the advertisement Release messages

When creating a Release message, and send the
advertisement to the relay-address. Otherwise, the server MUST
send client SHOULD start out with
a buffer initialized with zeroed octets. The client sets the advertisement
``msg-type'' field to 5, and places the client's link-local address. An IP address of the
interface on which the server received configuration information it wishes to release is
associated with in the Solicit
message MUST appear ``client's link-local address'' field.

The client generates a transaction ID in the server-address field range of the corresponding
advertisement,
1024--65535 and inserts this value in the 'S' bit MUST be set. ``transaction-ID''
field.

The server MAY append client includes extensions to containing the Advertisement, releasable resources it
is releasing in order to
offer the soliciting node the best possible information about the
available services and resources.

6.3. DHCP Request and Reply Message Processing ``extensions'' field. The appropriate ``status''
Bound, Carney, Perkins Expires 1 November 2000 [Page 33]

Internet Draft DHCP server MUST check to ensure that the client's link-local address for IPv6 5 May 2000

field of the Request message contains a link-local address. If not, in the message extensions MUST be silently discarded. If set to indicate the `S' bit is set, reason for the
server MUST check that
release.

The client places the server-address matches one of its own IP
addresses. If address of the server-address does not match, server who allocated the Request message
MUST be silently discarded.
resource(s) in the ``server-address'' field.

If the received agent-address and link-local client will have an appropriately scoped IP address do not
correspond to any binding known to after the server, then
release transaction is completed, the server
SHOULD create a new binding for client clears the previously unknown client,

Bound, Perkins Expires 25 August 1999 [Page 24]

Internet Draft DHCP Version 6 25 February 1999 ``R'' bit
and send a DHCP Reply with any resources allocated to places this address in the ``X-address'' field. If the client
will not have an appropriately scoped IP address after the new
binding. Otherwise, if release
transaction is completed, the server cannot create a new binding,
it SHOULD return a DHCP Reply with a status client sets the ``R'' bit and places
the address of ``NoBinding'' (see
Section 2.4). the appropriate relay in the ``X-address'' field.

If the client is updating its resources but configured to use authentication, the
database is temporarily unavailable, client
generates the server SHOULD return a DHCP
Reply with a status of ``Unavail'' (see Section 2.4).

While processing appropriate authentication extension, and adds this
extension to the Request, ``extensions'' field. Note that the server authentication
extension MUST first determine whether
or not be the Request is a retransmission of an earlier DHCP Request
from last extension in the same client. This ``extensions''
field. See the ``extension document'' for more details about the
authentication extension [2].

If the ``R'' bit is done by comparing set, then the transaction-ID client MUST unicast the Release
to all those transaction-IDs the relay indicated in the XID_TIMEOUT binding cache
received from ``X-address'' field. Otherwise, the same
client during unicasts the previous XID_TIMEOUT
seconds. Release message directly to the server indicated
in the ``server-address'' field.
11.4.5. Time out and retransmission of Release Messages

The client waits REP_MSG_TIMEOUT milliseconds, collecting Reply
messages. If no Reply messages are received, the transaction-ID is client retransmits
the same as one Release, and doubles the REP_MSG_TIMEOUT value, and waits again.
The client continues this process until a Reply is received during
that time, or
REL_MSG_ATTEMPTS unsuccessful attempts have been made, at which
time the server MUST take client SHOULD abort the same action (e.g., retransmit release attempt. The client
SHOULD return the same DHCP Reply abort status to the client) as it did after processing the
previous DHCP Request with application, if an application
initiated the same transaction-ID.

Otherwise, release.

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

Note that if the server has no record of a message from client fails to release the client
with resource, the same transaction-ID, resource
will be reclaimed by the server identifies and allocates
all when the relevant information, resources, and configuration data that
is lease associated with the client. Then it sends that information to
its client by constructing a
expires.

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

Internet Draft DHCP for IPv6 5 May 2000

11.4.6. Receipt of Reply message in response to a Release

Upon receipt of a valid Reply message, the client can consider the
Release event successful, and including SHOULD return the
client's information in DHCP Extensions successful status to
the Reply message. The
DHCP Reply message uses application layer, if an application initiated the same transaction-ID as 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 the IP address found in the
received DHCP Request ``server-address'' field of the
message. Note that
11.6. Server Behavior

For this discussion, the reply message Server is assumed to have been configured
in an implementation specific manner with configuration of interest
to clients. Such configuration information MAY contain information not specifically requested by the client.

If releasable
resources such as IP addresses.
11.6.1. Receipt of Request messages

Upon the DHCP receipt of a valid Request message has the `S' bit set in from a client the message
header, server
can respond to, (implementation-specific administrative policy
satisfied) the server MUST send scans the corresponding DHCP Reply message to extensions field.

If the agent-address found in client has set the Request (see section 7.2). Otherwise, ``C'' bit, the server SHOULD send the corresponding DHCP Reply message to MUST release all
releasable resources currently associated with the
IP source address client's binding
that do not appear in the IP header received from ``extensions'' field.

If the client Request
message.

6.3.1. Processing has set the ``R'' bit, the server MUST delete any
transaction-ID cache entries it is maintaining for this client, if
the server implements such a cache.

Server considerations for Extensions to DHCP Request and Reply Messages

The DHCP Request may contain extensions [15], which are interpreted
(by default) as advisory now evaluated (see the
``extensions document'', [2] for more details).

If the configuration information from to be returned to the client about its
configuration preferences. For instance,
includes releasable resources, the server checks if a binding
already exists for the IP Address Extension
is present, client. If so, the server SHOULD attempt examines the
data records within the binding to allocate or extend determine if the
lifetime client's
Request is a retransmission of an earlier Request or a new Request.
Releasable resource identifiers are stored within the address indicated by binding with
the extension. Some extensions
may be marked transaction-ID used by the client as required.

The server may accept some extensions for successful processing and
allocation, while still rejecting others, or it may reject various
extensions for different reasons, and set the status appropriately
for those extensions which return status to request the client. The server resource's
assignment. If the transaction-ID's match, this is a retransmission
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 25] 35]

Internet Draft DHCP Version 6 25 February 1999

sends a single DHCP Reply message in response to each DHCP Request,
with for IPv6 5 May 2000

and the same transaction-ID as server simply return the Request.

Whenever it is able to, contents of the server includes an extension in client's binding
which satisfy its request. If the
Reply message for every extension sent by transaction-ID's do not match,
the client server records the additional resources it is assigning in the Request
message.
existing binding with the new Request's transaction-ID.

If the client requests some extensions that cannot be
supplied by the server, does not have an existing binding, the server can simply fail to provide them,
not including them in creates a
binding for the Reply. Other extensions can be rejected
by including them client and records the resources it is assigning in
this binding along with the transaction-ID from the Reply with an appropriate status indicating
failure. client's Request.

The server can include extensions in the reply that were
not requested by then constructs a Reply message and sends it to the
client.

6.3.2. Client Requests to Deallocate Unknown Resources

When a client DHCP Request is received that has
11.6.2. Receipt of Release messages

Upon the `C' bit set, receipt of a valid Release message, the server should check performs a
lookup to find out whether the extensions listed
in the Request message match those which it has associated with the client's binding. Any resources which are not indicated If the binding is found, the
server examines the binding to see if the resource(s) identified by
the client in the Release message's extensions field are presumed in fact
assigned to be unknown by the client, and thus possible
candidates for reallocation to satisfy requests client. If they are, the server deletes these
resources from the client's binding, making them available to other
clients.

The server MUST deallocate all resources associated with the client
upon reception of then generates a DHCP Request with Reply message. If a binding was
found and the `C' bit set, except for
those which resources presented to the server is willing to reallocate in response to were deleted from
the client's request. It may be more efficient to avoid deallocating any
resources until after binding, the list of extensions to server sets the request has been
inspected.

6.4. Receiving DHCP Release Messages ``status'' field to
``Success''. If no binding is found, the server receives a DHCP Release Message, it MUST verify that sets the link-local address ``status''
field to ``NoBinding''(section 3.4).
11.6.3. Creation and sending of Reply messages

When creating a Reply message, the message contains an address which
could be server SHOULD start out with
a valid buffer initialized with zeroed octets. The server sets the
``msg-type'' field to 4 and copies the 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 (see Section 2.1).

o If not, the client's message MUST be silently discarded.

In response to is a DHCP Release Message Request with a valid client's
link-local address and agent-address, non-zero
``relay-address'' field value, the server formulates a DHCP sets the ``R'' bit in
the Reply message that will be sent back and copies the ``relay-address'' field value from the
Request to the releasing client. When Reply. If the `D' flag client's message is a Release with
the ``R'' bit set, the server MUST send sets the ``R'' bit in the DHCP Reply back and
sets the ``relay-agent'' field to the client using contents of the client-address Release's
X-address field.

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

Internet Draft DHCP for IPv6 5 May 2000

The server sets the ``status'' field of appropriately (see the Release message.
Otherwise, if table
in section 3.4) based upon the `D' bit is not set, results of processing the client's
request.

If configured to do so, a server MUST send its DHCP will include ``Reconfigure Multicast
Address'' extensions (see ``extensions document'', ``Reconfigure
Multicast Address Extension'' [2]), in Reply message (with the `L' bit set) messages sent in
response to a Request, informing the agent-address in client of one or more multicast
groups it should join to facilitate the
Release message, so that receipt of Reconfigure or
Reconfigure-init messages.

If the relay agent can subsequently forward DHCP domain is using authentication, the
Reply back to server will generate
an authentication extension with the releasing client at appropriate settings and add
that extension as the client's link-local address
indicated last extension in the ``extensions'' field of
the Reply message.

If the received agent-address and link-local address do not
correspond to any binding known to ``relay-address'' field of the server, Reply message is zero, then the
server SHOULD

Bound, Perkins Expires 25 August 1999 [Page 26]

Internet Draft DHCP Version 6 25 February 1999

return a DHCP Reply, indicating the error by setting unicasts the status code Reply directly to ``NoBinding'' (see Section 2.4).

Otherwise, if the agent-address and client using the ``client's
link-local address indicate a
binding known to address'' field value as destination address. If the server,
``relay-address'' field is non-zero, then the server continues processing unicasts the
Release message. If there are any extensions,
Reply directly to the server releases relay using the particular configuration items specified in ``relay-address'' field value
as the extensions. destination address.

If there are no extensions, the server releases all configuration
information in the client's binding.

After performing implements a transaction-ID cache, the operations indicated in server would add
an entry for the client to this cache.
12. DHCP Release message
and its extensions, the Server-Initiated Configuration Exchange

A server formulates initiates a DHCP Reply message,
copying configuration exchange on behalf of the transaction-ID from
administrator of the DHCP Release message. For
each Extension domain. An administrator may initiate such
an exchange when new networks are added to the domain or existing
networks are to be renumbered. Other examples include changes in
the DHCP Release location of directory servers, addition of new services such as
printing, and availability of new software (system or application).
12.1. Reconfigure Message Validation

Agents MUST silently discard any received Reconfigure messages.

Clients MUST discard any Reconfigure message successfully processed
by that meets any of the server, a matching Extension
following criteria:

o The ``transaction-ID'' field value is appended to the DHCP Reply
message. For extensions in not within
the DHCP Release 0--1023 range.

o The Reconfigure message which cannot be
successfully processed by contains an authentication extension, and
the server, a client's attempt to authenticate the message fails.
Bound, Carney, Perkins Expires 1 November 2000 [Page 37]

Internet Draft DHCP Reply for IPv6 5 May 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 containing
extensions with that meets any of
the appropriate status following criteria:

o The ``transaction-ID'' field value is not that same value the
server used in its Reconfigure message.

o The ``server-address'' field value does not match the value the
server placed in its Reconfigure message.
12.3. Reconfigure-init Message Validation

Agents MUST be returned by silently discard any received Reconfigure-init messages.

Clients MUST discard any Reconfigure-init messages that meets any of
the
server. If following criteria:

o The ``transaction-ID'' field value is not within
the Release 0--1023 range.

o The Reconfigure-init message contains no extensions, an authentication
extension, and the server
does not include any extensions in client's attempt to authenticate the corresponding DHCP Reply message to
fails.
12.4. Server Behavior

For this discussion, the client.

6.5. Sending DHCP Reconfigure Messages

If a server needs to change the configuration associated with any
of its clients, it constructs a DHCP Reconfigure message (possibly
including relevant extensions) and sends it to each such client. The
Reconfigure MAY be sent is assumed to have a multicast address chosen
implementation-specific interface by the server, which was previously sent to each such client in an extension to a
previous DHCP Reply message.

It administrator
may happen that initiate a client does not send reconfiguration event with some set of clients.

There are two methods of initiating a DHCP Request message
after the DHCP Reconfigure message reconfiguration event. Each
has been issued and retransmitted
RECONF_MSG_MIN_RETRANS times, according to the algorithm specified
in Section 8. its advantages:

Reconfigure with payload
This can happen when the client is not listening for method uses the Reconfigure message, possibly because the client is a mobile
node disconnected from the network, or because the client node
has sustained a power outage or operating system crash. In such
cases, the server SHOULD reserve any resources issued message. Items
to be changed are included as extensions in the client
until the client responds at some future time, until the resource
allocation times out (see section 6.6), or until administrative
intervention causes the resources to
``extensions'' field. This method MUST NOT be manually returned used
to use. reconfigure releasable resources. Examples of
information which can be reconfigured using this
method are DNS domain and servers, NTP servers, other
name service parameters. The server SHOULD also log a DHCP System Error.

If the server gets another DHCP Request from a client, with a
transaction-ID which does not match that of the recently transmitted
reconfigure message, generates and
sends the server SHOULD send a DHCP Reply to Reconfigure message; clients respond with
Reconfigure-reply messages.
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 27] 38]

Internet Draft DHCP Version 6 25 February 1999

the client, and wait for RECONF_MSG_RETRANS_INTERVAL, before
retransmitting the DHCP IPv6 5 May 2000

Reconfigure again.

6.6. Client-Resource timeouts

Some resources (for instance, a client's IP address) may only be
allocated to Trigger
This method uses the Reconfigure-init message. When
a client for receives a particular length of time (for instance, Reconfigure-init message, it
initiates a Request/Reply exchange with the valid lifetime server.
Any kind of an IP address). If the client does not renew
the resource allocation for such a resource, the server MAY make the can be reconfigured using this
method, including releasable resources. An example
of an releasable resource available for allocation to another client. However, under
administrative control, the is an IP address.

A server MAY reserve any resources issued can send Reconfigure and Reconfigure-init messages only to the client until the client responds at some future time.

7. DHCP Relay Considerations

The DHCP protocol is constructed so that a relay does not
those clients who have an address of sufficient scope to maintain any state in order to mediate DHCP client/server
interactions.

The DHCP relay enables be reachable
by the server. Thus, those clients who have not requested an IP
address and servers to carry out DHCP protocol
transactions. DHCP Solicit messages are issued by the relay when
initiated off-link cannot be reconfigured by prospective clients. By default, the relay locates
servers by use of multicasting solicitations to server.

Before initiating a reconfigure process, the All-DHCP-Servers
multicast group, but relays server SHOULD allow this behavior to be
configurable. The relay
configured with a REC_THRESHOLD threshold value which represents
the percentage of clients successfully reconfigured before the
reconfigure process is considered a success. See section 3.5 for the
default setting of REC_THRESHOLD. Note that the server MUST be able
to determine which the set of its
interfaces received clients that should receive the client's solicitation message.

7.1. DHCP Solicit reconfigure,
in order to determine when the reconfigure process is complete.
12.4.1. Creation and DHCP Advertise Message Processing

Upon receiving a DHCP Solicit message from sending of Reconfigure messages

When creating a prospective client, Reconfigure message, the server SHOULD start out
with a relay, by default, forwards buffer initialized with zeroed octets. The server sets the message
``msg-type'' field to servers at 6. The server generates a site
according to the following procedure:

- copying transaction-ID
from the prospective client's solicitation message fields into 0--1023 range and inserts it in the ``transaction-ID''
field. The server places its address (of appropriate fields of scope) in the outgoing solicitation,

- copying a non-link-local address of its interface from which
``server-address'' field.

The server then generates extensions for the
solicitation was received from non-releasable resources
to be changed and places them in the client into ``extensions'' field.

If the relay-address
field, and

- setting DHCP domain is using authentication, the prefix-size field appropriately,

- by default, setting server will generate
an authentication extension with the hop-count field appropriate settings and add
that extension as the last extension in the IP header ``extensions'' field of
the solicitation Reconfigure message.

The server multicasts the Reconfigure message to one or more
Reconfigure Multicast Addresses previously sent as extensions to the value DEFAULT_SOLICIT_HOPCOUNT (see
section 8).
clients. Note that a server MAY unicast Reconfigure message(s) to
specific clients by walking its list of bindings to determine the
unicast address(es) of the clients. Whether or not the Reconfigure
is multicast or unicast is an implementation detail.

A server waits for Reconfigure-reply messages from clients confirming
that they have received the Reconfigure.

Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 28] 39]

Internet Draft DHCP Version 6 25 February 1999

- setting the IP source address to be a site-local or global-scope
address belonging to the relay's interface on which for IPv6 5 May 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 client's
original solicitation was expected Reconfigure-reply
messages are received,

- finally, sending then the resulting message to one reconfigure process is successful.
If some or more servers.

By default, the relay sends solicitations to all of the All-DHCP-Servers
multicast address, FF05:0:0:0:0:0:1:3. However, expected Reconfigure-reply messages are not
received, then the relay MAY be
configured with an alternate server address, or retransmits the FQDN of a server.
Methods for automatically updating such alternately configured Reconfigure, and doubles
the RECREP_MSG_TIMEOUT value, and waits again. The server
addresses are not specified in continues
this document.

When the relay receives a DHCP advertisement, it relays process until all Reconfigure-reply messages are received or
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time
the
advertisement to server SHOULD abort the client at reconfigure process. The server SHOULD
log the client's link-local address by way result of the interface indicated reconfigure process.

Default and initial values for RECREP_MSG_TIMEOUT and
REC_MSG_ATTEMPTS are documented in the agent's address field.

7.2. DHCP Request Message Processing

When a relay receives section 3.5.
12.4.3. Receipt of Reconfigure-reply messages

Upon receipt of a DHCP Request valid Reconfigure-reply message, it SHOULD check that the IP source address in server
removes that client from the IP header list of clients it is expecting a link-local address,
that the link-local address matches the link-local address field in
the Request
Reconfigure-reply message header, from.
12.4.4. Creation and that the agent-address field sending of Reconfigure-init messages

When creating a Reconfigure-init message, the
message matches an IP address associated server SHOULD start
out with a buffer initialized with zeroed octets. The server sets
the interface ``msg-type'' field to 8. The server generates a transaction-ID
from
which the DHCP Request message was received. If any of these checks
fail, 0--1023 range and inserts it in the relay MUST silently discard ``transaction-ID''
field. The server places its address (of appropriate scope) in the Request message.
``server-address'' field.

The relay MUST check whether server MAY generate an ERE extension to inform the client of what
information has been changed or new information that has been added.

If the `S' bit DHCP domain is set in using authentication, the message
header. If not, server will generate
an authentication extension with the packet is discarded, appropriate settings and add
that extension as the relay SHOULD
return a DHCP Reply message to the address contained last extension in the client's
link-local address ``extensions'' field of
the Request message, with status
``PoorlyFormed'' (see Section 2.4).

If the received request message is acceptable, the relay then
transmits Reconfigure-init message.

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

The server found
in multicasts the server-address field of Reconfigure-init message to one or more
Reconfigure Multicast Addresses previously sent as extensions
to the received clients. Note that a server MAY unicast Reconfigure-init
Bound, Carney, Perkins Expires 1 November 2000 [Page 40]

Internet Draft DHCP Request message.
All for IPv6 5 May 2000

message(s) to specific clients by walking its list of bindings to
determine the fields unicast address(es) of DHCP the clients. Whether or not the
Reconfigure-init is multicast or unicast is an implementation detail.

A server waits for a Request message transmitted by from each client confirming that
they have received the relay Reconfigure-init and are copied over unchanged from thus initiating a
Request/Reply transaction with the DHCP server. The server can determine
that a Request received from the
client. Only message is in response to a Reconfigure-init because
the fields transaction-ID in the IP header Request will differ from be the
packet received from same value as was used
in the client. All relays MUST send DHCP Reconfigure-init message.
12.4.5. Time out and retransmission of Reconfigure-init messages

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

Upon receipt of a valid Request
messages using the source IP address from message with the interface where same transaction-ID
as the
DHCP request was received. If Reconfigure-init messages it sent, the Relay receives an ICMP error, server removes that
client from the
Relay SHOULD return list of clients it is expecting to initiate a DHCP
Request/Reply transaction.

The server generates and sends Reply message message(s) to the client address (which
can be found as
described in section 11.6.3, including in the payload of ``extension'' field
new values for configuration parameters. If the ICMP message [5]), extensions include
releasable resources, the server will include two extensions for each
resource - one with status
``ICMPError'' (see Section 2.4), along the original values with the DHCP Relay ICMP Error 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 [15]. 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 25 August 1999 1 November 2000 [Page 29] 41]

Internet Draft DHCP Version 6 25 February 1999

7.3. DHCP Reply Message Processing

When the relay receives for IPv6 5 May 2000

12.5.1. Receipt of Reconfigure messages

Upon receipt of a DHCP Reply, it MUST check that valid Reconfigure message, the message
has client extracts
the `L' bit set. It MUST check that configuration parameters contained in the client's link-local
address field contains a link-local address. If either check fails, ``extensions''
field, and notifies the packet MUST be silently discarded. If both checks application layer that new values for these
parameters are satisfied, available. The client then generates and sends a
Reconfigure-reply message to the relay MUST send server.
12.5.2. Creation and sending of Reconfigure-reply messages

When creating a Reconfigure-reply message, the client SHOULD start
out with a DHCP Reply message buffer initialized with zeroed octets. The client sets
the ``msg-type'' field to 7, and places the link-local address
listed in of
the interface upon which it received Reply message. Only the fields Reconfigure message in
the IP
header will differ from ``client's link-local address'' field. The client copies the packet received
values of the following fields from the server, not Reconfigure message to the
payload.

8. Retransmission and Configuration Variables

When a
Reconfigure-reply message:

o transaction-ID

o server-address

The client does not receive a DHCP Reply sets the ``status'' field appropriately (see the table
in response to a pending
DHCP Request, section 3.4) based upon the client MUST retransmit results of processing the identical DHCP Request,
with server's
reconfigure-reply.

The client places the same transaction-ID, to address of the same destination server again until it can
be reasonably sure that in the server
``server-address'' field.

If the client is unavailable configured to use authentication, the client
generates the appropriate authentication extension, and an alternative
can be chosen. The DHCP server assumes adds this
extension to the ``extensions'' field. Note that the authentication
extension MUST be the last extension in the ``extensions'' field.

The client has received delays the configuration information included with sending of the extensions to Reconfigure-reply by some
random value selected in the
DHCP Reply message, range of REC_REP_MIN and it is up to REC_REP_MAX
seconds. This delay helps reduce the client to continue to try for
a reasonable amount load on the server generated by
processing large numbers of time Reconfigure-reply messages.

Default and initial values for REC_REP_MIN and REC_REP_MAX are
documented in section 3.5.

The client unicasts the Reconfigure-reply to complete the transaction. All address identified
in the
actions specified ``server-address'' field. Sending the Reconfigure-reply
completes the reconfiguration process for the client.

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

Internet Draft DHCP Request in this section hold also for DHCP
Release IPv6 5 May 2000

12.5.3. Receipt of Reconfigure-init messages sent by

Upon receipt of a valid Reconfigure-init message, the client.

Similarly, when client
initiates a Request/Reply transaction with the server.
12.5.4. Creation and sending of Request messages

When responding to a Reconfigure-init, the client creates and
sends a DHCP the Request message in response to
a Reconfigure message from exactly the server, same manner as outlined in
section 11.4.1 with the following differences:

transaction-ID
The client assumes that the
DHCP server has received copies the Request. The server MUST retransmit transaction-ID from the identical DHCP Reconfigure to
Reconfigure-init message into the Request message.

Pause before sending Request
The client pauses before sending the Request for
a reasonable number
of times to try to elicit random value within the range REC_REP_MIN and
REC_REP_MAX seconds, as outlined in section 12.5.2.
12.5.5. Time out and retransmission of Request message from messages

The client uses the client.
If no corresponding DHCP same variables and retransmission algorithm as it
does with Request is received by messages generated as part of a client-initiated
configuration exchange. See section 11.4.2 for details.
12.5.6. Receipt of Reply messages

Upon the server after
REQUEST_MSG_MIN_RETRANS retransmissions, receipt of a valid Reply message, the server MAY erase or
deallocate information as needed from client extracts
the client's binding, but see
section 6.5.

Retransmissions occur using contents of the following ``extension'' field, and sets (or resets)
configuration variables
for a DHCP implementation. These parameters appropriately. If the configuration variables MUST be
configurable
parameters changed were requested by a the application layer, the
client or server:

CLIENT_ADV_WAIT

The minimum amount notifies the application layer of time a the changes using an
implementation-specific interface. If the resources changed are
releasable, the client waits makes the appropriate adjustments to receive its
management of the leases of these resources.
13. Using DHCP
Advertisements after transmitting a for network renumbering

An administrator can use DHCP Solicit to renumber links within her DHCP
domain through two techniques, passive renumbering and active
renumbering.

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

Internet Draft DHCP for IPv6 5 May 2000

13.1. Passive Renumbering

The administrator can configure her servers to return relatively
short preferred and valid lifetimes for the IP addresses she
makes available to clients. When she determines that she'd like
to renumber a network, she configures her servers through an
implementation-specific manner to disallow the extension of the IP
address lifetimes on the original network, and adds the new network
configuration data to the
All-DHCP Agents multicast address (see section 5.3).

Default: 2 seconds

Bound, Perkins Expires 25 August 1999 [Page 30]

Internet Draft DHCP Version 6 25 February 1999

DEFAULT_SOLICIT_HOPCOUNT server's database.

The default hop-count used in clients on the original network will fail to acquire lifetime
extensions on their IP header by DHCP relays addresses, and will request and acquire
IP addresses from the new network when
sending DHCP Solicit messages on behalf the valid lifetime of a client.

Default: 4

SERVER_MIN_ADV_DELAY

The minimum amount the
original IP addresses approaches expiration.

When the lifetimes for all of time a server waits to transmit a
DHCP Advertisement after receiving a DHCP Solicit at the
All-DHCP-Servers or All-DHCP-Agents multicast address.

Default: 100 milliseconds

SERVER_MAX_ADV_DELAY IP addresses on the original
network expire, the network can be considered renumbered.
13.2. Active Renumbering

The maximum amount administrator can force the renumbering of time a server waits to transmit a DHCP
Advertisement after receiving a networks in her DHCP Solicit at
domain by using the All-DHCP
Agents multicast address.

Default: 1 second

REPLY_MSG_TIMEOUT reconfigure feature of DHCP. She instructs her
servers of the network renumbering through an implementation-specific
interface. The time servers in seconds that a client waits the domain will generate Reconfigure-init
messages, which will cause the clients to receive a server's
DHCP Reply before retransmitting initiate a DHCP Request. Request/Reply
transaction with the server. The
client MUST multiply REPLY_MSG_TIMEOUT by a factor of 2 in
an exponential manner servers will include two IP address
extensions for each time it retransmits until
REQUEST_MSG_MIN_RETRANS (below) is attained. IP address being changed. The first will contain
the original IP address, with the preferred and valid lifetimes set
to zero. The second will contain the new IP address, with non-zero
preferred and valid lifetimes.

A client server implementation MAY be
configured permit the administrator to attempt 2 retransmissions before beginning set the
original IP address lifetimes to some small value greater than zero,
to allow applications running on the
exponential backoff retransmission in client to orderly transfer to
the previous sentence.

Default: 2 seconds.

REQUEST_MSG_MIN_RETRANS

The minimum number of new network over time.
14. DHCP Request transmissions that a client
should retransmit, before aborting Client Implementator Notes

This section provides helpful information for the request.

Default: 10 retransmissions.

RECONF_MSG_MIN_RETRANS client implementor
regarding their implementations. The minimum number text described here is not part
of DHCP Reconfigure messages that a
server should retransmit, before assuming the protocol, but rather a discussion of implementation features
we feel the client is
unavailable.

Default: 10 retransmissions. implementor should consider during implementation.

Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 31] 44]

Internet Draft DHCP Version 6 25 February 1999

RECONF_MSG_RETRANS_INTERVAL

The least time in seconds that a server waits for a
client's IPv6 5 May 2000

14.1. Primary Interface

Since configuration parameters acquired through DHCP Request before each retransmission of can be
interface-specific or more general, the DHCP
Reconfigure.

Default: 12 seconds.

RECONF_MMSG_MIN_RESP

The minimum amount of time before client implementor SHOULD
provide a mechanism by which the client implementation can respond be
configured to a specify which interface is the primary interface. The
client SHOULD always query the DHCP Reconfigure message sent to data associated with the primary
interface for non-interface specific configuration parameters. An
implementation MAY implement a multicast address.

Default: 2 seconds.

RECONF_MMSG_MAX_RESP

The maximum amount list of interfaces which would be
scanned in order to satisfy the general request. In either case, the
first interface scanned is considered the primary interface.

By allowing the specification of time before a primary interface, the client MUST respond to
implementor identifies which interface is authoritative for
non-interface specific parameters, which prevents configuration
information ambiguity within the client implementation.
14.2. Advertise Message and Configuration Parameter Caching

If the hardware the client is running on permits it, the implementor
SHOULD provide a
DHCP Reconfigure message sent to cache for Advertise messages and a multicast address.

Default: 10 seconds.

RECONF_MULTICAST_REQUEST_WAIT cache of
configuration parameters received through DHCP. Providing these
caches prevents unnecessary DHCP traffic and the subsequent load
this generates on the servers. The time a client should wait before retransmitting a Request
message in reponse to implementor SHOULD provide a retransmitted multicast Reconfigure
message.

Default: 120 seconds

MIN_SOLICIT_DELAY

The minimum
configuration knob for setting the amount of time a prospective the cache(s) are
valid.
14.3. Time out and retransmission variables

Note that the client time out and retransmission variables outlined
in section 3.5 can be configured on the server and sent to the client
through the use of the ``DHCP Retransmission Parameter Extension'',
which is required documented in the ``extensions document'' [2]. A client
implementation SHOULD be able to
wait, after determining from a Router Advertisement message
that reset these variables using the
values from this extension.
14.4. Server Preference

A client should perform stateful address configuration,
before MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
Solicit message to collect Advertise messages and compare their
preferences (see section 15.3), unless it receives an Advertise
message with a server.

Default: 1 second

MAX_SOLICIT_DELAY

The maximum amount preference of time a prospective 255. If the client is required to
wait, after determining from a Router Advertisement receives an
Advertise message
that with a preference of 255, then the client should perform stateful address configuration,
before sending a DHCP Solicit to a server.

Default: 5 seconds MAY act
immediately on that Advertise without waiting for any more additional
Advertise messages.

Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 32] 45]

Internet Draft DHCP Version 6 25 February 1999

XID_TIMEOUT

The amount of time a for IPv6 5 May 2000

15. DHCP server has to keep track of
client transaction-IDs in order to make sure that client
retransmissions using the same transaction-ID are idempotent.

Default: 600 seconds

9. Security Considerations

Clients and servers often have to authenticate Server Implementator Notes

This section provides helpful information for the messages they
exchange. For instance, a server may wish to be certain that a DHCP
Request originated from the client identified by implementor.
15.1. Client Bindings

A server implementation can use the <link-local
address, agent-address> fields included within client's link-local address
and the subnet prefix specification from which the client sent its
Request message
header. Conversely, it is quite often essential message(s) as an index for a client to
be certain that the finding configuration parameters and addresses
assigned to the client. While it has
received were sent isn't critical to keep track
of which clients were given information (resources) that isn't
releasable, it by an authoritative server. Similarly, a IS critical for the server should only accept a DHCP Release message which seems to be
from one keep track of its clients, if which
client it has some assurance that assigned releasable resources. The server MUST
include the client
actually did transmit transaction-ID from the Release message. Again, a client might
wish to only accept DHCP Reconfigure messages client's Request along with
the releasable resource identifier(s) within the binding. This is
done so that are certain to
have originated from a the server with authority to issue them.

The IPv6 Authentication Header can provide security for DHCPv6
messages when both endpoints have a suitable IP address. However, detect whether a client often has only Request is a link-local address, and such
retransmission of an address
is not sufficient earlier Request or an entirely new Request.

The server should periodically scan its bindings for a releasable
resources whose leases have expired. When the server which is off-link. In those
circumstances finds expired
resource assignments, it MUST delete these assignments, thereby
making these resources available to 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 DHCP relay lease on a releasable resource is involved, so that the DHCP message renewable, and
by how long.
15.2. Reconfigure Considerations

A server implementation MUST have the relay's address in provide an interface to the IP destination address field,
even though
administrator for initiating reconfigure events.

A server implementation may provide a mechanism for allowing the client aims to deliver
specification of how many clients comprise a reconfigure multicast
group. This enables the message administrator to control the server.
The DHCP Client-Server Authentication Extension [15] is intended to
be used in these circumstances.

Note that, if hit a client receives server
takes when a DHCP message which fails
authentication, it should continue to wait for another message which
might be correctly authenticated just as if the failed message had
never arrived; however, receiving such failed messages reconfigure event occurs.
15.3. Server Preference

The server implementation SHOULD be
logged.

10. Year 2000 considerations

Since all times are relative to allow the current time setting of a server
preference value by the transaction,
there administrator. The server preference
variable is no problem within an unsigned single octet value (0--255), with the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of lowest
preference being 0 and the current year. highest 255. Clients will choose higher
preference servers over those with lower preference values. If you
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 33] 46]

Internet Draft DHCP Version 6 25 February 1999

11. IANA Considerations

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

Section 3.3 specifies the use of several multicast groups, with
multicast addresses FF02:0:0:0:0:0:1:2, FF05:0:0:0:0:0:1:3, and
FF05:0:0:0:0:0:1:4.

This document also defines several status codes that are to be
returned with the DHCP Reply message (see section 4.4). The nonzero
values for these status codes which are currently specified are shown
in section 2.4.

There is a DHCPv6 extension [15] which allows clients and servers IPv6 5 May 2000

don't choose to
exchange values for some of the timing and retransmission parameters
defines in section 8. Adding new parameters implement this feature in your server, you MUST set
the future would
require extending server preference field to 0 in the values Advertise messages generated
by which the parameters are indicated 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 and transaction-ID, and enables the DHCP extension. Since there needs server to be quickly
determine whether a list kept, Request is a retransmission or a new Request
without the default
values for each parameter should also be stored as part cost of a database lookup. If an implementor chooses to
implement this cache, then they SHOULD provide a configuration knob
to tune the list.

All lifetime of these protocol elements may be specified to assume new values
at some point in the future. New values should be approved by cache entries.
16. DHCP Relay Implementator Notes

A relay implementation SHOULD allow the
process specification of IETF Consensus [12].

12. Acknowledgements

Thanks to the DHC Working Group a list of
destination addresses for their time and input into the
specification. Ralph Droms Solicit messages. This list MAY contain
any mixture of unicast addresses and Thomas Narten have had multicast addresses.

If a major
role relay receives an ICMP message in shaping the continued improvement of the protocol by their
careful reviews. Many thanks response to Matt Crawford, Erik Nordmark, Gerald
Maguire, and Mike Carney a DHCP message it
has forwarded, it SHOULD log this event.
17. Open Issues for their studied review as part of the
Last Call process. Thanks also Working Group Discussion

This section contains some items for the consistent input, ideas, and
review discussion by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.

Thanks to Steve Deering and Bob Hinden, who the working group.
17.1. Trade-offs: Optional fields in DHCP messages

You'll notice that the message formats have consistently
taken changed. In particular,
some of the time to discuss optional fields are now required. This will increase the more complex parts
size of DHCP messages in some cases, consuming network bandwidth and
memory on the IPv6
specifications.

A. Changes DHCP client (an issue for this revision

- Fixed grammatical and clarity problems.

- Added saved agent-address field small devices such as PDAs).

The changes were made for the following reasons:

o Fields that were used most 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 for
robustness reasons (receivers can validate that the solicit message is
for them, and
altered and enhanced references to in the C bit use. case of clients, know which interface the
message is intended for).

o Simplicity.
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 34] 47]

Internet Draft DHCP Version 6 25 February 1999

- Removed all references of agent-address prefix for IPv6 5 May 2000

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

Now that the DHCPv4 authentication draft is implied
by in last call, should
we use the technique described in that document to provide
authentication for DHCPv6, or should we continue with the
authentication technique currently documented in the agent-address extensions
draft?
17.3. The Reconfigure Message and Subnet Prefix Extensions

The drafts currently specify that Releasable resources (such as an IP
address) can only be used as such by implementors.

- Verified all binding dependencies use reconfigured using the link-local address and
agent-address.

- Added Reconfigure-init trigger
message. This was done for simplicity (enables clients in what cases SHOULD retain specific addresses when to perform
DAD on the client is not stationary.

- Updated DHCP terminology section new address and re-ordered.

- Put RFC 2119 terms in lower case, in section 3.1.

- Changed definition return the appropriate result to the
server) using the same mechanism as a standard Request/Reply/Release
exchange. This method also makes no assumptions about the
charactistics of transaction-ID and specified ranges the releasable resource.

However, for
client and server use.

- Added IP addresses with interface IDs, one could send out
two IP address extensions, one for the old prefix and fixed text to clarify use of Reconfigure message one for the
new, and cause clients in all relevant sections.

- Added words in spec to differentiate format section from
processing section.

- Added retransmission algorithm for Reconfigure multicast messages change the prefix and new configuration parameter. thus renumber over
time. This scheme avoids the added DHCP Request traffic - Differentiated processing for requests by clients when received
from Reconfigure
acknowledge with a Reconfigure-reply message.

- Added more words when binding cache
17.4. ``R'' bit in Request message not needed?

Now that the transaction-ID is used for XID timeout.

- Added exponential backoff to client retransmissions.

- Updated stored along with the references section.

B. Related Protocol Specifications

Related work releasable
resource identifier in IPv6 that would best serve a client's binding, the transaction-ID cache
becomes an implementor to study
is optional feature of the IPv6 Specification [7], DHCP server implementation, not a
requirement of the IPv6 Addressing Architecture [9],
IPv6 Stateless Address Autoconfiguration [20], IPv6 Neighbor
Discovery Processing [14], protocol. Should we do away with the ``R'' bit?
18. Security Considerations

Clients and Dynamic Updates to DNS [22]. These
specifications enable DHCP servers often have to build upon authenticate the IPv6 work messages they
exchange. For instance, a server may wish to provide
both robust stateful autoconfiguration and autoregistration of DNS
Host Names.

The IPv6 Specification provides be certain that a
Request originated from the base architecture and design of
IPv6. A key point client identified by the <link-local
address, subnet-prefix> fields included within the Request message
header. Conversely, it is quite often essential for DHCP implementors a client to understand is that IPv6
requires
be certain that every link in the internet have configuration parameters and addresses it has
received were sent to it by an MTU authoritative server. Similarly, a
server should only accept a Release message which seems to be from
one of 1500 octets
or greater (in IPv4 the requirement is 68 octets). This means its clients, if it has some assurance that the client actually
Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 35] 48]

Internet Draft DHCP Version 6 25 February 1999

a UDP packet of 536 octets will always pass through an internet
(less 40 octets for the IPv6 header), as long as there 5 May 2000

did transmit the Release message. Again, a client might wish to only
accept Reconfigure or Reconfigure-init messages that are no IP
options prior certain to the UDP header in the packet. But,
have originated from a server with authority to issue them.

The IPv6 does 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
support fragmentation at routers, sufficient for a server which is off-link. In those
circumstances the relay is involved, so that fragmentation takes place
end-to-end between hosts. If the DHCP message MUST
have the relay's address in the IP destination address field, even
though the client aims to deliver the message 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 DHCP implementation needs message which fails
authentication, it should continue to wait 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 2000 considerations

Since all times are relative to send a
packet greater than 1500 octets it can either fragment the UDP packet
into fragments current time of 1500 octets or less, or use Path MTU Discovery [11]
to determine the size transaction,
there is no problem within the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the packet that will traverse a network
path. It is implementation dependent how this is accomplished in
DHCP. Path MTU Discovery for IPv6 is supported for both current year.
20. IANA Considerations

This document defines message types 1--8 to be received by UDP at
port numbers 546 and TCP
and can cause end-to-end fragmentation when the PMTU changes for a
destination.

The IPv6 Addressing Architecture specification [9] defines the
address scope that can 547. Additional message types may be used defined 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 future.

Section 3.1 lists several multicast is required, and nodes can create link-local addresses
during initialization. used by DHCP.

This means document also defines several status codes that a client can immediately use
its link-local address and a well-known multicast address to begin
communications are to discover neighbors on
be returned with the link. For instance, a
client can send a DHCP Solicit Reply and locate a server or relay.

IPv6 Stateless Address Autoconfiguration [20] (Addrconf) specifies
procedures by Reconfigure-reply messages (see
sections 9.4 and 9.7). The non-zero values for these status codes
which are currently specified are shown in the table in section 3.4.

There is a node may autoconfigure addresses based on
router advertisements [14], DHCPv6 extension [2] which allows clients and the use of a valid lifetime servers to
support renumbering
exchange values for some of addresses on the Internet. In addition timing and retransmission parameters
defined in section 3.5. Adding new parameters in the
protocol interaction future would
require extending the values by which a node begins stateless or stateful
autoconfiguration is specified. the parameters are indicated in
the DHCP is one vehicle extension. Since there needs to perform
stateful autoconfiguration. Compatibility with Addrconf is be a design
requirement list kept, the default
values for each parameter should also be stored as part of the list.
Bound, Carney, Perkins Expires 1 November 2000 [Page 49]

Internet Draft DHCP (see Section 3.1). for IPv6 Neighbor Discovery [14] is the node discovery 5 May 2000

All of these protocol elements may be specified to assume new values
at some point in IPv6
which replaces and enhances functions the future. New values should be approved by the
process of ARP [16]. To understand
IPv6 and Addrconf it is strongly recommended that implementors
understand IPv6 Neighbor Discovery.

Dynamic Updates IETF Consensus [11].
21. Acknowledgements

Thanks to DNS [22] is a specification that supports the
dynamic update of DNS records DHC Working Group for both IPv4 their time and IPv6. DHCP can use input into the dynamic updates to DNS
specification. Ralph Droms and Thomas Narten have had a major
role in shaping the continued improvement of the protocol by their
careful reviews. Many thanks to integrate addresses Matt Crawford, Erik Nordmark, Gerald
Maguire, and Mike Carney for their studied review as part of the
Last Call process. Thanks also for the consistent input, ideas, and
review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
Rekhter, Matt Thomas, Sue Thomson, and name space to
not only support autoconfiguration, but also autoregistration in
IPv6. The security model Phil Wells.

Thanks to be used with DHCPv6 should conform as
closely as possible Steve Deering and Bob Hinden, who have consistently
taken the time to discuss the authentication model outlined in [10].

Bound, Perkins Expires 25 August 1999 [Page 36]

Internet Draft DHCP Version 6 25 February 1999

C. more complex parts of the IPv6
specifications.
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 [8, [7, 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 a an on-link server or relay agent
on the local link.
relay.

o The need for BOOTP compatibility and the broadcast flags is 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 Many Some DHCPv4 options are unnecessary now because the configuration
parameters are either obtained through IPv6 Neighbor Discovery or
the Service Location protocol [21]. [16].

DHCPv6 Architecture/Model Changes:

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

o IPv6 Address allocations are now handled in a message extension
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

Bound, Perkins Expires 25 August 1999 [Page 37]

Internet Draft DHCP Version 6 25 February 1999
either directly from an on-link server, or from a remote off-link server
through an on-link relay-agent. relay.

o Servers are discovered by a client solicit, Solicit, followed by a server
or relay-agent advertisement.
Advertise message

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

o The on-link relay-agent locates remote relay may locate off-link server addresses from
system configuration or by the use of a site wide 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 DHCP 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 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 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.

o Addresses allocated with too-long lifetimes can be reclaimed using the Reconfigure Reconfigure-init message.

o Integration between stateless and stateful address
autoconfiguration.

Bound, Perkins Expires 25 August 1999 [Page 38]

Internet Draft DHCP Version 6 25 February 1999

o Enabling relay-agents relays to locate remote servers for a link.

D. 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. RFC 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 words for Use use in RFCs to Indicate Requirement
Levels. RFC Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.

[3]

[4] S. Bradner and A. Mankin. The Recommendation for the IP Next
Generation Protocol. RFC 1752, January 1995.

[4] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) Request for the Comments (Proposed Standard)
1752, Internet Protocol Version 6 (IPv6). RFC 1885,
December Engineering Task Force, January 1995.

[5] A. Conta and S. Deering. RFC 2463: Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)

Bound, Perkins Expires 25 August 1999 [Page 39] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for
Comments 951, Internet Draft DHCP Version 6 25 February 1999

Specification, December 1998. Obsoletes RFC1885 [4]. Status:
DRAFT STANDARD. Engineering Task Force, September 1985.

[6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995.

[7] S. Deering and R. Hinden. RFC 2460: Request for Comments (Draft Standard) 2460,
Internet Protocol, Version
6 (IPv6) specification, Engineering Task Force, December 1998. Obsoletes RFC1883 [6].
Status: DRAFT STANDARD.

[8]

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

[9]

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

[10]

[9] S. Kent and R. Atkinson. RFC 2402: IP authentication header, Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998. Status: PROPOSED STANDARD.

[11]

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

[12]

[11] T. Narten and H. Alvestrand. RFC 2434: Guidelines for writing Writing an IANA considerations section
Considerations Section in RFCs, RFCs. Request for Comments (Best
Current Practice) 2434, Internet Engineering Task Force, October
1998. Status:
BEST CURRENT PRACTICE.

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

Internet Draft DHCP for IPv6 5 May 2000

[12] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP version Version 6 (IPv6). RFC 1970, August 1996.

[14] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor
discovery Request for IP Version 6 (IPv6), Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998. Obsoletes
RFC1970 [13]. Status: DRAFT STANDARD.

[15] C. Perkins. Extensions for the Dynamic Host Configuration
Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-11.txt, February
1999. (work in progress).

[16] David

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

[17]

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

[18] J. B. Postel, Editor. Internet Protocol. RFC 791, September
1981.

[19]

[15] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. RFC 1971, August 1996.

Bound, Perkins Expires 25 August 1999 [Page 40] Request for Comments (Draft Standard) 2462,
Internet Draft DHCP Version 6 25 February 1999

[20] S. Thomson and T. Narten. RFC 2462: IPv6 stateless address
autoconfiguration, Engineering Task Force, December 1998. Obsoletes RFC1971 [19].
Status: DRAFT STANDARD.

[21]

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

[22]

[17] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic
Updates in the Domain Name System (DNS). RFC (DNS UPDATE). Request for
Comments (Proposed Standard) 2136, Internet Engineering Task
Force, April 1997.
Bound, Carney, Perkins Expires 1 November 2000 [Page 54]

Internet Draft DHCP for IPv6 5 May 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

Phone: (717) 524-1145 (570) 577-1145
E-mail: droms@bucknell.edu

Author's Address

Questions about this memo can be directed to:

Jim Bound Charles E. Perkins
Compaq Computer Corporation Sun Microsystems Laboratories
Mail Stop: ZK03-3/U14
110 Spitbrook Road, ZKO3-3/U14 15 Network Circle Road
Nashua, NH 03062 Menlo Park, CA 94025
USA
USA
Phone: +1-603-884-0400 Phone: +1 650 786-6464
EMail:
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: cperkins@eng.sun.com charliep@iprg.nokia.com
Fax: +1 650 786-6445 625-2502

Bound, Carney, Perkins Expires 25 August 1999 1 November 2000 [Page 41] 55]
----