WDIFF

draft-ietf-dhc-dhcpv6-18.txt --> draft-ietf-dhc-dhcpv6-19.txt

Internet Engineering Task Force J. Bound
INTERNET DRAFT Nokia Compaq
DHC Working Group M. Carney
Obsoletes: draft-ietf-dhc-dhcpv6-18.txt Sun Microsystems, Inc
C. Perkins
Nokia Research Center
R. Droms(ed.)
Cisco Systems
15 April
30 June 2001

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-18.txt
draft-ietf-dhc-dhcpv6-19.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
Stateless Address Autoconfiguration" [13], [20], and can be used separately
or concurrently with the latter to obtain configuration parameters.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page i]

Internet Draft DHCP for IPv6 15 April 30 June 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 4
6.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 4
6.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 5

7. DHCP Constants 6
7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 7 6
7.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3. DHCP message types . . . . . . . . . . . . . . . . . . . 7
7.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 9
7.4.1. Generic Error Values . . . . . . . . . . . . . . 9
7.4.2. Server-specific Error Values . . . . . . . . . . 9
7.5. Configuration Variables . . . . . . . . . . . . . . . . . 10 9

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

9. Message Formats 13 12
9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 13
9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 14 13
9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 14
9.4. DHCP Confirm Message Format . . . . . . . . . . . . . . . 15 14
9.5. DHCP Renew Message Format . . . . . . . . . . . . . . . . 15
9.6. DHCP Rebind Message Format . . . . . . . . . . . . . . . 15
9.7. DHCP Reply Message Format . . . . . . . . . . . . . . . . 16 15
9.8. DHCP Release Message Format . . . . . . . . . . . . . . . 16

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page ii]

Internet Draft DHCP for IPv6 15 April 30 June 2001

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

10. Relay messages 17
10.1. Relay-forward message . . . . . . . . . . . . . . . . . . 18 17
10.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 18

11. DHCP unique identifier (DUID) 18

12. Identity association 19

12. 18

13. DHCP Server Solicitation 19
12.1.
13.1. Solicit Message Validation . . . . . . . . . . . . . . . 19
12.2.
13.2. Advertise Message Validation . . . . . . . . . . . . . . 19
12.3.
13.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 19
12.3.1.
13.3.1. Creation and sending of the Solicit message . . . 20
12.3.2. 19
13.3.2. Time out and retransmission of Solicit Messages . 20
12.3.3.
13.3.3. Receipt of Advertise messages . . . . . . . . . . 20
12.4.
13.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 21
12.4.1.
13.4.1. Receipt of Solicit messages . . . . . . . . . . . 21
12.4.2.
13.4.2. Creation and sending of Advertise messages . . . 21

13.

14. DHCP Client-Initiated Configuration Exchange 22
13.1.
14.1. Client Message Validation . . . . . . . . . . . . . . . . 23
13.2.
14.2. Server Message Validation . . . . . . . . . . . . . . . . 23
13.3.
14.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 24
13.3.1.
14.3.1. Creation and sending of Request messages . . . . 24
13.3.2.
14.3.2. Creation and sending of Confirm messages . . . . 25
13.3.3.
14.3.3. Creation and sending of Renew messages . . . . . 26
13.3.4.
14.3.4. Creation and sending of Rebind messages . . . . . 27
13.3.5.
14.3.5. Receipt of Reply message in response to a Reply, Request,
Confirm, Renew or Rebind message . . . . . 28
13.3.6.
14.3.6. Creation and sending of Release messages . . . . 30
13.3.7. 29
14.3.7. Time out and retransmission of Release Messages . 30
13.3.8.
14.3.8. Receipt of Reply message in response to a Release
message . . . . . . . . . . . . . . . . . 30
14.3.9. Creation and sending of Decline messages . . . . 30
13.3.9.
14.3.10. Time out and retransmission of Decline Messages . 31
13.3.10.
14.3.11. Receipt of Reply message in response to a Release
message . . . . . . . . . . . . . . . . . 31
13.4.
14.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31
13.4.1.
14.4.1. Receipt of Request messages . . . . . . . . . . . 32
13.4.2.
14.4.2. Receipt of Confirm messages . . . . . . . . . . . 32
13.4.3.
14.4.3. Receipt of Renew messages . . . . . . . . . . . . 33
13.4.4.
14.4.4. Receipt of Rebind messages . . . . . . . . . . . 34
13.4.5.
14.4.5. Receipt of Release messages . . . . . . . . . . . 35
13.4.6.
14.4.6. Sending of Reply messages . . . . . . . . . . . . 35

14. 36

15. DHCP Server-Initiated Configuration Exchange 36
14.1.
15.1. Reconfigure-init Message Validation . . . . . . . . . . . 36
14.2.
15.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 36
14.2.1.
15.2.1. Creation and sending of Reconfigure-init messages 36
14.2.2.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page iii]

Internet Draft DHCP for IPv6 30 June 2001

15.2.2. Time out and retransmission of unicast Reconfigure-init
messages . . . . . . . . 37
14.2.3. Time out and retransmission of multicast
Reconfigure-init messages . . . . . . . . 38
14.2.4. . 37
15.2.3. Receipt of Request messages . . . . . . . . . . . 38

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page iii]

Internet Draft DHCP for IPv6 15 April 2001

14.3. 37
15.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 38
14.3.1.
15.3.1. Receipt of Reconfigure-init messages . . . . . . 38
14.3.2.
15.3.2. Creation and sending of Request messages . . . . 38
14.3.3. 39
15.3.3. Time out and retransmission of Request messages . 39
14.3.4.
15.3.4. Receipt of Reply messages . . . . . . . . . . . . 39

15.

16. Relay Behavior 39
15.1.
16.1. Relaying of client messages . . . . . . . . . . . . . . . 39
15.2.
16.2. Relaying of server messages . . . . . . . . . . . . . . . 40

16.

17. Authentication of DHCP options messages 40
16.1. Format of
17.1. DHCP options threat model . . . . . . . . . . . . . . . . . 40
16.2. Identity association option . . . 40
17.2. Summary of DHCP authentication . . . . . . . . . . . . . 41
16.3. Option request option
17.3. Replay detection . . . . . . . . . . . . . . . . . . 43
16.4. Client message option . . 41
17.4. Configuration token protocol . . . . . . . . . . . . . . 42
17.5. Delayed authentication protocol . . . . . 43
16.5. Server message option . . . . . . . . 42
17.5.1. Management issues in the delayed authentication
protocol . . . . . . . . . . . 44
16.6. Retransmission parameter option . . . . . . 42
17.5.2. Use of the Authentication option in the delayed
authentication protocol . . . . . . . . 44
16.7. Reconfigure-delay option . 43
17.5.3. Message validation . . . . . . . . . . . . . . . 44
16.8. DSTM Global IPv4 Address Option
17.5.4. Key utilization . . . . . . . . . . . . . . . . 45
16.9. Authentication option . 44
17.5.5. Client considerations for delayed authentication
protocol . . . . . . . . . . . . . . . . . 46

17. DHCP Client Implementor Notes 46
17.1. Primary Interface 44
17.5.6. Receiving Advertise messages . . . . . . . . . . 45
17.5.7. Server considerations for delayed authentication
protocol . . . . . . . . . . . . . . . 46
17.2. Advertise Message and Configuration Parameter Caching . . 46
17.3. Time out and retransmission variables

18. DHCP options 46
18.1. Format of DHCP options . . . . . . . . . . 47
17.4. Server Preference . . . . . . . 47
18.2. DHCP unique identifier option . . . . . . . . . . . . . . 47

18. DHCP Server Implementor Notes 47
18.1. Client Bindings
18.3. Identity association option . . . . . . . . . . . . . . . 47
18.4. Option request option . . . . . . 47
18.2. Reconfigure-init Considerations . . . . . . . . . . . . 50
18.5. Client message option . 47
18.2.1. Reliable transmission of multicast Reconfigure-init
messages . . . . . . . . . . . . . . . . . 48
18.3. 50
18.6. Server Preference message option . . . . . . . . . . . . . . . . . . 51
18.7. Retransmission parameter option . . 48
18.4. Request Message Transaction-ID Cache . . . . . . . . . . 48

19. DHCP Relay Implementor Notes 48

20. Open Issues for Working Group Discussion 49
20.1. Authentication . 51
18.8. DSTM Global IPv4 Address Option . . . . . . . . . . . . . 51
18.9. Authentication option . . . . . . . 49
20.2. Identification of IAs by servers . . . . . . . . . . . 52
18.10. Server unicast option . 49
20.3. DHCP-DNS interaction . . . . . . . . . . . . . . . . . 53
18.11. Domain Search Option . 49
20.4. Temporary addresses . . . . . . . . . . . . . . . . . 53
18.12. Domain Name Server Option . . 49
20.5. Use of term "agent" . . . . . . . . . . . . . . 54

19. DHCP Client Implementor Notes 55
19.1. Primary Interface . . . . . 49
20.6. Client behavior when response to Rebind is not received . 49
20.7. Additional options . . . . . . . . . . . . . . 55
19.2. Advertise Message and Configuration Parameter Caching . . 55
19.3. Time out and retransmission variables . . . 50
20.8. Operational parameters . . . . . . . 55
19.4. Server Preference . . . . . . . . . . 50

21. Security 50

22. Year 2000 considerations 50

23. IANA Considerations 50

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page iv]

Internet Draft . . . . . . . . . . 56

20. DHCP for IPv6 15 April 2001

24. Acknowledgments 51

A. Comparison between DHCPv4 and DHCPv6 51

B. Full Copyright Statement 53

C. Changes in this draft 53
C.1. New messages for confirming addresses and extending the lease
on an IA Server Implementor Notes 56
20.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 56

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page iv]

Internet Draft DHCP for IPv6 30 June 2001

20.2. Reconfigure-init Considerations . . 54
C.2. New message formats . . . . . . . . . . . 56
20.3. Server Preference . . . . . . . . 54
C.3. Renamed Server-forward message . . . . . . . . . . . . 56
20.4. Request Message Transaction-ID Cache . 54
C.4. Clarified relay forwarding of messages . . . . . . . . . 54
C.5. Addresses and 57

21. DHCP Relay Implementor Notes 57

22. Security 57

23. Year 2000 considerations 57

24. IANA Considerations 57
24.1. DHCPv6 options in Advertise messages . . . . . . . 54
C.6. Clarification of IA option format . . . . . . . . . . . . 54
C.7. Specification of transaction ID in Solicit message . . 57
24.2. Multicast addresses . 54
C.8. Edits to definitions . . . . . . . . . . . . . . . . . . 55
C.9. Relay agent messages 58
24.3. Status codes . . . . . . . . . . . . . . . . . . 55
C.10. Relay agent behavior . . . . 58
24.4. Retransmission parameter option . . . . . . . . . . . . . 58
24.5. Authentication option . 55
C.11. Transmission of all client messages through relays . . . 55
C.12. Reconfigure-init messages . . . . . . . . . . . . . . 58

25. Acknowledgments 59

A. Comparison between DHCPv4 and DHCPv6 59

B. Full Copyright Statement 61

C. Changes in this draft 61
C.1. Reconfigure-init . . 55
C.13. Ordering of sections . . . . . . . . . . . . . . . . . . 55
C.14. DSTM option 62
C.2. Authentication . . . . . . . . . . . . . . . . . . . . . 62
C.3. Confirm message . . . . . 55
C.15. Message and option numbering . . . . . . . . . . . . . . 55
C.16. Inclusion . . 62
C.4. Failure of IAs Rebind message . . . . . . . . . . . . . . . . 63
C.5. Server behavior in Solicit response to Release message by client . . . . . 63
C.6. Client behavior when sending a Release message . 56
C.17. Clarification of destination of client messages . . . . 63
C.7. IA option . 56
C.18. Clarification of client use of Confirm messages . . . . . 56 . . . . . . . . . . . . . . . . . . 63
C.8. DSTM option . . . . . . . . . . . . . . . . . . . . . . . 63
C.9. Server unicast option . . . . . . . . . . . . . . . . . . 64
C.10. Domain search option . . . . . . . . . . . . . . . . . . 64
C.11. DNS servers option . . . . . . . . . . . . . . . . . . . 64
C.12. DUID and IAID . . . . . . . . . . . . . . . . . . . . . . 64
C.13. Continuing to poll with Solicit . . . . . . . . . . . . . 64
C.14. Using DHCPv6 without address assignment . . . . . . . . . 64
C.15. Potential crossing in flight of Request and Reconfigure-init
messages . . . . . . . . . . . . . . . . . . . . . . . 64

D. Open Issues for Working Group Discussion 64
D.1. Generation and use of DUID and IAID . . . . . . . . . . . 65
D.2. Address registration . . . . . . . . . . . . . . . . . . 65
D.3. Prefix advertisement . . . . . . . . . . . . . . . . . . 65
D.4. DHCP-DNS interaction . . . . . . . . . . . . . . . . . . 65
D.5. Use of term "agent" . . . . . . . . . . . . . . . . . . . 65
D.6. Additional options . . . . . . . . . . . . . . . . . . . 65
D.7. Operational parameters . . . . . . . . . . . . . . . . . 65

Chair's Address 58

Author's 68

Author's Address 68

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

Internet Draft DHCP for IPv6 30 June 2001

1. Introduction

This document describes DHCP for IPv6 (DHCP), a UDP [18]
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 Stateless
Autoconfiguration" [20]. 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" defined to
carry this information.

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

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 [3].

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

3. Background

Related work in IPv6 that would best serve an implementor to study
is the IPv6 Specification [6], the IPv6 Addressing Architecture [9],
IPv6 Stateless Address Autoconfiguration [20], IPv6 Neighbor
Discovery Processing [16], and Dynamic Updates to DNS [22]. These
specifications enable DHCP to build upon the IPv6 work to provide

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

Internet Draft DHCP for IPv6 30 June 2001

both robust stateful autoconfiguration and autoregistration of DNS
Host Names.

The IPv6 Specification provides the base architecture and design of
IPv6. A key point for DHCP implementors to understand is that IPv6
requires that every link in the Internet have an MTU of 1280 octets
or greater (in IPv4 the requirement is 68 octets). This means that
a UDP packet of 536 octets will always pass through an internetwork
(less 40 octets for the IPv6 header), as long as there are no IP
options prior to the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a
packet greater than 1500 octets it can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [11]
to determine the size of the packet that will traverse a network
path.

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

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

The IPv6 Addressing Architecture specification [9] defines the
address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin
communications to discover neighbors on the link. For instance, a
client can send a Solicit message and locate a server or relay.

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

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

Dynamic Updates to DNS [22] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space to

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page v] 2]

Internet Draft DHCP for IPv6 15 April 30 June 2001

1. Introduction

This document describes

not only support autoconfiguration, but also autoregistration in
IPv6.

4. Design Goals

- DHCP for IPv6 (DHCP), is a UDP [12]
client/server protocol designed to reduce mechanism rather than a policy. Network administrators
set their administrative policies through the cost of management
of IPv6 nodes configuration
parameters they place upon the DHCP servers in environments where network managers require more
control over the allocation DHCP domain
they're managing. DHCP is simply used to deliver parameters
according to that policy to each of the DHCP clients within the
domain.

- DHCP is compatible with IPv6 addresses and stateless autoconf [20].

- DHCP does not require manual configuration of network stack parameters than that offered by "IPv6 Stateless
Autoconfiguration" [13].
on DHCP clients, except in cases where such configuration is
needed for security reasons. A node configuring itself using
DHCP should require no user intervention.

- DHCP does not require a 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 server on each link. To allow for scale
and management of network nodes. economy, 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, must work across DHCP relays.

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

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

- DHCP servers, rather than distributing such
information in local configuration files among each will provide the ability to renumber network(s) when
required by network node. administrators [4].

- A DHCP is designed to be easily extended to carry new client can make multiple, different requests for
configuration parameters through when necessary from one or more DHCP
servers at any time.

- DHCP will contain the addition 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 new a DHCP "options" defined server to
carry this information.

Those readers familiar with server protocol.

- How a DHCP for IPv4 [6] will find server stores its DHCP for IPv6
provides data.

- How to manage a superset of features, and benefits from the additional
features DHCP domain or DHCP server.

- How a DHCP relay is configured or what sort of IPv6 and freedom from BOOTP [4]-backward compatibility
constraints. For more information about the differences between it may
log.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 3]

Internet Draft DHCP for IPv6 30 June 2001

6. Terminology

6.1. IPv6 Terminology

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

address An IP layer identifier 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 also makes use an interface or
a set of internal conceptual variables interfaces.

unicast address An identifier for a single interface.
A packet sent to describe protocol behavior and external variables a unicast address is
delivered to the interface identified by
that an
implementation must allow system administrators address.

multicast address An identifier for a set of interfaces
(typically belonging to change. different nodes).
A packet sent to a multicast address is
delivered to all interfaces identified by
that address.

host Any node that is not a router.

IP Internet Protocol Version 6 (IPv6). The
specific variable names, how their values change,
terms IPv4 and how their
settings influence protocol behavior IPv6 are provided to demonstrate
protocol behavior. An implementation used only in
contexts where it is not required necessary to have them in avoid
ambiguity.

interface A node's attachment to a link.

link A communication facility or medium over
which nodes can communicate at the exact form described here, so long 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 its external behavior is
consistent with that described in this document.

3. Background

Related work in
tunnels over IPv4 or IPv6 that would best serve itself.

link-layer identifier A link-layer identifier for an implementor to study
is the IPv6 Specification [5], the IPv6 Addressing Architecture [7],
IPv6 Stateless Address Autoconfiguration [13], IPv6 Neighbor
Discovery Processing [10], interface.
Examples include IEEE 802 addresses for
Ethernet or Token Ring network interfaces,
and Dynamic Updates E.164 addresses for ISDN links.

link-local address An IP address having link-only
scope, indicated by having the prefix
(FE80::0000/64), that can be used to DNS [15]. These
specifications enable DHCP reach
neighboring nodes attached to build upon the IPv6 work to provide same
link. Every interface has a link-local
address.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 1] 4]

Internet Draft DHCP for IPv6 15 April 30 June 2001

both robust stateful autoconfiguration and autoregistration

message A unit of DNS
Host Names.

The IPv6 Specification provides the base architecture data carried in a packet,
exchanged between DHCP agents and design of
IPv6. clients.

neighbor A key point for DHCP implementors node attached to understand is that IPv6
requires that every link in the Internet have an MTU of 1280 octets
or greater (in IPv4 the requirement is 68 octets). This means same link.

node A device that
a UDP implements IP.

packet An IP header plus payload.

prefix The initial bits of 536 octets will always pass through an internetwork
(less 40 octets for the IPv6 header), as long as there are no address, or a set
of IP
options prior to address that share the UDP header same initial
bits.

prefix length The number of bits in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a prefix.

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

6.2. DHCP implementation needs Terminology

Terminology specific to send a
packet greater than 1500 octets it DHCP can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [8] be found below.

abort status A status value returned to determine the size of the packet
application that will traverse has invoked a network
path. DHCP clients use Path MTU discovery when they have an
client operation, indicating anything
other than success.

agent address The address of
sufficient scope to reach the DHCP server. If a neighboring DHCP client does not
have such an address, that client MUST fragment its packets if Agent
on the
resultant message size is greater than same link as the minimum 1280 octets.

Path MTU Discovery for IPv6 DHCP client.

binding A binding (or, client binding) is supported for both UDP and TCP and
can cause end-to-end fragmentation when the PMTU changes for a
destination.

The IPv6 Addressing Architecture specification [7] defines
group of server data records containing
the
address scope that can be used server's information about the
addresses in an IPv6 implementation, IA and the
various any other
configuration architecture guidelines for network designers
of information assigned to
the IPv6 address space. Two advantages of IPv6 are that support
for multicast client. A binding is required, indexed by the
tuple <DUID, IAID>.

DHCP Dynamic Host Configuration Protocol
for IPv6. The terms DHCPv4 and nodes can create link-local addresses
during initialization. This means that a client can immediately use
its link-local address DHCPv6
are used only in contexts where it is
necessary to avoid ambiguity.

configuration parameter An element of the configuration
information set on the server and a well-known multicast address to begin
communications
delivered to discover neighbors on the link. For instance, a client can send using DHCP.
Such parameters may be used to carry
information to be used by a Solicit message node to
configure its network subsystem and locate
enable communication on a server link or relay.
internetwork, for example.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 5]

Internet Draft DHCP for IPv6 Stateless Address Autoconfiguration [13] (Addrconf) specifies
procedures 30 June 2001

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

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

DHCP server (or server) A server is a node that responds to
requests from clients, and may autoconfigure addresses based or
may not be on
router advertisements [10], and the use of a valid lifetime same link as the
client(s).

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

DHCP agent (or agent) Either a DHCP server on the
protocol interaction by which same link as
a node begins stateless client, or stateful
autoconfiguration is specified. a DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with addrconf is relay.

DUID A DHCP unique identifier for a design
requirement client.

Identity association (IA) A collection of DHCP (see Section 4).

IPv6 Neighbor Discovery [10] is addresses assigned to
a client. Each IA has an associated
IAID. An IA may have 0 or more addresses
associated with it.

Identity association identifier (IAID) An identifier for an IA,
chosen by the node discovery protocol in IPv6 client. Each IA has an
IAID, which replaces and enhances functions of ARP [11]. To understand
IPv6 and Addrconf it is strongly recommended chosen to be unique among
all IAIDs for IAs belonging to that implementors
understand IPv6 Neighbor Discovery.

Dynamic Updates
client.

transaction-ID An unsigned integer to DNS [15] is match responses
with replies initiated either by a specification that supports the
dynamic update of DNS records for both IPv4
client or server.

7. DHCP Constants

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

7.1. Multicast Addresses

DHCP can makes use of the dynamic updates to DNS to integrate addresses and name space following multicast addresses:

All DHCP Agents address: FF02::1:2 This link-scoped multicast
address is used by clients to communicate with the
on-link agent(s) when they do not know those agents'

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 2] 6]

Internet Draft DHCP for IPv6 15 April 30 June 2001

not only support autoconfiguration, but also autoregistration in
IPv6.

4. Design Goals

link-local address(es). All agents (servers and
relays) are members of this multicast group.

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

7.2. UDP ports

DHCP uses the following destination UDP [18] port numbers. While
source ports MAY be arbitrary, client implementations SHOULD permit
their administrative policies specification through the a local configuration
parameters they place upon parameter to
facilitate the use of DHCP through firewalls.

546 Client port. Used by servers in as the DHCP domain
they're managing. DHCP is simply used to deliver parameters
according destination port
for messages sent to that policy clients and relays. Used by relay
agents as the destination port for messages sent to each of
clients.

547 Agent port. Used as the DHCP destination port by clients within
for messages sent to agents. Used as the
domain.

- destination
port by relays for messages sent to servers.

7.3. DHCP is compatible with IPv6 stateless autoconf [13].

- message types

DHCP does not require manual configuration of network parameters defines the following message types. More detail on DHCP clients, except these
message types can be found in cases where such configuration is
needed Section 9. Message types 0 and
TBD--255 are reserved and MUST be silently ignored. The message code
for security reasons. A node configuring itself using
DHCP should require no user intervention.

- DHCP does not require a server on each link. To allow for scale
and economy, DHCP must work across message type is shown with the message name.

SOLICIT (1) The DHCP relays.

- Solicit (or Solicit) message is used
by clients to locate servers.

ADVERTISE (2) The DHCP coexists with statically configured, non-participating nodes
and with existing network protocol implementations.

- Advertise (or Advertise) message is
used by servers responding to Solicits.

REQUEST (3) The DHCP Request (or Request) 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 request configuration
parameters when necessary from one or more DHCP
servers at any time.

- servers.

CONFIRM (4) The DHCP will contain Confirm (or Confirm) message is used
by clients to confirm that the appropriate time out and retransmission
mechanisms addresses
assigned to efficiently operate in environments with high
latency an IA and low bandwidth characteristics.

5. Non-Goals

This specification explicitly does not cover the following:

- Specification of a DHCP server to server protocol.

- How a DHCP server stores its DHCP data.

- How to manage a DHCP domain or DHCP server.

- How a DHCP relay is configured or what sort of information it may
log. lifetimes for
those addresses, as well as the current

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 3] 7]

Internet Draft DHCP for IPv6 15 April 30 June 2001

6. Terminology

6.1. IPv6 Terminology

IPv6 terminology relevant

configuration parameters assigned by the
server to this specification from the IPv6
Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless
Address Autoconfiguration [13] client are still valid.

RENEW (5) The DHCP Renew (or Renew) message is included below.

address An IP layer identifier for used by
clients to obtain the addresses assigned to
an interface or
a set of interfaces.

unicast address An identifier IA and the lifetimes for a single interface.
A packet sent those addresses,
as well as the current configuration
parameters assigned by the server to the
client. A client sends a unicast address is
delivered Renew message to
the interface identified by server that address.

multicast address An identifier originally assigned the IA
when the lease on an IA is about to expire.

REBIND (6) The DHCP Rebind (or Rebind) message is
used by clients to obtain the addresses
assigned to an IA and the lifetimes for a set of interfaces
(typically belonging
those addresses, as well as the current
configuration parameters assigned by the
server to different nodes). the client. A packet sent to clients sends a multicast address is
delivered
Rebind message to all interfaces identified by
that address.

host Any node that available DHCP servers
when the lease on an IA is not a router.

IP Internet Protocol Version 6 (IPv6). about to expire.

REPLY (7) The
terms IPv4 and IPv6 are used only in
contexts where it DHCP Reply (or Reply) message is necessary used
by servers responding to avoid
ambiguity.

interface A node's attachment Request, Confirm,
Renew, Rebind, Release and Decline messages.
In the case of responding to a link.

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

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

link-local address An IP address having link-only
scope, indicated by having Reply
contains configuration parameters destined
for the prefix
(FE80::0000/64), that can be client.

RELEASE (8) The DHCP Release (or Release) message is used
by clients to reach
neighboring nodes attached return one or more IP addresses
to the same
link. Every interface has a link-local
address.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 4]

Internet Draft servers.

DECLINE (9) The DHCP for IPv6 15 April 2001 Decline (or Decline) message A unit of data carried in a packet,
exchanged between DHCP agents and clients.

neighbor A node attached is used
by clients to indicate that the same link.

node A device client has
determined that implements IP.

packet An IP header plus payload.

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

prefix length The number of bits more addresses in a prefix.

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

6.2. DHCP Terminology

Terminology specific an
IA are already in use on the link to which
the client is connected.

RECONFIG-INIT (10) The DHCP can be found below.

abort status A status value returned Reconfigure-init (or
Reconfigure-init) message is sent by
server(s) to the
application inform client(s) that the
server(s) has invoked a DHCP
client operation, indicating anything
other than success.

agent address The address of new or updated configuration
parameters, and that the client(s) are to
initiate a neighboring DHCP Agent
on Request/Reply transaction with the same link as
server(s) in order to receive the updated
information.

RELAY-FORW (11) The DHCP client.

binding A binding (or, Relay-forward (or Relay-forward)
message is used by relays to forward
client binding) messages to servers. The client
message is a
group of server data records containing
the server's information about the
addresses encapsulated in an IA and any other
configuration information assigned to option in the client. A binding
Relay-forward message.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 8]

Internet Draft DHCP for IPv6 30 June 2001

RELAY-REPL (12) The DHCP Relay-reply (or Relay-reply)
message is indexed used by servers to send messages
to clients through a relay. The server
encapsulates the
tuple <prefix, DUID>, where client message as an option
in the 'prefix'
is a prefix assigned to Relay-reply message, which the link relay
extracts and forwards to
which the client.

7.4. Error Values

This section describes error values exchanged between DHCP
implementations.

7.4.1. Generic Error Values

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

DISCUSSION: 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_______________|_

7.4.2. Server-specific Error Values

The indexing of an IA following symbolic names are used by <prefix,
DUID> is still under discussion.

|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)____|_

7.5. Configuration Protocol Variables

This section presents a table of client and server configuration
variables and the default or initial values for IPv6. these variables. The terms DHCPv4
client-specific variables MAY be configured on the server and DHCPv6
are used only in contexts where it is
necessary MAY be
delivered to avoid ambiguity. the client through the "DHCP Retransmission Parameter
Option" in a Reply message.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 5] 9]

Internet Draft DHCP for IPv6 15 April 30 June 2001

configuration parameter An element

_________________________________________________________________________
|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_THRESHOLD______|100____|_%_of_required_clients____________________|_
|SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_

8. Overview

This section provides a general overview of the configuration
information set on the server and
delivered to interaction between
the client using functional entities of DHCP.
Such parameters may be used to carry
information to The overview is organized as a
series of questions and answers. Details of DHCP such as message
formats and retransmissions can be used by found in later sections of this
document.

8.1. How does a node know to
configure its network subsystem and
enable communication on a link or
internetwork, for example.

DHCP client (or client) A use DHCP?

An unconfigured node determines that initiates requests on a link it is to obtain configuration parameters from
one or more DHCP servers. use DHCP domain A set for
configuration of links managed by DHCP and
operated an interface by a single administrative
entity.

DHCP server detecting the presence (or server) A server is a absence)
of routers on the link. If router(s) are present, the node that responds examines
router advertisements to
requests from clients, 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. Details of
this process can be found in neighbor discovery [16] and may stateless
autoconfiguration [20].

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

Use of DHCP in such environments requires one or
may not more DHCP relays
be set up on the same link as client's link, because a client may only have a
link-local address. Relays receive messages from the client and
forward them to some set of servers within the
client(s). DHCP relay (or relay) A node that acts domain. The
client message is forwarded verbatim as an intermediary option in the message
from the relay to
deliver DHCP messages between clients
and servers, and is on the same link as
a client.

DHCP agent (or agent) Either a DHCP server server. A relay will include one of its own
addresses (of sufficient scope) from the interface on the same link
as
a the client, or a DHCP relay.

DUID A DHCP unique identifier for a client.

DISCUSSION:

Rules for choosing a DUID are TBD.

Identity association (IA) A collection as well as the prefix length of addresses assigned that address, in its
message to
a client. Each IA has an associated
DUID. An IA may have 0 or more addresses
associated with it.

transaction-ID An unsigned integer the server. Servers receiving the forwarded traffic
use this information to match responses
with replies initiated either by a aid in selecting configuration parameters
appropriate to the client's link.

Servers use relays to forward messages to clients. The message
intended for the client or server.

7. DHCP Constants

This section describes various program and networking constants used
by DHCP. is carried as an option in the message to the

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 6] 10]

Internet Draft DHCP for IPv6 15 April 30 June 2001

7.1. Multicast Addresses

DHCP makes

relay. The relay extracts the message from the option and forwards
it to the client. Servers use of the following multicast addresses:

All DHCP Agents address: FF02::1:2 This link-scoped multicast relay's address is used by clients as the destination
to communicate with forward client-destined messages for final delivery by the
on-link agent(s) when they do not know those agents'
link-local address(es). All agents (servers and
relays) are members relay.

Relays forward client messages to servers using some combination
of this multicast group. the All DHCP Servers address: FF05::1:3 This site-scoped site-local multicast
address is used by clients 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 to communicate MUST be configured with server(s), either because they want to send
messages global addresses for the client's
link so as to all be reachable by servers outside the relays' site-local
environment.

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 (the server is
on the same link as the client) or because they do not know indirectly (through the server(s) unicast address(es). on-link
relay). The client MAY include a Option Request Option 18.4 (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
for 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 use this address, request additional information as
it must have an
address of sufficient scope to be reachable 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
server(s). All client. The Reply MAY
also include additional information.

8.4. How do clients and servers within the site are members of
this multicast group.

DISCUSSION:

Is there a requirement for identify and manage addresses?

Servers and clients manage addresses in groups called "identity
associations." Each identity association (IA) is identified using
a site-scoped "All unique identifier. An identity association may contain one or
more IPv6 addresses. DHCP Clients"
multicast address, servers assign addresses to be used as the default in sending
Reconfigure messages.

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

546 Client port. Used by servers as the destination port
for messages sent addresses in an identity
association to clients 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 relays. Used by relay
agents as valid lifetime. Over
time, the destination port for messages sent to
clients.

547 Agent port. Used as server may change the characteristics of the destination port by clients addresses in
an IA; for messages sent to agents. Used as the destination
port example, by relays for messages sent to servers.

7.3. DHCP message types

DHCP defines changing 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 preferred or valid lifetime for each message type is shown with
an address in the message name.

SOLICIT (1) IA. The DHCP Solicit (or Solicit) message is used by
clients server may also add or delete addresses
from an IA; for example, deleting old addresses and adding new
addresses to locate servers. renumber a client. A client can request the current

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 7] 11]

Internet Draft DHCP for IPv6 15 April 30 June 2001

ADVERTISE (2) The DHCP Advertise (or Advertise) message is used
by servers responding to Solicits.

REQUEST (3) The DHCP Request (or Request) message is used by
clients

list of addresses assigned to request configuration parameters an IA from
servers.

CONFIRM (4) a server through an exchange
of protocol messages.

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 DHCP Confirm (or Confirm) message is used 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 7.5), the client can abandon the Release attempt. In this
case, the address(es) in the IA will be reclaimed by
clients to confirm that the server(s)
when the lifetimes on the addresses expire.

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

If the lifetimes for those addresses,
as well as client determines through a mechanism like Duplicate Address
Detection [20] that the current configuration parameters address it was assigned by the server to is
already in use by another client, the client are still
valid.

RENEW (5) The DHCP Renew (or Renew) will send a Decline
message is used by
clients to obtain the addresses assigned server.

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 an IA
and request additional
configuration information/extend the lifetimes for those addresses, as well lifetime on an address. or
through a server-initiated event known as a reconfigure event.

The reconfiguration feature of DHCP offers network administrators
the current opportunity to update configuration parameters assigned by information on DHCP clients
whenever necessary. To signal the need for client reconfiguration,
the server will unicast a Reconfigure-init message to the client. A each client sends
individually. A Reconfigure-init is a trigger which will cause the
client(s) to initiate a standard Request/Reply exchange with the
server in order to acquire the new or updated addresses.

9. Message Formats

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 described for every message and fields that are not used in a Renew
message to the server that originally assigned are marked as "unused". All unused fields in a message MUST
be transmitted as zeroes and ignored by the
IA when receiver of the lease on an IA is about to expire.

REBIND (6) message.

The DHCP Rebind (or Rebind) message is used by
clients to obtain the addresses assigned to an IA
and the lifetimes header:

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 12]

Internet Draft DHCP for those addresses, as well
as the current configuration parameters assigned IPv6 30 June 2001

9.1. DHCP Solicit Message Format

msg-type SOLICIT

preference (unused) MUST be 0

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

client-link-local-address The link-local address of the client. A clients sends a
Rebind message to all available DHCP servers when
interface for which the lease on an IA client is about to expire.

REPLY (7) The
using DHCP.

server-address (unused) MUST be 0

options See section 18.

9.2. DHCP Reply (or Reply) message is used by
servers responding Advertise Message Format

msg-type ADVERTISE

preference An unsigned integer indicating a
server's willingness to Request, Confirm, Renew,
Rebind, Release and Decline messages. In the case
of responding provide
service to a Request, Confirm, Renew or
Rebind message, the Reply contains configuration
parameters destined for the client.

RELEASE (8) The

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 13]

Internet Draft DHCP Release (or Release) message is for IPv6 30 June 2001

transaction-ID An unsigned integer used by
clients to return one or more identify
this Advertise message. Copied from
the client's Solicit message.

client-link-local-address The IP addresses to
servers.

DECLINE (9) link-local address of the
client interface from which the client
issued the Solicit message.

server-address The IP address of the server that
generated this message. If the DHCP Decline (or Decline) message is used
domain crosses site boundaries, then
this address MUST be globally-scoped.

options See section 18.

9.3. DHCP Request Message Format

msg-type REQUEST

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by
clients to indicate that the
client has determined
that one or more addresses in an IA are already in
use on the link used to identify this Request
message.

client-link-local-address The link-local address of the client
interface from which the client is connected.

RECONFIG (10) will
issue the Request message.

server-address The DHCP Reconfigure-init (or Reconfigure-init) IP address of the server to which
the this message is sent directed, copied
from an Advertise message.

options See section 18.

9.4. DHCP Confirm Message Format

msg-type CONFIRM

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by server(s) to inform
client(s) that the server(s) has new or updated
configuration parameters, and that
client used to identify this Confirm
message.

client-link-local-address The link-local address of the client(s)
are to initiate a Request/Reply transaction with client
interface from which the server(s) in order to receive client will
issue the updated
information. Confirm message.

server-address MUST be zero.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 8] 14]

Internet Draft DHCP for IPv6 15 April 30 June 2001

RELAY-FORW (11) The

options See section 18.

9.5. DHCP Relay-forward (or Relay-forward) message
is used Renew Message Format

msg-type RENEW

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by relays to forward the
client messages used to
servers. identify this Renew
message.

client-link-local-address The link-local address of the client message is encapsulated in an
option in
interface from which the Relay-forward client will
issue the Renew message.

RELAY-REPL (12)

server-address The DHCP Relay-reply (or Relay-reply) IP address of the server to which
this Renew message is used by servers to send messages to clients
through a relay. The server encapsulates directed, which
MUST be the
client message as an option in address of the Relay-reply
message, server from
which the relay extracts and forwards to
the client.

7.4. Error Values

This IAs in this message were
originally assigned.

options See section describes error values exchanged between 18.

9.6. DHCP
implementations.

7.4.1. Generic Error Values

The following symbolic names are used between Rebind Message Format

msg-type REBIND

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by the
client and server
implementations 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.

7.4.2. Server-specific Error Values identify this Rebind
message.

client-link-local-address The following symbolic names are used by server implementations link-local address of the client
interface from which the client will
issue the Rebind message.

server-address MUST be zero.

options See section 18.

9.7. DHCP Reply Message Format

msg-type REPLY

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 9] 15]

Internet Draft DHCP for IPv6 15 April 30 June 2001

7.5. Configuration Variables

This section presents a table of client and server configuration
variables and

transaction-ID An unsigned integer used to identify
this Reply message. Copied from the default
client's Request, Confirm, Renew or initial values
Rebind message.

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

server-address The
client-specific variables MAY IP address of the server.
If the DHCP domain crosses site
boundaries, then this address MUST be configured on
globally-scoped.

options See section 18.

9.8. DHCP Release Message Format

msg-type RELEASE

preference (unused) MUST be 0

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

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

server-address The IP address of the server and MAY that
assigned the IA.

options See section 18.

9.9. DHCP Decline Message Format

msg-type DECLINE

preference (unused) MUST be
delivered 0

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

client-link-local-address The client's link-local address for
the interface from which the client through
will send the "DHCP Retransmission Parameter
Option" in a Reply Decline 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

server-address The IP address of the interaction between server that
assigned the functional entities of DHCP. addresses.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 16]

Internet Draft DHCP for IPv6 30 June 2001

options See section 18.

9.10. DHCP Reconfigure-init Message Format

msg-type RECONFIG-INIT

preference (unused) MUST be 0

transaction-ID (unused) MUST be 0

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

server-address The overview is organized as a
series of questions and answers. Details IP address of the DHCP such as message
formats and retransmissions can server
issuing the Reconfigure-init message.
MUST be found in later sections of this
document.

8.1. How does a node know sufficient scope to use DHCP?

An unconfigured node determines be
reachable by all clients.

options See section 18.

10. Relay messages

Relay agents exchange messages with servers to forward messages
between clients and servers that it is are not connected to use DHCP for
configuration of an interface by detecting the presence (or absence)
of routers on the same link. If router(s) are present,

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 | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| relay-address |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type RELAY-FORW

prefix-length The length of the node examines
router advertisements to determine if DHCP should be used to
configure prefix in the interface. If there are no routers present, then address in the node MUST use DHCP
"relay-address" field.

relay-address An address assigned to configure the interface. Detail on
this process can be found in neighbor discovery [10] and stateless
autoconfiguration [13].

8.2. 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 interface through which
the client's link, because a client may only have a
link-local address. Relays receive messages message from the client and
forward them to some set of servers within the DHCP domain. The was received.

options MUST include a "Client message option"; see
section 18.5.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 10] 17]

Internet Draft DHCP for IPv6 15 April 30 June 2001

client

10.2. Relay-reply message is forwarded verbatim as an option in

msg-type RELAY-REPL

prefix-length The length of the message
from prefix in the relay to address in the server. A relay will include one of its own
addresses (of sufficient scope) from
"relay-address" field.

relay-address An address identifying the interface on the same link
as the client, as well as through which
the prefix length of that address, in its message to from the server. Servers receiving server should be forwarded;
copied from the forwarded traffic "relay-forward" message.

options MUST include a "Server message option"; see
section 18.6.

11. DHCP unique identifier (DUID)

Each DHCP client has a DUID. DHCP servers use this information DUIDs to aid in selecting identify
clients for the selection of configuration parameters
appropriate to and in
the client's link.

Servers use relays to forward messages to association of IAs with clients. The message
intended See section 18.2 for the client
representation of a DUID in a DHCP message.

DISCUSSION:

The syntax, rules for selecting and requirements for gloabl
uniqueness in DUIDs are TBD.

The DUID is carried as in an option in the message to the
relay. The relay extracts the message from the optin because it may be variable
length and forwards because it
to the client. Servers use the relay's address as the destination to
forward client-destined is not required in all DHCP options
(e.g., messages for final delivery sent by the relay.

Relays forward client messages to servers using some combination need not include a DUID).

12. Identity association

An "identity-association" (IA) is a construct through which a server
and a client can identify, group and manage IPv6 addresses. Each IA
consists of the All DHCP Servers site-local multicast address, some other
(perhaps an IAID and a combination) list of site-local multicast associated IPv6 addresses set up
within the (the list
may be empty). A client associates an IA with one of its interfaces

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 18]

Internet Draft DHCP domain to include for IPv6 30 June 2001

and uses the servers in IA to obtain IPv6 addresses for that domain, or interface from a
list of unicast addresses
server.

See section 18.3 for servers. The network administrator
makes relay configuration decisions based upon the topological
requirements (scope) representation of the an IA in a DHCP domain they are managing. Note
that if the message.

13. 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.3. How does Server Solicitation

This section describes how a client request configuration parameters from servers?

To request configuration parameters, the locates servers. The behavior
of client forms a Request
message, and sends it to the server either directly (the server implementations is
on discussed, along with the same link as
messages they use.

13.1. Solicit Message Validation

Clients MUST silently discard any received Solicit messages.

Agents MUST silently discard any received Solicit messages if the client) or indirectly (through
"client-link-local-address" field does not contain a valid link-local
address.

13.2. Advertise Message Validation

Servers MUST discard any received Advertise messages.

Clients MUST discard any Advertise messages that meet any of the on-link
relay).
following criteria:

o The client MAY include a Option Request Option 16.3 (ORO)
along with other options to request specific information from "Transaction-ID" field value does not match the
server. Note that value 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) used in
order to satisfy its needs. As a client's needs may change over time
(perhaps based Solicit message.

o The "client-link-local-address" field value does not match the
link-local address of the interface upon an application's requirements), which the client may
form additional Request messages sent
the Solicit message.

13.3. Client Behavior

Clients use the Solicit message to request additional information as
it is needed.

The server(s) respond with Reply messages containing discover DHCP servers configured
to serve addresses on the requested
configuration parameters, link to which can include status information
regarding the information requested by client is attached.

13.3.1. Creation and sending of the client. Solicit message

The Reply MAY
also include additional information, such as a reconfiguration event
multicast group for the client sets the "msg-type" field to join SOLICIT, and places the
link-local address of the interface it wishes to monitor reconfiguration
events, as described configure in section 8.7. the
"client-link-local-address" field.

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

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 11] 19]

Internet Draft DHCP for IPv6 15 April 30 June 2001

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

Servers and clients manage addresses in groups called "identity
associations." Each identity associations is identified using

The client includes a
unique identifier. An identity association may contain one or
more IPv6 addresses. DHCP servers assign addresses to identity
associations. DHCP clients use the addresses in an identity
association DUID option to configure interfaces. There is always at least one
identity association per interface that a client wishes identify itself 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. server.
The server may also add or delete addresses
from an IA; client MUST include options for example, deleting old addresses and adding new
addresses any IAs to renumber a client. A client can request which the current
list of addresses assigned client is
expecting to an IA from a have the server through an exchange
of protocol messages.

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

A client forms
does not have any IAs with addresses when sending a Release Solicit message, including options identifying
all of the IA to IAs MUST be released. empty. The client sends the Release to MAY include an Option
Request Option in the server
which assigned Solicit message. The client MUST NOT include
any other options except those specifically allowed as defined by
specific options.

The client sends the addresses Solicit message to the client initially. If that
server cannot All DHCP Agents
multicast address, destination port 547. The source port selection
can be reached after arbitrary, although it SHOULD be possible using a certain number of attempts (see
section 7.5), the client can abandon the Release attempt. In this
case, the address(es) in
configuration facility to set a specific source port value.

13.3.2. Time out and retransmission of Solicit Messages

The client's first Solicit message on the IA will interface MUST be reclaimed delayed
by a random amount of time between the server(s)
when interval of MIN_SOL_DELAY and
MAX_SOL_DELAY. This random delay desynchronizes clients which start
at the lifetimes on same time (e.g., after a power outage).

The client waits ADV_MSG_TIMEOUT, collecting Advertise messages.
If no Advertise messages are received, the addresses expire.

8.6. What if client retransmits
the client determines Solicit, and doubles the ADV_MSG_TIMEOUT value. This process
continues until either one or more of its assigned addresses Advertise messages are already being used by another client?

If received or
ADV_MSG_TIMEOUT reaches the client determines through a mechanism like Duplicate Address
Detection [13] that ADV_MSG_MAX value. Thereafter, Solicits
are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
made, at which time the address it was assigned by client MAY choose to stop trying to DHCP
configure the server interface. An event external to DHCP is
already in use by another client, required
to restart the DHCP configuration process. A DHCP client will form a Decline
message, including the option carrying the in-use address. The
option's status field MUST be set MAY,
alternatively, choose to continue sending Solicit messages at the value reflecting the "in
use" status of the address.

8.7. How
ADV_MSG_MAX interval.

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

13.3.3. Receipt of server configuration changes?

There are two possibilities. Either the clients discover Advertise messages

Upon receipt of one or more validated Advertise messages, the new
information when they revisit client
selects one or more Advertise messages based upon the server(s) to request additional
configuration information/extend following
criteria.

- Those Advertise messages with the lifetime on an address. or
through a server-initiated event known as highest server preference
value (see section 19.4) are preferred over all other Advertise
messages.

- Within a reconfigure event.

The reconfiguration feature group of DHCP offers network administrators
the opportunity to update configuration information on DHCP clients
whenever necessary. To signal Advertise messages with the need for same server
preference value, a client reconfiguration, MAY select those servers whose
Advertise messages advertise information of interest to
the client. For example, one server will unicast a Reconfigure-init message to each may be advertising the

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 12] 20]

Internet Draft DHCP for IPv6 15 April 30 June 2001

availability of IP addresses which have an address scope of
interest to the client.

Once a client individually. The has selected Advertise message(s), the client will
typically store information about each server, such as server may use multicast to signal
preference value, addresses advertised, when the
reconfiguration 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.

If the client needs to multiple clients simultaneously. (Note that
there is no mechanism defined select an alternate server in the protocol to guarantee case that
every a
chosen server does not respond, the client actually performs chooses the server with
the next highest preference value.

The client MAY choose a reconfiguration less-preferred server if that server has a
better set of advertised parameters, such as the available addresses
advertised in response IAs.

13.4. Server Behavior

For this discussion, the server is assumed to a
multicast reconfigure-init message.) A Reconfigure-init 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.

13.4.1. Receipt of Solicit messages

If the server receives a trigger
which will cause Solicit message, the client(s) to initiate client must be on the
same link as the server. If the server receives a standard Request/Reply
exchange with Relay-forward
message containing a Solicit message, the client must be on the server in order
link to acquire which the new or updated
addresses.

9. Message Formats

Each DHCP message has an identical fixed format header; some messages
also allow a variable format area for options. Not all prefix identified by the "relay-address" and
"prefix-length" fields in the header are used in every message. In this section, every field Relay-forward message is described for every assigned.
The server records the "relay-address" field from the Relay-forward
message and fields that are not used in a extracts the solicit message are marked as "unused". All unused fields in from the "client-message"
option.

If administrative policy permits the server to respond to a message MUST
be transmitted as zeroes client on
that link, the server will generate and ignored by send an Advertise message to
the receiver client.

13.4.2. Creation and sending of the message. Advertise messages

The DHCP message header:

9.1. DHCP Solicit Message Format

msg-type SOLICIT

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by server sets the
client used "msg-type" field to identify this ADVERTISE and copies the
values of the following fields from the client's Solicit
message. to the
Advertise message:

o transaction-ID

o client-link-local-address

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 13] 21]

Internet Draft DHCP for IPv6 15 April 30 June 2001

client-link-local-address

The link-local address server places one of its IP addresses (determined through
administrator setting) in the
interface for which "server-address" field of the client is
using DHCP.

server-address (unused) MUST be 0

options Advertise
message. The server sets the "preference" field according to its
configuration information. See section 16.

9.2. DHCP Advertise Message Format

msg-type ADVERTISE

preference An unsigned integer indicating 20.3 for a
server's willingness description of
server preference.

The server MUST include options to provide
service the Advertise message containing
any addresses that would be assigned to IAs contained in the Solicit
message from the client.

transaction-ID An unsigned integer used The server MAY include other options the
server will return to identify
this Advertise message. Copied from the client's Solicit client in a subsequent Reply message.

client-link-local-address
The IP link-local address of information in these options will be used by the client interface from which in the
selection of a server if the client
issued receives more than one Advertise
message.

If the Solicit message.

server-address 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" option. The IP server unicasts the
Relay-reply message to the address of in the server that
generated this "relay-address" field from
the Relay-forward message.

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

options See section 16.

9.3. DHCP Request Message Format

msg-type REQUEST

preference (unused) MUST be 0

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

client-link-local-address The link-local address of server, the client
interface from which
server unicasts the Advertise message directly to the client will
issue using
the Request message.

server-address "client-link-local-address" field value as the destination
address. The IP address of Advertise message MUST be unicast through the server to interface
on which the this Solicit message is directed, copied
from an Advertise message.

options See section 16.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 14]

Internet Draft DHCP for IPv6 15 April 2001

9.4. was received.

14. DHCP Confirm Message Format

msg-type CONFIRM

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by the Client-Initiated Configuration Exchange

A client used initiates a message exchange with a server or servers to identify this Confirm
message.

client-link-local-address The link-local address
acquire or update configuration information of the interest. The client
interface from which
may initiate the client will
issue configuration exchange as part of the Confirm message.

server-address MUST be zero.

options See section 16.

9.5. DHCP Renew Message Format

msg-type RENEW

preference (unused) MUST be 0

transaction-ID An unsigned integer generated operating
system configuration process or when requested to do so by the
application layer.

The client used uses the following messages to identify this Renew
message.

client-link-local-address The link-local address of initiate a configuration
event:

Request Obtain initial configuration information (from a server
identified in a previously received Advertise message)
when the client
interface has no assigned addresses

Confirm Confirm the validity of assigned addresses and other
configuration changes through the server from which the client will
issue
configuration information was obtained when the Renew message.

server-address The IP address of client's
assigned addresses may not be valid; for example, when
the server client reboots or loses its connection to which
this a link

Renew message is directed, which
MUST be Extend the address of lease on an IA through the server from
which the IAs in this message were that
originally assigned.

options See section 16.

9.6. DHCP assigned the IA

Rebind Message Format

msg-type REBIND

preference (unused) MUST be 0

transaction-ID An unsigned integer generated by Extend the
client used lease on an IA through any server willing to identify this Rebind
message.
extend the lease

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 15] 22]

Internet Draft DHCP for IPv6 15 April 30 June 2001

client-link-local-address The link-local address of the client
interface from which

Release Release the client will
issue lease on an IA and release all of the Rebind message.

server-address MUST be zero.

options See section 16.

9.7. DHCP Reply Message Format

msg-type REPLY

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

transaction-ID An unsigned integer used to identify
this Reply message. Copied from IA,

Decline Decline the
client's Request, Confirm, Renew or
Rebind message.

client-link-local-address The link-local address assignment of the
interface for which the one or more addresses in an
IA.

A client is
using DHCP.

server-address The IP address of uses the server.
If Release/Reply message exchange to indicate to the
DHCP domain crosses site
boundaries, then this address MUST be
globally-scoped.

options See section 16.

9.8. DHCP Release Message Format

msg-type RELEASE

preference (unused) MUST be 0

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

client-link-local-address The client's link-local address for will no longer be using the interface from which addresses in
the client
will send released IA.

A client uses the Release message.

server-address The IP address of Decline/Reply message exchange to indicate to the
DHCP server that the client has detected that one or more addresses
assigned by the IA.

options See section 16.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 16]

Internet Draft DHCP for IPv6 15 April 2001

9.9. DHCP Decline server is already in use on the client's link.

14.1. Client Message Format

msg-type DECLINE

preference (unused) Validation

Clients MUST be 0

transaction-ID An unsigned integer generated by the silently discard any received client used to identify this messages (Request,
Confirm, Renew, Rebind, Release or Decline
message.

client-link-local-address The client's link-local address for
the interface from messages).

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

Servers MUST discard any received client
will send messages in which the Decline message.

server-address The IP address of
"options" field contains an authentication option, and the server that
assigned
cannot successfully authenticate the client.

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

options See section 16.

9.10. DHCP Reconfigure-init

14.2. Server Message Format

preference (unused) Validation

Servers MUST be 0

transaction-ID An unsigned integer generated
by the silently discard any received server to identify this messages
(Advertise, Reply or Reconfigure-init message

client-link-local-address (unused) messages).

Clients MUST be 0

server-address discard any server messages that meet any of the
following criteria:

o The IP "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" field value in the server message
does not match the link-local address of the DHCP server
issuing interface from which
the Reconfigure-init client sent in its Request, Confirm, Renew, Rebind, Release
or Decline 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

o The server message contains an authentication option, and servers that are not connected the
client's attempt to authenticate the same link. message fails.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 17] 23]

Internet Draft DHCP for IPv6 15 April 30 June 2001

10.1. Relay-forward

Relays MUST discard any Relay-reply message

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| relay-address |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number in which the
"client-link-local-address" in the encapsulated Reply message does
not contain a valid link-local address.

14.3. Client Behavior

A client will use Request, Confirm, Renew and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type RELAY-FORW

prefix-length The length Rebind messages to
acquire and confirm the 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 constructing Request and
Renew message(s). Note that a client may request configuration
information from one or more servers at any time.

A client uses the prefix Release message in the address in management of IAs when
the
"relay-address" field.

relay-address An address assigned client has been instructed to release the IA prior to the interface through which IA
expiration time since it is no longer needed.

A client uses the Decline message from when the client was received.

options MUST include 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 "Client message option"; see
section 16.4.

10.2. Relay-reply message

14.3.1. Creation and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type RELAY-REPL

prefix-length 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 length client includes one or more IAs in the
Request message, to which the server assigns new addresses. The
server then returns IA(s) to the client in a Reply message.

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

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

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

relay-address An address identifying

The client adds a DUID option to identify itself to the interface through which server. The
client adds any other approppriate options, including one or more IA
options (if the message from client is requesting that the server should assign it some
network addresses). The list of addresses in each included IA MUST
be forwarded;
copied from empty. If the "client-forward" message. client is not requesting that the server assign it
any addresses, the client omits the IA option.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 18] 24]

Internet Draft DHCP for IPv6 15 April 30 June 2001

options MUST include a "Server

The client sends the Request message option"; see
section 16.5.

11. Identity association

An "identity-association" (IA) is to the All DHCP Agents
multicast address, destination port 547. The source port selection
can be arbitrary, although it SHOULD be possible using a construct through which 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 can identify, group MUST abort the configuration attempt. The
client SHOULD report the abort status to the application layer.

Default and manage IPv6 addresses. Each IA
consists initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
are documented in section 7.5.

14.3.2. Creation and sending of Confirm messages

Whenever a DUID and client may have moved to a list of associated new link, its IPv6 addresses (the list
may no longer 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.

See section 16.2 for the representation valid. Examples of an IA in times when a DHCP message.

12. DHCP Server Solicitation

This section describes how client may have
moved to a new link include:

o The client locates servers. reboots

o The behavior
of client and server implementations is discussed, along with the
messages they use.

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" field does not contain physically disconnected from a valid link-local
address.

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: wired connection

o The "Transaction-ID" field value does not match the value the client used in its Solicit message. returns from sleep mode

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

12.3. Client Behavior

Clients use the Solicit message to discover DHCP servers configured
to serve addresses on the link using a wireless technology changes cells

In any situation when a client may have moved to which a new link, the
client is attached.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 19]

Internet Draft DHCP for IPv6 15 April 2001

12.3.1. Creation and sending MUST initiate a Confirm/Reply message exchange. The client
includes any IAs, along with the addresses associated with those IAs,
in its Confirm message. Any responding servers will indicate the
acceptability of the Solicit message addresses with the status in the IA it returns
to the client.

The client sets the "msg-type" field to SOLICIT, CONFIRM, and places
the link-local address of the interface it wishes to configure acquire
configuration information for in the "client-link-local-address"
field.

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

The client MUST include options for any IAs to which the client is
expecting to have the server assign addresses. Because the client
does not have any IAs with addresses when sending a Solicit message,
all of the IAs MUST be empty. The client MAY include an Option
Request Option in the Solicit 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
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.

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 sets the
interface. An event external "server-address" field to DHCP is required 0.

The client adds a DUID option to identify itself 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 7.5.

12.3.3. Receipt of Advertise messages

Upon receipt of one or more validated Advertise messages, the server. The
client
selects adds any appropriate options, including one or more Advertise messages based upon IA options
(if the following
criteria.

- Those Advertise messages with client is requesting that the highest server preference
value (see section 17.4) are preferred over all other Advertise
messages. confirm the validity of
some network addresses). If the client does include any IA options,

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 20] 25]

Internet Draft DHCP for IPv6 15 April 30 June 2001

- 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

it MUST include the
availability list of IP addresses which have an address scope of
interest to the client.

Once a client currently has selected Advertise message(s), the
associated with that IA.

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 sends the client's
invoking user, Confirm message to the client MAY initiate All DHCP Agents
multicast address, destination port 547. The source port selection
can be arbitrary, although it SHOULD be possible using a configuration exchange with
the server(s) immediately, or MAY defer this exchange until later.

If the client needs
configuration facility to set a specific source port value.

Servers will respond to select an alternate server in the case that Confirm message with a
chosen server does not respond, Reply message. If
no Confirm message is received within REP_MSG_TIMEOUT milliseconds,
the client chooses retransmits the server Confirm with the next highest preference value. same transaction-ID,
and doubles the REP_MSG_TIMEOUT value, and waits again. The client MAY choose a less-preferred server if that server has a
better set of advertised parameters, such as the available addresses
advertised in IAs.

12.4. Server Behavior

For
continues this discussion, the server process until a Reply is assumed to received or QRY_MSG_ATTEMPTS
unsuccessful attempts have been configured in
an implementation specific manner. This made, at which time the client MUST
abort the configuration is assumed attempt. The client SHOULD report the abort
status to
contain all network topology information the application layer.

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

If the client receives no response to its Confirm message, it MAY
restart the configuration process by locating a DHCP domain, as well server with an
Advertise message and sending a Request to that server, as any necessary authentication information.

12.4.1. Receipt described
in section 14.3.1.

14.3.3. Creation and sending of Solicit Renew messages

If the server receives

IPv6 addresses assigned to a Solicit message, the client must be on through an IA use the same link
preferred and valid lifetimes as the server. If the IPv6 addresses obtained through
stateless autoconfiguration. The server receives a Relay-forward
message containing a Solicit message, the client must be on assigns preferred and valid
lifetimes to the
link IPv6 addresses it assigns to which an IA. To extend those
lifetimes, the prefix identified by client sends a Request to the "relay-address" server containing an
"IA option" for the IA and
"prefix-length" fields its associated addresses. The server
determines new lifetimes for the addresses in the Relay-forward message is assigned. IA according to
the server's administrative configuration. The server records may also add
new addresses to the "relay-address" field IA. The server remove addresses from the Relay-forward
message IA by
setting the preferred and extracts valid lifetimes of those addresses to zero.

The server controls the solicit message from time at which the "client-message"
option.

If administrative policy permits client contacts the server
to respond to a client extend the lifetimes on
that link, assigned addresses through the server will generate T1 and send an Advertise message
T2 parameters assigned to an IA. If the client.

12.4.2. Creation and sending of Advertise messages

The server sets does not assign an
explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the "msg-type" field
shortest preferred lifetime of any address assigned to ADVERTISE the IA and copies
T2 defaults to 0.875 times the
values shortest preferred lifetime of any
address assigned to the following fields from IA.

At time T1 for an IA, the client's Solicit client initiates a Request/Reply message
exchange to extend the
Advertise message: lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned to
the IA in its Request message. The client sends this Request message
to the All DHCP Agents multicast address.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 21] 26]

Internet Draft DHCP for IPv6 15 April 30 June 2001

o transaction-ID

o client-link-local-address

The server client sets the "msg-type" field to RENEW, 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 generates a transaction ID inserts this value in the
"transaction-ID" field.

The client places one the address of its IP addresses (determined through
administrator setting) the destination server in the
"server-address" field of field.

The client adds a DUID option to identify itself to the Advertise
message. server. The
client adds any appropriate options, including one or more IA options
(if the client is requesting that the server sets extend the "preference" field according to its lease on some
IAs; note that the client may check the status of other configuration information. See section 18.3
parameters without asking for a description of
server preference.

The server lease extensions). If the client does
include any IA options, it MUST include options to the Advertise message containing
any list of addresses the
client currently has associated with that would be assigned to IAs contained in IA.

The client sends the Solicit Renew message from to the client. 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 MAY include other options the server will return respond to the client in Renew message with a subsequent Reply message.
If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Renew with the same transaction-ID, and
doubles the REP_MSG_TIMEOUT value, and waits again. The information client
continues this process until a Reply is received or until time T2 is
reached (see section 14.3.4).

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

14.3.4. Creation and sending of Rebind messages

At time T2 for an IA (which will only be used by the client in the
selection of a server reached if the client receives more than one Advertise
message.

If server to
which the Solicit Renew message was received in a Relay-forward message, sent at time T1 has not responded),
the
server constructs client initiates a Relay-reply Rebind/Reply message exchange. The client
includes an IA option with all addresses currently assigned to the Advertise message IA
in
the payload of a "server-message" option. its Rebind message. The server unicasts the
Relay-reply client sends this message to the address in All DHCP
Agents multicast address.

The client sets the "relay-address" "msg-type" field from
the Relay-forward message.

If the Solicit message was received directly by the server, to REBIND, and places
the
server unicasts link-local address of the Advertise message directly interface it wishes to the client using acquire
configuration information for in the "client-link-local-address" field
field.

The client generates a transaction ID inserts this value as in the destination
address.
"transaction-ID" field.

The Advertise message MUST be unicast through the interface
on which client sets the Solicit message was received.

13. "server-address" field to 0.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 27]

Internet Draft DHCP Client-Initiated Configuration Exchange

A for IPv6 30 June 2001

The client initiates a message exchange with adds a server or servers DUID option to
acquire or update configuration information of interest. identify itself to the server.
The client adds any appropriate options, including one or more IA
options. If the client does include any IA options (if the client is
requesting that the server extend the lease on some IAs; note that
the client may initiate check the status of other configuration parameters
without asking for lease extensions), it MUST include the configuration exchange as part list of
addresses the operating
system configuration process or when requested to do so by the
application layer. client currently has associated with that IA.

The client uses sends the following messages Rebind message to initiate a configuration
event with the All DHCP Agents multicast
address, destination port 547. The source port selection can
be arbitrary, although it SHOULD be possible using a server or servers:

Request Obtain initial client
configuration information (from facility to set a specific source port value.

The server
identified in will respond to the Rebind message with a previously Reply message.
If no Reply message is received Advertise message)
when within REP_MSG_TIMEOUT milliseconds,
the client has no assigned addresses

Confirm Confirm retransmits the validity of assigned addresses Rebind with the same transaction-ID, and other
configuration changes through
doubles the server REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received.

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

The client has several alternatives to choose from which if it receives no
response to its Rebind message.

- When the
configuration information was obtained when lease on the client's
assigned addresses may not be valid; for example, when IA expires, the client reboots or loses its connection may choose to use a link

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 22]

Internet Draft
Solicit message to locate a new DHCP server and send a Request
for IPv6 15 April 2001

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

Rebind Extend

- Some addresses in the lease on an IA through any server willing to may have lifetimes that extend beyond
the lease

A client uses of the Release/Reply message exchange IA, so the client may choose to indicate continue to use
those addresses; once all of the addresses have expired, the
client may choose to locate a new DHCP server that the

- The client will no longer be using the may have other addresses in other IAs, so the released IA.

A client uses the Decline/Reply message exchange to indicate
may choose to discard the
DHCP server that expired IA and use 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 client messages (Request,
other IAs

14.3.5. Receipt of Reply message in response to a Request, Confirm, Renew, Rebind, Release
Renew or Decline messages).

Agents MUST discard any received client messages in which Rebind message

Upon the
"client-link-local-address" field does not contain receipt of a valid link-local
address.

Servers MUST discard any received client messages Reply message in which the
"options" field contains an authentication option, and the server
cannot successfully authenticate the client.

Servers MUST discard any received response to a
Request, Renew, Release Confirm, Renew or Decline
message Rebind message, the client extracts the
configuration information contained in which the "server-address" Reply. If the "status"
field value does not match any
of contains a non-zero value, the server's addresses.

13.2. Server Message Validation

Servers MUST silently discard any received server messages (Reply or
Reconfigure-init messages).

Clients MUST discard any server messages that meet any of client reports the
following criteria:

o The "transaction-ID" field value in error status
to the server message does
not match application layer.

The client records the value T1 and T2 times for each IA in the Reply
message. The client used records any addresses included with IAs in its Request or Release
the Reply message.

o The "client-link-local-address" field value in client updates the server message
does not match preferred and valid
lifetimes for the link-local address of addresses in the interface IA from which the client sent lifetime information
in its Request, Confirm, Renew, Rebind, Release
or Decline message.

o The server message contains an authentication option, and the
client's attempt to authenticate IA option. The client leaves any addresses that the message fails. client

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 23] 28]

Internet Draft DHCP for IPv6 15 April 30 June 2001

Relays MUST discard any Relay-reply message

has associated with the IA that are not included in which the
"client-link-local-address" IA option
unchanged.

Management of the specific configuration information is detailed in
the encapsulated Reply message does
not contain definition of each option, in section 18.

When the client receives an Unavail error status in an IA from the
server for a valid link-local address.

13.3. Client Behavior

A Request message the client will use Request, Confirm, Renew and Rebind messages have to
acquire and confirm find a new
server to create an IA.

When the validity of configuration information. A client may initiate such receives a NoBinding error status in an exchange automatically IA from the
server for a Confirm message the client can assume it needs to send a
Request to reestablish an IA with the server.

When the client receives a Conf_NoMatch error status in order an IA from
the server for a Confirm message the client can send a Renew message
to
acquire the necessary network parameters server to communicate with nodes
off-link. The extend the lease for the addresses.

When the client uses receives a NoBinding error status in an IA from the
server address information from
previous Advertise message(s) for use in constructing Request and a Renew message(s). Note that message the client can assume it needs to send a
Request to reestablish an IA with the server.

When the client may request configuration
information receives a Renw_NoMatch error status in an IA from one or more servers at any time.

A client uses
the Release server for a Renew message in the management of IAs when the client has been instructed can assume it needs to release the IA prior send
a Request to the reestablish an IA
expiration time since it is no longer needed.

A client uses with the Decline message when server.

When the client has determined
through DAD or some other method that one or more of the addresses
assigned by receives an Unavail error status in an IA from the
server in for a Renew message the IA is already in use by client can assume it needs to send a different
client.

13.3.1. Creation and sending of
Request messages

If a client has no valid IPv6 addresses of sufficient scope to
communicate reestablish an IA with the server.

When the client receives a DHCP server, NoBinding error status in an IA from the
server for a Rebind message the client can assume it may needs to send a
Request message to
obtain new addresses. The client includes one reestablish an IA with the server or more IAs try another server.

When the client receives a Rebd_NoMatch error status in an IA from
the server for a Rebind message the client can assume it needs to
send a Request message, to which reestablish an IA with the server assigns new addresses. The
server then returns IA(s) to or try another
server.

When the client receives an Unavail error status in an IA from the
server for a Reply message. Rebind message the client can assume it needs to send a
Request to reestablish an IA with the server or try another server.

14.3.6. Creation and sending of Release messages

The client sets the "msg-type" field to REQUEST, RELEASE, and places the
link-local address of the interface associated with the configuration
information it wishes to acquire
configuration information for release in the "client-link-local-address"
field.

The client generates a transaction ID inserts and places this value in the
"transaction-ID" field.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 29]

Internet Draft DHCP for IPv6 30 June 2001

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

The client adds any appropriate options, including one or more IA
options (if a DUID option to identify itself to the server. The
client is requesting that includes options containing the server assign IAs it some
network addresses). is releasing in the
"options" field. The list of addresses in each included IA to be released MUST be empty. included in
the IAs. The client sends appropriate "status" field in the Request message options MUST be set
to indicate the All DHCP Agents
multicast address, destination port 547. The source port selection

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 24]

Internet Draft DHCP reason for IPv6 15 April 2001

can be arbitrary, although it SHOULD the release.

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 be possible using a
the last option in the "options" field. See section 18.9 for more
details about the authentication option.

The client sends the Release message to the All DHCP Agents multicast
address.

14.3.7. Time out and retransmission of Release Messages

A client
configuration facility MAY choose to set wait for a specific source port value.

The Reply message from the server will respond in
response to the Request message with Release message. If the client does wait for a Reply
Reply, the client MAY choose to retransmit the Release message.

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

Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS REL_MSG_ATTEMPTS
are documented in section 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:

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

Note that if the client may have moved fails to a new link, release the
client MUST initiate a Confirm/Reply message exchange. The client
includes any IAs, along with IA, the addresses associated with those IAs,
in its Confirm message. The server
assigned to the IA will indicate be reclaimed by the acceptability
of server when the addresses lease
associated with the status in the IA it returns to the client.

DISCUSSION:

This section used to allow servers to change the addresses expires.

14.3.8. Receipt of Reply message in an IA. Without some additional mechanism, servers
responding response to Confirm messages can't change safely
change a Release message

Upon receipt of a valid Reply message, the addresses in IAs (although they client can change consider the lifetimes), because servers may send back different
addresses.
Release event successful, and SHOULD return the successful status to
the application layer, if an application initiated the release.

14.3.9. Creation and sending of Decline messages

The client sets the "msg-type" field to CONFIRM, DECLINE, and places the
link-local address of the interface associated with the configuration

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

Internet Draft DHCP for IPv6 30 June 2001

information it wishes to acquire
configuration information for decline in the "client-link-local-address"
field.

The client generates a transaction ID inserts and places this value in the
"transaction-ID" field.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 25]

Internet Draft DHCP for IPv6 15 April 2001

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

The client adds any appropriate options, including one or more IA
options (if the client is requesting that the server confirm the
validity of some network addresses). If the client does include
any IA options, it MUST include places the list IP address of addresses the client
currently has associated with server that IA.

The client sends allocated the Confirm message to
address(es) in the All DHCP Agents
multicast address, destination port 547. "server-address" field.

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

Servers will respond DUID option to identify itself to the Confirm message with a Reply message. If
no Confirm message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Confirm 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 QRY_MSG_ATTEMPTS
unsuccessful attempts have been made, at which time the server. The
client includes options containing the IAs it is declining in the
"options" field. The addresses to be released MUST
abort be included in
the configuration attempt. IAs. The client SHOULD report appropriate "status" field in the abort
status options MUST be set
to indicate the application layer.

Default and initial values reason for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS
are documented in section 7.5. declining the address.

If the client receives no response is configured to its Confirm message, it MAY
restart use authentication, the configuration process by locating a DHCP server with an
Advertise message and sending a Request to that server, as described
in section 13.3.1.

13.3.3. Creation and sending of Renew messages

IPv6 addresses assigned to a client through an IA use
generates the same
preferred and valid lifetimes as IPv6 addresses obtained through
stateless autoconfiguration. The server assigns preferred appropriate authentication option, and valid
lifetimes adds this option
to the IPv6 addresses it assigns to an IA. To extend those
lifetimes, "options" field. Note that the client sends a Request to authentication option MUST be
the server containing an
"IA option" for last option in the IA and its associated addresses. The server
determines new lifetimes "options" field. See section 18.9 for more
details about the addresses in authentication option.

The client send the IA according Decline message to the server's administrative configuration. The server may also add
new addresses to All DHCP Agents multicast
address.

14.3.10. Time out and retransmission of Decline Messages

If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the IA. The server remove addresses from client retransmits the IA by
setting Decline, doubles the preferred REP_MSG_TIMEOUT
value, and valid lifetimes of those addresses to zero. waits again. The server controls the time client continues this process until a
Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have
been made, at which time the client contacts SHOULD abort the server attempt to extend
decline the lifetimes on assigned addresses through address. The client SHOULD return the T1 and
T2 parameters assigned abort status to an IA. If
the server does not assign an
explicit value to T1 or T2 for application, if an IA, T1 defaults to 0.5 times application initiated the
shortest preferred lifetime release.

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

14.3.11. Receipt of any address assigned Reply message in response to a Release message

Upon receipt of a valid Reply message, the IA client can consider the
Release event successful, and
T2 defaults SHOULD return the successful status to 0.875 times
the shortest preferred lifetime application layer, if an application initiated the release.

14.4. Server Behavior

For this discussion, the Server is assumed to have been configured in
an implementation specific manner with configuration of any
address assigned interest to the IA.
clients.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 26] 31]

Internet Draft DHCP for IPv6 15 April 30 June 2001

At time T1 for an IA,

14.4.1. Receipt of Request messages

Upon the client initiates receipt of 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 in its Request message. The client multicasts this valid Request message to the All DHCP Agents multicast address.

The from a client sets the "msg-type" field to RENEW, and places the link-local address of server
can respond to, (implementation-specific administrative policy
satisfied) the interface it wishes to acquire
configuration information for in server scans the "client-link-local-address" options field.

The client generates server then constructs a transaction ID inserts this value in Reply message and sends it to the
"transaction-ID" field.
client.

The client places the address of the destination server in SHOULD process each option for the
"server-address" field.

The client adds any appropriate options, including one or more IA
options (if in an
implementation-specific manner. The server MUST construct a Reply
message containing the client is requesting that following values:

msg-type REPLY

preference Enter the server extend server's preference to
provide services to the lease
on some IAs; note that client.

transaction-ID Enter the client may check transaction-ID from the status of other
configuration parameters without asking for lease extensions). If
Request message.

client-link-local address Enter the client does include any IA options, it MUST include client-link-local address
from the list of
addresses Request message.

server address Enter the client currently has associated with that IA.

The client sends IP address of the Renew message to server.

When the 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 Renew message with receives a Reply message.
If no Reply message Request and IA option is received within REP_MSG_TIMEOUT milliseconds, included the
client retransmits the Renew with is requesting the same transaction-ID, and
doubles configuration of a new IA by the REP_MSG_TIMEOUT value, and waits again. server.
The client
continues this process until a Reply is received or until time T2 is
reached (see section 13.3.4).

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

13.3.4. Creation server MUST take the clients IA and sending of Rebind messages

At time T2 associate a binding for that
client in an IA (which will only be reached if implementation-specific manner within the server's
configuration parameter database for DHCP clients.

If the server cannot provide addresses to
which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange. The client
includes it SHOULD send
back an empty IA option with all addresses currently assigned to the IA
in its Rebind message. The client multicasts this message with the status field set to Unavail.

If the server can provide addresses to the All
DHCP Agents multicast address.

The client sets it MUST send back
the "msg-type" field IA to REBIND, and places the link-local address client with all fields entered and a status of Success,
and add the interface it wishes IA as a new client binding.

The server adds options to acquire the Reply message for any other
configuration information for in to be assigned to the "client-link-local-address" client.

14.4.2. Receipt of Confirm messages

Upon the receipt of a valid Confirm 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 15 October 30 November 2001 [Page 27] 32]

Internet Draft DHCP for IPv6 15 April 30 June 2001

The server SHOULD process each option for the client generates a transaction ID inserts this value in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:

msg-type REPLY

preference Enter the server's preference to
provide services to the client.

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

client-link-local address Enter the client-link-local address
from the
"transaction-ID" field.

The client sets Confirm message.

server address Enter the "server-address" field to 0.

The client adds any appropriate options, including one or more IA
options. If server's address.

When the client does include any server receives a Confirm and an IA options (if option is included the
client is requesting confirmation that the server extend addresses in the lease on some IAs; note that IA are
valid. The server SHOULD locate the client may check clients binding and verify the status of other configuration parameters
without asking for lease extensions), it MUST include
information in the list of
addresses IA from the client currently has associated with that IA.

The client sends matches the Rebind message to information stored
for that client.

If the All DHCP Agents multicast
address, destination port 547. The source port selection can
be arbitrary, although it SHOULD be possible using server cannot find a client
configuration facility to set a specific source port value.

The server will respond to entry for this IA the Rebind message server
SHOULD return an empty IA with a Reply message. status set to NoBinding.

If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Rebind with server finds that the same transaction-ID, and
doubles information for the REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply does not
match what is received.

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

DISCUSSION:

The the server's records for that client has several alternatives the server
should send back an empty IA with status set to choose from if it
receives no response Conf_NoMatch.

If the server finds a match to its Rebind message.

- When the lease on Confirm then the server should
send back the IA expires, to the client may choose with status set to use success.

14.4.3. Receipt of Renew messages

Upon the receipt of a Solicit valid Renew message to locate from a new DHCP client the server and
send a Request for
can respond to, (implementation-specific administrative policy
satisfied) the expired IA to server scans the new options field.

The server

- Some addresses in then constructs a Reply message and sends it to the IA may have lifetimes that extend
beyond
client.

The server SHOULD process each option for the lease of client in an
implementation-specific manner. The server MUST construct a Reply
message containing the IA, so following values:

msg-type REPLY

preference Enter the client may choose server's preference to continue
provide services to use those addresses; once all of the
addresses have expired, the client may choose to locate
a new client.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 33]

Internet Draft DHCP for IPv6 30 June 2001

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

- The client may have other addresses in other IAs, so address Enter the
client may choose to discard server's address.

When the expired server receives a Renew and IA option from a client it
SHOULD locate the clients binding and use verify the
addresses information in the other IAs

13.3.5. Receipt of Reply message in response to a Reply, Confirm, Renew
or Rebind message

Upon
IA from the receipt of client matches the information stored for that client.

If the server cannot find a valid Reply message in response client entry for this IA the server
SHOULD return an empty IA with status set to a
Request, Confirm, Renew or Rebind message, NoBinding.

If the client extracts server finds that the
configuration information contained addresses in the Reply. If the "status"

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 28]

Internet Draft DHCP IA for IPv6 15 April 2001

field contains a non-zero value, the client reports do
not match the error clients binding the server should return an empty IA
with status set to Renw_NoMatch.

If the application layer.

The client records the T1 and T2 times server cannot Renew addresses for each the client it SHOULD send
back an empty IA in to the Reply
message. The client records any addresses included with IAs in the Reply message. The client updates status field set to Unavail.

If the preferred and valid
lifetimes for server finds the addresses in the IA from for the lifetime information
in client then the
server SHOULD send back the IA option. The client leaves any addresses that to the client
has associated with new lease times
and T1/T2 times if the IA that are default is not included in the IA option
unchanged.

Management being used, and set status to
Success.

14.4.4. Receipt of Rebind messages

Upon the specific configuration information is detailed in
the definition receipt of each option, in section 16.

When the client receives an Unavail error status in an IA a valid Rebind message from a client the server for a Request message
can respond to, (implementation-specific administrative policy
satisfied) the client will have to find a new server to create an IA.

When scans the client receives options field.

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

The server SHOULD process each option for the client in an IA from the
implementation-specific manner. The server for MUST construct a Confirm Reply
message containing the client can assume it needs following values:

msg-type REPLY

preference Enter the server's preference to send a
Request
provide services to reestablish an IA with the server.

When client.

transaction-ID Enter the client receives a Conf_NoMatch error status in an IA transaction-ID from the server for a
Confirm message message.

client-link-local address Enter the client can send a Renew message
to client-link-local address
from the Confirm message.

server to extend address Enter the lease server's address.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 34]

Internet Draft DHCP for the addresses. IPv6 30 June 2001

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

When clients binding and verify the client receives a Renw_NoMatch error status information in an the
IA from the server for a Renew message the client can assume it needs to send
a Request to reestablish an IA with matches the server.

When information stored for that client.

If the server cannot find a client receives an Unavail error status in an entry for this IA from the server for a Renew message the client can assume it needs to send a
Request to reestablish
SHOULD return an empty IA with status set to NoBinding.

If the server.

When server finds that the client receives a NoBinding error status addresses in an IA from the
server IA for a Rebind message the client can assume it needs to send a
Request to reestablish an IA with do
not match the server or try another server.

When clients binding the client receives a Rebd_NoMatch error status in server should return an empty IA from
with status set to Rebd_NoMatch.

If the server for a cannot Rebind message addresses for the client can assume it needs to SHOULD send a Request to reestablish
back an empty IA to the client with the status field set to Unavail.

If the server or try another
server.

When finds the client receives an Unavail error status addresses in an the IA from for the client then the
server for 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.

DISCUSSION:

There is a significant difference between Renew and Rebind
messages: Because the Rebind message is processed by a
single server, the client respnding server can assume it needs actually change the
addresses in the IA. However, because multiple servers may
repsond to send a
Request to reestablish an IA with Rebind, all they can safely do is update T1, T2
(for the server or try another server.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 29]

Internet Draft DHCP for IPv6 15 April 2001

13.3.6. Creation IA) and sending lifetimes (for individual addresses).

14.4.5. Receipt of Release messages

The client sets

Upon the "msg-type" field to RELEASE, receipt of a valid Release message, the server examines the
IAs and places the
link-local address of addresses in the interface associated with IAs for validity. If the configuration
information it wishes to release IAs in the "client-link-local-address"
field.

The client generates
message are in a transaction ID binding for the client and places this value the addresses in the
"transaction-ID" field.

The client places IAs
have been assigned by the IP address of server to those IA, the server that allocated deletes
the
address(es) in addresses from the IAs and makes the "server-address" field. addresses available for
assignment to other clients.

The client includes options containing server then generates a Reply message. If all of the IAs it is releasing in were
valid and the
"options" field. The addresses to be released MUST be included in successfully released,, the server sets the IAs. The appropriate
"status" field in the options MUST be set to indicate "Success". If any of the reason for IAs were invalid or if
any of the release.

If addresses were not successfully released, the client is configured to use authentication, server
releases none of the client
generates addresses in the appropriate authentication option, message and adds this option
to sets the "options" field. Note that "status"
field to "NoBinding"(section 7.4).

If the authentication option MUST be client successfully releases some but not all of the last option addresses
in an IA, the "options" field. See section 16.9 for more
details about IA continues to exist and holds the authentication option.

The remaining,
unreleased addresses.

A client can send the Release message an option containing an IA with no listed addresses
to the All DHCP Agents multicast
address.

13.3.7. Time out and retransmission release implicitly all of Release Messages

If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Release, doubles addresses in the REP_MSG_TIMEOUT
value, and waits again. The client continues this process until a
Reply IA.

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

Internet Draft DHCP for IPv6 30 June 2001

A server is received or REL_MSG_ATTEMPTS unsuccessful attempts not required to (but may choose to as an implementation
strategy) retain any record of an IA from which all of the addresses
have been
made, at which time released.

14.4.6. Sending of Reply messages

If the Request, Confirm, Renew, Rebind or Release message from
the client SHOULD abort was originally received by the release attempt.
The client SHOULD return server, the abort status server
unicasts the Reply message to the application, if an
application initiated link-local address in the release.

Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented
"client-link-local-address" field.

If the message was originally received in section 7.5.

Note that if a Forward-request or
Forward-release message from a relay, the client fails to release server places the IA, Reply
message in the addresses
assigned options field of a Response-reply message and unicasts
the message to the IA will be reclaimed by relay's address from the original message.

15. 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 lease
associated DHCP domain are to be renumbered. Other
examples include changes in the location of directory servers,
addition of new services such as printing, and availability of new
software (system or application).

15.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 client's
authentication check.

15.2. Server Behavior

A server sends a Reconfigure-init message to cause a client to
initiate immediately a Request/Reply message exchange with it expires.

13.3.8. the
server.

15.2.1. Creation and sending of Decline Reconfigure-init messages

The client server sets the "msg-type" field to DECLINE, RECONFIG-INIT. The server
generates a transaction-ID and places inserts it in the
link-local "transaction-ID"
field. The server places its address of the interface associated with the configuration
information it wishes to decline (of appropriate scope) in the "client-link-local-address"
"server-address" field.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 30] 36]

Internet Draft DHCP for IPv6 15 April 30 June 2001

The client generates a transaction ID and places this value in server MAY include an ORO option to inform the
"transaction-ID" field.

The client places the IP address of what
information has been changed or new information that has been added.
In particular, the server that allocated specifies the
address(es) IA option in the "server-address" field.

The client includes options containing ORO if the IAs it is declining in
server wants the
"options" field. The addresses client to be released MUST be included in
the IAs. obtain new address information.

The appropriate "status" field in the options server MUST be set
to indicate the reason for declining the address.

If the client is configured to use authentication, the client
generates the appropriate include an authentication option, and adds this option
to with the "options" field. Note appropriate
settings and add that the authentication option MUST be as the last option in the "options" field. See section 16.9 for more
details about
field of the authentication option. Reconfigure-init message.

The server MUST NOT include any other options in the Reconfigure-init
except as specifically allowed in the definition of individual
options.

The server unicasts the Reconfigure-init message to one client. The
server may unicast Reconfigure-init messages to more than one client send
concurrently; for example, to reliably reconfigure all known clients,
the Decline server will unicast a Reconfigure-init message to each client.

After the All DHCP Agents multicast
address.

13.3.9. server sends the Reconfigure-init message, it waits for a
Request message from those clients confirming that each client has
received the Reconfigure-init and are thus initiating a Request/Reply
transaction with the server.

15.2.2. Time out and retransmission of Decline Messages Reconfigure-init messages

If no Reply the server does not receive a Request message is received within REP_MSG_TIMEOUT milliseconds, from the client
in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
the Decline, Reconfigure-init message, doubles the REP_MSG_TIMEOUT
value, RECREP_MSG_TIMEOUT
value and waits again. The client server continues this process until a
Reply is received or REL_MSG_ATTEMPTS
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time the client SHOULD abort the attempt to
decline point
the address. The client server SHOULD return the abort status to
the application, if an application initiated the release. reconfigure process.

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

13.3.10. Receipt of Reply message in response to a Release message

Upon receipt of a valid Reply message, the client can consider the
Release event successful, and SHOULD return the successful status to
the application layer, if an application initiated the release.

13.4. Server Behavior

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

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 31]

Internet Draft DHCP for IPv6 15 April 2001

13.4.1.

15.2.3. Receipt of Request messages

Upon the receipt of a valid Request 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 generates and sends it Reply message(s) to the
client.

The server SHOULD process each option for the client as
described in section 14.4.6, including in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:

msg-type REPLY

preference Enter the servers preference to
provide services to the client.

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

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

server address Enter the IP address of "options" field new
values for configuration parameters.

It is possible that the server.

When client may send a Request message after the
server receives has sent a Request and IA option is included Reconfigure-init but before the
client Reconfigure-init is requesting the configuration of a new IA
received by the server.
The server MUST take client. In this case, the clients IA client's Request message
may not include all of the IAs and associate a binding requests for
that client in an implementation-specific manner within parameters to be
reconfigured by the servers
configuration parameter database for DHCP clients.

If server. To accommodate this scenario, the server cannot provide addresses
MAY choose to the client it SHOULD send
back an empty IA to the client a Reply with the status field set IAs and other parameters to Unavail.

If
be reconfigured, even if those IAs and parameters were not in the server can provide addresses to
Request message from the client.

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

Internet Draft DHCP for IPv6 30 June 2001

15.3. Client Behavior

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

15.3.1. Receipt of Reconfigure-init messages

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

The server adds options to
initiates a Request/Reply transaction with the Reply message for any other
configuration information to be assigned to server. While
the client.

13.4.2. Receipt of Confirm Request/Reply transaction is in progress, the client silently
discards any Reconfigure-init messages

Upon the receipt of a valid Confirm it receives.

DISCUSSION:

The Reconfigure-init message from acts as a trigger that signals
the client to complete a successful Request/Reply message
exchange. Once the server
can respond to, (implementation-specific administrative policy
satisfied) client has received a Recongfigure-init,
the server scans client proceeds with the options field.

The server then constructs a Reply Request/Reply message and sends it to
exchange (retransmitting the
client.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 32]

Internet Draft DHCP for IPv6 15 April 2001

The server SHOULD process each option for Request if necessary); the
client ignores any additional Reconfigure-init messages
(regardless of the transaction ID in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:

msg-type REPLY

preference Enter Reconfigure-init
message) until the servers preference to
provide services to Request/Reply exchange is complete.
Subsequent Reconfigure-init messages (again independent
of the client.

transaction-ID Enter transaction ID) cause the transaction-ID from client to initiate a new
Request/Reply exchange.

How does this mechanism work in the
Confirm message.

client-link-local address Enter face of duplicated
or retransmitted Reconfigure-init messages? Duplicate
messages will be ignored because the client-link-local address
from client will begin
the Confirm message.

server address Enter Request/Reply exchange after the server's address.

When receipt of the server receives a Confirm and an IA option is included
first Reconfigure-init. Retransmitted messages will
either trigger the
client is requesting confirmation that Request/Reply exchange (if the addresses in first
Reconfigure-init was not received by the IA are
valid. client) or will
be ignored. The server SHOULD locate can discontinue retransmission of
Reconfigure-init messages to the clients binding and verify client once the
information in server
receives the IA from client's Request.

It might be possible for a duplicate or retransmitted
Reconfigure-init to be sufficiently delayed (and
delivered out of order) to arrive at the client matches after
the information stored
for that client.

If Request/Reply exchange (initiated by the server cannot find a client entry for original
Reconfigure-init) has been completed. In this IA case, the server
SHOULD return an empty IA with status set
client would initiate a redundant Request/Reply exchange.
The likelihood of delayed and out of order delivery is small
enough to NoBinding.

If the server finds that be ignored. The consequence of the information redundant
exchange is inefficiency rather than incorrect operation.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 38]

Internet Draft DHCP for IPv6 30 June 2001

15.3.2. Creation and sending of Request messages

When responding to a Reconfigure-init, the client does not
match what is in creates and
sends the servers records for that client Request message in exactly the server
should send back an empty IA same manner as outlined in
section 14.3.1 with status set to Conf_NoMatch.

If the server finds a match to the Confirm then following difference:

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

15.3.3. Time out and retransmission of Request messages

The client uses the same variables and retransmission algorithm as it
does with status set to success.

13.4.3. Request messages generated as part of a client-initiated
configuration exchange. See section 14.3.1 for details.

15.3.4. Receipt of Renew Reply messages

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

The server then constructs a Reply message "options" field, and sends it to the
client. sets (or resets) configuration
parameters appropriately. The server SHOULD process each option for the client records and updates the
lifetimes for any addresses specified in an
implementation-specific manner. The server MUST construct a IAs in the Reply
message containing message.
If the following values:

msg-type REPLY

preference Enter configuration parameters changed were requested by the servers preference to
provide services to
application layer, the client.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 33]

Internet Draft DHCP for IPv6 15 April 2001

transaction-ID Enter client notifies the transaction-ID from application layer of the
Confirm message.

client-link-local address Enter
changes using an implementation-specific interface.

As discussed in section 15.2.3, the client-link-local address Reply from the Confirm message.

server address Enter the server's address.

When the server receives a Renew may include
IAs and IA option parameters that were not included in the Request message from a
the client. The client it
SHOULD locate MUST configure itself with all of the clients binding IAs and verify the information
parameters in the
IA Reply from the client matches the information stored for that client.

If the server cannot find a client entry for server.

16. Relay Behavior

For this IA discussion, the server
SHOULD return an empty IA with status set Relay may be configured to NoBinding.

If the use a list of
server finds that destination addresses, which may include unicast addresses,
the All DHCP Servers multicast address, or other multicast addresses in
selected by the IA for network administrator. If the client do Relay has not match the clients binding the server should return an empty IA
with status set to Renw_NoMatch.

If been
explicitly configured, it will use the server cannot Renew addresses for All DHCP Servers multicast
address as the default.

16.1. Relaying of client messages

When a Relay receives a valid client message, it SHOULD send
back constructs
a Relay-forward message. The relay places an empty IA to address from
the interface on which the client with message was received in the status
"relay-address" field set to Unavail.

If the server finds the addresses in and the IA prefix length for that address in the client then
"prefix-length" field. This address will be used by the server SHOULD send back to
identify the IA link to which the client with new lease times
and T1/T2 times if the default is not being used, connected and set status will be used

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 39]

Internet Draft DHCP for IPv6 30 June 2001

by the relay to
Success.

13.4.4. Receipt of Rebind messages

Upon forward the receipt of a valid Rebind Advertise 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 back to
the client.

The server SHOULD process each relay constructs a "client-message" option for 18.5 that contains
the entire message from the client in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:

msg-type REPLY

preference Enter data field of the servers preference to
provide services to
option. The relay places the client.

transaction-ID Enter "relay-message" option along with any
"relay-specific" options in the transaction-ID from options field of the
Confirm Relay-forward
message.

client-link-local address Enter The Relay then sends the client-link-local address
from Relay-forward message to the Confirm message. list
of server address Enter the server's address.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 34]

Internet Draft DHCP for IPv6 15 April 2001 destination addresses that it has been configured with.

16.2. Relaying of server messages

When the server relay receives a Rebind and IA option from a client Relay-reply message, it
SHOULD locate extracts the clients binding and verify server
message from the information in "server-message" option and forwards the
IA from message
to the client matches address in the information stored for that client.

If client-link-local-address field in the server cannot find a client entry for this IA
message. The relay forwards the server
SHOULD return an empty IA with status set message through the interface
identified in the "relay-address" field in the Relay-reply message.

17. Authentication of DHCP messages

Some network administrators may wish to NoBinding.

If provide authentication of
the server finds that source and contents of DHCP messages. For example, clients may
be subject to denial of service attacks through the use of bogus
DHCP servers, or may simply be misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish to
constrain the allocation of addresses to authorized hosts to avoid
denial of service attacks in "hostile" environments where the IA network
medium is not physically secured, such as wireless networks or
college residence halls.

Because of the risk of denial of service attacks against DHCP
clients, the use of authentication is mandated in Reconfigure-init
messages. A DHCP server MUST include an authentication option in
Reconfigure-init messages sent to clients.

The DHCP authentication mechanism is based on the design of
authentication for DHCP for IPv4 [8].

17.1. DHCP threat model

The threat to DHCP is inherently an insider threat (assuming a
properly configured network where DHCPv6 ports are blocked on
the enterprise's perimeter gateways.) Regardless of the gateway
configuration, however, the potential attacks by insiders and
outsiders are the same.

The attack specific to a DHCP client do
not match is the clients binding possibility of the
establishment of a "rogue" server should return an empty IA with status set the intent of providing
incorrect configuration information to Rebd_NoMatch.

If the server cannot Rebind addresses client. The motivation

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 40]

Internet Draft DHCP for IPv6 30 June 2001

for doing so may be to establish a "man in the client middle" attack or it SHOULD send
back an empty IA
may be for a "denial of service" attack.

There is another threat to the DHCP clients from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests
with the status field set unintentionally incorrect configuration parameters.

The threat specific to Unavail.

If the a DHCP server finds the addresses in the IA for the is an invalid client then the
server SHOULD send back the IA
masquerading as a valid client. The motivation for this may be for
"theft of service", or to circumvent auditing for any number of
nefarious purposes.

The threat common to both the client with new lease times and T1/T2 times if the default server is not being used, and set status to
Success.

13.4.5. Receipt the resource
"denial of Release messages

Upon service" (DoS) attack. These attacks typically involve
the receipt exhaustion of a valid Release message, the server examines addresses, or the
IAs exhaustion of CPU or
network bandwidth, and are present anytime there is a shared
resource. In current practice, redundancy mitigates DoS attacks the addresses in
best.

17.2. Summary of DHCP authentication

Authentication of DHCP messages is accomplished through the IAs for validity. If use of
the IAs Authentication option. The authentication information carried
in the
message are in a binding for Authentication option can be used to reliably identify the client
source of a DHCP message and to confirm that the addresses in contents of the IAs DHCP
message have not been assigned by the server to those IA, the server deletes tampered with.

The Authentication option provides a framework for multiple
authentication protocols. Two such protocols are defined here.
Other protocols defined in the addresses from future will be specified in separate
documents.

The protocol field in the IAs and makes Authentication option identifies the addresses available for
assignment
specific protocol used to other clients. generate the authentication information
carried in the option. The server then generates algorithm field identifies a Reply message. If all of specific
algorithm within the IAs were
valid and authentication protocol; for example, the addresses successfully released,,
algorithm field specifies the server sets hash algorithm used to generate the
"status"
message authentication code (MAC) in the authentication option. The
replay detection method (RDM) field to "Success". If any of specifies the IAs were invalid or if
any type of replay
detection used in the addresses were not successfully released, replay detection field.

17.3. Replay detection

The Replay Detection Method (RDM) field determines the server
releases none type of the addresses replay
detection used in the message and sets Replay Detection field.

If the "status" RDM field contains 0x00, the replay detection field MUST be
set to "NoBinding"(section 7.4).

DISCUSSION:

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

Can monotonically increasing counter. Using a client send an empty IA to release all addresses in
the IA?

If the IA becomes empty - all addresses are released - can
counter value such as the server discard any record current time of day (e.g., an NTP-format
timestamp [12]) can reduce the IA?

13.4.6. Sending danger of Reply messages

If the Request, Confirm, Renew, Rebind or Release message from
the client was originally received replay attacks. This method
MUST be supported by the server, the server all protocols.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 35] 41]

Internet Draft DHCP for IPv6 15 April 30 June 2001

unicasts the Reply message to the link-local address in the
"client-link-local-address" field.

17.4. Configuration token protocol

If the message was originally received in a Forward-request or
Forward-release message from a relay, the server places the Reply
message in protocol field is 0, the options authentication information field of
holds a Response-reply simple configuration token. The configuration token is an
opaque, unencoded value known to both the sender and receiver. The
sender inserts the configuration token in the DHCP message and unicasts the
receiver matches the token from the message to the relay's address shared token. If
the configuration option is present and the token from the original message
does not match the shared token, the receiver MUST discard the
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 token may use be used to pass a server-initiated plain-text configuration
exchange when links in the
token and provides only weak entity authentication and no message
authentication. This protocol is only useful for rudimentary
protection against inadvertently instantiated DHCP domain are servers.

DISCUSSION:

The intent here is to be renumbered. pass a constant, non-computed token
such as a plain-text password. Other
examples include changes in the location of directory servers,
addition types of new services entity
authentication using computed tokens such as printing, and availability of new
software (system Kerberos
tickets 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 one-time passwords will be defined as separate
protocols.

17.5. Delayed authentication option or that fail protocol

If the client's
authentication check.

Clients MUST discard any Reconfigure-init messages that contain a
transaction-ID that matches protocol field is 1, the transaction-ID in a Reconfigure-init message previously received from is using the same DHCP server.

14.2. Server Behavior

A server sends a Reconfigure-init message to trigger a client to
initiate immediately a Request/Reply message exchange with "delayed
authentication" mechanism. In delayed authentication, the
server. A server may unicast a Reconfigure-init message directly
to a single client or use multicast to deliver a Reconfigure-init
requests authentication in its Solicit message to multiple clients.

14.2.1. Creation and sending of Reconfigure-init messages

The the server sets replies
with an Advertise message that includes authentication information.
This authentication information contains a nonce value generated by
the "msg-type" field source as a message authentication code (MAC) to RECONFIG. provide message
authentication and entity authentication.

The server
generates use of a transaction-ID and inserts it in particular technique based on the "transaction-ID"
field. The server places its address (of appropriate scope) HMAC protocol [10]
using the MD5 hash [19] is defined here.

17.5.1. Management issues in the
"server-address" field. delayed authentication protocol

The server MAY include an ORO option "delayed authentication" protocol does not attempt to inform the address
situations where a client may roam from one administrative domain
to another, i.e. interdomain roaming. This protocol is focused on
solving the intradomain problem where the out-of-band exchange of what
information has been changed or new information that has been added. a
shared secret is feasible.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 36] 42]

Internet Draft DHCP for IPv6 15 April 30 June 2001

The server MUST include an authentication option with the appropriate
settings and add that option as

17.5.2. Use of the last Authentication option in the "options"
field of the Reconfigure-init message.

The server MAY include delayed authentication
protocol

In a Reconfigure-delay Solicit message, the Authentication option in a
Reconfigure-init message to be unicast to a client, carries the Protocol,
Algorithm, RDM and MUST
include a Reconfigure-delay Replay detection fields, but no Authentication
information.

In an Advertise, Request, Renew, Rebind or Confirm message, the
Authentication option in a Reconfigure-init message to
be multicast to a group of clients. carries the Protocol, Algorithm, RDM and Replay
detection fields and Authentication information. The server MUST NOT include any other options format of the
Authentication information is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secret ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-MD5 (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following definitions will be used in the Reconfigure-init
except description of the
authentication information for delayed authentication, algorithm 1:

Replay Detection - as specifically allowed in defined by the definition of individual
options.

The server may either unicast RDM field
K - a secret value shared between the Reconfigure-init message to one
client or multicast source and
destination of the message to one or more Reconfigure Multicast
Addresses previously sent as options to message; each secret has a
unique identifier (secret ID)
secret ID - the clients. The server
may unicast Reconfigure-init messages to more than one client
concurrently; unique identifier for example, to reliably reconfigure all clients, the
server will unicast a Reconfigure-init message secret value
used to each client.

If generate the server unicasts to one or more clients, it waits MAC for a Request this message from those clients confirming that it has received the
Reconfigure-init and are thus initiating a Request/Reply transaction
with
HMAC-MD5 - the server. MAC generating function.

The server can determine that a Request message is
in response to a Reconfigure-init because sender computes the transaction-ID in MAC using the
Request will be HMAC generation algorithm [10]
and the same value MD5 hash function [19]. The entire DHCP message (except
as was used in the Reconfigure-init
message.

If the server multicasts noted below), including the Reconfigure-init message, it must use
some TBD authentication mechanism that can authenticate DHCP message header and the server to
multiple clients. There options
field, is no reliability mechanism for multicast
Reconfigure-init messages. A server might use multicast in used as input to the
case where it does not have a list of its clients; for example, a
server that distributes configuration information HMAC-MD5 computation function. The
'secret ID' field MUST be set to clients using
stateless autoconfiguration might not keep a list of clients it has
communicated with.

DISCUSSION:

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

See section 18.2 for recommendations on the secret used to
generate the MAC.

DISCUSSION:

Algorithm 1 specifies the use of multicast
and unicast Reconfigure-init messages for reliable client
reconfiguration.

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

If the server does not receive a Request message from the
different technique, such as HMAC-SHA, will be specified as
a separate protocol.

Delayed authentication requires a shared secret key for each
client
in RECREP_MSG_TIMEOUT milliseconds, the on each DHCP server retransmits
the Reconfigure-init message, doubles with which that client may wish
to use the RECREP_MSG_TIMEOUT
value and waits again. The server continues this process until DHCP protocol. Each secret key has a unique
identifier that can be used by a receiver to determine which

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 37] 43]

Internet Draft DHCP for IPv6 15 April 30 June 2001

REC_MSG_ATTEMPTS unsuccessful attempts have been made, at

secret was used to generate the MAC in the DHCP message.
Therefore, delayed authentication may not scale well in an
architecture in which point a DHCP client connects to multiple
administrative domains.

17.5.3. Message validation

To validate an incoming message, the server SHOULD abort receiver first checks that
the reconfigure process.

Default value in the replay detection field is acceptable according
to the replay detection method specified by the RDM field. Next,
the receiver computes the MAC as described in [10]. The receiver
MUST set the 'MAC' field of the authentication option to all 0s for
computation of the MAC, and initial because a DHCP relay agent may alter
the values for RECREP_MSG_TIMEOUT of the 'giaddr' and
REC_MSG_ATTEMPTS are documented 'hops' fields in section 7.5.

14.2.3. Time out and retransmission the DHCP message,
the contents of multicast Reconfigure-init
messages

After those two fields MUST also be set to zero for the server transmits
computation of the initial Reconfigure-init message, MAC. If the MAC computed by the receiver does not
match the MAC contained in the server waits RECREP_MSG_TIMEOUT milliseconds. The server
then retransmits authentication option, the Reconfigure-init message, doubles receiver
MUST discard the
RECREP_MSG_TIMEOUT value and waits again. The server repeats this
process until DHCP message.

17.5.4. Key utilization

Each DHCP client has a total of REC_MSG_ATTEMPTS Reconfigure-init key, K. The client uses its key to encode
any messages
have been transmitted.

Default it sends to the server and initial values for RECREP_MSG_TIMEOUT to authenticate and
REC_MSG_ATTEMPTS are documented in section 7.5.

14.2.4. Receipt of Request verify
any messages it receives from the server. The server generates and sends Reply message(s) client's key SHOULD
be initially distributed to the client as
described in section 13.4.6, including through some out-of-band
mechanism, and SHOULD be stored locally on the client for use in all
authenticated DHCP messages. Once the "option" field new
values client has been given its key,
it SHOULD use that key for all transactions even if the client's
configuration parameters.

14.3. Client Behavior

A changes; e.g., if the client is assigned a new network
address.

Each DHCP server MUST always monitor UDP port 546 know, or be able to obtain in a secure manner,
the keys for Reconfigure-init all authorized clients. If all clients use the same
key, clients can perform both entity and message authentication for
all messages on interfaces upon which it has acquired DHCP parameters.
Since received from servers. However, the results sharing of keys
is strongly discouraged as it allows for unauthorized clients to
masquerade as authorized clients by obtaining a reconfiguration event may affect application
layer programs, the client SHOULD log these events, and MAY notify
these programs copy of the change through an implementation-specific
interface.

14.3.1. Receipt of Reconfigure-init messages

Upon receipt of a valid Reconfigure-init message, shared
key. To authenticate the identity of individual clients, each client
initiates a Request/Reply transaction
MUST be configured with the server.

14.3.2. Creation and sending of Request a unique key.

17.5.5. Client considerations for delayed authentication protocol

17.5.5.1. Sending Solicit messages

When responding to a Reconfigure-init, the client creates and sends the Request a Solicit message in exactly and wishes to use
authentication, it includes an Authentication option with the same manner desired
protocol, algorithm, RDM and replay detection field as outlined described
in section 13.3.1 with the following differences:

transaction-ID 17.5. The client copies the
transaction-ID from does not include any authentication
information in the Authentication option.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 38] 44]

Internet Draft DHCP for IPv6 15 April 30 June 2001

Reconfigure-init message into the
Request message.

IAs

17.5.6. Receiving Advertise messages

The client includes IA options validates any Advertise messages containing an
Authentication option specifying the addresses delayed authentication protocol
using the client
currently has assigned to those IAs
for validation test described in section 17.5.3.

Client behavior if no Advertise messages include authentication
information or pass the interface through which validation test is controlled by local policy
on the Reconfigure-init message was
received.

Pause before sending Request The client. According to client pauses before sending policy, the Request for client MAY choose to
respond to a random value
within Advertise message that has not been authenticated.

The decision to set local policy to accept unauthenticated messages
should be made with care. Accepting an unauthenticated Advertise
message can make the range REC_REP_MIN client vulnerable to spoofing and
REC_REP_MAX seconds. This delay
helps reduce other
attacks. If local users are not explicitly informed that the load on client
has accepted an unauthenticated Advertise message, the
server generated by processing
large numbers of triggered
Request messages from a multicast
Reconfigure-init message.

14.3.3. Time out users may
incorrectly assume that the client has received an authenticated
address and retransmission of Request messages

The is not subject to DHCP attacks through unauthenticated
messages.

A client uses the same variables MUST be configurable to discard unauthenticated messages,
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 SHOULD be configured by default to discard unauthenticated
messages. A client MAY choose to differentiate between Advertise
messages

Upon with no authentication information and Advertise messages
that do not pass the receipt of validation test; for example, a valid Reply message, the client extracts the
contents of might
accept the "option" field, former and sets (or resets) configuration
parameters appropriately. The discard the latter. If a client records and updates does accept an
unauthenticated message, the
lifetimes for client SHOULD inform any addresses specified in IAs in local users and
SHOULD log the Reply message. event.

17.5.6.1. Sending Request, Confirm, Renew, Rebind or Release messages

If the configuration parameters changed were requested by client authenticated the
application layer, Advertise message through which the
client notifies the application layer of selected the
changes using an implementation-specific interface.

15. Relay Behavior

For this discussion, server, the Relay may be configured client MUST generate authentication
information for subsequent Request, Confirm, Renew, Rebind or Release
messages sent to use a list of the server destination addresses, which may include unicast addresses, as described in section 17.5. When the All DHCP Servers multicast address, or other multicast addresses
selected
client sends a subsequent message, it MUST use the same secret used
by the network administrator. server to generate the authentication information.

17.5.6.2. Receiving Reply messages

If the Relay has not been
explicitly configured, client authenticated the Advertise it will use accepted, the All DHCP Servers multicast
address as client
MUST validate the default.

15.1. Relaying of associated Reply message from the server. The
client messages

When a Relay receives a valid MUST discard the Reply if the message fails to pass validation
and MAY log the validation failure. If the Reply fails to pass
validation, the client message, it constructs MUST restart the DHCP configuration process by
sending a Relay-forward Solicit message. The relay places an address client MAY choose to remember which
server replied with a Reply message that failed to pass validation
and discard subsequent messages from that server.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 39] 45]

Internet Draft DHCP for IPv6 15 April 30 June 2001

the interface on which

If the client accepted an Advertise 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 did not include
authentication information or did not pass the link to which validation test, the
client is connected and will be used
by the relay to forward the Advertise MAY accept an unauthenticated Reply message from the server back to
the client. server.

17.5.7. Server considerations for delayed authentication protocol

17.5.7.1. Receiving Solicit messages and Sending Advertise messages

The relay constructs server selects a "client-message" option 16.4 that contains secret for the entire client and includes
authentication information in the Advertise message from returned to the
client as specified in section 17.5. The server MUST record the data field
identifier of the
option. The relay places secret selected for the "relay-message" option along client and use that same
secret for validating subsequent messages with any
"relay-specific" options the client.

17.5.7.2. Receiving Request, Confirm, Renew, Rebind or Release messages
and Sending Reply messages

The server uses the secret identified in the options field of message and validates
the Relay-forward
message. The Relay then sends message as specified in section 17.5.3. If the Relay-forward message fails to
pass validation or the list
of server destination addresses that it has been configured with.

15.2. Relaying of server messages

When does not know the relay receives a Relay-reply message, it extracts secret identified by
the 'secret ID' field, the server
message from MUST discard the "server-message" option message and forwards MAY
choose to log the validation failure.

If the message passes the validation procedure, the server responds
to the address specific message as described in section 14.4. The server
MUST include authentication information generated using the secret
identified in the client-link-local-address field received message as specified in the server
message. section 17.5.

17.5.7.3. Sending Reconfigure-Init messages

The relay forwards the server message through the interface
identified MUST include authentication information in the "relay-address" field a
Reconfigure-Init message, generated as specified in section 17.5
using the Relay-reply message.

16. secret the server initially selected for the client to
which the Reconfigure-Init message is to be sent.

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

16.1.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 46]

Internet Draft DHCP for IPv6 30 June 2001

18.1. Format of DHCP options

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

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

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

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 40]

Internet Draft DHCP for IPv6 15 April 2001

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

16.2.

18.2. DHCP unique identifier option

The DHCP unique identifier option is used to carry a DUID. The format
for the DUID is keyed to mark the type of identifier and is of
variable length. The format of the DUID option is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION DUID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID type | DUID len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

18.3. 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 30 November 2001 [Page 47]

Internet Draft DHCP for IPv6 30 June 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION IA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IA DUID |
| (8 IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IA status | num-addrs | |T| addr status | prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|T| addr status | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IPv6 address |
| (16 octets) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref. lifetime (cont.) | valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid lifetime (cont.) |T| addr status | IPv6 address prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_IA (1)

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 41]

Internet Draft DHCP for IPv6 15 April 2001 IPv6 address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_IA (1)

option-len Variable; equal to 18 24 + num-addrs*25 num-addrs*26

IA DUID ID 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

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 48]

Internet Draft DHCP for IPv6 30 June 2001

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.

T When set to 1, indicates that this address is
a "temporary address" [15]; when set to 0,
the address is not a temporary address.

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 the addresses in this address. IA.

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.

The 'T' bit identifies the associated address as a temporary address.
If the server is configured to assign temporary addresses to the
client, the server marks those temporary addresses with the 'T'
bit. The number of temporary addresses assigned to the client and
the lifetimes of those addresses is determined by the administrative
configuration of the server. The 'T' bit only identifies an address
as a temporary address; identification of an address as ``temporary''
has no implication on the lifetime of the extensibility of the
lifetime of the address.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 42] 49]

Internet Draft DHCP for IPv6 15 April 30 June 2001

16.3.

18.4. 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_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_ORO (2)

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.

16.4.

18.5. Client message option

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

option-code OPTION_CLIENT_MSG (3)

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.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 43] 50]

Internet Draft DHCP for IPv6 15 April 30 June 2001

16.5.

18.6. Server message option

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVER_MSG OPTION_SERVER_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP server message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_SERVER_MSG (4)

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.

18.7. Retransmission parameter 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_RETRANS_PARM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP server message option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_SERVER_MSG (4) OPTION_RETRANS_PARM (5)

option-len Variable; equal to An unsigned integer giving the length of the forwarded DHCP
server message. data in
this option in octets.

option-data TBD - The message received details of the operational parameters to
be set in the client

18.8. 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
contain an IPv4-Mapped IPv6 Address [9] in the case of a Client
receiving the option, or is a Request for an IPv4-Mapped IPv6 Address
from a client in the server; forwarded
verbatim case of a DHCPv6 Server receiving the option.
The option can also provide a set of IPv6 addresses to be used as the client.

16.6. Retransmission parameter
Tunnel Endpoint (TEP) to encapsulate an IPv6 packet within IPv6.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 51]

Internet Draft DHCP for IPv6 30 June 2001

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RETRANS_PARM OPTION_DSTM | option-len option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data Tunnel End Point (TEP) |
| (option-len (If Present) |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_RETRANS_PARM (5)

option-len An unsigned integer giving the

option code OPTION_DSTM (7)

option length Variable: 0 or multiple of 16

tunnel end point IPv6 Address or addresses if Present

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

18.9. Authentication option

The Authentication option carries authentication information to
authenticate the identity and contents of DHCP messages. The use of
the data in
this Authentication option is described in octets.

option-data TBD - section 17.

The details format of the operational parameters to be
set in the client

16.7. Reconfigure-delay option

The Reconfigure-delay Authentication option specifies the amount of time a client
should delay before sending a Request message in response to a
Reconfigure-init message.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 44]

Internet Draft DHCP for IPv6 15 April 2001 is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_DELAY OPTION_AUTH | option-len option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| minimum delay time (msec) Protocol | Algorithm | RDM | Replay detect.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | Auth. Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Information |
| maximum delay time (msec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_RECONF_DELAY (6)

option-len An unsigned integer giving the length of the data OPTION_AUTH (TBD)

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 52]

Internet Draft DHCP for IPv6 30 June 2001

option-length Variable

protocol The authentication protocol used in
this authentication option

algorithm The algorithm used in octets.

minimum delay time An unsigned integer giving the minimum delay
time in milliseconds

maximum delay time An unsigned integer giving the maximum delay
time
authentication protocol

RDM The replay detection method used in milliseconds
this authentication option

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

16.8. DSTM Global IPv4 Address Option RDM

Authentication information The DSTM Global IPv4 Address Option informs a client or server that authentication information,
as specified by the Identity Association Option (IA) following protocol and
algorithm used in this authentication
option

18.10. Server unicast option

This option will
contain an IPv4-Mapped IPv6 Address [7] in the case of a Client
receiving the option, or is used by a Request for an IPv4-Mapped IPv6 Address
from server to send to a client in to inform the case of
client it can send a DHCPv6 Server receiving Request, Renew, Confirm, Release, and Decline by
unicasting directly to the option.
The option can also provide an IPv6 server instead of the ALL-DHCPv6-Agents
Multicast address to be used as the Tunnel
Endpoint (TEP) to encapsulate an IPv4 packet within IPv6.

This option can be used with optimization, when the Request, Reply, and Reconfigure-Init
Messages for cases where a server wants to assign client as an address
of sufficient scope to clients
IPv4-Mapped IPv6 Addresses, thru reach the Option Request Option (ORO). server.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DSTM OPTION_UNICAST | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel End Point (TEP) |
| (If Present) |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 45]

Internet Draft DHCP for IPv6 15 April 2001

option code OPTION_DSTM (7)

option length Variable:

option-code OPTION_UNICAST (TBD)

option-length 0 or 16

tunnel end point IPv6 Address if Present

A DSTM IPv4 Global Address Option MUST

This option only apply applies to the IA following server address that sends this option.

16.9. Authentication option

The authentication option is TBD.

17. DHCP Client Implementor Notes to the
client.

18.11. Domain Search Option

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

17.1. Primary Interface

Since configuration parameters acquired through domain names a client can use to
resolve DNS names.

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_DOMAIN_SEARCH_LIST | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 53]

Internet Draft DHCP can be
interface-specific or more general, the client implementor SHOULD
provide a mechanism by which for IPv6 30 June 2001

| Domain Search List |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg type OPTION_DOMAIN_SEARCH_LIST (TBD)

option-length variable

Domain Search List The DNS domain search list the client implementation can be
configured
should use to specify which interface is the primary interface. The
client SHOULD always query the DHCP data associated with resolve names.

So that the primary
interface for non-interface specific configuration parameters. An
implementation MAY implement a search list of interfaces which would may be
scanned encoded compactly and uniformly,
search strings in order to satisfy the general request. In either case, the
first interface scanned is considered search list are concatenated and encoded using
the primary interface.

By allowing technique described in section 4.1 of [13].

For use in this specification, the specification compression pointer (see section
4.1.4 of a primary interface, [13]) refers to the client
implementor identifies which interface is authoritative for
non-interface specific parameters, which prevents configuration
information ambiguity offset within the client implementation.

17.2. Advertise Message and Configuration Parameter Caching

If the hardware the client is running on permits it, SearchString portion
of the implementor
SHOULD provide option.

18.12. Domain Name Server Option

This option provides a cache for Advertise messages and list of Domain Name System [13] that a cache client
name resolver can use to access DNS services. There must be at least
1 server listed in this 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_DNS_SERVERS | option_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS server (IP address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS server (IP address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type OPTION_DNS_SERVERS (TBD)

option-length variable

DNS server IPv6 address 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 DNS name server for setting the amount of time the cache(s)
client to use. The DNS servers are
valid. listed in

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 46] 54]

Internet Draft DHCP for IPv6 15 April 30 June 2001

17.3. Time out and retransmission variables

Note that

the order of preference for use by the client time out and retransmission variables outlined
in
resolver.

19. DHCP Client Implementor Notes

This section 7.5 can be configured on the server and sent to provides helpful information for the client
through the use implementor
regarding their implementations. The text described here is not part
of the "DHCP Retransmission Parameter Option", which
is documented in section 16.6. A client protocol, but rather a discussion of implementation SHOULD features
we feel the implementor should consider during implementation.

19.1. Primary Interface

Since configuration parameters acquired through DHCP can be
able to reset these variables using
interface-specific or more general, the values from this option.

17.4. Server Preference

A client MUST wait for SRVR_PREF_WAIT seconds after sending implementor SHOULD
provide a DHCP
Solicit message mechanism by which the client implementation can be
configured to collect Advertise messages and compare their
preferences (see section 18.3), unless it receives an Advertise
message with a preference of 255. If specify which interface is the primary interface. The
client receives an
Advertise message SHOULD always query the DHCP data associated with the primary
interface for non-interface specific configuration parameters. An
implementation MAY implement a preference list of 255, then interfaces which would be
scanned in order to satisfy 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 general request. In either case, the server implementor.

18.1. Client Bindings

A server implementation MUST use
first interface scanned is considered the IA's DUID and primary interface.

By allowing the prefix specification from which of a primary interface, the client sent its Request message(s) as an
index
implementor identifies which interface is authoritative for finding
non-interface specific parameters, which prevents configuration parameters assigned to
information ambiguity within the client.
While it isn't critical to keep track of client implementation.

19.2. Advertise Message and Configuration Parameter Caching

If the other parameters
assigned to a client, hardware the server MUST keep track of client is running on permits it, the addresses it
has assigned to an IA.

The server should periodically scan its bindings implementor
SHOULD provide a cache for addresses whose
leases have expired. When the server finds expired addresses, it
MUST delete the assignment Advertise messages and a cache of those addresses, thereby making
configuration parameters received through DHCP. Providing these
addresses available to other clients.

The client bindings MUST be stored in non-volatile storage.
caches prevents unnecessary DHCP traffic and the subsequent load
this generates on the servers. The server implementation should implementor SHOULD provide policy knobs to control
whether or not a
configuration knob for setting the amount of time the lifetimes on assigned addresses cache(s) are renewable,
valid.

19.3. Time out and
by how long.

18.2. Reconfigure-init Considerations

A retransmission variables

Note that the client time out and retransmission variables outlined
in section 7.5 can be configured on the server implementation MUST provide an interface and sent to the
administrator for initiating reconfigure-init events. client
through the use of the "DHCP Retransmission Parameter Option", which
is documented in section 18.7. A server client implementation may provide a mechanism for allowing SHOULD be
able to reset these variables using the
specification of how many clients comprise a reconfigure multicast values from this option.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 47] 55]

Internet Draft DHCP for IPv6 15 April 30 June 2001

group. This enables the administrator to control the processing load
impact of the multicast of

19.4. Server Preference

A client MUST wait for SRVR_PREF_WAIT seconds after sending a Reconfigure-init message.

18.2.1. Reliable transmission of multicast Reconfigure-init messages

Because clients will ignore Reconfigure-init DHCP
Solicit message to collect Advertise messages and compare their
preferences (see section 20.3), unless it receives an Advertise
message with the
same transaction-ID, a server can retransmit a Reconfigure-init
message (using preference of 255. If 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 receives an
Advertise message from some clients in with a
multicast group, preference of 255, then the server client MAY choose to unicast a Reconfigure-init
message to those clients. Because the clients may have received the
multicast Reconfigure-init messages while act
immediately on that Advertise without waiting for any more additional
Advertise messages.

20. DHCP Server Implementor Notes

This section provides helpful information for the server did not receive
the clients' Reply messages, the implementor.

20.1. Client Bindings

A server SHOULD implementation MUST use a different
transaction-ID in the unicast Reconfigure-init messages to trigger 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 reconfigure.

18.3. Server Preference

The server implementation SHOULD allow the setting client.
While it isn't critical to keep track of the other parameters
assigned to a client, the server
preference value by MUST keep track of the administrator. addresses it
has assigned to an IA.

The server preference
variable is an unsigned single octet value (0--255), with should periodically scan its bindings for addresses whose
leases have expired. When the lowest
preference being 0 and server finds expired addresses, it
MUST delete the highest 255. Clients will choose higher
preference servers over assignment of those with lower preference values. If you
don't choose addresses, thereby making these
addresses available to implement this feature in your server, you other clients.

The client bindings MUST set
the server preference field to 0 be stored in the Advertise messages generated
by your server.

18.4. Request Message Transaction-ID Cache

In order to improve performance, a non-volatile storage.

The server implementation MAY include
an in memory transaction-ID cache. This cache is indexed by client
binding and transaction-ID, and enables the server should provide policy knobs to quickly
determine control
whether a Request is a retransmission or a new Request
without not the cost of a database lookup. If an implementor chooses to
implement this cache, then they SHOULD lifetimes on assigned addresses are renewable, and
by how long.

20.2. Reconfigure-init Considerations

A server implementation MUST provide a configuration knob an interface to tune the lifetime of the cache entries.

19. DHCP Relay Implementor Notes

A relay
administrator for initiating reconfigure-init events.

20.3. Server Preference

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

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 48]

Internet Draft DHCP for IPv6 15 April 2001

If a relay receives an ICMP message in response to a DHCP message it
has forwarded, it SHOULD log this event.

20. Open Issues for Working Group Discussion

This section contains some items for discussion server
preference value by the working group.

20.1. Authentication

Authentication is not discussed in this document. Authentication
will be modeled on DHCPv4 authentication. Authentication of
multicast Reconfigure-init messages administrator. The server preference
variable is a special problem.

20.2. Identification of IAs by servers

Do servers identify an IA just by its DUID or by <prefix, DUID>? If
just by DUID, are DUIDs guaranteed unique (within unsigned single octet value (0--255), with the DHCP universe)?
If so, how is that guarantee implemented?

20.3. DHCP-DNS interaction

Interaction among DHCP servers, clients lowest
preference being 0 and DNS servers is not
discussed in this document.

20.4. Temporary addresses

How does DHCPv6 interact with temporary addresses? If the server
assigns temporary addresses (e.g., addresses with short lifetimes),
how can a client application highest 255. Clients will choose higher
preference servers over those with lower preference values. If you
don't choose an temporary address as a source
address in preference to a non-temporary 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.

20.6. Client behavior when response to Rebind is not received

Section 13.3.4 describes several plausible ways implement this feature in which a client
might respond when it does not receive a Reply to a Rebind message.
The acceptable client behaviors need your server, you MUST set
the server preference field to be defined and described 0 in 13.3.4. the Advertise messages generated
by your server.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 49] 56]

Internet Draft DHCP for IPv6 15 April 30 June 2001

20.7. Additional options

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

20.8. Operational parameters

Should servers have

20.4. Request Message Transaction-ID Cache

In order to improve performance, a server implementation MAY include
an option in memory transaction-ID cache. This cache is indexed by client
binding and transaction-ID, and enables the server to set operational parameters - quickly
determine whether a Request is a retransmission timeouts, number or a new Request
without the cost of retries - in clients?

21. Security

This document references a database lookup. If an "authentication option" which is TBD.

DISCUSSION:

Based on implementor chooses to
implement this cache, then they SHOULD provide a configuration knob
to tune the discussion lifetime of security issues at the 8/31/00
design team teleconference and subsequent DHC WG mailing
list discussion, DHCPv6 will use cache entries.

21. DHCP Relay Implementor Notes

A relay implementation SHOULD allow the security model from
DHCPv4, as described specification of a list of
destination addresses for forwarded messages. This list MAY contain
any mixture of unicast addresses and multicast addresses.

If a relay receives an ICMP message in draft-ietf-dhc-authentication-16.txt
(which is soon response to be an RFC). a DHCP message it
has forwarded, it SHOULD log this event.

22. Security

Section 17 describes a threat model and an option that provides an
authentication framework to defend against that threat model.

23. Year 2000 considerations

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

23.

24. IANA Considerations

This document defines several new name spaces associated with DHCPv6
and DHCPv6 options. IANA is requested to manage the allocation of
values from these name spaces.

New values in each of these name spaces should be approved by the
process of IETF Consensus [14].

24.1. DHCPv6 options

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

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 57]

Internet Draft DHCP for IPv6 30 June 2001

24.2. Multicast addresses

Section 7.1 lists several multicast addresses used by DHCP.

This document also
Additional multicast addresses may be defined in the future.

24.3. Status codes

Section 9.7 defines several status codes that are to be returned with
the Reply message (see message. The non-zero values for these status codes that
are currently specified are shown in the table in section 7.4.

24.4. Retransmission parameter option

There is a DHCPv6 option described in section 18.7, which allows
clients and servers to exchange values for some of 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.

24.5. Authentication option

Section 17 defines three new name spaces associated with the
Authentication Option (section 18.9), which are to be created and
maintained by IANA: Protocol, Algorithm and RDM.

Initial values assigned from the Protocol name space are 0 (for the
configuration token Protocol in section 17.4) and 1 (for the delayed
authentication Protocol in section 9.7). 17.5). Additional protocols may
be defined in the future.

The Algorithm name space is specific to individual Protocols. That
is, each Protocol has its own Algorithm name space. The non-zero guidelines
for assigning Algorithm name space values for these status codes which are currently a particular protocol
should be specified are shown
in along with the table in section 7.4.

There is definition of a DHCPv6 option new Protocol.

For the configuration token Protocol, the Algorithm field MUST be
0, as described in section 16.6, which allows
clients and servers 17.4. For the delayed authentication
Protocol, the Algorithm value 1 is assigned to exchange values for some of the timing
and retransmission parameters HMAC-MD5
generating function as defined in section 7.5. Adding new
parameters in the future would require extending the values by which 17.5. Additional
algorithms for the parameters are indicated delayed authentication protocol may be defined in
the DHCP option. Since there needs future.

The initial value of 0 from the RDM name space is assigned to be a list kept, the default values for each parameter should also
be stored as part
use of a monotonically increasing value as defined in section 17.3.
Additional replay detection methods may be defined in the list. future.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 50] 58]

Internet Draft DHCP for IPv6 15 April 30 June 2001

All 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 [9].

24.

25. 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, Francis DuPont,
Ted Lemon, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson,
Bernie Volz and Phil Wells.

Thanks to Steve Deering and Bob Hinden, who have consistently
taken the time to discuss the more complex parts of the IPv6
specifications.

Bill Arbaugh reviewed the authentication mechanism described in
section 17.

The Domain Search option described in section 18.11 is based on the
DHCPv4 domain search option, [1], and was reviewed by Bernard Aboba.

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] [7, 2] and DHCPv6.
There are three key reasons for the differences:

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

o DHCPv6 benefits from the new IPv6 features.

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

IPv6 Architecture/Model Changes:

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

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

o Multicast and address scoping in IPv6 permit the design of
discovery packets that would inherently define their range by the
multicast address for the function required.

o Stateful autoconfiguration has to coexist and integrate with
stateless autoconfiguration supporting Duplicate Address

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 51] 59]

Internet Draft DHCP for IPv6 15 April 30 June 2001

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

o Multiple addresses per interface are inherently supported in
IPv6.

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

DHCPv6 Architecture/Model Changes:

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

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

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

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

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

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

o ACKs and NAKs are not used.

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

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

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

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

o New options have been defined.

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

o Configuration of Dynamic Updates to DNS user features,
including

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 52] 60]

Internet Draft DHCP for IPv6 15 April 30 June 2001

o Configuration of Dynamic Updates to DNS

o Address deprecation, for dynamic renumbering.

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

o Authentication

o Clients can ask for multiple IP addresses.

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

o Integration between stateless and stateful address
autoconfiguration.

o Enabling relays to locate off-link servers.

B. Full Copyright Statement

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

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

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

C. Changes in this draft

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

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 61]

Internet Draft DHCP for IPv6 30 June 2001

C.1. Reconfigure-init

The client behavior in response to a Reconfigure-init message
described in its implementation may be prepared, copied, published
and distributed, section 15 has been changed. When the client receives
a Reconfigure-init message, the client goes into "Reconfigure"
mode. The client initiates a Request/Reply exchange in whole or which the
XID in part, without restriction client Request is independent of any
kind, provided that server Reconfigure-init XID.
The server waits for the above copyright notice and this paragraph
are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by
removing next Request message from the copyright notice or references client to
determine if the Internet Society
or other Internet organizations, except as needed for client has received the purpose
of developing Internet standards in which case Reconfigure-init.

To avoid redundant Request/Reply messages exchanges, the procedures client
ignores subsequent Reconfigure-init messages until it completes the
Request/Reply exchange.

Use of multicast for copyrights defined Reconfigure-init message delivery has been
removed:

- Multicast only saves, at most, 1/3 of the messages when
reconfiguring multiple clients

- Multicast might cause an implosion of Request messages;
additional complexity in the Internet Standards process must client and protocol messages would
be
followed, or as required to translate it into languages add delay to spread out Request messages

- Authentication of multicast Reconfigure-init messages (where a
single message must be authenticated by multiple clients) is an
open problem

Text has been added clarifying that the ORO option applies to IAs as
well as other than
English. options. The limited permissions granted above are perpetual and will not be
revoked server may choose to omit the IA option
from the ORO in the Reconfigure-init message.

The Reconfigure-delay option (used only by multicast
Reconfigure-init) has been removed.

The transaction ID feild in the Internet Society or its successors or assigns.

This document and the information contained herein Reconfigure-init message header 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.

C. Changes in
now marked as "(unused) MUST be zero".

C.2. Authentication

DHCPv4-style authentication has been added to this draft

This in
section describes 17.

C.3. Confirm message

The following DISCUSSION was removed from the changes between this version description of the DHCPv6
specification and draft-ietf-dhc-dhcpv6-16.txt.
Confirm message:

DISCUSSION:

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 53] 62]

Internet Draft DHCP for IPv6 15 April 30 June 2001

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 described in

This 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
type codes for these messages have been added used to section 7.3.

C.2. New message formats

Section 9 has been restructured allow servers to include only one copy of the DHCP
message header, because now all change the addresses
in an IA. Without some additional mechanism, servers
responding to Confirm messages have can't change safely
change the same header
format. Descriptions of addresses in IAs (although they can change
the use lifetimes), because servers may send back different
addresses.

C.4. Failure of header fields in the 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"

In section 14.3.4, the alternatives for consistency with client behavior in the
rest of
case that the document

C.4. Clarified relay forwarding of messages

Added text to sections on relay behavior client receives no response to clarify encapsulation a Rebind message were
taken out of a DISCUSSION section and
decapsulation made part of client messages in Relay-forward the spec. These
alternatives are really an implementation issue and Relay-reply
messages. not part of the
DHCPv6 spec.

C.5. Addresses and options Server behavior in Advertise messages

Modified section 12.4.2 so that servers include addresses response to be
assigned and other options in Advertise messages. Also added Release message

The following DISCUSSION was merged into the text to
section 12.3.1 to disallow option values (except as noted describing server
behavior in option
definitions) response to a Release message in Solicit messages.

C.6. Clarification of IA option format

Changed section 14.4.5:

DISCUSSION:

What is the label behavior of the prefix length field in server relative to a "partially
released" IA; i.e., an IA option for which some but not all
addresses are released?

Can a client send an empty IA to
"prefix length" release all addresses in
the IA?

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

C.6. Client behavior when sending a Release message

Text has been added to section 14.3.6 clarifying that a client MAY
(but not MUST) wait for a Reply to a Release message.

C.7. IA option

The format diagram, and moved diagram has been corrected to include the prefix
before the length
and address for consistency status with relay messages and other IPv6
protocols.

C.7. Specification of transaction ID each address. PROPOSAL - use left-most bit
in Solicit message

Add text (which was missing) address status to specify the insertion indicate whether an address is "temporary".

C.8. DSTM option

Definition of a
transaction ID in Solicit messages. DSTM option has been updated to carry multiple IPv6
addresses as tunnel endpoints.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 54] 63]

Internet Draft DHCP for IPv6 15 April 30 June 2001

C.8. Edits

C.9. Server unicast option

An option to definitions

Some of the definitions allow clients to use unicast where possible has been
added in section 6 have 18.10.

C.10. Domain search option

An option to pass a domain name search list to a client has been edited for clarity.

C.9. Relay agent messages

The formats of relay agent messages are now described
added in section 18.11.

C.11. DNS servers option

An option to pass a separate
section, 10.

C.10. Relay agent behavior

The behavior list of relay agents for all DNS options to a client has been added in
section 18.12.

C.12. DUID and server messages IAID

The "DHCP unique identifier" is
now described in defined as a single section, 15.

C.11. Transmission typed, variable length
value (see section 18.2). The DUID is carried in an option. The
details of all client messages through relays

All client messages are now multicast to the All Agents multicast
address and forwarded by relays DUID are TBD.

The "IA identifier" is defined as appropriate.

C.12. Reconfigure-init messages

Client behavior in response to a Reconfigure-init messages 4 octet identifier, unique among
all IAIDs for IAs from a client.

C.13. Continuing to poll with Solicit

Text has been extended added to accommodate receipt of multiple copies of section 13.3.2 allowing a
Reconfigure-init message due client to duplicate continue
to send Solicit messages or retransmission.

Server use of multicast Reconfigure-init at low frequency indefinitely.

C.14. Using DHCPv6 without address assignment

Text has been specified.

Hints about use added to section 14.3.1 allowing a client to send a
Solicit message containing no IAs to request other configuration
information without address assignment (equivalent to DHCPv4
DHCPINFORM).

C.15. Potential crossing in flight of multicast Request and unicast for reliable reconfiguration
have Reconfigure-init
messages

Text has been added to section 15 addressing the case in which the
client sends a Request after a server implementor's hints.

C.13. Ordering of sections

Several sections have been re-ordered for clarity.

C.14. DSTM option

The DSTM option has been added (section 16.8).

C.15. Message and option numbering

(In rev -18) Replaced TBD sent a Reconfigure-init but
before the client receives the Reconfigure-init.

D. Open Issues for message and option code numbering with
names and temporary values. Working Group Discussion

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

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 55] 64]

Internet Draft DHCP for IPv6 15 April 30 June 2001

C.16. Inclusion

D.1. Generation and use of IAs in Solicit message by DUID and IAID

Details for generation and use of DUID and IA identifiers is TBD.

D.2. Address registration

Should there be a way for a DHCP client

Added text to section 12.3.1 explaining that clients include empty
IA(s) in register stateless
autoconfig addresses with the server?

D.3. Prefix advertisement

Can a Solicit message and DHCP server advertise prefixes? This function might be used
to section 12.3.3 explaining that provide managed temporary addresses - the server advertises a
prefix and the client then registers selected addresses with the DHCP
server.

D.4. DHCP-DNS interaction

Interaction among DHCP servers, clients and DNS servers should be
discussed in client IAs.

C.17. Clarification of destination this document.

What is relationship between DHCP-DNS for IPv4 (work-in-progress) and
DHCP-DNS interaction requirements for IPv6?

D.5. Use of client messages

Added text term "agent"

The term "agent", taken to section 13 clarifying the destination (specific server mean "relay agent or any available server) of client messages

C.18. Clarification of client use of Confirm messages

Changed text server", may be
confusing. "relay agent or server" might be clearer.

D.6. Additional options

Which additional options should be included in this base spec
document? How should we reserve space for "local options" (as in section 13.3.2
DHCPv4)?

D.7. Operational parameters

Should servers have an option to correctly describe behavior set operational parameters -
retransmission timeouts, number of
clients retries - in response to Replay messages from servers. clients?

References

[1] B. Aboba. DHCP Domain Search Option. Internet Draft, Internet
Engineering Task Force, December 2000. Work in progress.

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 65]

Internet Draft DHCP for IPv6 30 June 2001

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

[2]

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

[3]

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

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

[5]

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

[6]

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

[7]

[8] R. Droms and W. Arbaugh. Authentication for DHCP Messages.
Internet Draft, Internet Engineering Task Force, January 2001.
Work in progress.

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

[8]

[10] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
for Message Authentication. Request for Comments
(Informational) 2104, Internet Engineering Task Force,
February 1997.

[11] 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.

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 2001 [Page 56]

[12] David L. Mills. Network Time Protocol (Version 3)
Specification, Implementation. Request for Comments (Draft
Standard) 1305, Internet Draft DHCP Engineering Task Force, March 1992.

[13] P. V. Mockapetris. Domain names - implementation and
specification. Request for IPv6 15 April 2001

[9] Comments (Standard) 1035, Internet
Engineering Task Force, November 1987.

[14] 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.

[10]

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 66]

Internet Draft DHCP for IPv6 30 June 2001

[15] T. Narten and R. Draves. Privacy Extensions for Stateless
Address Autoconfiguration in IPv6. Request for Comments
(Proposed Standard) 3041, Internet Engineering Task Force,
January 2001.

[16] 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.

[11]

[17] 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.

[12]

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

[13]

[19] R. Rivest. The MD5 Message-Digest Algorithm. Request for
Comments (Informational) 1321, Internet Engineering Task Force,
April 1992.

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

[14]

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

[15]

[22] 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 15 October 30 November 2001 [Page 57] 67]

Internet Draft DHCP for IPv6 15 April 30 June 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:

Bound, Carney, Perkins, Droms (ed.) Expires 30 November 2001 [Page 68]

Internet Draft DHCP for IPv6 30 June 2001

Jim Bound
Nokia Networks
5 Wayside
Compaq Computer Corporation
ZK3-3/W20
110 Spit Brook Road
Burlington, MA 01803
Nashua, NH 03062-2698
USA
Phone: +1-781-492-6010 +1 603 884 0062
Email: jim.bound@nokia.com Jim.Bound@compaq.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:
Email: charliep@iprg.nokia.com
Fax: +1 650 625-2502

Ralph Droms
Cisco Systems
300 Apollo Drive
Chelmsford, MA 01824
USA
Phone: +1 978 244 4733
Email: rdroms@cisco.com

Bound, Carney, Perkins, Droms (ed.) Expires 15 October 30 November 2001 [Page 58] 69]
----