WDIFF

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

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

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

Status of This Memo

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

Distribution of this memo is unlimited.

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

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

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

Abstract

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

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

Internet Draft DHCP for IPv6 22 November 2000 separately
or concurrently with the latter to obtain configuration parameters.

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

Internet Draft DHCP for IPv6 22 November 2000 1 March 2001

Contents

Status of This Memo i

Abstract i

1. Introduction 1

2. Requirements 1

3. Background 1

4. Design Goals 3

5. Non-Goals 3

6. Terminology 2
2.1. 4
6.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. 4
6.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3

3. 5

7. DHCP Constants 4
3.1. 6
7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 5
3.2. 7
7.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. 7
7.3. DHCP message types . . . . . . . . . . . . . . . . . . . 5
3.4. 7
7.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 7
3.4.1. 9
7.4.1. Generic Error Values . . . . . . . . . . . . . . 7
3.4.2. 9
7.4.2. Server-specific Error Values . . . . . . . . . . 7
3.5. 9
7.5. Configuration Variables . . . . . . . . . . . . . . . . . 8

4. Requirements 8

5. Background 9

6. Design Goals 10

7. Non-Goals 11

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

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

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

Internet Draft DHCP for IPv6 22 November 2000 14
9.4. DHCP Reply Confirm Message Format . . . . . . . . . . . . . . . . 17 14
9.5. DHCP Release Renew Message Format . . . . . . . . . . . . . . . 18 . 15
9.6. DHCP Reconfigure Rebind Message Format . . . . . . . . . . . . . 18 . . 15
9.7. DHCP Reconfigure-reply Reply Message Format . . . . . . . . . . 18 . . . . . . 16
9.8. DHCP Reconfigure-init Release Message Format . . . . . . . . . . 19
9.9. Relay-forward message . . . . . 16

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page ii]

Internet Draft DHCP for IPv6 1 March 2001

9.9. DHCP Decline Message Format . . . . . . . . . . . . . . . 20 16
9.10. Server-forward DHCP Reconfigure-init Message Format . . . . . . . . . . 17

10. Relay messages 17
10.1. Relay-forward message . . . . . . . . . . . . . . . . . 20
9.11. Identity association . 17
10.2. Relay-reply message . . . . . . . . . . . . . . . . . 21

10. . . 18

11. Identity association 18

12. DHCP Server Solicitation 21
10.1. 19
12.1. Solicit Message Validation . . . . . . . . . . . . . . . 21
10.2. Advertise 19
12.2. Advertise Message Validation . . . . . . . . . . . . . . 21
10.3. 19
12.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 22
10.3.1. 19
12.3.1. Creation and sending of the Solicit message . . . 22
10.3.2. 19
12.3.2. Time out and retransmission of Solicit Messages . 22
10.3.3. 20
12.3.3. Receipt of Advertise messages . . . . . . . . . . 23
10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 23
10.4.1. Relaying of Solicit messages . . . . . . . . . . 23
10.4.2. Relaying of Advertise messages . . . . . . . . . 24
10.5. 20
12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 24
10.5.1. 21
12.4.1. Receipt of Solicit messages . . . . . . . . . . . 24
10.5.2. 21
12.4.2. Creation and sending of Advertise messages . . . 24

11. 21

13. DHCP Client-Initiated Configuration Exchange 25
11.1. Request 22
13.1. Client Message Validation . . . . . . . . . . . . . . . 25
11.2. Reply . 22
13.2. Server Message Validation . . . . . . . . . . . . . . . . 26
11.3. Release Message Validation . . 23
13.3. Client Behavior . . . . . . . . . . . . . 26
11.4. Client Behavior . . . . . . . . 23
13.3.1. Creation and sending of Request messages . . . . 24
13.3.2. Creation and sending of Confirm messages . . . . 24
13.3.3. Creation and sending of Renew messages . . . . . 26
11.4.1.
13.3.4. Creation and sending of Request Rebind messages . . . . 27
11.4.2. Time out and retransmission of Request Messages . 27
11.4.3.
13.3.5. Receipt of Reply message in response to a Request Reply,
Confirm, Renew or Rebind message . . . . . 28
11.4.4.
13.3.6. Creation and sending of Release messages . . . . 28
11.4.5. 29
13.3.7. Time out and retransmission of Release Messages . 29
11.4.6.
13.3.8. Creation and sending of Decline messages . . . . 30
13.3.9. Time out and retransmission of Decline Messages . 30
13.3.10. Receipt of Reply message in response to a Release 29
11.4.7. When a client should send a Request
message . . . 29
11.4.8. Initialization . . . . . . . . . . . . . . 31
13.4. Server Behavior . . . 29
11.4.9. Confirming the validity of IPv6 addresses . . . . 29
11.4.10. Extending the lifetimes on IPv6 addresses . . . . 30
11.5. Relay Behavior . . . . . . . . . . 31
13.4.1. Receipt of Request messages . . . . . . . . . . . 31
11.5.1. Relaying
13.4.2. Receipt of Request or Release Confirm messages . . . . . 31
11.6. Server Behavior . . . . . . . . . 32
13.4.3. Receipt of Renew messages . . . . . . . . . . . . 31
11.6.1. 32
13.4.4. Receipt of Request Rebind messages . . . . . . . . . . . 31
11.6.2. 33
13.4.5. Receipt of Release messages . . . . . . . . . . . 31
11.6.3. Creation and sending 34
13.4.6. Sending of Reply messages . . . . . 32

12. . . . . . . . 35

14. DHCP Server-Initiated Configuration Exchange 33
12.1. Reconfigure 35
14.1. Reconfigure-init Message Validation . . . . . . . . . . . . . 33
12.2. Reconfigure-reply Message Validation 35
14.2. Server Behavior . . . . . . . . . . 33
12.3. Reconfigure-init Message Validation . . . . . . . . . . . 33

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

Internet Draft DHCP for IPv6 22 November 2000

12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 33
12.4.1. 35
14.2.1. Creation and sending of Reconfigure Reconfigure-init messages . . 34
12.4.2. 36
14.2.2. Time out and retransmission of Reconfigure unicast
Reconfigure-init messages . . . . . . . . . . . . . . . . . 34
12.4.3. Receipt of Reconfigure-reply messages . . . . . . 34
12.4.4. Creation and sending of Reconfigure-init messages 34
12.4.5. 37
14.2.3. Time out and retransmission of multicast
Reconfigure-init messages . . . . . . . . . . . . . . . . . 35
12.4.6. 37
14.2.4. Receipt of Request messages . . . . . . . . . . . 35
12.5. 37

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page iii]

Internet Draft DHCP for IPv6 1 March 2001

14.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 35
12.5.1. 37
14.3.1. Receipt of Reconfigure-init messages . . . . . . 35
12.5.2. 37
14.3.2. Creation and sending of Request messages . . . . 36
12.5.3. 38
14.3.3. Time out and retransmission of Request messages . 36
12.5.4. 38
14.3.4. Receipt of Reply messages . . . . . . . . . . . . 36

13. Using DHCP for network renumbering 36

14. DHCP Client Implementor Notes 37
14.1. Primary Interface . . 38

15. Relay Behavior 38
15.1. Relaying of Solicit messages . . . . . . . . . . . . . . 39
15.2. Relaying of Advertise messages . . . . 37
14.2. Advertise Message and Configuration Parameter Caching . . 37
14.3. Time out and retransmission variables . . . . . . . 39

16. DHCP options 39
16.1. Format of DHCP options . . . 37
14.4. Server Preference . . . . . . . . . . . . . . 40
16.2. Identity association option . . . . . . 38

15. DHCP Server Implementor Notes 38
15.1. Client Bindings . . . . . . . . . 40
16.3. Option request option . . . . . . . . . . . . 38
15.2. Reconfigure-init Considerations . . . . . . 42
16.4. Client message option . . . . . . . 38
15.3. Server Preference . . . . . . . . . . . 43
16.5. Server message option . . . . . . . . . 39
15.4. Request Message Transaction-ID Cache . . . . . . . . . 43
16.6. Retransmission parameter option . 39

16. DHCP Relay Implementor Notes 39

17. Open Issues for Working Group Discussion 39
17.1. Authentication . . . . . . . . . . . . 44
16.7. Authentication option . . . . . . . . . 39
17.2. DHCP-DNS interaction . . . . . . . . . 44
16.8. Reconfigure-delay option . . . . . . . . . 39
17.3. Release vs. Decline . . . . . . . 44
16.9. DSTM Global IPv4 Address Option . . . . . . . . . . . 40
17.4. Request messages . . 44

17. DHCP Client Implementor Notes 45
17.1. Primary Interface . . . . . . . . . . . . . . . . . . 40
17.5. Use of term ``agent'' . . 45
17.2. Advertise Message and Configuration Parameter Caching . . 46
17.3. Time out and retransmission variables . . . . . . . . . . 46
17.4. Server Preference . . . . 40
17.6. Use of terms ``subnet'' and ``network'' . . . . . . . . . 40

18. Security 40

19. Year 2000 considerations 41

20. IANA Considerations 41

21. Acknowledgments 41

22. DHCP options 42
22.1. Format of DHCP options . . . . . . . 46

18. DHCP Server Implementor Notes 46
18.1. Client Bindings . . . . . . . . . . 42

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

Internet Draft DHCP for IPv6 22 November 2000

22.2. Identity association option . . . . . . . . . . . 46
18.2. Reconfigure-init Considerations . . . . 43
22.3. Option request option . . . . . . . . . 47
18.2.1. Reliable transmission of multicast Reconfigure-init
messages . . . . . . . . . 44
22.4. Client message option . . . . . . . . 47
18.3. Server Preference . . . . . . . . . . 45
22.5. Server message option . . . . . . . . . . 47
18.4. Request Message Transaction-ID Cache . . . . . . . . 45
22.6. Retransmission parameter option . . 47

19. DHCP Relay Implementor Notes 48

20. Open Issues for Working Group Discussion 48
20.1. Authentication . . . . . . . . . . . 46
22.7. Authentication option . . . . . . . . . . 48
20.2. Identification of IAs by servers . . . . . . . . 46

23. Changes in this draft 46
23.1. Order of sections . . . . 48
20.3. DHCP-DNS interaction . . . . . . . . . . . . . . . . 47
23.2. Reconfigure message . . 48
20.4. Anonymous addresses . . . . . . . . . . . . . . . . . 47
23.3. Releasable resources . . 48
20.5. Use of term "agent" . . . . . . . . . . . . . . . . 47
23.4. DHCP message header . . . 48
20.6. Client behavior when response to Rebind is not received . 49
20.7. Additional options . . . . . . . . . . . . . . . 47
23.5. Design goals . . . . 49
20.8. Operational parameters . . . . . . . . . . . . . . . . . 49

21. Security 49

22. Year 2000 considerations 49

23. IANA Considerations 49

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

Internet Draft DHCP for IPv6 1 March 2001

24. Acknowledgments 50

A. Comparison between DHCPv4 and DHCPv6 50

B. Full Copyright Statement 52

C. Changes in this draft 53
C.1. New messages for confirming addresses and extending the lease
on an IA . 47
23.6. Overview . . . . . . . . . . . . . . . . . . . . . . 53
C.2. New message formats . . . . 47
23.7. Message formats, 9 . . . . . . . . . . . . . . . 53
C.3. Renamed Server-forward message . . . . 47
23.8. Solicit . . . . . . . . . 53
C.4. Clarified relay forwarding of messages . . . . . . . . . 53
C.5. Addresses and options in Advertise messages, (section 10) messages . . . . . . 48
23.9. Prefix advertisement . 53
C.6. Clarification of IA option format . . . . . . . . . . . . 53
C.7. Specification of transaction ID in Solicit message . . . 54
C.8. Edits to definitions . . 48
23.10. Identity Associations . . . . . . . . . . . . . . . . 54
C.9. Relay agent messages . . . 48
23.11. Extensions renamed options; defined in this document . . 48
23.12. Transaction-ID ranges . . . . . . . . . . . . . 54
C.10. Relay agent behavior . . . . . 48
23.13. Release . . . . . . . . . . . . . 54
C.11. Transmission of all client messages and through relays . . . 54
C.12. Reconfigure-init messages . . . . . . . . . . . . 48
23.14. Discovering relay agents . . . . 54
C.13. Ordering of sections . . . . . . . . . . . . 48

A. Comparison between DHCPv4 and DHCPv6 49

B. Full Copyright Statement 51 . . . . . . 54
C.14. DSTM option . . . . . . . . . . . . . . . . . . . . . . . 54

Chair's Address 54 57

Author's Address 54 57

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

Internet Draft DHCP for IPv6 22 November 2000 1 March 2001

1. Introduction

This document describes DHCP for IPv6 (DHCP), a UDP [13] client
/ server [12]
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 IPv6 addresses and configuration
of network stack parameters than that offered by ``IPv6 "IPv6 Stateless
Autoconfiguration'' [14].
Autoconfiguration" [13]. 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.

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.
DHCP is designed to be easily extended to carry new configuration
parameters through the addition of new DHCP ``options'' "options" defined to
carry this information. (What were called ``extensions'' in the -15
draft are now called ``options''; see section 23.11.)

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

2. Requirements

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

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 also makes use of internal conceptual variables
to helpful background specifications
covering related IPv6 protocols. Section 6 discusses the design
goals describe protocol behavior and external variables 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, an
implementation must allow system administrators to change. The
specific variable names, how their values change, and identifies DHCP functional
entities (client, relay, server). Section 9 describes how their
settings influence protocol behavior are provided to demonstrate
protocol behavior. An implementation is not required to have them in detail
the format of each DHCP message type. Section 10 discusses DHCP
server solicitation. Section 11 discusses DHCP client-initiated
configuration information exchange. Section 12 discusses DHCP
server-initiated configuration information exchange. Section 14
presents helpful notes for DHCP client implementors. Section 15
presents helpful notes for DHCP server implementors. Section 16
presents helpful notes for DHCP relay implementors. Section 18
discusses security considerations for DHCP.

Section 23 describes
the changes between exact form described here, so long as its external behavior is
consistent with that described in this version of document.

3. Background

Related work in IPv6 that would best serve an implementor to study
is the DHCPv6
specification IPv6 Specification [5], the IPv6 Addressing Architecture [7],
IPv6 Stateless Address Autoconfiguration [13], IPv6 Neighbor
Discovery Processing [10], and draft-ietf-dhc-dhcpv6-15.txt. Dynamic Updates to DNS [15]. These
specifications enable DHCP to build upon the IPv6 work to provide

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

Internet Draft DHCP for IPv6 22 November 2000

2. Terminology

2.1. IPv6 Terminology 1 March 2001

both robust stateful autoconfiguration and autoregistration of DNS
Host Names.

The IPv6 terminology relevant to this specification from Specification provides the IPv6
Protocol [5], IPv6 Addressing Architecture [7], base architecture and IPv6 Stateless
Address Autoconfiguration [14] is included below.

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

unicast address
An identifier for a single interface.
IPv6. A packet sent key point for DHCP implementors to a unicast address understand is delivered to that IPv6
requires that every link in the interface
identified by Internet have an MTU of 1280 octets
or greater (in IPv4 the requirement is 68 octets). This means that address.

multicast address
An identifier for
a set UDP packet of interfaces (typically
belonging 536 octets will always pass through an internetwork
(less 40 octets for the IPv6 header), as long as there are no IP
options prior to different nodes). A the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a
packet sent greater than 1500 octets it can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [8]
to determine the size of the packet that will traverse a
multicast network
path.

DHCP clients use Path MTU discovery when they have an address is delivered of
sufficient scope to all interfaces
identified by that address.

host Any node reach the DHCP server. If a DHCP client does not
have such an address, that client MUST fragment its packets if the
resultant message size is not greater than the minimum 1280 octets.

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

IP Internet Protocol Version 6 (IPv6).
destination.

The terms IPv4 and IPv6 are Addressing Architecture specification [7] defines the
address scope that can be 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 an IPv6 implementation, and the link layer, i.e.,
various configuration architecture guidelines for network designers
of 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 address space. Two advantages of IPv6 are that support
for Ethernet or Token Ring
network interfaces, multicast is required, and E.164 nodes can create link-local addresses for ISDN links.
during initialization. This means that a client can immediately use
its link-local address
An IP and a well-known multicast address having link-only scope, indicated by
having the prefix (FE80::0000/64), that can be used to reach neighboring nodes attached begin
communications to discover neighbors on the same link.
Every interface has For instance, a link-local address.

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

Internet Draft DHCP for IPv6 22 November 2000

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

neighbor A locate a server or relay.

IPv6 Stateless Address Autoconfiguration [13] (Addrconf) specifies
procedures by which a node attached to may autoconfigure addresses based on
router advertisements [10], and the same link.

node A device that implements IP.

packet An IP header plus payload.

prefix A bit string that consists of some number use of initial
bits a valid lifetime to
support renumbering of an address.

router A addresses on the Internet. In addition the
protocol interaction by which a node that forwards IP packets not explicitly
addressed to itself.

2.2. DHCP Terminology

Terminology specific to begins stateless or stateful
autoconfiguration is specified. DHCP can be found below.

abort status
A status value returned is one vehicle to the application that has
invoked perform
stateful autoconfiguration. Compatibility with addrconf is a DHCP client operation, indicating anything
other than success.

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

binding A binding (or, client binding) (see Section 4).

IPv6 Neighbor Discovery [10] is a group of server
data records indexed by <prefix, UUID> containing the
server's information about the addresses node discovery protocol in IPv6
which replaces and other
information assigned to the IA.

DHCP Dynamic Host Configuration Protocol for IPv6. The
terms DHCPv4 enhances functions of ARP [11]. To understand
IPv6 and DHCPv6 are used only in contexts where Addrconf it is necessary strongly recommended that implementors
understand IPv6 Neighbor Discovery.

Dynamic Updates to avoid ambiguity.

configuration parameter

An element of the configuration information set on DNS [15] is a specification that supports the
server
dynamic update of DNS records for both IPv4 and delivered to IPv6. DHCP can use
the client using DHCP. Such
parameters may be used to carry information dynamic updates to be used
by a node DNS to configure its network subsystem integrate addresses and enable
communication on a link or internetwork, for example. name space to

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

Internet Draft DHCP for IPv6 22 November 2000 1 March 2001

not only support autoconfiguration, but also autoregistration in
IPv6.

4. Design Goals

- DHCP client (or client)
A node that initiates requests on is a link to obtain
configuration parameters from one or more mechanism rather than a policy. Network administrators
set their administrative policies through the configuration
parameters they place upon the DHCP servers. servers in the DHCP domain
A chunk of network topology managed by DHCP and
operated by a single administrative entity.
they're managing. DHCP server (or server)
A server is a node that responds simply used to deliver parameters
according to requests from
clients, and may or may not be on the same link as the
client(s).

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

- DHCP agent (or agent)
Either a is compatible with IPv6 stateless autoconf [13].

- DHCP server does not require manual configuration of network parameters
on the same link as a client, or a DHCP relay.

Identity association (IA) clients, except in cases where such configuration is
needed for security reasons. A collection of addresses assigned to node configuring itself using
DHCP should require no user intervention.

- DHCP does not require a client. Each
IA has an associated UUID. A server identifies an IA by
the tuple (prefix, UUID), where ``prefix'' is on each link. To allow for scale
and economy, DHCP must work across DHCP relays.

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

- DHCP clients can operate on a prefix
assigned to the link to which without IPv6 routers present.

- DHCP will provide the client is attached,
An IA may have 0 or more addresses associated with it.

Releasable resource
(Removed; see section 23.3.)

transaction-ID
An unsigned integer ability to match responses with replies
initiated either renumber network(s) when
required by a client or server.

UUID network administrators [3].

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

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

5. Non-Goals

This specification explicitly does not cover the following:

- Specification of a client.

DISCUSSION:

Rules for choosing DHCP server to server protocol.

- How a UUID are TBD.

3. DHCP Constants

This section describes various program and networking constants used
by DHCP. server stores its DHCP data.

- How to manage a DHCP domain or DHCP server.

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

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

Internet Draft DHCP for IPv6 22 November 2000

3.1. Multicast Addresses

DHCP makes use 1 March 2001

6. Terminology

6.1. IPv6 Terminology

IPv6 terminology relevant to this specification from the IPv6
Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless
Address Autoconfiguration [13] is included below.

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

unicast address An identifier for a single interface.
A packet sent to a unicast address is
delivered to the following interface identified by
that address.

multicast addresses:

All DHCP Agents address: FF02::1:2
This link-local address An identifier for a set of interfaces
(typically belonging to different nodes).
A packet sent to a multicast address is used by clients
delivered to
communicate with the on-link agent(s) when they do all interfaces identified by
that address.

host Any node that is not
know those agents' link-local address(es). All agents
(servers a router.

IP Internet Protocol Version 6 (IPv6). The
terms IPv4 and relays) IPv6 are members of this multicast
group.

All DHCP Servers address: FF05::1:3
This site-local multicast address is used by clients or
relays to communicate with server(s), either because
they want only in
contexts where it is necessary to send messages avoid
ambiguity.

interface A node's attachment to all servers a link.

link A communication facility or because
they do not know medium over
which nodes can communicate at the server(s) unicast address(es).
Note that in order 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 a client to use this address,
it must have an interface.
Examples include IEEE 802 addresses for
Ethernet or Token Ring network interfaces,
and E.164 addresses for ISDN links.

link-local address of sufficient scope to be
reachable An IP address having link-only
scope, indicated by having the server(s). All servers within the
site are members of this multicast group.

3.2. UDP ports

DHCP uses the following destination UDP [13] port numbers. While
source ports MAY prefix
(FE80::0000/64), that can be arbitrary, client implementations SHOULD permit
their specification through a local configuration parameter to
facilitate the use of DHCP through firewalls.

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

547 Agent port. Used by clients to send messages reach
neighboring nodes attached to
agents. Also used by relays to send messages to
servers.

3.3. DHCP message types

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

01 DHCP Solicit

The DHCP Solicit (or Solicit) message is used by clients
to locate servers. This message is multicast using the same
link. Every interface has a link-local
address.

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

Internet Draft DHCP for IPv6 22 November 2000

All-DHCP-Agents address. Relay(s) forward Solicits as
necessary 1 March 2001

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

neighbor A node attached to off-link servers.

Section 9.1 contains more details about the Solicit message.

02 DHCP Advertise same link.

node A device that implements IP.

packet An IP header plus payload.

prefix The initial bits of an address, or a set
of IP address that share the same initial
bits.

prefix length The number of bits in a prefix.

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

6.2. DHCP Advertise (or Advertise) message is used by servers
responding Terminology

Terminology specific to Solicits. This message is unicast DHCP can be found below.

abort status A status value returned to the
client's link-local address (if the server and
application that has invoked a DHCP
client are operation, indicating anything
other than success.

agent address The address of a neighboring DHCP Agent
on the same link) or unicast to link as the relay through which DHCP client.

binding A binding (or, client binding) is a
group of server data records containing
the
Solicit was sent for final delivery to server's information about the client.

Section 9.2 contains more details about the Advertise message.

03 DHCP Request

The DHCP Request (or Request) message is used by clients to
request
addresses in an IA and any other
configuration parameters from servers. This message is
multicast using the All-DHCP-Agents address. Relay(s) forward
Requests as necessary information assigned to off-link servers.

Section 9.3 contains more details about
the Request message.

04 DHCP Reply

The DHCP Reply (or Reply) message client. A binding is used indexed by servers responding
to Request and Release messages. In the case of responding to
a Request message, the Reply contains configuration parameters
destined for
tuple <prefix, DUID>, where the client. This message 'prefix'
is unicast a prefix assigned to the client
if link to
which the client has an address of sufficient scope that is
reachable by the server. Otherwise, it attached and 'DUID'
is unicast to the relay
through which the Request or Release message was sent for final
delivery to DUID from the client.

Section 9.4 contains more details about IA in the Reply message.

05 DHCP Release binding.

DISCUSSION:

The DHCP Release (or Release) message indexing of an IA by <prefix,
DUID> is still under discussion.

DHCP Dynamic Host Configuration Protocol
for IPv6. The terms DHCPv4 and DHCPv6
are used by clients to
return one or more IP addresses only in contexts where it is
necessary to servers. 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. avoid ambiguity.

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

Internet Draft DHCP for IPv6 22 November 2000

06 DHCP Reconfigure

07 DHCP Reconfigure-reply

Removed; see section 23.2.

08 DHCP Reconfigure-init

The DHCP Reconfigure-init (or Reconfigure-init) message is 1 March 2001

configuration parameter An element of the configuration
information set
by server(s) on the server and
delivered to inform client(s) that the server(s) has new or
updated configuration parameters, and that the client(s) are
to initiate a Request/Reply transaction with the server(s) in
order to receive the updated information.

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

3.4. Error Values

This section describes error values exchanged between DHCP
implementations.

3.4.1. Generic Error Values

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

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

3.4.2. Server-specific Error Values

The following symbolic names are carry
information to be used by server implementations to
convey error conditions a node to clients. The following table contains the
actual numeric values
configure its network subsystem and
enable communication on a link or
internetwork, for each name.

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

Internet Draft example.

DHCP for IPv6 22 November 2000

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

3.5. Configuration Variables

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

DHCP domain A set of client links managed by DHCP and
operated by a single administrative
entity.

DHCP server configuration
variables (or server) A server is a node that responds to
requests from clients, and the default may or initial values for these variables. The
client-specific variables MAY
may not be configured on the server and MAY be
delivered to the client through same link as the ``DHCP Retransmission Parameter
Option'' in a Reply message. This option is TBD.

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

4. Requirements

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

This document also makes use of internal conceptual variables
to describe protocol behavior and external variables
client(s).

DHCP relay (or relay) A node that acts as an
implementation must allow system administrators intermediary to change. The
specific variable names, how their values change,
deliver DHCP messages between clients
and how their
settings influence protocol behavior servers, and is on the same link as
a client.

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

DUID A DHCP unique identifier for a client.

DISCUSSION:

Rules for choosing a DUID are provided TBD.

Identity association (IA) A collection of addresses assigned to demonstrate
protocol behavior.
a client. Each IA has an associated
DUID. An implementation is not required to IA may have them in
the exact form described here, so long as its external behavior is
consistent 0 or more addresses
associated with that described in this document. it.

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

7. DHCP Constants

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

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

Internet Draft DHCP for IPv6 22 November 2000

5. Background

Related work in IPv6 that would best serve an implementor to study
is the IPv6 Specification [5], 1 March 2001

7.1. Multicast Addresses

DHCP makes use of the IPv6 Addressing Architecture [7],
IPv6 Stateless Address Autoconfiguration [14], IPv6 Neighbor
Discovery Processing [11], and Dynamic Updates to DNS [16]. These
specifications enable following multicast addresses:

All DHCP Agents address: FF02::1:2 This link-scoped multicast
address is used by clients to build upon the IPv6 work to provide
both robust stateful autoconfiguration and autoregistration of DNS
Host Names.

The IPv6 Specification provides communicate with the base architecture
on-link agent(s) when they do not know those agents'
link-local address(es). All agents (servers and design
relays) are members of
IPv6. A key point for this multicast group.

All DHCP implementors to understand Servers address: FF05::1:3 This site-scoped multicast
address is that IPv6
requires that every link in the Internet have an MTU of 1280 octets used by clients or greater (in IPv4 the requirement is 68 octets). This means that
a UDP packet of 536 octets will always pass through an internetwork
(less 40 octets for the IPv6 header), as long as there are no IP
options prior relays to the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs communicate
with server(s), either because they want to send a
packet greater than 1500 octets it can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [9]
messages to determine the size of all servers or because they do not know
the packet server(s) unicast address(es). Note that will traverse in order
for a network
path.

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

Path MTU Discovery for IPv6 is supported for both UDP and TCP and
can cause end-to-end fragmentation when
server(s). All servers within the PMTU changes site are members of
this multicast group.

DISCUSSION:

Is there a requirement for a
destination.

The IPv6 Addressing Architecture specification [7] defines the
address scope that can site-scoped "All DHCP Clients"
multicast address, to be used as the default in an IPv6 implementation, and sending
Reconfigure messages.

7.2. UDP ports

DHCP uses the
various following destination UDP [12] port numbers. While
source ports MAY be arbitrary, client implementations SHOULD permit
their specification through a local configuration architecture guidelines for network designers
of parameter to
facilitate the IPv6 address space. Two advantages use of IPv6 are that support DHCP through firewalls.

546 Client port. Used by servers as the destination port
for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin
communications messages sent to discover neighbors on the link. For instance, a
client can send a Solicit message clients and locate a server or relay.

IPv6 Stateless Address Autoconfiguration [14] (Addrconf) specifies
procedures relays. Used by which a node may autoconfigure addresses based on
router advertisements [11], and relay
agents as the use of a valid lifetime destination port for messages sent to
support renumbering of addresses on the Internet. In addition
clients.

547 Agent port. Used as the
protocol interaction destination port by which a node begins stateless or stateful
autoconfiguration clients
for messages sent to agents. Used as the destination
port by relays for messages sent to servers.

7.3. DHCP message types

DHCP defines the following message types. More detail on these
message types can be found in Section 9. Message types 0 and
TBD--255 are reserved and MUST be silently ignored. The message code
for each message type is specified. shown with the message name.

TBD DHCP Solicit The DHCP Solicit (or Solicit) message
is one vehicle used by clients to perform locate servers.

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

Internet Draft DHCP for IPv6 22 November 2000

stateful autoconfiguration. Compatibility with addrconf is a design
requirement of 1 March 2001

TBD DHCP (see Section 6).

IPv6 Neighbor Discovery [11] Advertise The DHCP Advertise (or Advertise)
message is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [12]. To understand
IPv6 and Addrconf it used by servers responding
to Solicits.

TBD DHCP Request The DHCP Request (or Request)
message is strongly recommended that implementors
understand IPv6 Neighbor Discovery.

Dynamic Updates used by clients to DNS [16] request
configuration parameters from servers.

TBD DHCP Confirm The DHCP Confirm (or Confirm) message
is a specification used by clients to confirm that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space
to not only support autoconfiguration, but also autoregistration
in IPv6. The security model assigned to be used with DHCPv6 should conform an IA and
the lifetimes for those addresses,
as closely well as possible the current configuration
parameters assigned by the server to
the authentication model outlined in
RFC2402 [8].

6. Design Goals

- client are still valid.

TBD DHCP Renew The DHCP Renew (or Renew) message
is a mechanism rather than a policy. Network administrators
set their administrative policies through used by clients to obtain the
addresses assigned to an IA and the
lifetimes for those addresses, as
well as the current configuration
parameters they place upon assigned by the DHCP servers in server to
the client. A client sends a Renew
message to the server that originally
assigned the IA when the lease on an
IA is about to expire.

TBD DHCP domain
they're managing. Rebind The DHCP Rebind (or Rebind) message
is simply used by clients to deliver parameters
according to that policy obtain the
addresses assigned to each of an IA and the DHCP clients within
lifetimes for those addresses, as
well as the
domain.

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

- DHCP does not require manual current configuration of network
parameters
on assigned by the server to
the client. A clients sends a Rebind
message to all available DHCP clients, except in cases where such configuration servers
when the lease on an IA is
needed for security reasons. A node configuring itself using about to
expire.

TBD DHCP should require no user intervention.

- Reply The DHCP does not require Reply (or Reply) message is
used by servers responding to Request,
Confirm, Renew, Rebind, Release and
Decline messages. In the case of
responding to a server on each link. To allow Request, Confirm,
Renew or Rebind message, the Reply
contains configuration parameters
destined for scale
and economy, the client.

TBD DHCP must work across Release The DHCP relays.

- Release (or Release) message
is used by clients to return one or
more IP addresses to servers.

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

- Decline The DHCP Decline (or Decline) message
is used by clients can operate on a link without IPv6 routers present.

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

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

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

Internet Draft DHCP for IPv6 22 November 2000

- DHCP will contain 1 March 2001

the appropriate time out and retransmission
mechanisms to efficiently operate client has determined that one or
more addresses in environments with high
latency and low bandwidth characteristics.

7. Non-Goals

This specification explicitly does not cover an IA are already in
use on the following:

- Specification of a DHCP server link to server protocol.

- How a which the client is
connected.

TBD DHCP server stores its Reconfigure-init The DHCP data.

- How Reconfigure-init (or
Reconfigure-init) message is set by
server(s) to manage a DHCP domain inform client(s) that
the server(s) has new or DHCP server.

- How updated
configuration parameters, and that
the client(s) are to initiate a DHCP relay is configured or what sort of information it may
log.

8. Overview
Request/Reply transaction with the
server(s) in order to receive the
updated information.

7.4. Error Values

This section provides a general overview of the interaction describes error values exchanged between the functional entities of DHCP. The overview is organized
as a series of questions and answers. Details of DHCP such
as message formats and retransmissions
implementations.

7.4.1. Generic Error Values

The following symbolic names are left to sections 9,
10, 11, 12, 14, 15, used between client and 16.

8.1. How does a node know server
implementations to use DHCP?

An unconfigured node convey error conditions. The following table
contains the actual numeric values for each name. Note that the
numeric values do not start at 1, nor are they consecutive. The
errors are organized in logical groups.

7.4.2. Server-specific Error Values

|RenwNoMatch___|22______|_Client_record_Renew_not_match_IA___|_
|RebdNoMatch___|23______|_Client_record_Rebind_not_match_IA__|_
|InvalidSource_|24______|_Invalid_Client_IP_address__________|_
|NoServer______|25______|_Relay_cannot_find_Server_Address___|_
|ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 9]

Internet Draft DHCP for IPv6 1 March 2001

7.5. Configuration Variables

This section presents a table of client and server configuration
variables and the default or initial values for these variables. The
client-specific variables MAY be configured on the server and MAY be
delivered to the client through the "DHCP Retransmission Parameter
Option" in a Reply message.

_________________________________________________________________________
|Parameter__________|Default|_Description______________________________|_
|MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_
|MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_
|ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_
|ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_
|SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_
|REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_
|QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_
|REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_
|RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_
|REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_
|REC_REP_MIN________|5______|_Minimum_pause_interval_(secs)____________|_
|REC_REP_MAX________|7200___|_Maximum_pause_interval_(secs)____________|_
|REC_THRESHOLD______|100____|_%_of_required_clients____________________|_
|SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_

8. Overview

This section provides a general overview of the interaction between
the functional entities of DHCP. The overview is organized as a
series of questions and answers. Details of DHCP such as message
formats and retransmissions can be found in later sections of this
document.

8.1. How does a node know to use DHCP?

An unconfigured node determines that it is to use DHCP for
configuration of an interface by detecting the presence (or absence)
of routers on the link. If router(s) are present, the node examines
router advertisements to determine if DHCP should be used to
configure the interface. If there are no routers present, then
the node MUST use DHCP to configure the interface. Detail on
this process can be found in neighbor discovery [11] [10] and stateless
autoconfiguration [14]. [13].

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

(Section removed, see 23.6

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

Use of DHCP in such environments requires one or more DHCP relays
be set up on the client's link, because a client may only have a

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

Internet Draft DHCP for IPv6 22 November 2000
link-local address. Relays receive the Solicit and Request messages
from the client and forward them to some set of servers within the

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 10]

Internet Draft DHCP for IPv6 1 March 2001

DHCP domain. The client message is forwarded verbatim as the payload
in a message from the relay to the server. A relay will include
one of its own addresses (of sufficient scope) from the interface
on the same link as the client, as well as the prefix length of
that address, in its message to the server. Servers receiving
the forwarded traffic use this information to aid in selecting
configuration parameters appropriate to the client's link. The
servers also use the relay's address as the destination to forward
client-destined messages for final delivery by the relay.

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

8.4.

8.3. How does a client request configuration parameters from servers?

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

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

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

Internet Draft DHCP for IPv6 22 November 2000

8.5. 8.7.

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

Servers and clients manage addresses in groups called ``identity
associations.'' "identity
associations." Each identity associations is identified using a
unique identifier. An identity association may contain one or
more IPv6 addresses. DHCP servers assign addresses to identity
associations. DHCP clients use the addresses in an identity

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 11]

Internet Draft DHCP for IPv6 1 March 2001

association to configure interfaces. There is always at least one
identity association per interface that a client wishes to configure.
Each address in an IA has its own preferred and valid lifetime. Over
time, the server may change the characteristics of the addresses in
an IA; for example, by changing the preferred or valid lifetime for
an address in the IA. The server may also add or delete addresses
from an IA; for example, deleting old addresses and adding new
addresses to renumber a client. A client can request the current
list of addresses assigned to an IA from a server through an exchange
of protocol messages.

8.6.

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

A client forms a Release message, including options identifying
the IA to be released. The client sends the Release to the server
which assigned the addresses to the client initially. If that
server cannot be reached after a certain number of attempts (see
section 3.5), 7.5), the client can abandon the Release attempt. In this
case, the address(es) in the IA will be reclaimed by the server(s)
when the lifetimes on the addresses expire.

8.7.

8.6. What if the client determines one or more of its assigned addresses
are already being used by another client?

If the client determines through a mechanism like Duplicate Address
Detection [14] [13] that the address it was assigned by the server is
already in use by another client, the client will form a Release
message, including the option carrying the in-use address. The
option's status field MUST be set to the value reflecting the ``in
use'' "in
use" status of the address.

8.8.

8.7. How are clients notified of server configuration changes?

There are two possibilities. Either the clients discover the new
information when they revisit the server(s) to request additional
configuration information / extend information/extend the lifetime on an address. or
through a server-initiated event known as a reconfigure event.

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

Internet Draft DHCP for IPv6 22 November 2000

The reconfiguration feature of DHCP offers network administrators
the opportunity to update configuration information on DHCP clients
whenever necessary. To signal the need for client reconfiguration,
the server will unicast a Reconfigure-init message to each
client individually. The server may use multicast to signal the
reconfiguration to multiple clients simultaneously. (Note that
there is no mechanism defined in the protocol to guarantee that
every client actually performs a reconfiguration in response to a
multicast reconfigure-init message.) A Reconfigure-init is a trigger
which will cause the client(s) to initiate a standard Request/Reply

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 12]

Internet Draft DHCP for IPv6 1 March 2001

exchange with the server in order to acquire the new or updated
addresses.

9. Message Formats and Identity Associations

All reserved fields in a message MUST be transmitted as zeroes and
ignored by the receiver of the message.

DISCUSSION:

Each DHCP message has an identical fixed format header; some messages
also allow a variable format area for options. Not all fields in
the header are used in every message. In this section, every field
is included in described for every message format
diagram and fields that are not used in a
message are marked as ``unused''. As an alternative, the "unused". All unused fields could
be labeled ``unused'' in a message MUST
be transmitted as zeroes and ignored by the format diagram.

9.1. receiver of the message.

The DHCP Solicit Message Format message header:

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

Internet Draft
. .
. options .
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.1. DHCP for IPv6 22 November 2000 Solicit Message Format

msg-type TBD

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by the
client used to identify this Solicit
message.

client-link-local-address The link-local address of the
interface for which the client is
using DHCP.

server-address (unused) MUST be 0

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 13]

Internet Draft DHCP for IPv6 1 March 2001

options See section 16.

9.2. DHCP Advertise Message Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|

msg-type = 2 | TBD

preference An unsigned integer indicating a server's willingness
to provide service to the client. An unsigned integer indicating a
server's willingness to provide
service to the client.

transaction-ID An unsigned integer used to identify
this Advertise message. Copied from
the client's Solicit message.

client-link-local-address The IP link-local address of the
client interface from which the client
issued the Solicit message.

server-address The IP address of the server. server that
generated this message. If the DHCP
domain

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

Internet Draft DHCP for IPv6 22 November 2000 crosses site boundaries, then
this address MUST be globally-scoped.

options Options are described elsewhere in this document See Sections 14.4 and 15.3 for information about how clients and
servers handle the preference field. section 16.

9.3. DHCP Request Message Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by the
client used to identify this Request
message.

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

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

options
Options are described elsewhere in this document. See section 16.

9.4. DHCP Confirm Message Format

msg-type TBD

preference (unused) MUST be 0

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

Internet Draft DHCP for IPv6 22 November 2000

9.4. 1 March 2001

transaction-ID An unsigned integer generated by the
client used to identify this Confirm
message.

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

server-address MUST be zero.

options See section 16.

9.5. DHCP Reply Renew Message Format

msg-type TBD

preference (unused) MUST be 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|

transaction-ID An unsigned integer generated by the
client used to identify this Request
message.

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

server-address The IP address of the server to which
this Renew message is directed, which
MUST be the address of the server from
which the IAs in this message were
originally assigned.

options See section 16.

9.6. DHCP Rebind Message Format

msg-type = 4 | TBD

preference | (unused) MUST be 0

transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| An unsigned integer generated by the
client used to identify this Request
message.

client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| The link-local address of the client
interface from which the client will
issue the Request message.

options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See section 16.

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 15]

Internet Draft DHCP for IPv6 1 March 2001

9.7. DHCP Reply Message Format

msg-type TBD

preference An unsigned integer indicating a
server's willingness to provide
service to the client.

transaction-ID An unsigned integer used to identify
this Reply message. Copied from the
client's Request message.

client-link-local-address The link-local address of the
interface for which the client is
using DHCP.

server-address The IP address of the server.
If the DHCP domain crosses site
boundaries, then this address MUST be
globally-scoped.

options
Options are described elsewhere in this document.

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

Internet Draft DHCP for IPv6 22 November 2000

9.5. See section 16.

9.8. DHCP Release Message Format

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

preference (unused) MUST be

msg-type TBD

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by the
client used to identify this Release
message.

P (unused) MUST be 0

client-link-local-address The client's link-local address for
the interface from which the client
issued the Release message.

server-address The IP address of the server that
assigned the addresses.

options See section 22.

9.6. DHCP Reconfigure Message Format

The Reconfigure message has been deleted (see section 23.2).

9.7. 16.

9.9. DHCP Reconfigure-reply Decline Message Format

The Reconfigure-reply message has been deleted (see section 23.2).

msg-type TBD

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by the
client used to identify this Release
message.

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

Internet Draft DHCP for IPv6 22 November 2000

9.8. 1 March 2001

client-link-local-address The client's link-local address for
the interface from which the client
issued the Release message.

server-address The IP address of the server that
assigned the addresses.

options See section 16.

9.10. DHCP Reconfigure-init Message Format

preference (unused) MUST be 0

transaction-ID An unsigned integer generated
by the server to identify this
Reconfigure-init message

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

server-address The IP address of the DHCP server
issuing the Reconfigure-init message.
MUST be of sufficient scope to be
reachable by all clients.

options See section 16.

10. Relay messages

Relay agents exchange messages with servers to forward messages
between clients and servers that are not connected to the same link.

10.1. Relay-forward message

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

preference (unused) MUST be 0

transaction-ID
An unsigned integer generated by the server to identify
this Reconfigure-init message

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

server-address
The IP address of the DHCP server issuing the
Reconfigure-init message. MUST be of sufficient scope
to be reachable by all clients.

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

msg-type TBD

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

Internet Draft DHCP for IPv6 22 November 2000

9.9. Relay-forward message

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

msg-type TBD March 2001

prefix-length The length of the prefix in the address in the
``relay-address''
"relay-address" field.

relay-address An address assigned to the interface through which
the message from the client was received.

options MUST include a ``Client "Client message option''; option"; see
section 22.4.

9.10. Server-forward 16.4.

10.2. Relay-reply message

msg-type TBD

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

Internet Draft DHCP for IPv6 22 November 2000

prefix-length The length of the prefix in the address in the
``relay-address''
"relay-address" field.

relay-address An address identifying the interface through which
the message from the server should be forwarded;
copied from the ``client-forward'' "client-forward" message.

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

9.11. 16.5.

11. Identity association

An ``identity-association'' "identity-association" (IA) is a construct through which a server
and a client can identify, group and manage IPv6 addresses. Each IA
consists of a UUID DUID and a list of associated IPv6 addresses (the list
may be empty). A client associates an IA with one of its interfaces
and uses the IA to obtain IPv6 addresses for that interface from a
server.

10.

See section 16.2 for the representation of an IA in a DHCP message.

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

Internet Draft DHCP for IPv6 1 March 2001

12. DHCP Server Solicitation

This section describes how a client locates servers. The behavior of
client, server, and relay implementations is discussed, along with
the messages they use.

(Prefix advertisements have been deleted; see 23.9.)

10.1.

12.1. Solicit Message Validation

Clients MUST silently discard any received Solicit messages.

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

10.2.

12.2. Advertise Message Validation

Servers MUST discard any received Advertise messages.

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

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

Internet Draft DHCP for IPv6 22 November 2000

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

o The ``client-link-local-address'' "client-link-local-address" field value does not match the
link-local address of the interface upon which the client sent
the Solicit message.

10.3.

12.3. Client Behavior

Clients use the Solicit message to discover DHCP servers configured
to serve addresses on the link to which the client is attached.

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

10.3.1.

12.3.1. Creation and sending of the Solicit message

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

The client sets all other
fields to zero. generates a transaction ID inserts this value in the
"transaction-ID" field.

The client sends MAY include an Option Request Option in the Solicit message to the FF02::1:2 (All
message. The client MUST NOT include any other options except those
specifically allowed as defined by specific options.

The client sends the Solicit message to the All DHCP
Agents) Agents
multicast address, destination port 547. The source port selection

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 19]

Internet Draft DHCP for IPv6 1 March 2001

can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.

10.3.2.

12.3.2. Time out and retransmission of Solicit Messages

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 stops trying to DHCP configure the
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.

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

Internet Draft DHCP for IPv6 22 November 2000

10.3.3. 7.5.

12.3.3. Receipt of Advertise messages

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

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

- Within a group of Advertise messages with the same server
preference value, a client MAY select those servers whose
Advertise messages advertise information of interest to
the client. For example, one server may be advertising the
availability of IP addresses which have an address scope of
interest to the client.

Once a client has selected Advertise message(s), the client will
typically store information about each server, such as server
preference value, addresses advertised, when the advertisement was
received, and so on. Depending on the requirements of the client's
invoking user, the client MAY initiate a configuration exchange with
the server(s) immediately, or MAY defer this exchange until later.

10.4. Relay Behavior

For this discussion, the Relay may be configured to use a list of
server destination addresses, which may include unicast addresses,
the FF05::1:3 (All DHCP Servers) multicast address, or other
multicast addresses selected by the network administrator.

If the Relay has not been explicitly configured, it will use the
FF05::1:3 (All DHCP Servers) multicast address as the default.

10.4.1. Relaying of Solicit messages

When a Relay receives a valid Solicit message, it constructs a
Relay-forward message. The client Solicit message is carried as the
payload of a ``client-message'' option. The relay places needs to select an address
from the interface on which the Solicit message was received alternate server in the
``relay-address'' field and the prefix length for case that address in
the ``prefix-length'' field. The Relay then sends a
chosen server does not respond, the Relay-forward
message to client choose the list of server destination addresses that it has been
configured with. with the
next highest preference value.

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

Internet Draft DHCP for IPv6 22 November 2000

10.4.2. Relaying of Advertise messages

When the relay receives 1 March 2001

The client MAY choose a Relay-reply message, it extracts the less-preferred server
message from the ``server-message'' option and forwards the if that server
message to the address in the client-link-local-address field in
the server message. The relay forwards the server message through
the interface identified in the ``relay-address'' field in the
Relay-reply message.

10.5. Server Behavior

For this discussion, has a
better set of advertised parameters.

12.4. Server Behavior

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

10.5.1.

12.4.1. Receipt of Solicit messages

If the server receives a Solicit message, the client must be on the
same link as the server. If the server receives a Relay-forward
message containing a Solicit message, the client must be on the
link to which the prefix identified by the ``relay-address'' "relay-address" and
``prefix-length''
"prefix-length" fields in the Relay-forward message is assigned.
The server records the ``relay-address'' "relay-address" field from the Relay-forward
message and extracts the solicit message from the ``client-message'' "client-message"
option.

If administrative policy permits the server to respond to a client on
that link, the server will generate and send an Advertise message to
the client.

10.5.2.

12.4.2. Creation and sending of Advertise messages

The server sets the ``msg-type'' "msg-type" field to 2 TBD and copies the values
of the following fields from the client's Solicit to the Advertise
message:

o transaction-ID

o client-link-local-address

The server places one of its IP addresses (determined through
administrator setting) in the ``server-address'' "server-address" field of the Advertise
message. The server sets the ``preference'' "preference" field according to its
configuration information. See section 15.3 18.3 for a description of
server preference.

The server MUST include options to the Advertise message containing
any addresses that would be assigned to IAs contained in the Solicit
message from the client. The server MAY include other options the
server will return to the client in a subsequent Reply message.
The information in these options will be used by the client in the
selection of a server if the client receives more than one Advertise
message.

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

Internet Draft DHCP for IPv6 22 November 2000 1 March 2001

If the Solicit message was received in a Relay-forward message, the
server constructs a Relay-reply message with the Advertise message in
the payload of a ``server-message'' "server-message" option. The server unicasts the
Relay-reply message to the address in the ``relay-address'' "relay-address" field from
the Relay-forward message.

If the Solicit message was received directly by the server, the
server unicasts the Advertise message directly to the client using
the ``client-link-local-address'' "client-link-local-address" field value as the destination
address. The Advertise message MUST be unicast through the interface
on which the Solicit message was received.

DISCUSSION:

(From Ted Lemon) There is a danger in using Solicit versus
DHCPDISCOVER: in the Solicit paradigm, the client has to
choose the DHCP server before it knows if the DHCP server
will give it an IP address, or which addresses the server is
willing to assign to the client. It may be that there are
two or more DHCP servers owned by the same administrative
domain, and both are theoretically willing to give the
client addresses, but only one actually has any addresses to
give.

11.

13. DHCP Client-Initiated Configuration Exchange

A client uses the Request-Reply initiates a message exchange with the server to acquire
or update configuration information of interest. The client may
initiate the configuration exchange as part of the operating system
configuration process or when requested to do so by the application
layer.

The client uses the Release-Reply message exchange to indicate following messages to initiate a configuration
event with the
DHCP server that server:

Request Obtain initial configuration information when the client will
has no longer be using assigned addresses

Confirm Confirm the validity of assigned addresses in and other
configuration changes when the released IA.

11.1. Request Message Validation

Clients MUST silently discard any received Request messages.

Agents MUST discard any Request messages in which the
``client-link-local-address'' field does client's assigned
addresses may not contain be valid; for example, when the client
reboots or loses its connection to a valid
link-local address.

Servers link

Renew Extend the lease on an IA through the server that
originally assigned the IA

Rebind Extend the lease on an IA through any server willing to
extend the lease

A client uses the Release-Reply message exchange to indicate to the
DHCP server that the client will no longer be using the addresses in
the released IA.

A client uses the Decline-Reply message exchange to indicate to the
DHCP server that the client has detected that one or more addresses
assigned by the server is already in use on the client's link.

13.1. Client Message Validation

Clients MUST silently discard any received Request message which meets any of
the following criteria: client messages (Request,
Confirm, Renew, Rebind, Release or Decline messages).

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

Internet Draft DHCP for IPv6 22 November 2000

o The ``server-address'' 1 March 2001

Agents MUST discard any received client messages in which the
"client-link-local-address" field value does not match contain a valid link-local
address.

Servers MUST discard any of received client messages in which the
server's addresses.

o The ``options''
"options" field contains an authentication option, and the server
cannot successfully authenticate the client.

11.2. Reply

Servers MUST discard any received Request or Renew message in which
the "server-address" field value does not match any of the server's
addresses.

13.2. Server Message Validation

Servers MUST silently discard any received Reply messages. server messages (Reply
messages).

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

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

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

o The Reply server message contains an authentication option, and the
client's attempt to authenticate the message fails.

Relays MUST discard any Relay-reply message in which the
``client-link-local-address''
"client-link-local-address" in the encapsulated Reply message does
not contain a valid link-local address.

11.3. Release Message Validation

Clients MUST silently discard any received Release messages.

Agents MUST discard any Release message in which

13.3. Client Behavior

A client will use Request, Confirm, Renew and Rebind messages to
acquire and confirm the
``client-link-local-address'' field does not contain a valid
link-local address.

Servers MUST discard any received Release message in which the
``options'' field contains an authentication option, and the server
cannot successfully authenticate the client.

11.4. Client Behavior

A client will generate one or more Request messages to acquire validity of configuration information.
A client may initiate such an exchange automatically in order
to acquire the necessary network parameters to communicate with
nodes off-link. The client uses the server address information
from previous Advertise message(s) for use in

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

Internet Draft DHCP for IPv6 22 November 2000 constructing Request
message(s). Note that a client may request configuration information
from one or more servers at any time.

A client uses the Release message in the management of IAs when:

o The when
the client has been instructed to release the IA prior to the IA
expiration time since it is no longer needed.

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 23]

Internet Draft DHCP for IPv6 1 March 2001

A client uses the Decline message when the client has determined
through DAD or some other method that one or more of the addresses
assigned by the server in the IA is already in use by a different
client.

o The client has been instructed to release the IA prior to the IA
expiration time since it is no longer needed.

11.4.1.

13.3.1. Creation and sending of Request messages

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

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

The client generates a transaction ID inserts this value in the
``transaction-ID''
"transaction-ID" field.

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

The client adds any appropriate options, including one or more IA
options (if the client is requesting that the server assign it some
network addresses). If the client does include any IA options,
it MUST include the list of addresses the client currently has
associated with that IA. If the client is requesting configuration of
a new IA, the The list of addresses in each included IA MUST
be empty.

11.4.2. Time out and retransmission of Request Messages

The server will respond to the Request message with a Reply
message. If no Reply message is received within REP_MSG_TIMEOUT
milliseconds, the client retransmits sends the Request with message to the same
transaction-ID, and All DHCP Agents
multicast address, destination port 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.

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

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

13.3.2. Creation and sending of Confirm messages

Whenever a client may have moved to a new link, its IPv6 addresses
may no longer be valid. Examples of times when a client may have
moved to a new link include:

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

Internet Draft DHCP for IPv6 22 November 2000

11.4.3. Receipt of Reply message in response 1 March 2001

o The client reboots

o The client is physically disconnected from a wired connection

o The client returns from sleep mode

o The client using a wireless technology changes cells

In any situation when a client may have moved to a Request

Upon new link, the receipt of
client MUST initiate a valid Reply message, the Confirm/Reply message exchange. The client extracts
includes any IAs, along with the
configuration information contained addresses associated with those IAs,
in its Request message. The server returns the Reply. If the ``status''
field contains a non-zero value, the IAs with updated list
of addresses and associated lifetimes.

The client reports sets the error status "msg-type" field to TBD, and places the application layer.

The client records
link-local address of the T1 and T2 times interface it wishes to acquire
configuration information for each IA in the Reply
message. "client-link-local-address"
field.

The client records any addresses included with IAs generates a transaction ID inserts this value in the Reply message.
"transaction-ID" field.

The client updates sets the preferred and valid
lifetimes for "server-address" field to 0.

The client adds any appropriate options, including one or more IA
options (if the addresses in client is requesting that the IA from server confirm the lifetime information
in
validity of some network addresses). If the IA option. The client leaves does include
any IA options, it MUST include the list of addresses that the client
currently has associated with the IA that are not included in the IA option
unchanged.

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

11.4.4. Creation and sending of Release messages IA.

The client sets sends the ``msg-type'' field Confirm message to 5, and places the
link-local address of the interface associated with the configuration
information All DHCP Agents
multicast address, destination port 547. The source port selection
can be arbitrary, although it wishes SHOULD be possible using a client
configuration facility to set a specific source port value.

Servers will respond to release in the ``client-link-local-address''
field.

The client generates Confirm message with a transaction ID and places this value in Reply message. If
no Confirm message is received within REP_MSG_TIMEOUT milliseconds,
the
``transaction-ID'' field.

The client includes options containing retransmits the IAs it is releasing in Confirm with the
``options'' field. same transaction-ID,
and doubles the REP_MSG_TIMEOUT value, and waits again. The appropriate ``status'' field in client
continues this process until a Reply is received or QRY_MSG_ATTEMPTS
unsuccessful attempts have been made, at which time the options client MUST be set to indicate the reason for
abort the release. configuration attempt. The client places the IP address of SHOULD report the server that allocated abort
status to the
address(es) application layer.

Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS
are documented in the ``server-address'' field. section 7.5.

If the client is configured receives no response to use authentication, the client
generates its Confirm message, it MAY
restart the appropriate authentication option, configuration process by locating a different DHCP server
with an Advertise message and adds this option sending a Request to the ``options'' field. Note that the authentication option MUST
be the last option server, as
described in the ``options'' field. See section 22.7 for
more details about the authentication option.

(The client always forwards Release messages to the server through a
relay; see section 11.5.) 13.3.1.

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

Internet Draft DHCP for IPv6 22 November 2000

11.4.5. Time out 1 March 2001

13.3.3. Creation and retransmission sending of Release Messages

If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the Renew messages

IPv6 addresses assigned to a client retransmits the Release, doubles through an IA use the REP_MSG_TIMEOUT
value, same
preferred and waits again. valid lifetimes as IPv6 addresses obtained through
stateless autoconfiguration. The client continues this process until a
Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been
made, at which time server assigns preferred and valid
lifetimes to the client SHOULD abort IPv6 addresses it assigns to an IA. To extend those
lifetimes, the release attempt.
The client SHOULD return the abort status sends a Request to the application, if server containing an
application initiated
"IA option" for the release.

Default IA and initial values its associated addresses. The server
determines new lifetimes for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented the addresses in section 3.5.

Note that if the client fails IA according to release the IA,
the server's administrative configuration. The server may also add
new addresses
assigned to the IA. The server remove addresses from the IA will be reclaimed by
setting the server when the lease
associated with it expires.

11.4.6. Receipt preferred and valid lifetimes of Reply message in response those addresses to a Release

Upon receipt of a valid Reply message, zero.

The server controls the time at which the client can consider contacts the
Release event successful, and SHOULD return server
to extend the successful status lifetimes on assigned addresses through the T1 and
T2 parameters assigned to an IA. If the application layer, if server does not assign an application initiated
explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the release.

11.4.7. When a client should send a Request message

The description
shortest preferred lifetime of any address assigned to the Request/Reply message exchange in this section
makes no assumptions about IA and
T2 defaults to 0.875 times the timing or state shortest preferred lifetime of any
address assigned to the IA.

At time T1 for an IA, the client when
it initiates a Request/Reply message exchange. Sections 11.4.8
through 11.4.10 describe when a client MAY initiate a Request/Reply
message exchange. The procedures for timeout and retransmission of
Request messages are described
exchange to extend the lifetimes on any addresses in section 11.4.2.

11.4.8. Initialization

If a the IA. The
client has no valid IPv6 includes an IA option with all addresses of sufficient scope currently assigned
to
communicate with a DHCP server, it may a the IA in its Request message to obtain
new addresses. message. The client includes one or more IAs in the unicasts this Request
message,
message to which the server assigns new addresses. that originally assigned the addresses to the
IA.

The server then
returns client sets the "msg-type" field to IA(s) TBD, and places the
link-local address of the interface it wishes to acquire
configuration information for in the "client-link-local-address"
field.

The client in generates a Reply message.

11.4.9. Confirming transaction ID inserts this value in the
"transaction-ID" field.

The client places the address of the destination server in the
"server-address" field.

The client adds any appropriate options, including one or more IA
options (if the client is requesting that the server extend the lease
on some IAs; note that the validity of IPv6 addresses

Whenever a client may have moved to a new link, its IPv6 addresses
may no longer be valid. Examples check the status of times when other
configuration parameters without asking for lease extensions). If
the client does include any IA options, it MUST include the list of
addresses the client currently has associated with that IA.

The client sends the Renew message to the All DHCP Agents multicast
address, destination port 547. The source port selection can
be arbitrary, although it SHOULD be possible using a client may have
moved
configuration facility to set a new link include: specific source port value.

The server will respond to the Renew message with a Reply message.
If no Reply message is received within REP_MSG_TIMEOUT milliseconds,

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

Internet Draft DHCP for IPv6 22 November 2000

o The client reboots

o The client is physically disconnected from a wired connection

o The client returns from sleep mode

o The client using a wireless technology changes cells

In any situation when a client may have moved to a new link, 1 March 2001

the client MUST initiate a Request/Reply message exchange. The client
includes any IAs, along with retransmits the addresses associated Renew with those IAs,
in its Request message. The server returns the IAs with updated list
of addresses same transaction-ID, and associated lifetimes.

11.4.10. Extending the lifetimes on IPv6 addresses

IPv6 addresses assigned to a client through an IA use
doubles the same
preferred REP_MSG_TIMEOUT value, and valid lifetimes as IPv6 addresses obtained through
stateless autoconfiguration. waits again. The server assigns preferred and valid
lifetimes to the IPv6 addresses it assigns to an IA. To extend those
lifetimes, the client sends
continues this process until a Request to the server containing an
``IA option'' for the IA and its associated addresses. The server
determines new lifetimes for the addresses in the IA according to
the server's administrative configuration. The server may also add
new addresses to the IA. The server remove addresses from the IA by
setting the preferred and valid lifetimes of those addresses to zero.

The server controls the time at which the client contacts the server
to extend the lifetimes on assigned addresses through the T1 and
T2 parameters assigned to an IA. If the server does not assign an
explicit value to T1 Reply is received or until time T2 for an IA, T1 defaults to 0.5 times the
shortest preferred lifetime of any address assigned to the IA is
reached (see section 13.3.4).

Default and
T2 defaults to 0.875 times the shortest preferred lifetime of any
address assigned to the IA.

At time T1 initial values for an IA, the client initiates a Request/Reply message
exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned
to the IA REP_MSG_TIMEOUT are documented in its Request message. The client unicasts this Request
message to the server that originally assigned the addresses to the
IA.
section 7.5.

13.3.4. Creation and sending of Rebind messages

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

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

Internet Draft DHCP for IPv6 22 November 2000

11.5. Relay Behavior

11.5.1. Relaying of Request or Release messages

When a Relay receives a valid Request or Release message, it
constructs a Relay-forward message.

The client message is carried
as sets the payload of a ``client-message'' option. The relay "msg-type" field to TBD, and places an the
link-local address from of the interface on which it wishes to acquire
configuration information for in the "client-link-local-address"
field.

The client message was received generates a transaction ID inserts this value in the ``relay-address''
"transaction-ID" field.

The client sets the "server-address" field and to 0.

The client adds any appropriate options, including one or more IA
options. If the prefix length for client does include any IA options (if the client is
requesting that
address in the ``prefix-length'' field. The Relay then forwards server extend the
Relay-forward message to lease on some IAs; note that
the client may check the status of other configuration parameters
without asking for lease extensions), it MUST include the list of server destination
addresses
that it has been configured with.

11.6. Server Behavior

For this discussion, the Server is assumed to have been configured in
an implementation specific manner client currently has associated with configuration of interest to
clients.

11.6.1. Receipt of Request messages

Upon that IA.

The client sends the receipt of a valid Request Rebind message from to the All DHCP Agents multicast
address, destination port 547. The source port selection can
be arbitrary, although it SHOULD be possible using a client the
configuration facility to set a specific source port value.

The server
can will respond to, (implementation-specific administrative policy
satisfied) the server scans to the options field.

The server then constructs Rebind message with a Reply message.
If no Reply message and sends it to is received within REP_MSG_TIMEOUT milliseconds,
the
client.

DISCUSSION:

This section needs text about managing IAs and determining
options to be returned to client.

11.6.2. Receipt of Release messages

Upon the receipt of a valid Release message, client retransmits the server examines Rebind with the
IAs same transaction-ID, and
doubles the addresses in the IAs REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received.

Default and initial values for validity. If the IAs in the
message REP_MSG_TIMEOUT are documented in a binding for the
section 7.5.

DISCUSSION:

The client and the addresses in the IAs
have been assigned by the server has several alternatives to those IA, the server deletes
the addresses choose from the IAs and makes the addresses available for
assignment if it
receives no response to other clients.

The server then generates a Reply its Rebind message. If all of the IAs were
valid and the addresses successfully released,, the server sets the
``status'' field to ``Success''. If any of the IAs were invalid or
if any of the addresses were not successfully released, the server

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

Internet Draft DHCP for IPv6 22 November 2000

releases none of the addresses in the message and sets 1 March 2001

- When the ``status''
field to ``NoBinding''(section 3.4).

DISCUSSION:

What is lease on the behavior of IA expires, the server relative client may choose
to use a ``partially
released'' IA; i.e., an IA for which some but not all
addresses are released?

Can Solicit message to locate a client new DHCP server and
send an empty a Request for the expired IA to release all the new server

- Some addresses in the IA?

If the IA becomes empty - all addresses are released - can may have lifetimes that extend
beyond the server discard any record lease of the IA?

11.6.3. Creation and sending of Reply messages

DISCUSSION:

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

The server sets IA, so the ``msg-type'' field client may choose
to 4 and copies the values continue to use those addresses; once all of the following fields from
addresses have expired, the client's Request or Release client may choose to the
Reply message:

o transaction-ID

o client's link-local address

o server-address

The locate
a new DHCP server sets the ``status'' field appropriately (see the table

- The client may have other addresses in section 3.4) based upon the results of processing the client's
request.

If the Request or Release message from other IAs, so the
client was originally
received by the server, the server unicasts the Reply message may choose to discard the
link-local address in expired IA and use the ``client-link-local-address'' field.

If
addresses in the other IAs

13.3.5. Receipt of Reply message was originally received in response to a Forward-request Reply, Confirm, Renew
or
Forward-release Rebind message from

Upon the receipt of a relay, valid Reply, Confirm, Renew or Rebind message,
the server places client extracts the Reply
message configuration information contained in the options
Reply. If the "status" field of contains a Response-reply message and unicasts non-zero value, the message client
reports the error status to the relay's address from application layer.

The client records the original T1 and T2 times for each IA in the Reply
message.

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

Internet Draft DHCP The client records any addresses included with IAs in
the Reply message. The client updates the preferred and valid
lifetimes for IPv6 22 November 2000

12. DHCP Server-Initiated Configuration Exchange

A server initiates a configuration exchange on behalf of the
administrator of addresses in the DHCP domain. An administrator may initiate such
an exchange when new links are added to IA from the domain or existing links
are to be renumbered. Other examples include changes lifetime information
in the location
of directory servers, addition of new services such as printing, and
availability of new software (system or application).

DISCUSSION:

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

12.1. Reconfigure Message Validation

Reconfigure messages have been deleted; see section 23.2.

12.2. Reconfigure-reply Message Validation

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

12.3. Reconfigure-init Message Validation

Agents MUST silently discard any received Reconfigure-init messages.

Clients MUST discard IA option. The client leaves any Reconfigure-init messages addresses that do the client
has associated with the IA that are not contain an authentication included in the IA option or that fail
unchanged.

Management of the client's
authentication check.

12.4. Server Behavior

For this discussion, specific configuration information is detailed in
the definition of each option, in section 16.

When the client receives an Unavail error status in an IA from the
server is assumed to for a Request message the client will have to find a
implementation-specific interface by which new
server to create an administrator
may initiate IA Association.

When the client receives a reconfiguration event with some set of clients.

A NoBinding error status in an IA from the
server sends for a Reconfigure-init Confirm message to trigger a the client can assume it needs to
initiate immediately send a Request/Reply message exchange
Request to reestablish an IA Association with the server. A

When the client receives a Conf_NoMatch error status in an IA from
the server for a Confirm message the client can send Reconfigure-init messages only a Renew message
to those
clients who have an address of sufficient scope the server to be reachable by extend the server. Thus, those clients who have not requested an IP address
and are off-link cannot be reconfigured by lease for the addresses.

When the client receives a NoBinding error status in an IA from the
server for a Renew message the client can assume it needs to send a
Request to reestablish an IA Association with the server.

When the client receives a Renw_NoMatch error status in an IA from
the server for a Renew message the client can assume it needs to send
a Request to reestablish an IA Association with the server.

DISCUSSION:

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

Internet Draft DHCP for IPv6 22 November 2000

It would be possible to forward Reconfigure-init messages
through relays if the server records the client's link-local
address and 1 March 2001

When the relay's address client receives an Unavail error status in an IA from the client's Request
message.

12.4.1. Creation and sending of Reconfigure messages

Reconfigure messages have been deleted; see section 23.2.

12.4.2. Time out and retransmission of Reconfigure messages

12.4.3. Receipt of Reconfigure-reply messages

12.4.4. Creation and sending of Reconfigure-init messages

The
server sets for a Renew message the ``msg-type'' field client can assume it needs to 8. The server generates send a transaction-ID and inserts it in
Request to reestablish an IA Association set of addresses with the ``transaction-ID'' field.
The server places its address (of appropriate scope)
server.

When the client receives a NoBinding error status in an IA from the
``server-address'' field.

The
server MAY include an ORO option to inform for a Rebind message the client of what
information has been changed or new information that has been added.

The server MUST include can assume it needs to send
a Request to reestablish an authentication option IA Association with the appropriate
settings and add that option as server or try
another server.

When the last option client receives a Rebd_NoMatch error status in the ``options''
field of the Reconfigure-init message.

Typically, an IA from
the server will not provide more than an ORO and / or
Authentication option, since it will provide the new configuration
information as part of for a Rebind message the Request/Reply transaction triggered by client can assume it needs to
send a Request to reestablish an IA Association with the
Reconfigure-init message.

The server may either unicast or
try another server.

When the Reconfigure-init message to one client or multicast receives an Unavail error status in an IA from the
server for a Rebind message the client can assume it needs to one or more Reconfigure Multicast
Addresses previously sent as options send a
Request to reestablish an IA Association set of addresses with the clients. The
server
may unicast Reconfigure-init or try another server.

13.3.6. Creation and sending of Release messages to more than one

The client
concurrently; for example, to reliably reconfigure all clients, sets the
server will unicast a Reconfigure-init message "msg-type" field to each client.

If TBD, and places the server unicasts to one or more clients, it waits for a Request
message from those clients confirming that
link-local address of the interface associated with the configuration
information it has received wishes to release in the
Reconfigure-init and are thus initiating "client-link-local-address"
field.

The client generates a Request/Reply transaction
with ID and places this value in the server.
"transaction-ID" field.

The client places the IP address of the server can determine that a Request message allocated the
address(es) in the "server-address" field.

The client includes options containing the IAs it is releasing in response to a Reconfigure-init because the transaction-ID
"options" field. The appropriate "status" field in the
Request will options MUST
be set to indicate the same value as was used in the Reconfigure-init
message.

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

Internet Draft DHCP reason for IPv6 22 November 2000

If the server multicasts release.

If the Reconfigure-init message, it must client is configured to use
some TBD authentication, the client
generates the appropriate authentication mechanism option, and adds this option
to the "options" field. Note that can authenticate the server to
multiple clients. There is no reliability mechanism for multicast
Reconfigure-init messages. A server might use multicast authentication option MUST be
the last option in the
case where it does not have a list of its clients; "options" field. See section 16.7 for example, a
server that distributes configuration information to clients using
stateless autoconfiguration might not keep a list of clients it has
communicated with.

12.4.5. more
details about the authentication option.

13.3.7. Time out and retransmission of Reconfigure-init messages

It the server does not receive a Request Release Messages

If no Reply message from the client
in RECREP_MSG_TIMEOUT is received within REP_MSG_TIMEOUT milliseconds,
the server client retransmits the Reconfigure-init message, Release, doubles the RECREP_MSG_TIMEOUT
value REP_MSG_TIMEOUT
value, and waits again. The server client continues this process until
REC_MSG_ATTEMPTS a
Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been
made, at which point time the server client SHOULD abort the reconfigure process. release attempt.

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 29]

Internet Draft DHCP for IPv6 1 March 2001

The client SHOULD return the abort status to the application, if an
application initiated the release.

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

12.4.6. Receipt 7.5.

Note that if the client fails to release the IA, the addresses
assigned to the IA will be reclaimed by the server when the lease
associated with it expires.

13.3.8. Creation and sending of Request Decline messages

The server generates client sets the "msg-type" field to TBD, and sends Reply message(s) places the
link-local address of the interface associated with the configuration
information it wishes to decline in the "client-link-local-address"
field.

The client as
described generates a transaction ID and places this value in section 11.6.3, including the
"transaction-ID" field.

The client places the IP address of the server that allocated the
address(es) in the "server-address" field.

The client includes options containing the IAs it is declining in the ``option''
"options" field. The appropriate "status" field new
values in the options MUST
be set to indicate the reason for configuration parameters.

12.5. Client Behavior

A declining the address.

If the client is configured to use authentication, the client
generates the appropriate authentication option, and adds this option
to the "options" field. Note that the authentication option MUST always monitor UDP port 546 be
the last option in the "options" field. See section 16.7 for Reconfigure-init
messages on interfaces upon which it has acquired DHCP parameters.
Since more
details about the results authentication option.

13.3.9. Time out and retransmission of Decline Messages

If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Decline, doubles the REP_MSG_TIMEOUT
value, and waits again. The client continues this process until a reconfiguration event may affect application
layer programs,
Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have
been made, at which time the client SHOULD log these events, and MAY notify
these programs of abort the change through an implementation-specific
interface.

12.5.1. Receipt of Reconfigure-init messages

Upon receipt of a valid Reconfigure-init message, attempt to
decline the address. The client
initiates a Request/Reply transaction with SHOULD return the server. abort status to
the application, if an application initiated the release.

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

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

Internet Draft DHCP for IPv6 22 November 2000

12.5.2. Creation and sending 1 March 2001

13.3.10. Receipt of Request messages

When responding Reply message in response to a Reconfigure-init, the client creates Release message

Upon receipt of a valid Reply message, the client can consider the
Release event successful, and
sends SHOULD return the Request message in exactly successful status to
the same manner as outlined application layer, if an application initiated the release.

13.4. Server Behavior

For this discussion, the Server is assumed to have been configured in
section 11.4.1
an implementation specific manner with configuration of interest to
clients.

13.4.1. Receipt of Request messages

Upon the following differences:

transaction-ID
The receipt of a valid Request message from a client copies the transaction-ID from server
can respond to, (implementation-specific administrative policy
satisfied) the
Reconfigure-init server scans the options field.

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

IAs
client.

The server SHOULD process each option for the client includes IA options in an
implementation-specific manner. The server MUST construct a Reply
message containing the addresses following values:

msg-type TBD

preference Enter the client currently has assigned servers preference to
provide services to those IAs for the
interface through which client.

transaction-ID Enter the transaction-ID from the Reconfigure-init message was
received.

Pause before sending
Request
The client pauses before sending message.

client-link-local address Enter the client-link-local address
from the Request for
a random value within message.

server address Enter the range REC_REP_MIN and
REC_REP_MAX seconds. This delay helps reduce IP address of the
load on server.

When the server generated by processing large
numbers of triggered Request messages from receives a multicast
Reconfigure-init message.

12.5.3. Time out Request and retransmission IA option is included the
client is requesting the configuration of Request messages a new IA by the server.
The client uses server MUST take the same variables clients IA and retransmission algorithm as it
does with Request messages generated as part of associate a client-initiated binding for
that client in an implementation-specific manner within the servers
configuration exchange. See section 11.4.2 parameter database for details.

12.5.4. Receipt of Reply messages

Upon DHCP clients.

If the receipt of a valid Reply message, server cannot provide addresses to the client extracts the
contents of it SHOULD send
back an empty IA to the ``option'' field, and sets (or resets) configuration
parameters appropriately. The client records and updates the
lifetimes for any addresses specified in IAs in with the Reply message. status field set to Unavail.

If the configuration parameters changed were requested by the
application layer, server can provide addresses to the client notifies it MUST send back
the application layer IA to the client with all fields entered and a status of Success,
and add the
changes using an implementation-specific interface.

13. Using DHCP for network renumbering

This section has been deleted (to be moved to ``Notes about DHCP''
doc?). IA as a new client binding.

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

Internet Draft DHCP for IPv6 22 November 2000

14. DHCP Client Implementor Notes

This section provides helpful information for the client implementor
regarding their implementations. The text described here is not part 1 March 2001

13.4.2. Receipt of Confirm messages

Upon the protocol, but rather a discussion receipt of implementation features
we feel a valid Confirm message from a client the implementor should consider during implementation.

14.1. Primary Interface

Since configuration parameters acquired through DHCP server
can be
interface-specific or more general, respond to, (implementation-specific administrative policy
satisfied) the client implementor SHOULD
provide a mechanism by which server scans the client implementation can be
configured options field.

The server then constructs a Reply message and sends it to specify which interface is the primary interface.
client.

The
client server SHOULD always query the DHCP data associated with process each option for the primary
interface for non-interface specific configuration parameters. An
implementation MAY implement a list of interfaces which would be
scanned client in order an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:

msg-type TBD

preference Enter the servers preference to
provide services to satisfy the general request. In either case, client.

transaction-ID Enter the
first interface scanned is considered transaction-ID from the primary interface.

By allowing
Confirm message.

client-link-local address Enter the specification of a primary interface, client-link-local address
from the client
implementor identifies which interface is authoritative for
non-interface specific parameters, which prevents configuration
information ambiguity within Confirm message.

server address Enter the client implementation.

14.2. Advertise Message and Configuration Parameter Caching

If server's address.

When the hardware server receives a Confirm and an IA option is included the
client is running on permits it, requesting confirmation that the implementor addresses in the IA are
valid. The server SHOULD provide a cache for Advertise messages and a cache of
configuration parameters received through DHCP. Providing these
caches prevents unnecessary DHCP traffic locate the clients binding and verify the subsequent load
this generates on
information in the servers. The implementor SHOULD provide a
configuration knob for setting IA from the amount of time client matches the cache(s) are
valid.

14.3. Time out and retransmission variables

Note information stored
for that client.

If the server cannot find a client time out and retransmission variables outlined
in section 3.5 can be configured on entry for this IA the server and sent
SHOULD return an empty IA with status set to NoBinding.

If the client
through server finds that the use of information for the ``DHCP Retransmission Parameter Option'',
which client does not
match what is documented in section 22.6. A client implementation SHOULD
be able to reset these variables using the values from this option. servers records for that client the server
should send back an empty IA with status set to Conf_NoMatch.

If the server finds a match to the Confirm then the server should
send back the IA to the client with status set to success.

13.4.3. Receipt of Renew messages

Upon the receipt of a valid Renew message from a client the server
can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field.

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

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

Internet Draft DHCP for IPv6 22 November 2000

14.4. Server Preference

A 1 March 2001

The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST wait for SRVR_PREF_WAIT seconds after sending construct a DHCP
Solicit message to collect Advertise messages and compare their
preferences (see section 15.3), unless it receives an Advertise Reply
message with a containing the following values:

msg-type TBD

preference of 255. If Enter the client receives an
Advertise message with a servers preference of 255, then to
provide services to the client MAY act
immediately on that Advertise without waiting for any more additional
Advertise messages.

15. DHCP Server Implementor Notes

This section provides helpful information for client.

transaction-ID Enter the transaction-ID from the
Confirm message.

client-link-local address Enter the client-link-local address
from the Confirm message.

server implementor.

15.1. Client Bindings

A address Enter the server's address.

When the server implementation MUST use receives a Renew and IA option from a client it
SHOULD locate the IA's UUID clients binding and verify the prefix
specification information in the
IA from which the client sent its Request message(s) as an
index for finding configuration parameters assigned to matches the information stored for that client.
While it isn't critical to keep track of

If the other parameters
assigned to server cannot find a client, client entry for this IA the server MUST keep track of the addresses it
has assigned to
SHOULD return an IA.

The server should periodically scan its bindings for addresses whose
leases have expired. When empty IA with status set to NoBinding.

If the server finds expired addresses, it
MUST delete that the assignment of those addresses, thereby making these addresses 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 the IA for the client do
not match the clients binding the lifetimes on assigned addresses are renewable, and
by how long.

15.2. Reconfigure-init Considerations

A server implementation MUST provide should return an interface empty IA
with status set to Renw_NoMatch.

If the
administrator for initiating reconfigure-init events.

A server implementation may provide a mechanism cannot Renew addresses for allowing the
specification of how many clients comprise a reconfigure multicast
group. This enables client it SHOULD send
back an empty IA to the administrator client with the status field set to control Unavail.

If the hit a server
takes when a reconfigure-init event occurs.

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

Internet Draft DHCP finds the addresses in the IA for IPv6 22 November 2000

15.3. Server Preference

The the client then the
server implementation SHOULD allow send back the setting of a server
preference value by IA to the administrator. The server preference
variable is an unsigned single octet value (0--255), client with new lease times
and T1/T2 times if the lowest
preference default is not being 0 used, and set status to
Success.

13.4.4. Receipt of Rebind messages

Upon the highest 255. Clients will choose higher
preference servers over those with lower preference values. If you
don't choose to implement this feature in your server, you MUST set receipt of a valid Rebind message from a client the server preference field to 0 in
can respond to, (implementation-specific administrative policy
satisfied) the Advertise messages generated
by your server.

15.4. Request Message Transaction-ID Cache

In order to improve performance, a server implementation MAY include
an in memory transaction-ID cache. This cache is indexed by client
binding and transaction-ID, and enables scans the options field.

The server to quickly
determine whether a Request is a retransmission or a new Request
without the cost of a database lookup. If an implementor chooses to
implement this cache, then they SHOULD provide constructs a configuration knob Reply message and sends it to tune the lifetime of the cache entries.

16. DHCP Relay Implementor Notes

A relay implementation
client.

The server SHOULD allow the specification of a list of
destination addresses process each option for forwarded messages. This list MAY contain
any mixture of unicast addresses and multicast addresses.

If a relay receives an ICMP message the client in response to an
implementation-specific manner. The server MUST construct a DHCP Reply
message it
has forwarded, it SHOULD log this event.

17. Open Issues for Working Group Discussion

This section contains some items for discussion by containing the working group.

17.1. Authentication

Authentication is not discussed in this document.

17.2. DHCP-DNS interaction

Interaction among DHCP servers, clients and DNS servers is not
discussed in this document. following values:

msg-type TBD

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

Internet Draft DHCP for IPv6 22 November 2000

17.3. Release vs. Decline

Should there be a separate Decline message through which the client
informs 1 March 2001

preference Enter the server that it has discovered an servers preference to
provide services to the client.

transaction-ID Enter the transaction-ID from the
Confirm message.

client-link-local address that is in use
by some other host?

17.4. Request messages

In DHCPv4, there has been much confusion about overloading
DHCPREQUEST with Enter the actions of initial client-link-local address allocation
(INIT),
from the Confirm message.

server address confirmation (INIT-REBOOT), Enter the server's address.

When the server receives a Renew and extending leases
(RENEW/REBIND).

The model for DHCPv6 messages described in section 11 also uses one
type of message, Request, in each of IA option from a client it
SHOULD locate the scenarios in sections 11.4.8
through 11.4.10. The DHCPv6 specification clients binding and verify the information in this document does not
differentiate the actions taken by a
IA from the client matches the information stored for that client.

If the server based on different times
at which cannot find a client might initiate a Request/Reply exchange entry for this IA the server
SHOULD return an empty IA with a
server. That is, status set to NoBinding.

If the description of server actions finds that the addresses in section 11.6.1
does the IA for the client do
not differentiate among Requests received from match the clients based on binding the client behavior described in sections 11.4.8 through 11.4.10.

It may be necessary server should return an empty IA
with status set to define different Rebd_NoMatch.

If the server behaviors cannot Rebind addresses for each of the client scenarios. For example, in the address-reconfirmation
scenario (section 11.4.9), servers cannot safely assign new addresses it SHOULD send
back an empty IA to a client. The reconfirmation Request is broadcast the client with the status field set to multiple
servers, which cannot coordinate Unavail.

If the assignment of any addresses.
Therefore, in this scenario, servers can only acknowledge or deny server finds the
validity of addresses but cannot allocate any new addresses.

17.5. Use of term ``agent''

The term ``agent'', taken to mean ``relay agent or server'', may be
confusing. ``relay agent or server'' might be clearer.

17.6. Use in the IA for the client then the
server SHOULD send back the IA to the client with new lease times
and T1/T2 times if the default is not being used, and set status to
Success.

13.4.5. Receipt of terms ``subnet'' Release messages

Upon the receipt of a valid Release message, the server examines the
IAs and ``network''

The term ``subnet'' has the addresses in the IAs for validity. If the IAs in the
message are in a binding for the client and the addresses in the IAs
have been eliminated assigned by the server to those IA, the server deletes
the addresses from the document. The term
``network'' is no longer used IAs and makes the addresses available for
assignment to describe other clients.

The server then generates a link, collection Reply message. If all of links the IAs were
valid and the addresses successfully released,, the server sets the
"status" field to "Success". If any of the IAs were invalid or collection if
any of IPv6 addresses.

18. Security

This document references the addresses were not successfully released, the server
releases none of the addresses in the message and sets the "status"
field to "NoBinding"(section 7.4).

DISCUSSION:

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

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

Internet Draft DHCP for IPv6 22 November 2000

DISCUSSION:

Based on 1 March 2001

Can a client send an empty IA to release all addresses in
the discussion IA?

If the IA becomes empty - all addresses are released - can
the server discard any record of security issues at the
8/31/00 design team teleconference and subsequent
DHC WG mailing list discussion, DHCPv6 will use IA?

13.4.6. Sending of Reply messages

If the security model Request or Release message from DHCPv4, as described in
draft-ietf-dhc-authentication-15.txt.

19. Year 2000 considerations

Since all times are relative to the current time of client was originally
received by the transaction,
there is no problem within server, the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of server unicasts the current year.

20. IANA Considerations

This document defines Reply message types 1--8 to be received by UDP at
port numbers 546 and 547. Additional the
link-local address in the "client-link-local-address" field.

If the message types may be defined was originally received in a Forward-request or
Forward-release message from a relay, the future.

Section 3.1 lists several multicast addresses used by DHCP.

This document also defines several status codes that are to
be returned with server places the Reply and Reconfigure-reply messages (see
sections 9.4 and 9.7). The non-zero values for these status codes
which are currently specified are shown
message in the table in section 3.4.

There is a DHCPv6 option described in section 22.6, which allows
clients and servers to exchange values for some options field of the timing a Response-reply message and retransmission parameters defined in section 3.5. Adding new
parameters in unicasts
the future would require extending message to the values by which relay's address from the parameters are indicated original message.

14. DHCP Server-Initiated Configuration Exchange

A server initiates a configuration exchange to force DHCP clients
to obtain new addresses and other configuration information. For
example, an administrator may use a server-initiated configuration
exchange when links in the DHCP option. Since there needs domain are to be a list kept, renumbered. Other
examples include changes in the default values for each parameter should also
be stored as part location of the list.

All directory servers,
addition of these protocol elements may be specified to assume new values
at some point in the future. New values should be approved by the
process of IETF Consensus [10].

21. Acknowledgments

Thanks to the DHC Working Group for their time services such as printing, and input into availability of new
software (system or application).

14.1. Reconfigure-init Message Validation

Agents MUST silently discard any received Reconfigure-init messages.

Clients MUST discard any Reconfigure-init messages that do
not contain an authentication option or that fail the
specification. Ralph Droms and Thomas Narten have had client's
authentication check.

Clients MUST discard any Reconfigure-init messages that contain a major
role in shaping
transaction-ID that matches the continued improvement of transaction-ID in a Reconfigure-init
message previously received from the protocol by their
careful reviews. Many thanks same DHCP server.

14.2. Server Behavior

A server sends a Reconfigure-init message to Matt Crawford, Erik Nordmark, Gerald
Maguire, and Mike Carney for their studied review as part of trigger a client to
initiate immediately a Request/Reply message exchange with the
server. A server may unicast a Reconfigure-init message directly
to a single client or use multicast to deliver a Reconfigure-init
message to multiple clients.

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

Internet Draft DHCP for IPv6 22 November 2000

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, 1 March 2001

14.2.1. Creation and Phil Wells.

Thanks sending of Reconfigure-init messages

The server sets the "msg-type" field to Steve Deering TBD. The server generates
a transaction-ID and Bob Hinden, who have consistently
taken inserts it in the time "transaction-ID" field.
The server places its address (of appropriate scope) in the
"server-address" field.

The server MAY include an ORO option to discuss inform the more complex parts client of the IPv6
specifications.

22. DHCP options

Options are used to carry additional what
information has been changed or new information that has been added.

The server MUST include an authentication option with the appropriate
settings and parameters
in DHCP messages. Every add that option shares a common base format, as
described the last option in section 22.1.

this document describes the DHCP options defined as part "options"
field of the base
DHCP specification. Other options may be defined Reconfigure-init message.

The server MAY include a Reconfigure-delay option in the future a
Reconfigure-init message to be unicast to a client, and MUST
include a Reconfigure-delay option in a
separate document.

22.1. Format Reconfigure-init message to
be multicast to a group of DHCP clients.

The server MUST NOT include any other options

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

option-len
An unsigned integer giving the length of the data in
this option Reconfigure-init
except as specifically allowed in bytes.

option-data
The data for the option; the format of this data depends
on the definition of individual
options.

The server may either unicast the option.

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

Internet Draft DHCP Reconfigure-init message to one
client or multicast the message to one or more Reconfigure Multicast
Addresses previously sent as options to the clients. The server
may unicast Reconfigure-init messages to more than one client
concurrently; for IPv6 22 November 2000

22.2. Identity association option example, to reliably reconfigure all clients, the
server will unicast a Reconfigure-init message to each client.

If the server unicasts to one or more clients, it waits for a Request
message from those clients confirming that it has received the
Reconfigure-init and are thus initiating a Request/Reply transaction
with the server. The identity association option server can determine that a Request message is used
in response to carry an identity
association, a Reconfigure-init because the parameters associated with transaction-ID in the IA and
Request will be the addresses
assigned same value as was used in the Reconfigure-init
message.

If the server multicasts the Reconfigure-init message, it must use
some TBD authentication mechanism that can authenticate the server to
multiple clients. There is no reliability mechanism for multicast
Reconfigure-init messages. A server might use multicast in the IA.

The format
case where it does not have a list of the IA option is:

0 1 2 3
0 its clients; for example, a
server that distributes configuration information to clients using
stateless autoconfiguration might not keep a list of clients it has
communicated with.

DISCUSSION:

Authentication of multicast reconfigure-init is still an
open issue.

Bound, Carney, Perkins, Droms (ed.) Expires 1 2 3 4 5 6 7 8 9 0 September 2001 [Page 36]

Internet Draft DHCP for IPv6 1 2 3 4 5 6 7 8 9 0 March 2001

See section 18.2 for recommendations on the use of multicast
and unicast Reconfigure-init messages for reliable client
reconfiguration.

14.2.2. Time out and retransmission of unicast Reconfigure-init messages

If the server does not receive a Request message from the client
in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT
value and waits again. The server continues this process until
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point
the server SHOULD abort the reconfigure process.

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

14.2.3. Time out and retransmission of multicast Reconfigure-init
messages

After the server transmits the initial Reconfigure-init message,
the server waits RECREP_MSG_TIMEOUT milliseconds. The server
then retransmits the Reconfigure-init message, doubles the
RECREP_MSG_TIMEOUT value and waits again. The server repeats this
process until a total of REC_MSG_ATTEMPTS Reconfigure-init messages
have been transmitted.

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

14.2.4. Receipt of Request messages

The server generates and sends Reply message(s) to the client as
described in section 13.4.6, including in the "option" field new
values for configuration parameters.

14.3. Client Behavior

A client MUST always monitor UDP port 546 for 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.

14.3.1. Receipt of Reconfigure-init messages

Upon receipt of a valid Reconfigure-init message, the client
initiates a Request/Reply transaction with the server.

Bound, Carney, Perkins, Droms (ed.) Expires 1 2 3 4 5 6 September 2001 [Page 37]

Internet Draft DHCP for IPv6 1 March 2001

14.3.2. Creation and sending of Request messages

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

transaction-ID The client copies the
transaction-ID from the
Reconfigure-init message into the
Request message.

IAs The client includes IA options
containing the addresses the client
currently has assigned to those IAs
for the interface through which
the Reconfigure-init message was
received.

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

14.3.3. Time out and retransmission of Request messages

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

14.3.4. Receipt of Reply messages

Upon the receipt of a valid Reply message, the client extracts the
contents of the "option" field, and sets (or resets) configuration
parameters appropriately. The client records and updates the
lifetimes for any addresses specified in IAs in the Reply message.
If the configuration parameters changed were requested by the
application layer, the client notifies the application layer of the
changes using an implementation-specific interface.

15. Relay Behavior

For this discussion, the Relay may be configured to use a list of
server destination addresses, which may include unicast addresses,
the All DHCP Servers multicast address, or other multicast addresses
selected by the network administrator. If the Relay has not been

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

Internet Draft DHCP for IPv6 1 March 2001

explicitly configured, it will use the All DHCP Servers multicast
address as the default.

15.1. Relaying of Solicit messages

When a Relay receives a valid Solicit message, it constructs
a Relay-forward message. The relay places an address from
the interface on which the Solicit message was received in the
"relay-address" field and the prefix length for that address in the
"prefix-length" field. This address will be used by the server to
identify the link to which the client is connected and will be used
by the relay to forward the Advertise message from the server back to
the client.

The relay constructs a "relay-message" option 16.4 that contains
the entire Solicit message from the client in the data field of the
option. The relay places the "relay-message" option along with any
"relay-specific" options in the options field of the Relay-forward
message. The Relay then sends the Relay-forward message to the list
of server destination addresses that it has been configured with.

15.2. Relaying of Advertise messages

When the relay receives a Relay-reply message, it extracts the
Advertise message from the "server-message" option and forwards the
server message to the address in the client-link-local-address field
in the Advertise message. The relay forwards the server message
through the interface identified in the "relay-address" field in the
Relay-reply message.

16. DHCP options

Options are used to carry additional information and parameters
in DHCP messages. Every option shares a common base format, as
described in section 16.1.

this document describes the DHCP options defined as part of the base
DHCP specification. Other options may be defined in the future in a
separate document.

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

Internet Draft DHCP for IPv6 1 March 2001

16.1. Format of DHCP options

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

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

option-data The data for the option; the format of this data
depends on the definition of the option.

16.2. Identity association option

The identity association option is used to carry an identity
association, the parameters associated with the IA and the addresses
assigned to the IA.

The format of the IA option is:

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 40]

Internet Draft DHCP for IPv6 1 March 2001

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

option-code TBD

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

IA DUID The unique identifier for this IA; chosen by the client

T1 The time at which the client contacts the server from
which the addresses in the IA were obtained to extend
the lifetimes of the addresses assigned to the IA.

T2 The time at which the client contacts any available
server to extend the lifetimes of the addresses assigned
to the IA.

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 41]

Internet Draft DHCP for IPv6 1 March 2001

IA status Status of the IA in this option.

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

addr status Status of this address.

prefix length Prefix length for this address.

IPv6 address An IPv6 address assigned to this IA.

preferred lifetime The preferred lifetime for the associated IPv6
address.

valid lifetime The valid lifetime for the associated IPv6 address.

The "IPv6 address", "preferred lifetime" and "valid lifetime" fields
are repeated for each address in the IA option (as determined by the
"num-addrs" field).

DISCUSSION:

The details of the format and the selection of an IA's DUID
are TBD.

Note that an IA has no explicit "lifetime" or "lease length" of
its own. When the lifetimes of all of the addresses in an IA have
expired, the IA can be considered as having expired. T1 and T2
are included to give servers explicit control over when a client
recontacts the server about a specific IA.

16.3. Option request option

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

option-code TBD.

option-len Variable; equal to twice the number of option codes
carried in this option.

option-data A list of the option codes for the options requested
in this option.

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 42]

Internet Draft DHCP for IPv6 1 March 2001

16.4. Client message option

option-code TBD

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

option-data The message received from the client; forwarded
verbatim to the server.

16.5. Server message option

option-code TBD

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

option-data The message received from the server; forwarded
verbatim to the client.

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

Internet Draft DHCP for IPv6 1 March 2001

16.6. Retransmission parameter option

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

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

option-data The data for the option; the format of this data
depends on the definition of the option.

16.7. Authentication option

The authentication option is TBD.

16.8. Reconfigure-delay option

The Reconfigure-delay option specifies the amount of time a client
should delay before sending a Request message in response to a
Reconfigure-init 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| minimum delay time (msec) | maximum delay time (msec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The client chooses a random number between the minimum delay time and
the maximum delay time and delays that number of milliseconds before
sending its Request message.

16.9. DSTM Global IPv4 Address Option

The DSTM Global IPv4 Address Option informs a client or server that
the Identity Association Option (IA) following this option will

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 44]

Internet Draft DHCP for IPv6 1 March 2001

contain an IPv4-Mapped IPv6 Address [?] in the case of a Client
receiving the option, or is a Request for an IPv4-Mapped IPv6 Address
from a client in the case of a DHCPv6 Server receiving the option.
The option can also provide an IPv6 address to be used as the Tunnel
Endpoint (TEP) to encapsulate an IPv4 packet within IPv6.

This option can be used with the Request, Reply, and Reconfigure-Init
Messages for cases where a server wants to assign to clients
IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO).

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IA UUID |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addrs | IPv6 address |
+-+-+-+-+-+-+-+-+ (16 octets) |
| |
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | pref. len | preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref. lifetime (cont.) | valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid lifetime (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel End Point (TEP) |
| (If Present) |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code: TBD
option-length: Variable: 0 or 16
Tunnel End Point: IPv6 Address if Present

A DSTM IPv4 Global Address Option MUST only apply to the IA following
this option.

17. DHCP Client Implementor Notes

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

17.1. Primary Interface

Since configuration parameters acquired through DHCP can be
interface-specific or more general, the client implementor SHOULD
provide a mechanism by which the client implementation can be
configured to specify which interface is the primary interface. The
client SHOULD always query the DHCP data associated with the primary
interface for non-interface specific configuration parameters. An
implementation MAY implement a 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 a primary interface, the client
implementor identifies which interface is authoritative for
non-interface specific parameters, which prevents configuration
information ambiguity within the client implementation.

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

Internet Draft DHCP for IPv6 1 March 2001

17.2. Advertise Message and Configuration Parameter Caching

If the hardware the client is running on permits it, the implementor
SHOULD provide a cache for Advertise messages and a cache of
configuration parameters received through DHCP. Providing these
caches prevents unnecessary DHCP traffic and the subsequent load
this generates on the servers. The implementor SHOULD provide a
configuration knob for setting the amount of time the cache(s) are
valid.

17.3. Time out and retransmission variables

Note that the client time out and retransmission variables outlined
in section 7.5 can be configured on the server and sent to the client
through the use of the "DHCP Retransmission Parameter Option", which
is documented in section 16.6. A client implementation SHOULD be
able to reset these variables using the values from this option.

17.4. Server Preference

A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
Solicit message to collect Advertise messages and compare their
preferences (see section 18.3), unless it receives an Advertise
message with a preference of 255. If the client receives an
Advertise message with a preference of 255, then the client MAY act
immediately on that Advertise without waiting for any more additional
Advertise messages.

18. DHCP Server Implementor Notes

This section provides helpful information for the server implementor.

18.1. Client Bindings

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

The server should periodically scan its bindings for addresses whose
leases have expired. When the server finds expired addresses, it
MUST delete the assignment of those addresses, thereby making these
addresses available to other clients.

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

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

Internet Draft DHCP for IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code
TBD

option-len
Variable; equal 1 March 2001

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

18.2. Reconfigure-init Considerations

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

A server implementation may provide a mechanism for allowing the
specification of how many clients comprise a reconfigure multicast
group. This enables the administrator to control the processing load
impact of the multicast of a Reconfigure-init message.

18.2.1. Reliable transmission of multicast Reconfigure-init messages

Because clients will ignore Reconfigure-init messages with the
same transaction-ID, a server can retransmit a Reconfigure-init
message (using the same transaction-ID) without causing any
client to reply more than once. A server SHOULD retransmit a
multicast Reconfigure-init message several times to maximize the
probability that all clients in the multicast group have received the
Reconfigure-init message.

If a server does not receive a Reply message from some clients in a
multicast group, the server MAY choose to 17 + num-addrs*25

IA UUID
The unique identifier for this IA; chosen by unicast a Reconfigure-init
message to those clients. Because the client

T1 The time at which clients may have received the client contacts
multicast Reconfigure-init messages while the server from
which did not receive
the addresses clients' Reply messages, the server SHOULD use a different
transaction-ID in the IA were obtained unicast Reconfigure-init messages to extend trigger
the lifetimes client to reconfigure.

18.3. Server Preference

The server implementation SHOULD allow the setting of a server
preference value by the addresses assigned administrator. The server preference
variable is an unsigned single octet value (0--255), with the lowest
preference being 0 and the highest 255. Clients will choose higher
preference servers over those with lower preference values. If you
don't choose to implement this feature in your server, you MUST set
the server preference field to 0 in the IA. Advertise messages generated
by your server.

18.4. Request Message Transaction-ID Cache

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

Internet Draft DHCP for IPv6 22 November 2000

T2 The time at which 1 March 2001

without the client contacts any available
server cost of a database lookup. If an implementor chooses to extend
implement this cache, then they SHOULD provide a configuration knob
to tune the lifetimes lifetime of the addresses assigned
to the IA.

num-addrs
An unsigned integer giving cache entries.

19. DHCP Relay Implementor Notes

A relay implementation SHOULD allow the number specification of a list of
destination addresses
carried for forwarded messages. This list MAY contain
any mixture of unicast addresses and multicast addresses.

If a relay receives an ICMP message in this IA option (MAY be zero).

IPv6 address
An IPv6 address assigned response to a DHCP message it
has forwarded, it SHOULD log this IA.

preferred lifetime
The preferred lifetime for the associated IPv6 address.

valid lifetime
The valid lifetime event.

20. Open Issues for the associated IPv6 address.

The ``IPv6 address'', ``preferred lifetime'' and ``valid lifetime''
fields are repeated Working Group Discussion

This section contains some items for each address in the IA option (as determined discussion by the ``num-addrs'' field).

DISCUSSION:

The details working group.

20.1. Authentication

Authentication is not discussed in this document. Authentication
will be modeled on DHCPv4 authentication. Authentication of the format and the selection
multicast Reconfigure-init messages is a special problem.

20.2. Identification of IAs by servers

Do servers identify an IA's UUID
are TBD.

DISCUSSION:

An IA has no explicit ``lifetime'' or ``lease length'' of just by its own. When the lifetimes of all of the addresses in an
IA have expired, the IA can be considered as having expired.
T1 and T2 DUID or by <prefix, DUID>? If
just by DUID, are included to give servers explicit control over
when a client recontacts DUIDs guaranteed unique (within the server about a specific IA.

22.3. Option request option

20.3. DHCP-DNS interaction

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

20.4. Anonymous addresses

How does DHCPv6 interact with anonymous addresses? If the server
assigns anonymous addresses (e.g., addresses with short lifetimes),
how can a client application choose an anonymous address as a source
address in preference to a non-anonymous address?

20.5. Use of term "agent"

The term "agent", taken to mean "relay agent or server", may be
confusing. "relay agent or server" might be clearer.

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

Internet Draft DHCP for IPv6 22 November 2000

option-code TBD.

option-len
Variable; equal 1 March 2001

20.6. Client behavior when response to twice the Rebind is not received

Section 13.3.4 describes several plausible ways in which a client
might respond when it does not receive a Reply to a Rebind message.
The acceptable client behaviors need to be defined and described
in 13.3.4.

20.7. Additional options

Which additional options should be included in this base spec
document?

20.8. Operational parameters

Should servers have an option to set operational parameters -
retransmission timeouts, number of option codes
carried retries - in this option.

option-data
A list clients?

21. Security

This document references an "authentication option" which is TBD.

DISCUSSION:

Based on the discussion of security issues at the option codes for
8/31/00 design team teleconference and subsequent
DHC WG mailing list discussion, DHCPv6 will use
the options requested security model from DHCPv4, as described in
this option.

22.4. Client message option

option-code TBD

option-len
Variable; equal
draft-ietf-dhc-authentication-15.txt.

22. Year 2000 considerations

Since all times are relative to the length current time of the forwarded DHCP
client message.

option-data
The message received from transaction,
there is no problem within the client; forwarded verbatim DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the server.

22.5. Server message option

23. IANA Considerations

This document defines message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code types TBD

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

Internet Draft DHCP for IPv6 22 November 2000

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

option-data
The message be received from the server; forwarded verbatim
to the client.

22.6. Retransmission parameter option

option-code
An unsigned integer identifying the specific option type
carried by UDP at port
numbers 546 and 547. Additional message types may be defined in this option.

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

option-data
future.

Section 7.1 lists several multicast addresses used by DHCP.

This document also defines several status codes that are to be
returned with the Reply message (see section 9.7). The data non-zero
values for these status codes which are currently specified are shown
in the option; the format of this data depends
on the definition of the option.

22.7. Authentication option

The authentication option is TBD.

23. Changes table in this draft

This section describes the changes between this version of the DHCPv6
specification and draft-ietf-dhc-dhcpv6-15.txt. 7.4.

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

Internet Draft DHCP for IPv6 22 November 2000

23.1. Order 1 March 2001

There is a DHCPv6 option described in section 16.6, which allows
clients and servers to exchange values for some of sections the timing
and retransmission parameters defined in section 7.5. Adding new
parameters in the future would require extending the values by which
the parameters are indicated in the DHCP option. Since there needs
to be a list kept, the default values for each parameter should also
be stored as part of the list.

All of these protocol elements may be specified to assume new values
at some point in the future. New sections values should be approved by the
process of IETF Consensus [9].

24. Acknowledgments

Thanks to the DHC Working Group for their time and input into the
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 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 Phil Wells.

Thanks to Steve Deering and Bob Hinden, who have been added at consistently
taken the end of this document time to minimize
changes in section numbering. Those sections discuss the more complex parts of the IPv6
specifications.

A. Comparison between DHCPv4 and DHCPv6

This appendix is provided for readers who will be rearranged in find it useful to see
a
future revision.

23.2. Reconfigure message

DHCP Reconfigure model and Reconfigure-reply messages architecture comparison between DHCPv4 [6, 1] and DHCPv6.
There are three key reasons for the associated
mechanisms have been removed from this draft differences:

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

23.3. Releasable resources

``Releasable resources'' have been removed addresses.

o DHCPv6 benefits from this draft.

23.4. DHCP message header

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

23.5. Design goals

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

23.6. Overview

Section 8.2 (DHCP agents) has been removed. DHCP clients no longer
need to know about specific DHCP agents.

Section 8.3 has been modified to reflect the new encapsulating
mechanism through which relays forward client messages IPv6 features.

o New features were added to servers.

Section 8.6 support the expected evolution and 8.7 have been modified to describe ``identity
associations''.

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

23.7. Message formats, 9

Message formats 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 been changed. All messages share a common fixed
message header followed by options.
source IP address at all times to locate an on-link server or
relay.

o The various control bits (``P'',
``C'') need for BOOTP compatibility and the broadcast flag have been removed from the message header.
removed.

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

Internet Draft DHCP for IPv6 22 November 2000

23.8. Solicit 1 March 2001

o Multicast and Advertise messages, (section 10)

The description of the message exchanges have been changed to
reflect:

- New relay behavior - encapsulated client messages

- Use of IAs

23.9. Prefix advertisement

Servers no longer advertise prefixes.

23.10. Identity Associations

Section 9.11 describes IAs address scoping in detail. A definition IPv6 permit the design of ``IA''
discovery packets that would inherently define their range by the
multicast address for the function required.

o Stateful autoconfiguration has
been added to section 2. The description of messages exchanges
have been extended coexist and integrate with
stateless autoconfiguration supporting Duplicate Address
Detection and the two IPv6 lifetimes, to include IAs. The IA option is defined in
section 22.2

23.11. Extensions renamed options; defined facilitate the dynamic
renumbering of addresses and the management of those addresses.

o Multiple addresses per interface are inherently supported in this document

``extensions''
IPv6.

o Some DHCPv4 options are unnecessary now called ``options''; because the options referenced configuration
parameters are either obtained through IPv6 Neighbor Discovery or
the Service Location protocol [14].

DHCPv6 Architecture/Model Changes:

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

o IPv6 Address allocations are defined now handled in section 22.

23.12. Transaction-ID ranges

Solicit, Advertise, Request, Reply, Release and Reconfigure-init
messages all use an unsigned 16-bit integer ``Transaction-ID''.
Transaction-IDs generated by clients a message option as
opposed to the message header.

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

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

o The client will know if the server is no
need to restrict clients and servers to select Transaction-IDs on-link or off-link.

o The on-link relay may locate off-link server addresses from
specific ranges to avoid conflicts.

23.13. Release messages
system configuration or by the use of a site-wide multicast
packet.

o ACKs and relays

Release/Reply messages NAKs are forwarded through relays. not used.

o The server assumes the client receives its responses unless it
receives a retransmission of the same client request. This mechanism
eliminates
permits recovery in the need for an 'R' bit.

23.14. Discovering relay agents case where the network has faulted.

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

o The function of relay agents. When DHCPINFORM is inherent in the
client only has new packet design;
a link-local address (e.g., the client has no can request configuration parameters other than IPv6
addresses in the optional option headers.

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

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

Internet Draft DHCP for IPv6 22 November 2000

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

A. Comparison between DHCPv4 and DHCPv6

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

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

o DHCPv6 benefits from the new IPv6 features.

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

IPv6 Architecture/Model Changes: 1 March 2001

o The link-local address permits a node to New options have an address
immediately when been defined.

With the node boots, which means all clients have a
source IP address at all times changes just enumerated, we can support new user features,
including

o Configuration of Dynamic Updates to locate an on-link DNS

o Address deprecation, for dynamic renumbering.

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

o The need Authentication

o Clients can ask for BOOTP compatibility and multiple IP addresses.

o Addresses can be reclaimed using the broadcast flag have been
removed. Reconfigure-init message.

o Multicast Integration between stateless and stateful address scoping
autoconfiguration.

o Enabling relays to locate off-link servers.

B. Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in IPv6 permit the design its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of
discovery packets any
kind, provided that would inherently define their range by the
multicast address for the function required.

o Stateful autoconfiguration has to coexist above copyright notice and integrate with
stateless autoconfiguration supporting Duplicate Address
Detection 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 two IPv6 lifetimes, copyright notice or references to facilitate the dynamic
renumbering Internet Society
or other Internet organizations, except as needed for the purpose
of addresses and developing Internet standards in which case the management of those addresses.

o Multiple addresses per interface are inherently supported procedures
for copyrights defined in
IPv6.

o Some DHCPv4 options are unnecessary now because the configuration
parameters are either obtained through IPv6 Neighbor Discovery Internet Standards process must be
followed, or
the Service Location protocol [15].

DHCPv6 Architecture/Model Changes:

o as required to translate it into languages other than
English.

The message type is limited permissions granted above are perpetual and will not be
revoked by the first byte in Internet Society or its successors or assigns.

This document and the packet. 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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

Internet Draft DHCP for IPv6 22 November 2000

o IPv6 Address allocations 1 March 2001

C. Changes in this draft

This section describes the changes between this version of the DHCPv6
specification and draft-ietf-dhc-dhcpv6-16.txt.

C.1. New messages for confirming addresses and extending the lease on an
IA

Four new messages, DHCP Confirm, DHCP Renew, DHCP Rebind and DHCP
Decline, have been added and are now handled described in a section 13. Client
behavior - when and how to send these new messages - and server
behavior - how to respond to each - has been defined. The message option as
opposed
type codes for these messages have been added to the section 7.3.

C.2. New message header.

o Client/Server bindings are now mandatory and take advantage formats

Section 9 has been restructured to include only one copy of the client's link-local address to always permit communications
either directly from an on-link server, or from a off-link server
through an on-link relay.

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

o The client will know if header, because now all the server is on-link or off-link.

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

o ACKs and NAKs are not used.

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

o Clients can issue multiple, unrelated Request Confirm,
Renew, Rebind and Decline messages have been added to 9.

C.3. Renamed Server-forward message

Section 10.2 has been renamed "relay-reply" for consistency with the
same or different servers.

o The function
rest of DHCPINFORM is inherent in the new packet design;
a document

C.4. Clarified relay forwarding of messages

Added text to sections on relay behavior to clarify encapsulation and
decapsulation of client can request configuration parameters other than IPv6
addresses messages in the optional option headers.

o Clients MUST listen Relay-forward and Relay-reply
messages.

C.5. Addresses and options in Advertise messages

Modified section 12.4.2 so that servers include addresses to their UDP port for the new Reconfigure
message from servers.

o New be
assigned and other options have been defined.

With in Advertise messages. Also added text to
section 12.3.1 to disallow option values (except as noted in option
definitions) in Solicit messages.

C.6. Clarification of IA option format

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

o Configuration label of Dynamic Updates the prefix length field in an IA option to DNS

o Address deprecation,
"prefix length" in the option format diagram, and moved the prefix
before the address for dynamic renumbering.

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

o Authentication

o Clients can ask for multiple IP addresses. relay messages and other IPv6
protocols.

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

Internet Draft DHCP for IPv6 22 November 2000

o Addresses can be reclaimed using 1 March 2001

C.7. Specification of transaction ID in Solicit message

Add text (which was missing) to specify the Reconfigure-init message.

o Integration between stateless and stateful address
autoconfiguration.

o Enabling relays insertion of a
transaction ID in Solicit messages.

C.8. Edits to locate off-link servers.

B. Full Copyright Statement

Some of the definitions in section 6 have been edited for clarity.

C.9. Relay agent messages

This document and translations formats of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist relay agent messages are now described in its implementation may be prepared, copied, published a separate
section, 10.

C.10. Relay agent behavior

The behavior of relay agents for all client and distributed, in whole or server messages is
now described in part, without restriction a single section, 15.

C.11. Transmission of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies client messages through relays

All client messages are now multicast to the All Agents multicast
address and derivative works. However,
this document itself may not be modified in any way, such as forwarded by
removing the copyright notice or references relays as appropriate.

C.12. Reconfigure-init messages

Client behavior in response to the Internet Society a Reconfigure-init messages has
been extended to accommodate receipt of multiple copies of a
Reconfigure-init message due to duplicate messages or other Internet organizations, except as needed for the purpose retransmission.

Server use of developing Internet standards in which case the procedures multicast Reconfigure-init has been specified.

Hints about use of multicast and unicast for copyrights defined in the Internet Standards process must be
followed, or as required reliable reconfiguration
have been added to translate it into languages other than
English. server implementor's hints.

C.13. Ordering of sections

Several sections have been re-ordered for clarity.

C.14. DSTM option

The limited permissions granted above are perpetual and will not be
revoked by the DSTM option has been added (section 16.9).

Bound, Carney, Perkins, Droms (ed.) Expires 1 September 2001 [Page 54]

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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Draft DHCP for IPv6 1 March 2001

References

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

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

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

Internet Draft DHCP for IPv6 22 November 2000

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

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

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

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

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

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

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

[10]

[9] T. Narten and H. Alvestrand. Guidelines for Writing an IANA
Considerations Section in RFCs. Request for Comments (Best
Current Practice) 2434, Internet Engineering Task Force, October
1998.

[11]

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

[12]

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

[13]

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

[14]

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

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

Internet Draft DHCP for IPv6 22 November 2000

[15] 1 March 2001

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

[16]

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

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

Internet Draft DHCP for IPv6 22 November 2000 1 March 2001

Chair's Address

The working group can be contacted via the current chair:

Ralph Droms
Cisco Systems
300 Apollo Drive
Chelmsford, MA 01824

Phone: (978) 244-4733
E-mail: rdroms@cisco.com

Author's Address

Questions about this memo can be directed to:

Jim Bound
Compaq Computer Corporation
Mail Stop: ZK03-3/U14
110 Spitbrook
Nokia Networks
5 Wayside Road
Nashua, NH 03062
Burlington, MA 01803
USA
Phone: +1-603-884-0400 +1-781-492-6010
Email: bound@zk3.dec.com jim.bound@nokia.com

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

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

Bound, Carney, Perkins, Droms (ed.) Expires 1 May September 2001 [Page 54] 57]
----