WDIFF

draft-ietf-dhc-dhcpv6-23.txt --> draft-ietf-dhc-dhcpv6-24.txt

Internet Engineering Task Force J. Bound
INTERNET DRAFT Compaq
DHC Working Group M. Carney
Obsoletes: draft-ietf-dhc-dhcpv6-22.txt draft-ietf-dhc-dhcpv6-23.txt Sun Microsystems, Inc
C. Perkins
Nokia Research Center
Ted Lemon
Nominum
Bernie Volz
Ericsson
R. Droms(ed.)
Cisco Systems
1 Feb
22 Apr 2002

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-23.txt
draft-ietf-dhc-dhcpv6-24.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 dhcwg@ietf.org 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" (RFC2462), and can be used

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page i]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

Stateless Address Autoconfiguration" [21], and can be used

separately or concurrently with the latter to obtain configuration
parameters.

Contents

Status of This Memo i

Abstract i

1. Introduction and Overview 1

2. Requirements 2

3. Background 2

4. Design Goals 3

5. Non-Goals 4

6. Terminology 4
6.1. IPv6 Terminology
1.1. Protocols and addressing . . . . . . . . . . . . . . . . 2
1.2. Protocol implementation . . . . 4
6.2. DHCP Terminology . . . . . . . . . . . . . 2
1.3. Client-server exchanges involving two messages . . . . . 3
1.4. Client-server exchanges involving four messages . . 5

7. DHCP Constants 7
7.1. Multicast Addresses . . . 3

2. Requirements 4

3. Background 4

4. Terminology 5
4.1. IPv6 Terminology . . . . . . . . . . . . . . . . 7
7.2. UDP ports . . . . 5
4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 7
7.3. 6

5. DHCP message types Constants 8
5.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 8
7.4. Status Codes . . . . . . . . . . . . . . . . . .
5.2. Anycast address . . . . 9
7.4.1. Generic Status Codes . . . . . . . . . . . . . . 9
7.4.2. Server-specific Status Codes . . . 8
5.3. UDP ports . . . . . . . 10
7.5. Configuration Variables . . . . . . . . . . . . . . . . . 11

8. Message Formats 11
8.1. 8
5.4. DHCP Solicit Message Format . . message types . . . . . . . . . . . . . 12
8.2. DHCP Advertise Message Format . . . . . . 9
5.5. Status Codes . . . . . . . . 12
8.3. DHCP Request Message Format . . . . . . . . . . . . . . 10
5.6. Configuration Parameters . 12
8.4. DHCP Confirm Message Format . . . . . . . . . . . . . . . 13
8.5. DHCP Renew 11

6. Message Format . Formats 11

7. Relay agent messages 12
7.1. Relay-forward message . . . . . . . . . . . . . . . 13
8.6. DHCP Rebind Message Format . . . 13
7.2. Relay-reply message . . . . . . . . . . . . 13
8.7. DHCP Reply Message Format . . . . . . . 14

8. Representation and use of domain names 14

9. DHCP unique identifier (DUID) 14
9.1. DUID contents . . . . . . . . . 13
8.8. DHCP Release Message Format . . . . . . . . . . . . . 15
9.2. DUID based on link-layer address plus time . . 13
8.9. DHCP Decline Message Format . . . . . 15
9.3. Vendor-assigned unique ID based on Domain Name (VUID-DN) 16
9.4. Vendor-assigned unique ID based on Enterprise Number
(VUID-EN) . . . . . . . . . . 14
8.10. DHCP Reconfigure Message Format . . . . . . . . . . . . 17
9.5. Link-layer address . 14
8.11. Information-Request Message Format . . . . . . . . . . . 14

9. Relay messages 14
9.1. Relay-forward message . . . . . . . . . . . . . . . . . . 15
9.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 16 18

10. Representation and use of domain names 16 Identity association 19

11. DHCP unique identifier (DUID) 16 Selecting addresses for assignment to an IA 20

12. Management of temporary addresses 21

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page ii]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

11.1. DUID contents . . . . . . . . . . . . . . . . . . . . . . 17
11.2. DUID based on link-layer address plus time . . . . . . . 17
11.3. Vendor-assigned unique ID (VUID) . . . . . . . . . . . . 18
11.4. Link-layer address . . . . . . . . . . . . . . . . . . . 19

12. Identity association 20

13. Selecting addresses for assignment to an IA Transmission of messages by a client 21

14. Management of temporary addresses 22

15. Reliability of Client Initiated Message Exchanges 23

16. 21

15. Message validation 24
16.1. 23
15.1. Use of Transaction-ID field . . . . . . . . . . . . . . . 24
16.2. 23
15.2. Solicit message . . . . . . . . . . . . . . . . . . . . . 25
16.3. 23
15.3. Advertise message . . . . . . . . . . . . . . . . . . . . 25
16.4. 24
15.4. Request message . . . . . . . . . . . . . . . . . . . . . 25
16.5. 24
15.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 25
16.6. 24
15.6. Renew message . . . . . . . . . . . . . . . . . . . . . . 26
16.7. 24
15.7. Rebind message . . . . . . . . . . . . . . . . . . . . . 26
16.8. 25
15.8. Decline messages . . . . . . . . . . . . . . . . . . . . 26
16.9. 25
15.9. Release message . . . . . . . . . . . . . . . . . . . . . 27
16.10. 25
15.10. Reply message . . . . . . . . . . . . . . . . . . . . . . 27
16.11. 25
15.11. Reconfigure message . . . . . . . . . . . . . . . . . . . 27
16.12. 26
15.12. Information-request message . . . . . . . . . . . . . . . 27
16.13. 26
15.13. Relay-forward message . . . . . . . . . . . . . . . . . . 28
16.14. 26
15.14. Relay-reply message . . . . . . . . . . . . . . . . . . . 28

17. 26

16. Client Source Address and Interface Selection 28

18. 26

17. DHCP Server Solicitation 28
18.1. 27
17.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 29
18.1.1. 27
17.1.1. Creation of Solicit messages . . . . . . . . . . 29
18.1.2. 27
17.1.2. Transmission of Solicit Messages . . . . . . . . 29
18.1.3. 28
17.1.3. Receipt of Advertise messages . . . . . . . . . . 29
17.1.4. Receipt of Reply message . . . . . . . . . . . . 30
18.2.
17.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31
18.2.1. 30
17.2.1. Receipt of Solicit messages . . . . . . . . . . . 31
18.2.2. 30
17.2.2. Creation and transmission of Advertise messages . 30
17.2.3. Creation and Transmission of Reply messages . . . 31

19.

18. DHCP Client-Initiated Configuration Exchange 32
19.1.
18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 33
19.1.1. 32
18.1.1. Creation and transmission of Request messages . . 33
19.1.2. 32
18.1.2. Creation and transmission of Confirm messages . . 34
19.1.3.
18.1.3. Creation and transmission of Renew messages . . . 35
19.1.4.
18.1.4. Creation and transmission of Rebind messages . . 37
19.1.5. 36
18.1.5. Creation and Transmission of Information-request
messages . . . . . . . . . . . . . . . . . 38
19.1.6. 37
18.1.6. Receipt of Reply message in response to a Request,
Confirm, Renew, Rebind or Information-request
message . . . . . . . . . . . . . . . . . 38
19.1.7.
18.1.7. Creation and transmission of Release messages . . 40

Droms (ed.), et al. Expires 1 Aug 2002 [Page iii]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

19.1.8. 39
18.1.8. Receipt of Reply message in response to a Release
message . . . . . . . . . . . . . . . . . 41
19.1.9. 40
18.1.9. Creation and transmission of Decline messages . . 41
19.1.10. 40
18.1.10. Receipt of Reply message in response to a Decline
message . . . . . . . . . . . . . . . . . 42
19.2. 41
18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 42
19.2.1. 41
18.2.1. Receipt of Request messages . . . . . . . . . . . 42
19.2.2. 41
18.2.2. Receipt of Confirm messages . . . . . . . . . . . 43
19.2.3. 42

Droms (ed.), et al. Expires 22 Oct 2002 [Page iii]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

18.2.3. Receipt of Renew messages . . . . . . . . . . . . 44
19.2.4. 43
18.2.4. Receipt of Rebind messages . . . . . . . . . . . 45
19.2.5. 44
18.2.5. Receipt of Information-request messages . . . . . 46
19.2.6. 44
18.2.6. Receipt of Release messages . . . . . . . . . . . 47
19.2.7. 45
18.2.7. Receipt of Decline messages . . . . . . . . . . . 47
19.2.8. 45
18.2.8. Transmission of Reply messages . . . . . . . . . 47

20. 46

19. DHCP Server-Initiated Configuration Exchange 48
20.1. 46
19.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 48
20.1.1. 46
19.1.1. Creation and transmission of Reconfigure messages 48
20.1.2. 46
19.1.2. Time out and retransmission of Reconfigure
messages . . . . . . . . . . . . . . . . . 49
20.1.3. 47
19.1.3. Receipt of Renew messages . . . . . . . . . . . . 49
20.2. 47
19.2. Receipt of Information-request messages . . . . . . . . . 49
20.3. 48
19.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 50
20.3.1. 48
19.3.1. Receipt of Reconfigure messages . . . . . . . . . 50
20.3.2. 48
19.3.2. Creation and transmission of Renew messages . . . 51
20.3.3. 49
19.3.3. Creation and transmission of Information-request
messages . . . . . . . . . . . . . . . . . 51
20.3.4. 49
19.3.4. Time out and retransmission of Renew or
Information-request messages . . . . . . . 51
20.3.5. 49
19.3.5. Receipt of Reply messages . . . . . . . . . . . . 51

21. 49

20. Relay Agent Behavior 52
21.1. 50
20.1. Relaying of client messages . . . . . . . . . . . . . . . 52
21.2. 50
20.2. Relaying of server messages . . . . . . . . . . . . . . . 52

22. 50

21. Authentication of DHCP messages 53
22.1. 51
21.1. DHCP threat model . . . . . . . . . . . . . . . . . . . . 53
22.2. 51
21.2. Security of messages sent between servers and relay agents 54
22.3. 52
21.3. Summary of DHCP authentication . . . . . . . . . . . . . 54
22.4. 52
21.4. Replay detection . . . . . . . . . . . . . . . . . . . . 54
22.5. Configuration token protocol . . . . . . . . . . . . . . 54
22.6. 52
21.5. Delayed authentication protocol . . . . . . . . . . . . . 55
22.6.1. 53
21.5.1. Management issues in the delayed authentication
protocol . . . . . . . . . . . . . . . . . 55
22.6.2. 53
21.5.2. Use of the Authentication option in the delayed
authentication protocol . . . . . . . . . 55
22.6.3. 53
21.5.3. Message validation . . . . . . . . . . . . . . . 56
22.6.4. 54
21.5.4. Key utilization . . . . . . . . . . . . . . . . . 57
22.6.5. 54
21.5.5. Client considerations for delayed authentication
protocol . . . . . . . . . . . . . . . . . 57
22.6.6. 55
21.5.6. Server considerations for delayed authentication
protocol . . . . . . . . . . . . . . . . . 59

Droms (ed.), et al. Expires 1 Aug 2002 [Page iv]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

23. 57

22. DHCP options 60
23.1. 57
22.1. Format of DHCP options . . . . . . . . . . . . . . . . . 60
23.2. 58
22.2. Client Identifier option . . . . . . . . . . . . . . . . 60
23.3. 58
22.3. Server Identifier option . . . . . . . . . . . . . . . . 61
23.4. 59
22.4. Identity association Association option . . . . . . . . . . . . . . . 59
22.5. Identity Association for Temporary Addresses option . . . 61
23.5.
22.6. IA Address option . . . . . . . . . . . . . . . . . . . . 63
23.6. Requested Temporary Addresses (RTA) Option . . . . . . . 65
23.7.
22.7. Option Request option . . . . . . . . . . . . . . . . . . 65
23.8. 64
22.8. Preference option . . . . . . . . . . . . . . . . . . . . 66
23.9. 64

Droms (ed.), et al. Expires 22 Oct 2002 [Page iv]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

22.9. Elapsed Time . . . . . . . . . . . . . . . . . . . . . . 67
23.10. 65
22.10. Client message option . . . . . . . . . . . . . . . . . . 67
23.11. 66
22.11. Server message option . . . . . . . . . . . . . . . . . . 68
23.12. 66
22.12. Authentication option . . . . . . . . . . . . . . . . . . 68
23.13. 67
22.13. Server unicast option . . . . . . . . . . . . . . . . . . 69
23.14. 68
22.14. Status Code Option . . . . . . . . . . . . . . . . . . . 70
23.15. User Class Option . 68
22.15. Rapid Commit option . . . . . . . . . . . . . . . . . . . 70
23.16. 69
22.16. User Class Option . . . . . . . . . . . . . . . . . . . . 69
22.17. Vendor Class Option . . . . . . . . . . . . . . . . . . . 70
22.18. Vendor-specific Information option . . . . . . . . . . . 71
23.17.
22.19. Interface-Id Option . . . . . . . . . . . . . . . . . . . 72

24.
22.20. Reconfigure Message option . . . . . . . . . . . . . . . 73

23. Security Considerations 73

25.

24. Year 2000 considerations 73

26.

25. IANA Considerations 74
26.1. 73
25.1. Multicast addresses . . . . . . . . . . . . . . . . . . . 74
26.2.
25.2. Anycast addresses . . . . . . . . . . . . . . . . . . . . 74
25.3. DHCPv6 message types . . . . . . . . . . . . . . . . . . 74
26.3.
25.4. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 74
26.4. 75
25.5. DHCPv6 options . . . . . . . . . . . . . . . . . . . . . 74
26.5. 75
25.6. Status codes . . . . . . . . . . . . . . . . . . . . . . 74
26.6. 76
25.7. Authentication option . . . . . . . . . . . . . . . . . . 75

27. 76

26. Acknowledgments 75 77

References 75 77

Chair's Address 77 79

Authors' Addresses 77 79

A. Appearance of Options in Message Types 79 81

B. Appearance of Options in the Options Field of DHCP Messages 79 Options 81

C. Full Copyright Statement 80 82

1. Introduction and Overview

This document describes DHCP for IPv6 (DHCP), a UDP [19] client/server
protocol designed to reduce the cost of management
of IPv6 nodes in environments where network managers require more
control over the allocation that provides managed configuration of IPv6 devices.

DHCP can provide a device with addresses assigned by a DHCP server
and other configuration information. The addresses and additional
configuration are carried in options. DHCP can be extended through
the definition of network stack parameters than that offered by "IPv6 Stateless new options to carry configuration information not
specified in this document.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 1]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

Address Autoconfiguration" [21].

DHCP is a stateful counterpart to
stateless autoconfiguration. Note that both stateful the "stateful address autoconfiguration protocol" and stateless the
"stateful autoconfiguration can be used concurrently protocol" referred to in the same environment,
leveraging the strengths RFC2462, "IPv6
Stateless Address Autoconfiguration".

The remainder of both this introduction summarizes DHCP, explaining
the message exchange mechanisms and example message flows. The
message flows in order to reduce the
cost of ownership sections 1.3 and management 1.4 are intended as illustrations
of network nodes. DHCP reduces the cost of ownership by centralizing the management operation rather than an exhaustive list of network resources such as IP addresses, routing information, OS
installation information, directory service information, all possible
client-server interactions. Sections 17, 18 and other
such information on a few DHCP servers, rather than distributing such
information 19 explain client
and server operation in local configuration files among all network node. detail.

1.1. Protocols and addressing

Clients and servers exchange DHCP is designed to be easily extended to carry new configuration
parameters messages using UDP [17]. The
client uses its link-local address determined through the addition of new stateless
autoconfiguration for transmitting and receiving DHCP "options" defined messages.

DHCP servers receive messages from clients using a reserved,
link-scoped multicast address. A DHCP client transmits most messages
to
carry this information.

Those readers familiar reserved multicast address, so that the client need not be
configured with the address or addresses of DHCP for IPv4 [7] will find servers.

To allow a DHCP for
IPv6 provides client to send a superset of message to a DHCP server that is not
attached to the features of same link, a DHCP and benefits from relay agent on the additional features client's link
will forward messages between the client and server. The operation
of IPv6 the relay agent is transparent to the client and freedom from the constraints discussion
of
backward compatibility with BOOTP [4].

2. Requirements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear message exchanges in the remainder of this
document, are section will omit the
description of message forwarding by relay agents.

Once the client has determined the address of a server, it may
under some circumstances send messages directly to be interpreted as described in [2]. the server using
unicast.

1.2. Protocol implementation

This document also makes use specification for DHCP includes messages and descriptions of internal conceptual variables
to describe protocol
client and server behavior for several different functions. Some
clients 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 servers will be deployed in
the exact form described here, so long as its external behavior is
consistent with that described situations in this document.

3. Background

The IPv6 Specification provides the base architecture and design which not all
of
IPv6. Related work in IPv6 the functions will be required. For example, a client that would best serve an implementor uses
stateless autoconfiguration to study includes the determine its IPv6 Specification [5], addresses would
use only the IPv6 Addressing
Architecture [9], IPv6 Stateless Address Autoconfiguration [21], IPv6
Neighbor Discovery Processing [17], Information-request and Dynamic Updates to DNS [22].
These specifications enable DHCP to build upon the IPv6 work Reply messages to
provide both robust stateful autoconfiguration obtain other
configuration information.

Clients and autoregistration
of DNS Host Names.

The IPv6 Addressing Architecture specification [9] defines the
address scope servers that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers do not use all of the IPv6 address space. Two advantages functions of IPv6 are that support DHCP
need not implement processing for multicast those DHCP messages that will not
be used. A client or server that receives a message that it is required, not
prepared to process may simply discard that message. For example, a
DHCP server that only provides configuration information and nodes does not
do IPv6 address assignment can create link-local addresses respond to only Information-request
messages and discard other messages such as Solicit or Request
messages.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 2]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

during initialization. This means that a

1.3. Client-server exchanges involving two messages

A DHCP client can immediately use
its link-local address obtain configuration information such as a list
of available DNS servers or NTP servers through a single message
and reply exchanged with a well-known multicast address to begin
communications DHCP server. To obtain configuration
information the client first sends an Information-Request message
to discover neighbors on the link. For instance, All_DHCP_Relay_Agents_and_Servers multicast address. The
server responds with a Reply message containing the configuration
information for the client.

This message exchange assumes that the client requires only
configuration information and does not require the assignment of any
IPv6 addresses. Because the server need not keep any dynamic state
information about individual clients to support this two message
exchange, a server that provides just configuration information can send
be realized with a Solicit message relatively simple and locate small implementation.

When a server or relay. has IPv6 Stateless Address Autoconfiguration [21] specifies procedures
by which a node may autoconfigure addresses based on router
advertisements [17], and the use of other configuration information
committed to a valid lifetime client, the client and server may be able to support
renumbering complete
the exchange using only two messages, instead of addresses on four messages as
described in the Internet. next section. In addition this case, the
protocol interaction by which client sends a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle
Solicit message to perform
stateful autoconfiguration. Compatibility with stateless address
autoconfiguration is a design requirement of DHCP (see Section 4).

IPv6 Neighbor Discovery [17] is the node discovery protocol in IPv6
which replaces and enhances functions All_DHCP_Relay_Agents_and_Servers requesting
the assignment of ARP [18]. To understand
IPv6 addresses and stateless address autoconfiguration it is strongly
recommended other configuration information.
This message includes an indication that implementors understand IPv6 Neighbor Discovery.

Dynamic Updates to DNS [22] the client is a specification willing to
accept an immediate Reply message from the server. The server that supports
is willing to commit the
dynamic update assignment of DNS records for both IPv4 addresses to the client
immediately responds with a Reply message. The configuration
information and IPv6. DHCP can the addresses in the Reply message are then
immediately available for use by the dynamic updates to DNS client.

Each address assigned to integrate addresses the client has associated preferred and name space
valid lifetimes specified by the server. To request an extension
of the lifetimes assigned to
not only support autoconfiguration, but also autoregistration in
IPv6.

4. Design Goals

- DHCP is an address, the client sends a mechanism rather than Renew
message to the server. The server sends a policy. Network administrators
set their administrative policies through Reply message to the configuration
parameters they place upon
client with the DHCP servers in new lifetimes, allowing the DHCP domain
they're managing. DHCP is simply used to deliver parameters
according client to that policy continue to each of use
the DHCP clients within address without interruption.

1.4. Client-server exchanges involving four messages

To request the
domain.

- DHCP is compatible with assignment of one or more IPv6 stateless address
autoconfiguration [21], statically configured, non-participating
nodes and with existing network protocol implementations.

- addresses, a
client first locates a DHCP does not require manual configuration server and then requests the
assignment of network parameters
on DHCP clients, except in cases where such addresses and other configuration is
needed for security reasons. A node configuring itself using
DHCP should require no user intervention.

- DHCP does not require information
from the server. The client sends a Solicit message to the
All_DHCP_Relay_Agents_and_Servers address to find available DHCP
servers. Any server on each link. To allow that can meet the client's requirements
responds with an Advertise message. The client then chooses one
of the servers and sends a Request message to the server asking
for scale confirmed assignment of addresses and economy, DHCP must work across DHCP relays.

- DHCP clients can operate on other configuration
information. The server responds with a link without IPv6 routers present.

- DHCP will provide Reply message that contains
the ability to renumber network(s) when
required by network administrators [3]. confirmed addresses and configuration.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 3]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

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

- DHCP will contain the appropriate time out and retransmission
mechanisms to efficiently operate

As described in environments with high
latency and low bandwidth characteristics.

5. Non-Goals

This specification explicitly does not cover the following:

- Specification of previous section, the client sends a DHCP server Renew
messages to the server protocol.

- How a DHCP server stores to extend the lifetimes associated with its DHCP data.

- How
addresses, allowing the client to manage a DHCP domain or DHCP server.

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

6. Terminology

This sections defines terminology specific continue to IPv6 use those addresses
without interruption.

2. Requirements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and DHCP used OPTIONAL, when they appear in this document.

6.1. IPv6 Terminology

IPv6 terminology relevant
document, are to this specification from the IPv6
Protocol [5], IPv6 Addressing Architecture [9], be interpreted as described in [2].

This document also makes use of internal conceptual variables
to describe protocol behavior and IPv6 Stateless
Address Autoconfiguration [21] is included below.

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

unicast address An identifier for a single interface.
A packet sent
implementation must allow system administrators to a unicast address 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
delivered not required to have them in
the interface identified by exact form described here, so long as its external behavior is
consistent with that address.

multicast address An identifier for a set described in this document.

3. Background

The IPv6 Specification provides the base architecture and design of interfaces
(typically belonging
IPv6. Related work in IPv6 that would best serve an implementor
to different
nodes). A packet sent study includes the IPv6 Specification [3], the IPv6 Addressing
Architecture [7], IPv6 Stateless Address Autoconfiguration [19], IPv6
Neighbor Discovery Processing [15], and Dynamic Updates to a multicast
address is delivered DNS [20].
These specifications enable DHCP to all interfaces
identified by that address.

host Any node that is not a router.

IP Internet Protocol Version 6 (IPv6). The
terms IPv4 build upon the IPv6 work to
provide both robust stateful autoconfiguration and autoregistration
of DNS Host Names.

The IPv6 are Addressing Architecture specification [7] defines the
address scope that can be used only in

Droms (ed.), et al. Expires 1 Aug 2002 [Page 4]

Internet Draft DHCP an IPv6 implementation, and the
various configuration architecture guidelines for network designers
of the IPv6 (-23) 1 Feb 2002

contexts where it address space. Two advantages of IPv6 are that support
for multicast is necessary to avoid
ambiguity.

interface A node's attachment to a link.

link A communication facility or medium over
which required, and nodes can communicate at the link
layer, i.e., the layer immediately below
IP. Examples are Ethernet (simple or
bridged); Token Ring; PPP links, X.25,

Frame Relay, or ATM networks; and
Internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6
itself.

link-layer identifier A link-layer identifier for an
interface. Examples include IEEE 802
addresses for Ethernet or Token Ring
network interfaces, and E.164 create link-local addresses
for ISDN links.
during initialization. This means that a client can immediately use
its link-local address An IPv6 and a well-known multicast address having link-only
scope, indicated by having the prefix
(FE80::0000/64), that can be used to
reach neighboring nodes attached begin
communications to discover neighbors on the same link. Every interface has For instance, a
client can send a Solicit message and locate a server or relay agent.

IPv6 Stateless Address Autoconfiguration [19] specifies procedures
by which a
link-local address.

neighbor A node attached to may autoconfigure addresses based on router
advertisements [15], and the same link.

node A device that implements IP.

packet An IP header plus payload.

prefix The initial bits use of an address, or a
set valid lifetime to support
renumbering of IP address that share addresses on the same
initial bits.

prefix length The number of bits in Internet. In addition the
protocol interaction by which a prefix.

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

6.2. begins stateless or stateful
autoconfiguration is specified. DHCP Terminology

Terminology specific is one vehicle to DHCP can be found below.

agent address The perform
stateful autoconfiguration. Compatibility with stateless address of
autoconfiguration is a neighboring DHCP Agent
on the same link as the DHCP client. design requirement of DHCP.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 5] 4]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

binding A binding (or, client binding)

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

Dynamic Updates to DNS [20] is a
group specification that supports the
dynamic update of server data DNS records containing
the information the server has about for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space to
not only support autoconfiguration, but also autoregistration in an IA
IPv6.

4. Terminology

This sections defines terminology specific to IPv6 and any other
configuration information assigned DHCP used in
this document.

4.1. IPv6 Terminology

IPv6 terminology relevant to this specification from the client. A binding IPv6
Protocol [3], IPv6 Addressing Architecture [7], and IPv6 Stateless
Address Autoconfiguration [19] is indexed by included below.

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

anycast address An anycast address identifies a group
of nodes; message sent to an anycast
address is delivered to one node out of
the
tuple <DUID, IAID>.

DHCP Dynamic Host Configuration group of nodes associated with the
address

host Any node that is not a router.

IP Internet Protocol
for IPv6. Version 6 (IPv6). The
terms DHCPv4 IPv4 and DHCPv6 IPv6 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
delivered to the client using DHCP.
Such parameters may be used to carry
information

interface A node's attachment to be used by a node to
configure its network subsystem and
enable communication on a link or
internetwork, for example.

DHCP client (or client) A node that initiates requests on a link.

link
to obtain configuration parameters from
one or more DHCP servers.

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

DHCP server (or server) A server is a node that responds to
requests from clients, and may communication facility or
may not be on medium over
which nodes can communicate at the same link as
layer, i.e., the
client(s).

DHCP relay (or relay) A node that acts as an intermediary to
deliver DHCP messages between clients
and servers, layer immediately below
IP. Examples are Ethernet (simple or
bridged); Token Ring; PPP links, X.25,

Frame Relay, or ATM networks; and is on the same link as
a client.

DHCP agent
Internet (or agent) Either a DHCP server on the same link higher) layer "tunnels",
such as
a client, or a DHCP relay.

DUID A DHCP Unique IDentifier for a DHCP
participant; each DHCP client and server
has exactly one DUID.

Identity association (IA) A collection of addresses assigned to
a client. Each IA has an associated
IAID. An IA may have 0 tunnels over IPv4 or more addresses
associated with it. IPv6
itself.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 6] 5]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

Identity association

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

link-local address An IPv6 address having link-only
scope, indicated by having the client. Each IA has an
IAID, which is chosen to prefix
(FE80::0000/64), that can be unique among
all IAIDs used to
reach neighboring nodes attached to
the same link. Every interface has a
link-local address.

multicast address An identifier for IAs a set of interfaces
(typically belonging to that
client.

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

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

7. DHCP Constants

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

7.1. Multicast Addresses

DHCP makes use of the following multicast addresses:

All_DHCP_Agents (FF02::1:2) This link-scoped multicast
address is used delivered to all interfaces
identified by clients that address.

neighbor A node attached to communicate with the
on-link agent(s) when they do not know the
link-local address(es) for those agents. All
agents (servers and relays) are members same link.

node A device that implements IP.

packet An IP header plus payload.

prefix The initial bits of this
multicast group.

All_DHCP_Servers (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 an address, or because they do not
know the server(s) unicast address(es). Note a
set of IP address that share the same
initial bits.

prefix length The number of bits in order a prefix.

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

unicast address An identifier for a client single interface.
A packet sent to use this address,
it must have an a unicast address of sufficient scope is
delivered 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 [19] port numbers. While
source ports MAY interface identified by
that address.

4.2. DHCP Terminology

Terminology specific to DHCP can be arbitrary, found below.

binding A binding (or, client implementations SHOULD permit
their specification through binding) is a local
group of server data records containing
the information the server has about
the addresses in an IA and any other
configuration parameter information assigned to
facilitate
the use of DHCP through firewalls.

546 Client port. Used client. A binding is indexed by servers as
the destination port
for messages sent to clients and relays. Used by relay tuple <DUID, IA-type, IAID> (where

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 7] 6]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

agents as the destination port for messages sent to
clients.

547 Agent port. Used as

IA-type is the destination port by clients
for messages sent to agents. Used as type of address in the destination
port by relays
IA; for messages sent to servers.

7.3. DHCP message types

DHCP defines example, temporary)

configuration parameter An element of the following message types. More detail configuration
information set on these
message types can be found in Section 8. Message types not listed
here are reserved for future use. The message code for each message
type is shown with the message name.

SOLICIT (1) The Solicit message is used by clients server and
delivered to
locate servers.

ADVERTISE (2) The Advertise message is the client using DHCP.
Such parameters may be used by servers
responding to Solicits.

REQUEST (3) The Request message is used by clients carry
information to
request configuration parameters from servers.

CONFIRM (4) The Confirm message is be used by clients to
confirm that the addresses assigned a node to an IA
configure its network subsystem and the lifetimes
enable communication on a link or
internetwork, for those addresses, as
well as the current configuration parameters
assigned by the server to the client are still
valid.

RENEW (5) example.

DHCP Dynamic Host Configuration Protocol
for IPv6. The Renew message is terms DHCPv4 and DHCPv6
are used by clients only in contexts where it is
necessary to
update the addresses assigned avoid ambiguity.

DHCP client (or client) A node that initiates requests on a link
to an IA and the
lifetimes for those addresses, as well as the
current obtain configuration parameters assigned from
one or more DHCP servers.

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

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

DHCP server (or server) A client sends a
Renew message to the server that originally
populated the IA at time T1.

REBIND (6) The Rebind message is used by clients a node that responds to extend
requests from clients, and may or
may not be on the lifetimes of addresses assigned to an IA,
as well same link as the current configuration parameters
assigned by the server to the client.
client(s).

DUID A
client sends DHCP Unique IDentifier for a Rebind message to all available DHCP servers at time T2 only after the
participant; each DHCP client
has been unable to contact the and server that
originally populated
has exactly one DUID. See section 9 for
details of the IA with ways in which a Renew
message.

REPLY (7) The Reply message is used by servers
responding DUID may
be constructed.

Identity association (IA) A collection of addresses assigned to Request, Confirm, Renew, Rebind,
Information-request, Release and Decline
messages. In the case
a client. Each IA has an associated
IAID. A client may have more than one
IA assigned to it; for example, one for
each of responding its interfaces.

Identity association identifier (IAID) An identifier for an IA,
chosen by the client. Each IA has an
IAID, which is chosen to be unique among
all IAIDs for IAs belonging to that
client.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 8] 7]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

a Request, Confirm, Information-request,
Renew or Rebind message, the Reply contains
configuration parameters destined for the
client.

RELEASE (8) The Release

message is used by clients to
indicate A unit of data carried in a packet,
exchanged among DHCP servers, relay
agents and clients.

transaction-ID An unsigned integer to match responses
with replies initiated either by a server that the
client will no
longer use one or more addresses in an IA.

DECLINE (9) The Decline message is server.

5. DHCP Constants

This section describes various program and networking constants used
by clients to
indicate that the client has determined that
one or more addresses in an IA are already
in DHCP.

5.1. Multicast Addresses

DHCP makes use on the link to which of the client is
connected.

RECONFIGURE (10) The Reconfigure message is sent following multicast addresses:

All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped
multicast address used by a server client to inform communicate with
neighboring (i.e., on-link) relay agents and servers.
All servers and relay agents are members of this
multicast group.

All_DHCP_Servers (FF05::1:3) A site-scoped multicast address
used by a client that the server has new or
updated configuration parameters, and that relay agent to communicate with
servers, either because the client is to initiate a Renew/Reply or
Information-request/Reply transaction with
the server in order relay agent
wants to receive the updated
information.

INFORMATION-REQUEST (11) The Information-request message is sent
by clients send messages to request configuration parameters
without all servers or because it
does not know the assignment of any IP unicast addresses to of the client.

RELAY-FORW (12) The Relay-forward message is used by relays to
forward client messages to servers. The client
message is encapsulated in an option
Note that in the
Relay-forward message.

RELAY-REPL (13) The Relay-reply message is used by servers to
send messages to clients through order for a relay. The
server encapsulates the client message as an
option in the Relay-reply message, which the or relay extracts and forwards agent to use
this address, it must have an address of sufficient
scope to be reachable by the client.

7.4. Status Codes

This section describes status codes exchanged between DHCP
implementations. These status codes may appear in the Status Code
option or in servers. All servers
within the status field site are members of an IA.

7.4.1. Generic Status Codes

The status codes in this section are used between clients and servers multicast group.

5.2. Anycast address

DHCP proposes to convey status conditions. The use the following table contains reserved anycast address:

DHCP_Anycast (FEC0:0:0:0:FFFF::4) This document proposes the status
codes,
assignment of the name DHCP_Anycast address for each code (as used in this document) use
by clients attached to links that do not support
multicast.

5.3. UDP ports

Clients listen for DHCP messages on UDP port 546. Servers and a brief relay
agents listen for DHCP messages on UDP port 547.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 9] 8]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

description. Note that

5.4. DHCP message types

DHCP defines the numeric values do not start at 1, nor are
they consecutive. The status codes are organized in logical groups.

Name Code Description
---------- ---- -----------
Success 0 Success
UnspecFail 16 Failure, reason unspecified
AuthFailed 17 Authentication failed or nonexistent
PoorlyFormed 18 Poorly formed following message
AddrUnavail 19 Addresses unavailable
OptionUnavail 20 Requested options unavailable

7.4.2. Server-specific Status Codes

The status codes types. More detail on these
message types can be found in this section Section 6. Message types not listed
here are used by servers to convey status
conditions to clients. reserved for future use. The following table contains the status
codes, the name message code for each code (as used in this document) and message
type is shown with the message name.

SOLICIT (1) A client sends a brief
description. Note Solicit message to locate
servers.

ADVERTISE (2) A server sends an Advertise message to indicate
that the numeric values do not start at 1, nor are
they consecutive. The status codes are organized in logical groups.

Name Code Description
---- ---- -----------
NoBinding 32 Client record (binding) unavailable
ConfNoMatch 33 Client record Confirm doesn't match IA
RenwNoMatch 34 Client record Renew doesn't match IA
RebdNoMatch 35 Client record Rebind doesn't match IA
InvalidSource 36 Invalid Client IP address
NoPrefixMatch 37 One or more prefixes of the addresses
in the IA it is not valid available for the link DHCP service, in
response to a Solicit message received from which the a
client.

REQUEST (3) A client sends a Request message was received

Droms (ed.), et al. Expires 1 Aug 2002 [Page 10]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

7.5. Configuration Variables

This section presents to request
configuration parameters from a table of server.

CONFIRM (4) A client and sends a Confirm message to servers to
request that the server configuration
variables validate and confirm
that the default or initial values for these variables.

Parameter Default Description
-------------------------------------
MIN_SOL_DELAY 1 sec Min delay of first Solicit
MAX_SOL_DELAY 5 secs Max delay of first Solicit
SOL_TIMEOUT 500 msecs Initial Solicit timeout
SOL_MAX_RT 30 secs Max Solicit timeout value
REQ_TIMEOUT 250 msecs Initial Request timeout
REQ_MAX_RT 30 secs Max Request timeout value
REQ_MAX_RC 10 Max Request retry attempts
CNF_TIMEOUT 250 msecs Initial Confirm timeout
CNF_MAX_RT 1 sec Max Confirm timeout
CNF_MAX_RD 10 secs Max Confirm duration
REN_TIMEOUT 10 sec Initial Renew timeout
REN_MAX_RT 600 secs Max addresses and current configuration
parameters assigned by the server to the client
are still valid.

RENEW (5) A client sends a Renew timeout value
REB_TIMEOUT 10 secs Initial message to the server
that originally provided the client's addresses
and configuration addresses to update the
addresses assigned to the client and the
lifetimes for those addresses, as well as the
current configuration parameters assigned by
the server to the client.

REBIND (6) A client sends a Rebind timeout
REB_MAX_RT 600 secs Max message to update
the addresses assigned to the client and the
lifetimes for those addresses, as well as the
current configuration parameters assigned by
the server to the client; this message is sent
after a client receives no response to a Renew
message.

REPLY (7) A server sends a Reply message containing
assigned addresses and configuration parameters
in response to a Solicit, Request, Renew,
Rebind timeout value
INF_TIMEOUT 500 ms Initial Information-request timeout
INF_MAX_RT 30 secs Max or Information-request timeout value
REL_TIMEOUT 250 msecs Initial Release timeout
REL_MAX_RT 1 sec Max Release timeout
REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 250 msecs Initial Decline timeout
DEC_MAX_RT 1 sec Max Decline timeout
DEC_MAX_RC 5 Max message received
from a client. A server sends a Reply message
confirming or denying the validity of the
client's addresses and configuration parameters
in response to a Confirm message. A server
sends a Reply message to acknowledge receipt of
a Release or Decline attempts

8. Message Formats

All message.

RELEASE (8) A client sends a Release message to the server
that assigned addresses to the client to

Droms (ed.), et al. Expires 22 Oct 2002 [Page 9]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

indicate that the client will no longer use one
or more of the assigned addresses.

DECLINE (9) A client sends a Decline message to a server to
indicate that the client has determined that
one or more addresses assigned by the server
are already in use on the link to which the
client is connected.

RECONFIGURE (10) A server sends a Reconfigure message to a
client to inform the client that the server has
new or updated configuration parameters, and
that the client is to initiate a Renew/Reply
or Information-request/Reply transaction with
the server in order to receive the updated
information.

INFORMATION-REQUEST (11) A client sends an Information-request
message to a server to request configuration
parameters without the assignment of any IP
addresses to the client.

RELAY-FORW (12) A relay agent sends a Relay-forward message to
forward client messages to servers. The client
message is encapsulated in an option in the
Relay-forward message.

RELAY-REPL (13) A server sends a Relay-reply message to a relay
agent to send messages to clients through the
relay agent. The server encapsulates the
client message as an option in the Relay-reply
message, which the relay agent extracts and
forwards to the client.

5.5. Status Codes

DHCPv6 uses status codes to communicate the success or failure of
operations requested in messages sent between from clients and servers share an identical
fixed format header servers, and a variable format area for options. Not all
fields in to
provide additional information about the header are used in every message.

All values in specific cause of the message header and in options
failure of a message. The specific status codes are defined in network order.
section 25.6.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 11] 10]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

The following diagram illustrates the format

5.6. Configuration Parameters

This section presents a table of DHCP messages sent
between clients and servers:

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 | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following sections configuration parameters used to
describe the use of the fields in the DHCP message header in each transmission behavior of the DHCP messages. In these descriptions,
fields that are not used in a message are marked as "unused". All
unused fields in a message MUST be transmitted as zeroes clients and ignored
by the receiver servers.

Parameter Default Description
-------------------------------------
MIN_SOL_DELAY 1 sec Min delay of the message.

8.1. DHCP first Solicit Message Format

msg-type SOLICIT

transaction-ID An unsigned integer generated by the client used
to identify this
MAX_SOL_DELAY 5 secs Max delay of first Solicit message.

options See section 23.

8.2. DHCP Advertise Message Format

msg-type ADVERTISE

transaction-ID An unsigned integer used to identify this
Advertise message. Copied from the
SOL_TIMEOUT 500 msecs Initial Solicit timeout
SOL_MAX_RT 30 secs Max Solicit
message received from the client.

options See section 23.

8.3. DHCP timeout value
REQ_TIMEOUT 250 msecs Initial Request Message Format

msg-type REQUEST

transaction-ID An unsigned integer generated by the client used
to identify this timeout
REQ_MAX_RT 30 secs Max Request message.

options See section 23.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 12]

Internet Draft DHCP for IPv6 (-23) timeout value
REQ_MAX_RC 10 Max Request retry attempts
CNF_TIMEOUT 250 msecs Initial Confirm timeout
CNF_MAX_RT 1 Feb 2002

8.4. DHCP sec Max Confirm Message Format

msg-type CONFIRM

transaction-ID An unsigned integer generated by the client used
to identify this timeout
CNF_MAX_RD 10 secs Max Confirm message.

options See section 23.

8.5. DHCP duration
REN_TIMEOUT 10 sec Initial Renew Message Format

msg-type RENEW

transaction-ID An unsigned integer generated by the client used
to identify this timeout
REN_MAX_RT 600 secs Max Renew message.

options See section 23.

8.6. DHCP timeout value
REB_TIMEOUT 10 secs Initial Rebind Message Format

msg-type REBIND

transaction-ID An unsigned integer generated by the client used
to identify this timeout
REB_MAX_RT 600 secs Max Rebind message.

options See section 23.

8.7. DHCP Reply timeout value
INF_TIMEOUT 500 ms Initial Information-request timeout
INF_MAX_RT 30 secs Max Information-request timeout value
REL_TIMEOUT 250 msecs Initial Release timeout
REL_MAX_RT 1 sec Max Release timeout
REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 250 msecs Initial Decline timeout
DEC_MAX_RT 1 sec Max Decline timeout
DEC_MAX_RC 5 Max Decline attempts

6. Message Format

msg-type REPLY

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

All DHCP messages sent between clients and servers share an identical
fixed format header and a variable format area for options.

All values in the client Request,
Confirm, Renew or Rebind message received from
the client.

options See section 23.

8.8. DHCP Release Message Format

msg-type RELEASE

transaction-ID An unsigned integer generated by the client used
to identify this Release message. header and in options See section 23. are in network order.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 13] 11]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

8.9.

The following diagram illustrates the format of DHCP Decline Message Format messages sent
between clients and servers:

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 DECLINE | transaction-ID An unsigned integer generated by the client used
to identify this Decline message. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options See section 23.

8.10. DHCP Reconfigure Message Format .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type RECONFIG

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

options See DHCP message type; the
available message types are listed in
section 23.

8.11. Information-Request Message Format

msg-type INFORMATION-REQUEST

transaction-ID 5.4.

transaction-id An unsigned integer generated used by the a client used or
server to identify this Information-request match a response message to a
request message.

options See Options carried in this message; options are
described in section 23.

9. 22.

7. Relay agent messages

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

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 14] 12]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

There are two relay agent messages, which share the following format:

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

The following sections describe the use of the Relay Agent message
header.

9.1.

7.1. Relay-forward message

The following table defines the use of message fields in a
Relay-forward message.

msg-type RELAY-FORW

link-address An A global or site-local address with a prefix that is assigned will be used
by the server to identify the link from on which the
client should
be assigned an address.

client-return-address is located.

client-address The IPv6 source address in which of the
message client from which the client message
to be forwarded was received by
the relay agent

options MUST include a "Client message option";
see option" (see
section 23.10; 22.10); MAY include other options added
by the relay agent

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 15] 13]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

9.2.

7.2. Relay-reply message

The following table defines the use of message fields in a
Relay-reply message.

msg-type RELAY-REPL

link-address The link-address copied from the Relay-forward message; used by the relay
agent to select the link on which the
message is returned to the client

client-return-address

client-address The source address client's address, copied from the IP datagram
in which the
relay-forward message from the client was
received by the relay agent

options MUST include a "Server message option"; see
section 23.11; 22.11; MAY include other options

10.

8. Representation and use of domain names

So that domain names may be encoded uniformly encoded uniformly and compactly, a
domain name or a list of domain names is encoded using the technique
described in sections 3.1 and 4.1.4 of RFC1035 [12]. Section 4.1.4
of RFC1035 describes how more than one domain name can be represented
in a list of domain names. For use in this specification, in a
list of domain names, the compression pointer (see section 4.1.4 of
RFC1035) refers to the offset within the list.

9. DHCP unique identifier (DUID)

Each DHCP client and server has a DUID. DHCP servers use DUIDs to
identify clients for the selection of configuration parameters and
in the association of IAs with clients. DHCP clients use DUIDs to
identify a server in messages where a server needs to be identified.
See sections 22.2 and 22.3 for the representation of a DUID in a DHCP
message.

Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT in any
other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the types defined in this document as additional DUID types
may be defined in the future.

The DUID is carried in an option because it may be variable length
and because it is not required in all DHCP messages. The DUID is
designed to be unique across all DHCP clients and compactly, servers, and
consistent for any specific client or server - that is, the DUID
used by a
domain name client or server SHOULD NOT change over time; for example,
a list device's DUID should not change as a result of domain names is encoded using the technique
described a change in sections 3.1 and 4.1.4 of RFC1035 [14]. Section 4.1.4
of RFC1035 describes how the
device's network hardware.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 14]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

The motivation for having more than one domain name can type of DUID is that the DUID
must be represented
in a list globally unique, and must also be easy to generate. The sort
of domain names. For use in this specification, globally-unique identifier that is easy to generate for any given
device can differ quite widely. Also, some devices may not contain
any persistent storage. Retaining a generated DUID in such a
list of domain names, device
is not possible, so the compression pointer (see section 4.1.4 DUID scheme must accommodate such devices.

9.1. DUID contents

A DUID consists of
RFC1035) refers to the offset within the list.

If a single domain name is being used two octet type code represented in network
order, followed by a vendor as a vendor
identifier, then the vendor MUST ensure variable number of octets that make up the domain name has not
previously been used by a different vendor.

11. DHCP
actual identifier. A DUID can be no more than 256 octets long. The
following types are currently defined:

1 Link-layer address plus time
2 Vendor-assigned unique identifier (DUID)

Each DHCP client and server has a DUID. DHCP servers use DUIDs to
identify clients ID based on domain name
3 Vendor-assigned unique ID based on Enterprise Number
4 Link-layer address

Formats for the selection variable field of configuration parameters and
in the association DUID for each of the above
types are shown below.

9.2. DUID based on link-layer address plus time

This type of DUID consists of IAs with clients. DHCP clients use DUIDs to
identify a server in messages where two octet type field containing the
value 1, a server needs two octet hardware type code, four octets containing
a time value, followed by link-layer address of any one network
interface that is connected to be identified.
See sections 23.3 and 23.2 for the representation of a DHCP device at the time that the
DUID is generated. The time value is the time that the DUID is
generated represented in a DHCP
message.

Clients and servers seconds since midnight (UTC), January 1,
2000, modulo 2^32. The hardware type MUST treat DUIDs be a valid hardware type
assigned by the IANA as opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT described in any
other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the types defined section on ARP in this document as additional DUID types
may be defined RFC 826.
Both the time and the hardware type are stored in network order.

The following diagram illustrates the future. format of a DUID based on
link-layer address plus time:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 16] 15]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

The DUID is carried in an option because it may be variable length
and because it is not required in all DHCP options. The DUID is
designed to be unique across all DHCP clients and servers, and
consistent for any specific client or server - that is, the DUID used
by a client or server SHOULD NOT change over time, for example, as a
result choice of network hardware reconfiguration.

The motivation for having more than one type of DUID is that the DUID
must be globally unique, and must also interface can be easy to generate. The sort
of globally-unique identifier completely arbitrary, as long
as that is easy to generate for any given
device can differ quite widely. Also, some devices may not contain
any persistent storage. Retaining a generated DUID in such interface provides a device
is not possible, so unique link-layer address, and the same
DUID scheme must accommodate such devices.

11.1. DUID contents

A DUID consists of a sixteen-bit type code represented should be used in configuring all network
order, followed by a variable number of octets that make up the
actual identifier. A DUID can be no more than 256 octets long. The
following types are currently defined:

1 Link-layer address plus time
2 Vendor-assigned unique ID
3 Link-layer interfaces connected
to the device, regardless of which interface's link-layer address

Formats for was
used to generate the variable field DUID.

Clients and servers using this type of DUID MUST store the DUID for each of
in stable storage, and MUST continue to use this DUID even if the
network interface used to generate the above
types are shown below.

11.2. DUID based on link-layer address plus time

This is removed. Clients and
servers that do not have any stable storage MUST NOT use this type of
DUID.

Clients and servers that use this DUID consists SHOULD attempt to configure
the time prior to generating the DUID, if that is possible, and MUST
use some sort of time source (for example, a two octet type field containing real-time clock) in
generating the
value 1, a two octet hardware type code, four octets containing
a DUID, even if that time value, followed by link-layer address source could not be configured
prior to generating the DUID. The use of any one a time source makes it
unlikely that two identical DUIDs will be generated if the network
interface that is connected removed from the client and another client then uses
the same network interface to generate a DUID. A DUID collision is
very unlikely even if the clocks haven't been configured prior to
generating the DUID.

This method of DUID generation is recommended for all general purpose
computing devices such as desktop computers and laptop computers, and
also for devices such as printers, routers, and so on, that contain
some form of writable non-volatile storage.

Despite our best efforts, it is possible that this algorithm for
generating a DUID could result in a client identifier collision. A
DHCP device at the time client that the generates a DUID is generated. The time value is the time using this mechanism MUST provide
an administrative interface that replaces the existing DUID is
generated represented in seconds since midnight (UTC), January 1,
2000, modulo 2^32. with a
newly-generated DUID of this type.

9.3. Vendor-assigned unique ID based on Domain Name (VUID-DN)

The hardware type MUST be vendor-assigned unique ID based on the domain name consists of a valid hardware type
assigned by
two-octet value giving the IANA as described in length of the section on ARP in RFC 826.
Both identifier, the time value of the
identifier and the hardware type are stored in network order. vendor's registered domain name.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 17] 16]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

The following diagram illustrates summarizes the format structure of a DUID based on
link-layer address plus time: VUID-DN:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 2 | Hardware type (16 bits) identifier length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time (32 bits) |
. .
. identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address domain name (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The choice of network interface can be completely arbitrary, as long
as that interface provides a unique link-layer address, and the same
DUID should be used in configuring all network interfaces connected
to the device, regardless of which interface's link-layer address was
used to generate the DUID.

Clients and servers using this type source of DUID MUST store the DUID
in stable storage, and MUST continue to use this DUID even if the
network interface used to generate the DUID identifier is removed. Clients and
servers that do not have any stable storage MUST NOT use this type of
DUID.

Clients and servers that use this DUID SHOULD attempt left up to configure the time prior vendor defining it,
but each identifier part of each VUID-DN MUST be unique to generating the DUID, if device
that is possible, using it, and MUST
use some sort of time source (e.g., a real-time clock) in generating
the DUID, even if that time source could not be configured prior assigned to
generating the DUID. The use of a device at the time source makes it unlikely that
two identical DUIDs will of
manufacture and stored in some form of non-volatile storage. The
VUID-DN SHOULD be generated if the network interface recorded in non-erasable storage. The domain name
is
removed from simply any domain name that has been legally registered by the client and another client then uses
vendor in the same network
interface to generate domain name system [11], stored in the form described
in section 8.

If a DUID. A DUID collision domain name is very unlikely even
if being used by a vendor as a vendor identifier,
then the clocks haven't been configured prior to generating vendor MUST ensure that the DUID. domain name has not previously
been used by a different vendor.

An example DUID of this type might look like this:

+---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 8 | 12|192|132|221|
+---+---+---+---+---+---+---+---+
| 3 | 0 | 9 | 18|101|120| 97|109|
+---+---+---+---+---+---+---+---+
|112|108|101| 46| 99|111|109|
+---+---+---+---+---+---+---+

This method example includes the two-octet type of DUID generation is recommended for all general purpose
computing devices such as desktop computers and laptop computers, and
also for devices such as printers, routers, and so on, that contain
some form 2, the two-octet length
of writable non-volatile storage.

11.3. 8, eight octets of identifier data, followed by "example.com"
represented in ASCII.

9.4. Vendor-assigned unique ID (VUID) based on Enterprise Number (VUID-EN)

The vendor-assigned unique ID based on Enterprise Number consists
of a two-octet value giving
the length of the identifier, vendor's registered Enterprise Number as maintained by IANA
followed by the value of the idnetifier and the
vendor's registered domain name. identifier.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 18] 17]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

The following diagram summarizes the structure of a VUID: VUID-EN:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 3 | identifier length Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
| Enterprise Number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. domain name (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The source of the identifier is left up to the vendor defining it,
but each identifier part of each VUID VUID-EN MUST be unique to the device
that is using it, and MUST be assigned to the device at the time of
manufacture and stored in some form of non-volatile storage. The
VUID SHOULD be recorded in non-erasable storage. The domain name Enterprise
Number is simply any domain name that has been legally registered by the
vendor in the domain name system [13], stored in vendor's Enterprise code from the form described list "SMI Network
Management Private Enterprise Codes", as maintained by IANA in section 10. file
ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers. The
Enterprise Number is stored as an unsigned 32 bit number.

An example DUID of this type might look like this:

+---+---+---+---+---+---+---+---+
| 0 | 2 3 | 0 | 8 0 | 12|192|132|221|
+---+---+---+---+---+---+---+---+ 0 | 9| 12|192|
+---+---+---+---+---+---+---+---+
|132|221| 3 | 0 | 9 | 18|101|120| 97|109|
+---+---+---+---+---+---+---+---+
|112|108|101| 46| 99|111|109|
+---+---+---+---+---+---+---+ 18|
+---+---+---+---+---+---+

This example includes the two-octet type of 2, 3, the two-octet length
of 8, Enterprise Number
(9), followed by eight octets of identifier data, followed by "example.com"
represented in ASCII.

11.4. data.

9.5. Link-layer address

This type of DUID consists of two octets containing the DUID type 3, 4,
a two octet network hardware type code, followed by the link-layer
address of any one network interface that is permanently connected to
the client or server device and cannot device. For example, this DUID could be removed. used
by a host that has a network interface implemented in a chip that is
unlikely to be removed and used elsewhere. The hardware type MUST
be a valid hardware type assigned by the IANA as described in the
section on ARP in RFC 826. The hardware type is stored in network
order.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 19] 18]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

The following diagram illustrates the format of a DUID based on
link-layer address:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 4 | Hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The choice of network interface can be completely arbitrary, as
long as that interface provides a unique link-layer address and
is permanently attached to the device on which the DUID is being
generated. The same DUID should be used in configuring all network
interfaces connected to the device, regardless of which interface's
link-layer address was used to generate the DUID.

This type of DUID is recommended for devices that have a
permanently-connected network interface with a link-layer address and
do not have nonvolatile, writable stable storage. This type of DUID
MUST NOT be used by DHCP clients or servers that cannot tell whether
or not a network interface is permanently attached to the device on
which the DHCP client is running.

12.

10. 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 an IAID and associated configuration information.

A client must associate at least one distinct IA with each of
its network interfaces and uses that IA to obtain configuration
information from a server for that interface. Other distinct IAs may
be associated with applications. Each IA must be
associated with exactly one interface.

The IAID uniquely identifies the IA and must be chosen to be unique
among the IAIDs on the client. The IAID is chosen by the client.
For any given use of an IA by the client, the IAID for that IA MUST
be consistent across restarts of the DHCP client. The client may
maintain consistency either by storing the IAID in non-volatile
storage or by using an algorithm that will consistently produce the
same IAID as long as the configuration of the client has not changed.
There may be no way for a client to maintain consistency of the IAIDs
if it does not have non-volatile storage and the client's hardware
configuration changes.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 20]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

The configuration information in an IA consists of one or more IPv6
addresses and other parameters. The parameters are specified as DHCP

Droms (ed.), et al. Expires 22 Oct 2002 [Page 19]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

options within the IA, and are associated with the addresses in the
IA and the interface to which the IA belongs. Other parameters that
are not associated with a particular interface may be specified in
the options section of a DHCP message, outside the scope of any IA.

Each address in an IA has a preferred lifetime and a valid lifetime,
as defined in RFC2462 [21]. [19]. The lifetimes are transmitted from the
DHCP server to the client in the IA option. The lifetimes apply to
the use of IPv6 addresses as described in section 5.5.4 of RFC2462.
An address whose valid lifetime has expired MAY be discarded from the
IA.

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

13.

11. Selecting addresses for assignment to an IA

A server selects addresses to be assigned to an IA according to the
address assignment policies determined by the server administrator
and the specific information the server determines about the client
from some combination of the following sources:

- The link to which the client is attached. The server determines
the link as follows:

* If the server receives the message directly from the client
and the source address in the IP datagram in which the
message was received is a link-local address, then the client
is on the same link to which the interface over which the
message was received is attached

* If the server receives the message from a forwarding relay
agent, then the client is on the same link as the one to
which the interface identified by the link-address field in
the message from the relay is attached

- The DUID supplied by the client

- Other information in options supplied by the client

- Other information in options supplied by from the relay agent

- is attached

* If the server receives the message directly from the client
and the source address in the IP datagram in which the
message was received is not a link-local address, then the
client is on the link identified by the source address in the
IP datagram (note that this situation can occur only if the
server has enabled the use of unicast message delivery by the
client and the client has sent a message for which unicast
delivery is allowed)

- The DUID supplied by the client

- Other information in options supplied by the client

- Other information in options supplied by the relay agent

A server MUST generate link identifiers for unicast addresses with
the "u" (universal/local) and "g" (individual/group) bits of the
EUI-64 identifier set to 0 (see RFC 2373).

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 21] 20]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

The addresses that the

A server selects for the client MUST be valid on
the link to which the interface NOT assign an address that is attached, regardless of the way in
which the server selects the addresses.

14. otherwise reserved by
IANA.

12. Management of temporary addresses

A client may be assigned temporary addresses [16]. (temporary addresses
are defined in RFC 3041 [14]). Clients and servers simply label identify
addresses as "temporary". DHCPv6 handling of address lifetimes and lifetime extensions assignment is
no different for temporary addresses. DHCPv6 says nothing about
details of temporary addresses like lifetimes, lifetime extensions, how clients use
temporary addresses, rules for generating successive temporary
addresses, etc.

In DHCP, temporary addresses are identified with T-bit set in the IA
Address Option(see section 23.5). A client may have zero or more
temporary addresses. Addresses with the T-bit set MUST be intended
for the client to use for the general purposes described in RFC3041.
Addresses that otherwise have short lifetimes or are not intended to
be renewed by the server MUST NOT have the T-bit set.

Clients ask for temporary addresses and servers assign them. When
a client sends an IA to a server, the client lists all of the
temporary addresses it knows about and optionally indicates how many
additional temporary
Temporary addresses it wants are carried in the Requested Identity Association for
Temporary Addresses Option(see (IA_TA) option (see section 23.6). The server compares the number
of requested additional temporary addresses against any previously
allocated 22.5). Each IA_TA
option contains at most one temporary addresses address for each of the IA that were not reported
by the client in the IA but still have some reasonable preferred
lifetime left. If the number of temporary addresses is less than the
requested number, the server adds additional temporary addresses to
the IA to satisfy
prefixes on the requested number (subject link to server policy).

DISCUSSION:

It is important that the server include any allocated
temporary addresses that were not reported by which the client as
it is possible attached.

Unless otherwise stated, an IA_TA option is used in the client never received same way in
as an earlier Reply
that contained these additional temporary addresses. If IA option. In the server did not consider these, a client that fails to
receive protocol specification, unless otherwise
stated, a server's reply might cause the server reference to allocate
many temporary addresses.

When the valid lifetime on a temporary address expires, both the
client and server silently discard the address from the IA. an IA should be read as either an IA or an
IA_TA.

The
discarded address no longer counts against the client's allotment of
temporary addresses.

A server SHOULD NOT assign a client temporary addresses without the
client having specifically asked IAID number space for it. The client the IA_TA option IAID number space is not obligated
to install address(es) that it receives and did not request and can
release any addresses it does not want.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 22]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002
separate from the IA option IAID number space.

The server MAY update the DNS for a temporary address as described in
section 4 of RFC3041, and MUST NOT update the DNS in any other way
for a temporary address.

15.

13. Transmission of messages by a client

Unless otherwise specified, a client sends DHCP messages to the
All_DHCP_Relay_Agents_and_Servers or the DHCP_Anycast address.

If the client is attached to a link that supports multicast
transmission, the client sends DHCP messages to the
All_DHCP_Relay_Agents_and_Servers address. If the client is
attached to a link that does not support multicast transmission, the
client uses the DHCP_Anycast address.

A client may send some messages directly to a server using unicast,
as described in section 22.13.

14. Reliability of Client Initiated Message Exchanges

DHCP clients are responsible for reliable delivery of messages in the
client-initiated message exchanges described in sections 18 17 and 19. 18.
If a DHCP client fails to receive an expected response from a server,

Droms (ed.), et al. Expires 22 Oct 2002 [Page 21]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

the client must retransmit its message. This section describes the
retransmission strategy to be used by clients in client-initiated
message exchanges.

Note that the procedure described in this section is slightly
modified for use with the Solicit message (section 18.1.2). 17.1.2).

The client begins the message exchange by transmitting a message to
the server. The message exchange terminates when either the client
successfully receives the appropriate response or responses from a
server or servers, or when the message exchange is considered to have
failed according to the retransmission mechanism described below.

The client retransmission behavior is controlled and described by the
following variables:

RT Retransmission timeout

IRT Initial retransmission time

MRC Maximum retransmission count

MRT Maximum retransmission time

MRD Maximum retransmission duration

RAND Randomization factor

With each message transmission or retransmission, the client sets RT
according to the rules given below. If RT expires before the message
exchange terminates, the client recomputes RT and retransmits the
message.

Each of the computations of a new RT include a randomization factor
(RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to
minimize synchronization of messages transmitted by DHCP clients.
The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different
sequence of numbers from each invocation of the DHCP client.

RT for the first message transmission is based on IRT:

Droms (ed.), et al. Expires 1 Aug 2002 [Page 23]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

RT = 2*IRT + RAND*IRT

RT for each subsequent message transmission is based on the previous
value of RT:

RT = 2*RTprev + RAND*RTprev

Droms (ed.), et al. Expires 22 Oct 2002 [Page 22]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

MRT specifies an upper bound on the value of RT. If MRT has a value
of 0, there is no upper limit on the value of RT. Otherwise:

if (RT > MRT)
RT = MRT + RAND*MRT

MRC specifies an upper bound on the number of times a client may
retransmit a message. If MRC has a value of 0, the client MUST
continue to retransmit the original message until a response is
received. Otherwise, the message exchange fails once the client has
transmitted the message MRC times.

MRD specifies an upper bound on the length of time a client may
retransmit a message. If MRD has a value of 0, the client MUST
continue to retransmit the original message until a response is
received. Otherwise, the message exchange fails once the client has
transmitted the message MRD seconds.

If both MRC and MRD are non-zero, the message exchange fails whenever
either of the conditions specified in the previous two paragraphs are
met.

16.

15. Message validation

Servers MUST discard any received messages that include
authentication information and fail the authentication check by the
server.

Clients MUST discard any received messages that include
authentication information and fail the authentication check by the
client, except as noted in section 22.6.5.2.

16.1. 21.5.5.2.

15.1. Use of Transaction-ID field

The "transaction-ID" field holds a value used by clients and servers
to synchronize server responses to client messages. A client SHOULD
choose a different transaction-ID for each new different transaction-ID for each new message it sends. A
client MUST leave the transaction-ID unchanged in retransmissions of
a message.

15.2. Solicit message

Clients MUST discard any received Solicit messages.

Servers MUST discard any Solicit messages that do not include a
Client Identifier option.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 23]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

15.3. Advertise message

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

- the message does not include a Server Identifier option

- the message does not include a Client Identifier option

- the contents of the Client Identifier option does not match the
client's DUID

- the "Transaction-ID" field value does not match the value the
client used in its Solicit message

Servers and relay agents MUST discard any received Advertise
messages.

15.4. Request message

Clients MUST discard any received Request messages.

Servers MUST discard any received Request message that meet any of
the following conditions:

- the message does not include a Server Identifier option

- the contents of the Server Identifier option do not match the
server's identifier

- the message does not include a Client Identifier option

15.5. Confirm message

Clients MUST discard any received Confirm messages.

Servers MUST discard any Confirm messages received that do not
include a Client Identifier option.

15.6. Renew message it sends. A
client

Clients MUST leave the transaction-ID unchanged in retransmissions discard any received Renew messages.

Servers MUST discard any received Renew message that meets any of the
following conditions:

- the message does not include a message. Server Identifier option

- the contents of the Server Identifier option do not match the
server's identifier

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 24]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

16.2. Solicit

- the message does not include a Client Identifier option

15.7. Rebind message

Clients MUST discard any received Solicit Rebind messages.

Relay agents MUST discard any Solicit messages received through port
546.

Servers MUST discard any Solicit messages received Rebind message that do does not
include a Client Identifier option.

16.3. Advertise message

15.8. Decline messages

Clients MUST discard any received Advertise messages Decline messages.

Servers MUST discard any received Decline message that meet meets any of
the following conditions:

- the message does not include a Server Identifier option

- the message does not include a Client Identifier option

- the contents of the Client Server Identifier option does do not match the
client's DUID
server's identifier

- the "Transaction-ID" field value message does not match the value the
client used in its Solicit message

Servers and relay agents MUST discard any received Advertise
messages.

16.4. Request include a Client Identifier option

15.9. Release message

Clients MUST discard any received Request Release messages.

Relay agents MUST discard any Request messages received through port
546.

Servers MUST discard any received Request Decline message that meet meets any of
the following conditions:

- the message does not include a Server Identifier option

- the contents of the Server Identifier option do not match the
server's identifier

- the message does not include a Client Identifier option

16.5. Confirm

15.10. Reply message

Clients MUST discard any received Confirm messages. Reply messages that meet any of the
following conditions:

- the message does not include a Server Identifier option

- the "transaction-ID" field in the message does not match the
value used in the original message

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 25]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

Relay agents MUST discard any Confirm messages received through port
546.

Servers MUST discard any Confirm messages received that do

- the message does not include a Client Identifier option.

16.6. Renew option and the
original message

Clients from the client contained a Client Identifier
option

- the message includes a Client Identifier option and the contents
of the Client Identifier option does not match the DUID of the
client

Servers and relay agents MUST discard any received Renew Reply messages.

Relay

15.11. Reconfigure message

Servers and relay agents MUST discard any Renew messages received through port
546.

Servers Reconfigure
messages.

Clients MUST discard any received Renew message Reconfigure messages that meets meet any of the
following conditions:

- the message does not include a Server Identifier option

- the contents of the Server Identifier option do not match the
server's identifier

- the message does not include a Client Identifier contain an authentication option

16.7. Rebind

- the message fails the authentication validation performed by the
client

15.12. Information-request message

Clients MUST discard any received Rebind Information-request messages.

Relay agents MUST discard any Rebind messages received through port
546.

Servers MUST MAY discard any received Rebind message Information-request messages that does do
not include a Client Identifier option.

16.8. Decline messages

Clients

Servers MUST discard any received Decline messages.

Relay agents Information-request message that
includes a Server Identifier option and the DUID in the option does
not match the server's DUID.

15.13. Relay-forward message

Clients MUST discard any Decline messages received through port
546.

Servers Relay-forward messages.

15.14. Relay-reply message

Clients and servers MUST discard any received Decline Relay-reply messages.

16. Client Source Address and Interface Selection

When a client sends a DHCP message that meets any to the
All_DHCP_Relay_Agents_and_Servers multicast address, it MUST

Droms (ed.), et al. Expires 22 Oct 2002 [Page 26]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

use the IPv6 link-local address assigned to the interface for which
the client is interested in obtaining configuration as the source
address in the header of the following conditions:

- IP datagram.

When a client sends a DHCP message to the DHCP_Anycast address, it
MUST use an address assigned to the interface for which the client
is interested in obtaining configuration, which is suitable for use
by the message does not include a Server Identifier option

- server in responding to the contents of client, as the Server Identifier option do not match source address in
the
server's identifier

- header of the message does not include IP datagram. See "Default Address Selection for
IPv6" [4] for more details.

When a client sends a Client Identifier option

Droms (ed.), et al. Expires 1 Aug 2002 [Page 26]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

16.9. Release message

Clients MUST discard any received Release messages.

Relay agents MUST discard any Release messages received through port
546.

- the message does not include directly to a server using unicast
(after receiving the Server Identifier Unicast option

- from that server), it MUST
use an address assigned to the contents of interface for which the Server Identifier option do not match client is
interested in obtaining configuration, which is suitable for use by
the
server's identifier

- server in responding to the message does not include a Client Identifier option

16.10. Reply message

Clients MUST discard any received Reply messages that meet any client, as the source address in the
header of the
following conditions:

- IP datagram.

The client MUST transmit the message does not include a Server Identifier option

- on the "transaction-ID" field in link that the message does not match interface
for which configuration information is being obtained is attached
to. The client SHOULD send the
value used in message through that interface. The
client MAY send the original message

- through another interface attached to the
same link if and only if the message does not include a Client Identifier option

- client is certain the contents of two interface are
attached to the Client Identifier option does not match same link.

17. DHCP Server Solicitation

This section describes how a client locates servers that will assign
addresses to IAs belonging to the
DUID of client.

The client is responsible for creating IAs and requesting that a
server assign configuration information, including IPv6 addresses,
to the IA. The client

Servers first creates an IA and relay agents MUST discard any received Reply messages.

16.11. Reconfigure assigns it an IAID.
The client then transmits a Solicit message containing an IA option
describing the IA. Servers and relay agents MUST discard any received Reconfigure
messages.

Clients MUST discard any Reconfigure messages that meet any of can assign configuration information
to the
following conditions:

- IA respond to the message does not include client with an Advertise message. The
client then initiates a Server Identifier option

- configuration exchange as described in
section 18.

17.1. Client Behavior

A client uses the Solicit message does not contain an authentication option

- to discover DHCP servers configured
to serve addresses on the message fails link to which the authentication validation performed by client is attached.

17.1.1. Creation of Solicit messages

The client sets the "msg-type" field to SOLICIT. The client

16.12. Information-request message

Clients MUST discard any received Information-request messages. generates
a transaction ID and inserts this value in the "transaction-ID"
field.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 27]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

Relay agents MUST discard any Information-request messages received
through port 546.

Servers MAY choose to discard any received Information-request
messages that do not 27]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

The client MUST include a Client Identifier option.

Servers MUST discard any received Information-request message that
includes a Server Identifier option and the DUID in the option does
not match to identify itself
to the server's DUID.

16.13. Relay-forward message

Clients MUST discard any received Relay-forward messages.

16.14. Relay-reply message

Clients and servers server. The client MUST discard include one or more IA options for
any received Relay-reply messages.

17. Client Source Address and Interface Selection

When a client sends a DHCP message IAs to the All_DHCP_Agents multicast
address, which it MUST use wants the IPv6 link-local address assigned server to assign addresses. The client
MAY include addresses in the IAs as a hint to the interface server about
addresses for which the client is interested in obtaining
configuration has a preference. The client MUST
NOT include any other options except those specifically allowed as
defined by specific options.

The client may send just IA options for the source address in the header assignment of
non-temporary addresses, just IA_TA options for the IP datagram.

When assignment of
only temporary options, or a mix of both IA and IA_TA options.

The client sends a DHCP message directly to a server using unicast
(after receiving the Server Unicast option MAY request specific options from that server), it
MUST use the server by including
an address assigned to Option Request option (see section 22.7) indicating the interafce for which options
the client is interested in obtaining configuration, which is suitable for use
by receiving. The client MAY include
options with data values as hints to the server about parameter
values the client would like to have returned.

If the client will accept a Reply message with committed address
assignments and other resources in responding response to the client, as Solicit message,
the source address client includes a Rapid Commit option (see section 22.15) in the header
Solicit message.

17.1.2. Transmission of the IP datagram. See "Default Address Selection for
IPv6" [6] for more details. Solicit Messages

The first Solicit message from the client on the interface MUST transmit
be delayed by a random amount of time between MIN_SOL_DELAY and
MAX_SOL_DELAY. In the case of a Solicit message on transmitted when DHCP
is initiated by IPv6 Neighbor Discovery, the link that delay gives the interface
for amount
of time to wait after the ManagedFlag changes from FALSE to TRUE (see
section 5.5.3 of RFC2462). This random delay desynchronizes clients
which configuration information is being obtained is attached
to. The client SHOULD send start at the message through that interface. same time (for example, after a power outage).

The client MAY send transmits the message through another interface attached according to section 14, using the
same link if and only if
following parameters:

IRT SOL_TIMEOUT

MRT SOL_MAX_RT

MRC 0

MRD 0

If the client has included a Rapid Commit option and is certain waiting for
a Reply message, the two interface are
attached to client terminates the same link.

18. DHCP Server Solicitation

This section describes how retransmission process as
soon as a client locates servers that will assign
addresses to IAs belonging to Reply message is received.

If the client.

The client is responsible waiting for creating IAs and requesting that a
server assign configuration information, including IPv6 addresses,
to the IA. The client first creates an IA and assigns it an IAID.
The client then transmits a Advertise message, the mechanism in
section 14 is modified as follows for use in the transmission of
Solicit messages. The message containing exchange is not terminated by the
receipt of an IA option Advertise before IRT has elapsed. Rather, the client

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 28]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

describing

collects Advertise messages until IRT has elapsed. Also, the IA. Servers that can assign configuration information first
RT MUST be selected to the IA respond be strictly greater than IRT by choosing RAND
to the be strictly greater than 0.

A client with MUST collect Advertise messages for IRT seconds, unless it
receives an Advertise message. message with a preference value of 255. The
preference value is carried in the Preference option (section 22.8).
Any Solicit that does not include a Preference option is considered
to have a preference value of 0. If the client then initiates receives an Advertise
message with a configuration exchange as preference value of 255, then the client SHOULD
act immediately on that Advertise message without waiting for any
additional Advertise messages.

If the client does not receive any Advertise messages before IRT
has elapsed, it begins the retransmission mechanism described in
section 19.

18.1. Client Behavior

A 14. The client uses terminates the Solicit message to discover DHCP servers configured
to serve addresses retransmission process as
soon as it receives any Advertise message, and the client acts on
the link received Advertise message without waiting for any additional
Advertise messages.

A DHCP client SHOULD choose MRC and MRD to which be 0. If the DHCP client
is attached.

18.1.1. Creation of Solicit messages

The client sets the "msg-type" field configured with either MRC or MRD set to SOLICIT. The client generates a transaction ID and inserts this value in the "transaction-ID"
field.

The client other than
0, it MUST include a Client Identifier option to identify itself stop trying to configure the interface if the message
exchange fails. After the server. The DHCP client MUST include one or more IA options for
any IAs stops trying to which it wants configure the server
interface, it SHOULD choose to assign addresses. The client
MAY include addresses in restart the IAs reconfiguration process
after some external event, such as a hint to the server about
addresses for which user input, system restart, or
when the client has is attached to a preference. The client MAY
include an Option Request Option in the Solicit message. new link.

17.1.3. Receipt of Advertise messages

The client MUST NOT include ignore any other options except those specifically allowed
as defined by specific options.

If Advertise message that includes a Status
Code option containing the value AddrUnavail, with the exception that
the client chooses MAY display the associated status message to request specific options from the server,
it does so by including an Option Request option (see section 23.7,
which MUST include all user.

Upon receipt of one or more valid Advertise messages, the options the client is requesting. The client MAY include options
selects one or more Advertise messages based upon the following
criteria.

- Those Advertise messages with data values as hints to the highest server
about parameter values preference value
are preferred over all other Advertise messages.

- Within a group of Advertise messages with the same server
preference value, a client would like to have returned.

18.1.2. Transmission MAY select those servers whose
Advertise messages advertise information of Solicit Messages

The client sends the Solicit message interest to the All_DHCP_Agents multicast
address.

The first Solicit message from
client. For example, the client on the interface MUST
be delayed by may choose a random amount server that
returned an advertisement with configuration options of time between MIN_SOL_DELAY and
MAX_SOL_DELAY. This random delay desynchronizes clients which start
at interest
to the same time (e.g., after client.

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

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 29]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

The

Once a client transmits the message according to section 15, using has selected Advertise message(s), the
following parameters:

IRT SOL_TIMEOUT

MRT SOL_MAX_RT

MRC 0

MRD 0

The mechanism in section 15 is modified client will
typically store information about each server, such as follows for use in the
transmission of Solicit messages. The message exchange is not
terminated by server
preference value, addresses advertised, when the receipt of an Advertise before IRT has elapsed.
Rather, advertisement was
received, and so on.

If the client collects Advertise messages until IRT has elapsed.
Also, the first RT MUST be selected to be strictly greater than IRT
by choosing RAND needs to be strictly greater than 0.

A client MUST collect Advertise messages for IRT seconds, unless
it receives select an Advertise message with a preference value of 255.
The preference value is carried alternate server in the Preference option (section
23.8). Any Solicit case that a
chosen server does not include a Preference option is
considered respond, the client chooses the next server
according to have a preference value the criteria given above.

17.1.4. Receipt of 0. Reply message

If the client receives
an Advertise message with includes a preference value of 255, then Rapid Commit option in the client
MAY act immediately on that Advertise Solicit message,
it will expect a Reply message without waiting for any
additional Advertise messages. that includes a Rapid Commit option
in response. If the client does not receive any Advertise messages before IRT
has elapsed, receives a Reply message, it begins processes
the retransmission mechanism message as described in section 15. The client terminates 18.1.6. If the retransmission process as
soon as it recieves any Advertise client does not
receive a Reply message, and the client acts on restarts the received Advertise server solicitation
process by sending a Solicit message without waiting for any additional
Advertise messages. that does not include a Rapid
Commit option.

17.2. Server Behavior

A DHCP server sends an Advertise message in response to Solicit messages
it receives to announce the availability of the server to the client.

17.2.1. Receipt of Solicit messages

The server determines the information about the client SHOULD choose MRC and MRD its
location as described in section 11 and checks its administrative
policy about responding to be 0. the client. If the DHCP client server is configured with either MRC or MRD set not
permitted to a value other than
0, it MUST stop trying respond to configure the interface if client, the message
exchange fails. After server discards the Solicit
message.

If the DHCP client stops trying has included a Rapid Commit option in the Solicit
message and the server has been configured to configure respond with committed
address assignments and other resources, the
interface, it SHOULD choose server responds to restart the reconfiguration process
after some external event, such
Solicit with a Reply message as user input, system restart, or
when described in section 17.2.3.

Otherwise, the client is attached server generates and sends an Advertise message to a new link.

18.1.3. Receipt the
client.

17.2.2. Creation and transmission of Advertise messages

The server sets the "msg-type" field to ADVERTISE and copies the
contents of the transaction-ID field from the Solicit message
received from the client MUST ignore any to the Advertise message that message. The server
includes its server identifier in a Status
Code Server Identifier option.

The server MAY add a Preference option containing to carry the preference value AddrUnavail, with the exception that
the client MAY display the associated status message to
for the user. Advertise message. The server implementation SHOULD allow

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 30]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

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

- Those Advertise messages with

the highest setting of a server preference value
are preferred over all other Advertise messages.

- Within a group of Advertise messages with by the same administrator.
The server preference value, a client MAY select those servers whose
Advertise messages advertise information of interest value MUST default to zero unless otherwise
configured by the
client. For example, the client may choose a server that
returned an advertisement with configuration options of interest
to the client.

- administrator.

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

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

If the client needs would be assigned to select an alternate server IAs contained in
the case that a
chosen server does not respond, the client chooses Solicit message from the client.

If the next server
according will not assign any addresses to IAs in a subsequent
Request from the client, the criteria given above.

18.2. Server Behavior

A server sends MUST send an Advertise message in response to Solicit messages
it receives to announce
the availability of client that includes only a status code option with the server status
code set to AddrUnavail and a status message for the client.

18.2.1. Receipt of Solicit messages user.

The server determines MAY include other options the server will return to the
client in a subsequent Reply message. The information about in these
options will be used by the client and its
location as described in section 13. If administrative policy
permits the selection of a server to respond to the client, if
the client receives more than one Advertise message. The server will generate
and send
SHOULD include options specifying values for options requested by the
client in an Advertise Option Request Option included in the Solicit message.

If the Solicit message to was received directly by the server, the client.

18.2.2. Creation and transmission of Advertise messages

The
server sets unicasts the "msg-type" field Advertise message directly to ADVERTISE and copies the
contents of client using
the transaction-ID address in the source address field from the IP datagram in
which the Solicit message
received from was received. The Advertise message MUST
be unicast through the client to interface on which the Advertise message. The server
includes its server identifier Solicit message was
received.

If the Solicit message was received in a Server Identifier option.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 31]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

The Relay-forward message,
the server MAY add constructs a Preference option to carry the preference value
for Relay-reply message with the Advertise message. The server implementation SHOULD allow
message in the setting payload of a server preference value by the administrator.
The server preference value MUST default to zero unless otherwise
configured by the server administrator. "server-message" option. The server MUST include IA options in
unicasts the Advertise Relay-reply message
containing any addresses that would be assigned directly to IAs contained the relay agent using
the address in the Solicit message source address field from the client. IP datagram in which
the Relay-forward message was received.

17.2.3. Creation and Transmission of Reply messages

The server MAY include some or
all of the IA options from MUST commit the assignment of any addresses or other
configuration information message before sending a Reply message to a
client in the Advertise response to a Solicit message.

DISCUSSION:

When using the Solicit-Advertise message exchange, a server will
need not assign any addresses commit the assignment of configuration information
to IAs in a subsequent
Request from the client, client or otherwise keep state about the client
before the server SHOULD either send an sends the Advertise message to the client.
The client that includes only a status code option with will choose one of the status code set to AddrUnavail responding servers and
send a status Request message for the user
or not respond to the Solicit message. obtain configuration information.
The server may choose to assign fewer temporary other servers can make any addresses than they might have
offered to the client requested with an RTA option (see section 23.6) and
includes a status code of Success in the IA. If the server will
assign no temporary addresses, the server includes a status code of
AddrUnavail.

The server MAY include available for assignment to other options
clients.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 31]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

When using the Solicit-Reply message exchange, the server will return to
commits the assignment of any addresses before sending the
client in a subsequent
Reply message. The information in these
options will be used by the client can assume it has been assigned
the addresses in the selection of Reply message and does not need to send
a server if Request message for those addresses.

Typically, servers that are configured to use the client receives
Solicit-Reply message exchange will be deployed so that only
one server will respond to a Solicit message. If more than
one Advertise message. The server
SHOULD include options specifying values for options requested by responds, the client in an Option Request Option included in the Solicit message.

If will only use the Solicit message was received directly by addresses
from one of the server, servers and the
server unicasts addresses from the Advertise message directly other
servers will be committed to the client using but not used by the address
client.

The server includes a Rapid Commit option in the source address field from Reply message to
indicate that the IP datagram Reply is in
which the response to a Solicit message was received. message.

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

If server produces the Solicit Reply message was as though it had received in
a Relay-forward Request message,
the server constructs a Relay-reply message with the Advertise
message as described in the payload of a "server-message" option. section 18.2.1. The server
unicasts
transmits the Relay-reply Reply message directly to the relay agent using
the address in the source address field from the IP datagram as described in which
the Relay-forward message was received.

19. section 18.2.8.

18. DHCP Client-Initiated Configuration Exchange

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

Droms (ed.), et al. Expires 1 Aug 2002 [Page 32]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

19.1. application layer, when required by Stateless Address
Autoconfiguration or as required to extend the lifetime of an address
(Rebind and Renew messages).

18.1. Client Behavior

A client will use Request, Confirm, Renew, Rebind and
Information-request messages to acquire and confirm the
validity of configuration information. The client uses the server
identifier information and information about IAs from previous
Advertise messages for use in constructing Request messages. Note
that a client may request configuration information from one or more
servers at any time.

19.1.1.

18.1.1. Creation and transmission of Request messages

The client uses a Request message to populate IAs with addresses
and obtain other configuration information. The client includes
one or more IA options in the Request message, with addresses and
information about the IAs that were obtained from the server in a
previous Advertise message. The server then returns addresses and
other information about the IAs to the client in IA options in a
Reply message.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 32]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

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

The client places the identifier of the destination server in a
Server Identifier option.

The client MUST include a Client Identifier option to identify itself
to the server. The client adds any other appropriate options,
including one or more IA options (if the client is requesting that
the server assign it some network addresses). The list of addresses
in each included IA MUST include the addresses received by the client
in a previous Advertise message.

If the client chooses to request specific options from the server,
it does so by including an Option Request option (see section 23.7, 22.7),
which MUST include all of the options the client is requesting. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.

If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received
a Server Unicast option (section 23.13) 22.13) from the server, the client
SHOULD unicast the Request message to the server. Otherwise, the
client MUST send the Request message to the All_DHCP_Agents multicast
address.

DISCUSSION:

Use of multicast or anycast on a link and relay agents
enables the inclusion of relay agent options in all messages
sent by the client. The server should enable the use of
unicast only when relay agent options will not be used.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 33]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

The client transmits the message according to section 15, 14, using the
following parameters:

IRT REQ_TIMEOUT

MRT REQ_MAX_RT

MRC REQ_MAX_RC

MRD 0

If the message exchange fails, the client MAY choose one of the
following actions:

- Select another server from a list of servers known to the client;
e. g.,
for example, servers that responded with an Advertise message

- Initiate the server discovery process described in section 18 17

- Terminate the configuration process and report failure

19.1.2.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 33]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

18.1.2. Creation and transmission of Confirm messages

Whenever a client may have moved to a new link, its IPv6 addresses
and other configuration information 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 access points

In any situation when a client may have moved to a new link, the
client 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 addresses with the status in the Reply message
it returns to the client.

The client sets the "msg-type" field to CONFIRM. The client generates
a transaction ID and inserts this value in the "transaction-ID"
field.

The client MUST include a Client Identifier option to identify itself
to the server. The client adds any appropriate options, including
one or more IA options. The client MUST include the addresses the
client currently has associated with those IAs.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 34]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

If the client chooses to request specific options from the server,
it does so by including an Option Request option (see section 23.7, 22.7,
which MUST include all of the options the client is requesting. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.

The

When the client sends the Confirm message to the All_DHCP_Agents multicast
address. The client message, it MUST use an IPv6
address that the client has confirmed to be valid on the link to
which it is currently attached and that is assigned to the interface
for which the client is interested in obtaining configuration
information as the source address in the IP header of the datagram
carrying the Confirm message.

The client transmits the message according to section 15, 14, using the
following parameters:

IRT CNF_TIMEOUT

MRT CNF_MAX_RT

MRC 0

MRD CNF_MAX_RD

Droms (ed.), et al. Expires 22 Oct 2002 [Page 34]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

If the client receives no responses before the message transmission
process as described in section 15 14 terminates, the client SHOULD
continue to use any IP addresses, using the last known lifetimes for
those addresses, and SHOULD continue to use any other previously
obtained configuration parameters.

19.1.3.

18.1.3. Creation and transmission of Renew messages

To extend the valid and preferred lifetimes associated with
addresses, the client sends a Renew message to the server containing
an "IA option" IA option for the IA and its associated addresses. The server
determines new lifetimes for the addresses in the IA according to the
administrative configuration of the server. The server may also add
new addresses to the IA. The server may remove addresses from the IA
by setting the preferred and valid lifetimes of those addresses to
zero.

The server controls the time at which the client contacts the server
to extend the lifetimes on assigned addresses through the T1 and T2
parameters assigned to an IA.

If T1 or T2 is set to 0 by the server, the client does not send a
Renew or Rebind message, respectively, for the IA.

At time T1 for an IA, the client initiates a Renew/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 Renew message.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 35]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

The client sets the "msg-type" field to RENEW. The client generates a
transaction ID and inserts this value in the "transaction-ID" field.

The client places the identifier of the destination server in a
Server Identifier option.

The client MUST include a Client Identifier option to identify
itself to the server. The client adds any appropriate options,
including one or more IA options (if the client is requesting that
the server extend the lifetimes of the addresses assigned
itself to those
IAs; note that the server. The client may check the status of other configuration
parameters without asking for lifetime extensions). adds any appropriate options,
including one or more IA options. The client MUST include the list
of addresses the client currently has associated with the IAs in the
Renew message.

If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received a
Server Unicast option (section 23.13) (see section 22.13) from the server, the client
SHOULD unicast the Renew message to the server. Otherwise, the
client sends the Renew message to the All_DHCP_Agents multicast
address.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 35]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

DISCUSSION:

Use of multicast or anycast on a link and relay agents
enables the inclusion of relay agent options in all messages
sent by the client. The server MUST NOT enable the use of
unicast for a client when relay agent options are required
for that client.

The client transmits the message according to section 15, 14, using the
following parameters:

IRT REN_TIMEOUT

MRT REP_MAX_RT

MRC 0

MRD 0

The mechanism in section 15 14 is modified as follows for use in the
transmission of Renew messages. The message exchange is terminated
when time T2 is reached (see section 19.1.4), 18.1.4), at which time the
client begins a Rebind message exchange.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 36]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

19.1.4.

18.1.4. Creation and transmission of Rebind messages

At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded),
the client initiates a Rebind/Reply message exchange. The client
includes an IA option with all addresses currently assigned to the IA
in its Rebind message.

The client sends this message to the
All_DHCP_Agents multicast address.

The client sets the "msg-type" field to REBIND. The client generates
a transaction ID and inserts this value in the "transaction-ID"
field.

The client MUST include a Client Identifier option to identify
itself to the server. The client adds any appropriate options,
including one or more IA options. The client MUST include the list
of addresses the client currently has associated with the IAs in the
Rebind message.

The client sends the Rebind message to the All_DHCP_Agents multicast
address.

The client transmits the message according to section 15, 14, using the
following parameters:

IRT REB_TIMEOUT

Droms (ed.), et al. Expires 22 Oct 2002 [Page 36]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

MRT REB_MAX_RT

MRC 0

MRD 0

The mechanism in section 15 14 is modified as follows for use in the
transmission of Rebind messages. The message exchange is terminated
when the lifetimes of all of the addresses assigned to the IA expire
(see section 12), 10), at which time the client has several alternative
actions to choose from:

- The client may choose to use a Solicit message to locate a new
DHCP server and send a Request for the expired IA to the new
server

- The client may have other addresses in other IAs, so the client
may choose to discard the expired IA and use the addresses in the
other IAs

Droms (ed.), et al. Expires 1 Aug 2002 [Page 37]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

19.1.5.

18.1.5. Creation and Transmission of Information-request messages

The client uses an Information-request message to obtain
configuration information without having addresses assigned to it.

The client sets the "msg-type" field to INFORMATION-REQUEST. The
client generates a transaction ID and inserts this value in the
"transaction-ID" field.

The client SHOULD include a Client Identifier option to identify
itself to the server. If the client does not include a Client
Identifier option, the server will not be able to return any
client-specific options to the client. client, or the server may choose not
to respond to the message at all.

If the client has an IPv6 address of sufficient scope, the
client MAY choose to send the Information-request message to the
All_DHCP_Servers multicast address. Otherwise, the client MUST send
the Information-request message to the All_DHCP_Agents multicast
address.

The client transmits the message according to section 15, 14, using the
following parameters:

IRT INF_TIMEOUT

MRT INF_MAX_RT

Droms (ed.), et al. Expires 22 Oct 2002 [Page 37]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

MRC 0

MRD 0

19.1.6.

18.1.6. Receipt of Reply message in response to a Request, Confirm,
Renew, Rebind or Information-request message

Upon the receipt of a valid Reply message in response to a Request,
Confirm, Renew, Rebind or Information-request message, the client
extracts the configuration information contained in the Reply. The
client MAY choose to report any status code or message from the
status code option in the Reply message.

The client SHOULD perform duplicate address detection [21] [19] on each
of the addresses in any IAs it receives in the Reply message after
a Request message. before
using that address for traffic. If any of the addresses are found
to be in use on the link, the client sends a Decline message to the
server as described in section 19.1.9.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 38]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002 18.1.9.

The client records the T1 and T2 times for each IA in the Reply
message. The client records any addresses included with IAs in
the Reply message. The client updates the preferred and valid
lifetimes for the addresses in the IA from the lifetime information
in the IA option. The client leaves any addresses that the client
has associated with the IA that are not included in the IA option
unchanged.

The client SHOULD respond to the server with a Release message for
any addresses in the Reply message that have a valid lifetime of 0.
The client constructs and transmits this message as described in
section 19.1.7.

If the Reply was received in response to a Renew or Rebind message,
the client must update the information in any IA option contained in
the Reply message. The client adds any new addresses from the IA
option to the IA, updates lifetimes for existing addresses in the IA
from the IA option and discards any addresses with a lifetime of zero
in the IA option.

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

When the client receives a NoPrefixMatch NotOnLink status in an IA from the server
in response to a Confirm message, the client can assume it needs to
send a Request to the server to obtain appropriate addresses for the
IA. If the client receives any Reply messages that do not indicate
a NoPrefixMatch NotOnLink status, the client can use the addresses in the IA and
ignore any messages that do indicate a NoPrefixMatch NotOnLink status.

When the client receives an AddrUnavail status in an IA from the
server for a Request message the client will have to find a new
server to create an IA.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 38]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

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

When the client receives a ConfNoMatch an AddrUnavail status in an IA from the
server for a Confirm Renew message the client can assume it needs to send a Renew message to
the server
Request to extend the lifetimes of reestablish an IA with the addresses. server.

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

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

When

18.1.7. Creation and transmission of Release messages

To release one or more addresses, a client sends a Release message to
the server.

The client receives an AddrUnavail status sets the "msg-type" field to RELEASE. The client generates
a transaction ID and places this value in the "transaction-ID" field.

The client places the identifier of the server that allocated the
address(es) in a Server Identifier option.

The client MUST include a Client Identifier option to identify itself
to the server. The client includes options containing the IAs for
the addresses it is releasing in the "options" field. The addresses
to be released MUST be included in the IAs. Any addresses for the
IAs the client wishes to continue to use should not be in added to
the IAs.

The client MUST NOT use any of the addresses if is releasing as
the source address in the Release message or in any subsequently
transmitted message.

If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received
a Server Unicast option (section 22.13) from the server, the client
SHOULD unicast the Release message to the server.

DISCUSSION:

Use of multicast or anycast on a link and relay agents
enables the inclusion of relay agent options in an IA from all messages
sent by the client. The server MUST NOT enable the use of
unicast for a Renew message the client can assume it needs to send a
Request to reestablish an IA with the server. when relay agent options are required
for that client.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 39]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

When the

The client receives SHOULD choose to guarantee the delivery of the Release
message using the retransmission strategy in section 14. An example
of a NoBinding status situation in an IA from the server
for which a Rebind message client would not guarantee delivery would
be when the client can assume it needs is powering down or restarting because of some
error condition.

The client transmits the message according to send a Request section 14, using the
following parameters:

IRT REL_TIMEOUT

MRT 0

MRC REL_MAX_MRC

MRD 0

The client MUST abandon the attempt to reestablish an IA with release addresses if the server or try another server.

When
Release message exchange fails.

The client MUST stop using all of the addresses being released as
soon as the client receives a RebdNoMatch status in an IA from begins the
server for a Rebind Release message exchange process.
If addresses are released but the client can assume it needs to send Reply from a
Request to reestablish an IA with DHCP server is
lost, the client will retransmit the Release message, and the
server or try another server.

When may respond with a Reply indicating a status of "Nobinding".
Therefore, the client receives an AddrUnavail does not treat a Reply message with a status
of "Nobinding" in a Release message exchange as if it indicates an
error.

Note that if the client fails to release the addresses, the addresses
assigned to the IA from will be reclaimed by the server for when the lifetime
of the address expires.

18.1.8. Receipt of Reply message in response to a Rebind Release message

Upon receipt of a valid Reply message, the client can assume it needs to send a
Request to reestablish an IA with consider the server or try another server.

19.1.7.
Release event successful.

18.1.9. Creation and transmission of Release Decline messages

The client sets the "msg-type" field to RELEASE. DECLINE. The client generates
a transaction ID and places this value in the "transaction-ID" field.

The client places the identifier of the server that allocated the
address(es) in a Server Identifier option.

The client MUST include a Client Identifier option to identify itself
to the server. The client includes options containing the IAs for
the addresses it is releasing declining in the "options" field. The addresses
to be released declined MUST be included in the IAs. The client continues to use any other Any addresses in for the IAs. The appropriate "status" field in
IAs the options
MUST client wishes to continue to use should not be set in added to indicate
the reason IAs.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 40]

Internet Draft DHCP for the release. IPv6 (-24) 22 Apr 2002

The client MUST NOT use any of the addresses in the IAs in the
message it is declining as
the source address in the Release Decline message or in any subsequently
transmitted message.

If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received
a Server Unicast option (section 23.13) 22.13) from the server, the client
SHOULD unicast the Release Decline message to the server. Otherwise, the
client MUST send the Release message to the All_DHCP_Agents multicast
address.

DISCUSSION:

The client MAY choose transmits the message according to wait for a section 14, using the
following parameters:

IRT DEC_TIMEOUT

MRT DEC_MAX_RT

MRC DEC_MAX_RC

MRD 0

The client MUST abandon the attempt to decline addresses if the
Decline message exchange fails.

18.1.10. Receipt of Reply message from the server in response to a Decline message

Upon receipt of a valid Reply message, the Release message. If client can consider the
Decline event successful.

18.2. Server Behavior

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

18.2.1. Receipt of Request messages

When the server receives a Request message via unicast from a
client does wait for to which the server has not sent a
Reply, unicast option, the client MAY choose to retransmit server
discards the Release message. Request message and responds with a Reply message
containing a status code option with value UseMulticast and no other
options.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 40] 41]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

The

When the server receives a Request the client transmits is requesting the message
configuration of IAs by the server. The server creates the bindings
for that client according to section 15, using the
following parameters:

IRT REL_TIMEOUT

MRT 0

MRC REL_MAX_MRC

MRD 0 server's policy and configuration
information and records the IAs and other information about the
client.

The client MUST abandon server contructs a Reply message by setting the attempt "msg-type" field
to release addresses if REPLY, copying the
Release transaction ID from the Request message exchange fails. into
the transaction-ID field.

The client server MUST stop using all of the addresses in include a Server Identifier option containing the IA(s) being
released as soon as
server's DUID and the client begins Client Identifier option from the Release Request
message exchange
process. in the Reply message.

If an the server finds that the prefix on one or more IP addresses in
any IA is released but in the Reply message from a DHCP server
is lost, the client will retransmit is not a valid prefix for the Release message, and
link to which the client is connected, the server may respond with a Reply indicating a status of "Nobinding".
Therefore, MUST return the IA
to the client does not treat a Reply message with a the status
of "Nobinding" in a Release message exchange as if it indicates an
error.

Note that if field set to NotOnLink.

If the client fails server cannot assign any addresses to release any of the IA, IAs in the addresses
assigned to
message from the IA will be reclaimed by client, the server when MUST include the lifetime
of IAs in the address expires.

19.1.8. Receipt of Reply
message with the status field set to AddrUnavail and no addresses in response
the IA.

For any IAs to a Release message

Upon receipt of a valid Reply message, which the client server can consider assign addresses, the
Release event successful.

19.1.9. Creation server
includes the IA with addresses and transmission of Decline messages

The other configuration parameters and
records the IA as a new client sets binding.

The server adds options to the "msg-type" field Reply message for any other
configuration information to be assigned to DECLINE. The client generates
a transaction ID and places this value in the "transaction-ID" field.

The client places client. If the identifier of
Request message contained an Option Request option, the server that allocated the
address(es) in a Server Identifier option.

The client MUST
include a Client Identifier options in the Reply message for any options in the Option
Request option the server is configured to identify itself return to the server. client. The client includes
server MAY choose to return other options containing not specified in the IAs it Option
Request option.

18.2.2. Receipt of Confirm messages

When the server receives a Confirm message, the client is
declining in requesting
confirmation that the "options" field. configuration information it will use is valid.
The addresses to be declined MUST
be included in server locates the IAs. The binding for that client continues to use other addresses
in and compares the IAs. The appropriate "status" field
information in the options MUST be
set Confirm message from the client to indicate the reason information
associated with that client.

If the server finds that the information for declining the address.

The client MUST NOT use any of the addresses does not
match what is in the IAs in binding for that client or the configuration
information is not valid, the server sends a Reply message as containing
a Status Code option with the source address in value ConfNoMatch.

If the Decline message or server finds that the information for the client does match
the information in any
subsequently transmitted message. the binding for that client, and the configuration

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 41] 42]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

If the client has a source address of sufficient scope that can be
used by

information is still valid, the server as sends a return address and the client has received Reply message
containing a Server Unicast Status Code option (section 23.13) from with the server, value Success.

If the client
SHOULD unicast server cannot determine if the Decline message to information in the server. Otherwise, Confirm
message is valid or invalid, the
client server MUST NOT send the Decline message a reply to the All_DHCP_Agents multicast
address.

DISCUSSION:

Use of multicast and relay agents enables the inclusion of
relay agent options in all messages sent by the
client. The
server MUST NOT enable For example, if the use of unicast for server does not have a client when
relay agent options are required binding for that client.

The client transmits the message according to section 15, using the
following parameters:

IRT DEC_TIMEOUT

MRT DEC_MAX_RT

MRC DEC_MAX_RC

MRD 0

The client MUST abandon
client, but the attempt to decline addresses if configuration information in the
Decline Confirm message exchange fails.

19.1.10. Receipt of
appears valid, the server does not reply.

The server contructs a Reply message in response by setting the "msg-type" field
to a Decline REPLY, copying the transaction ID from the Confirm message

Upon receipt of into
the transaction-ID field.

The server MUST include a valid Reply message, Server Identifier option containing the client can consider
server's DUID and the
Decline event successful.

19.2. Server Behavior

For this discussion, Client Identifier option from the Server is assumed to have been configured Confirm
message in
an implementation specific manner with configuration of interest to
clients.

19.2.1. the Reply message.

The Reply message from the server MUST include a Status Code option.

18.2.3. Receipt of Request Renew messages

The

When the server MAY choose to discard Request messages received receives a Renew message via unicast from a client to
which the server has not sent a unicast
option. option, the server discards
the Renew message and responds with a Reply message containing a
status code option with value UseMulticast and no other options.

When the server receives a Request the Renew and IA option from a client is requesting it
locates the
configuration of a new IA by client's binding and verifies that the server. The server MUST take information in the
IA from the client and associate a binding matches the information stored for that client in an
implementation-specific manner within client.

If the configuration parameter
database server cannot find a client entry for DHCP clients managed by the server.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 42]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

Upon IA the receipt server
returns the IA containing no addresses with status set to NoBinding
in the Renew message.

If the server finds that any of a the addresses are no longer valid Request message from a client
for the server
can respond to, (implementation-specific administrative policy
satisfied) client, the server scans returns the address to the client with
lifetimes of 0.

If the options field.

The server finds the addresses in the IA for the client then constructs a Reply message and the
server sends it back the IA to the
client. client with new lifetimes and T1/T2
times, and includes a Status Code option with value Success. The
server SHOULD process each option for may choose to change the client list of addresses and the lifetimes
of addresses in an
implementation-specific manner. IAs that are returned to the client.

The server MUST construct contructs a Reply message containing by setting the following values:

msg-type REPLY

transaction-ID The transaction-ID "msg-type" field
to REPLY, copying the transaction ID from the Request message. Renew message into the
transaction-ID field.

The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Renew message
in the Reply message.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 43]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

18.2.4. Receipt of Rebind messages

When the server finds receives a Rebind and IA option from a client it
locates the client's binding and verifies that the prefix on one or more IP addresses in
any IA information in the message
IA from the client is not a valid prefix for matches the
link to which information stored for that client.

If the server cannot find a client is connected, entry for the IA the server MUST return
returns the IA
to the client containing no addresses with the status field set to NoPrefixMatch. NoBinding
in the Rebind message.

If the server cannot assign any addresses to finds that the any of the IAs in
the message from addresses are no longer valid
for the client, the server SHOULD include returns the IAs in address to the Reply message client with
lifetimes of 0.

If the server finds the status field set to AddrUnavail and no addresses in the IA.

For any IAs to which IA for the server can assign addresses, server includes client then the IA with addresses and other configuration parameters a status of
Success, and add
server SHOULD send back the IA as a new client binding.

The server may choose to assign fewer temporary addresses than the client requested with an RTA option (see section 23.6) new lifetimes and
includes a status code of Success in the IA. If
T1/T2 times if the default is not being used.

The server chooses contructs a Reply message by setting the "msg-type" field
to
assign no temporary addresses, REPLY, copying the transaction ID from the Rebind message into the
transaction-ID field.

The server includes MUST include a status code of
AddrUnavail. Server Identifier option containing the
server's DUID and the Client Identifier option from the Rebind
message in the Reply message.

The server adds options to the Reply message for any other
configuration information to be assigned to the client.

19.2.2. If the
Rebind message contained an Option Request option, the server MUST
include options in the Reply message for any options in the Option
Request option the server is configured to return to the client. The
server MAY choose to return other options not specified in the Option
Request option.

18.2.5. Receipt of Confirm Information-request messages

When the server receives a Confirm an Information-request message, the
client is requesting
confirmation that the configuration information it will use is valid. that does not
include the assignment of any addresses. The server SHOULD locate determines all
configuration parameters appropriate to the binding for that client and compare client, based on the
information in
server configuration policies known to the Confirm server.

The server contructs a Reply message from by setting the client "msg-type" field
to REPLY, copying the information
associated with that client.

Upon transaction ID from the receipt of a valid Confirm Rebind message from into the
transaction-ID field.

The server MUST include a client Server Identifier option containing the
server's DUID and the Client Identifier option from the Rebind
message in the Reply message.

The server
can respond to, (implementation-specific administrative policy
satisfied) adds options to the Reply message for all of the server scans
configuration parameters to be returned to the client. If the options field.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 43] 44]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

If the server cannot determine if the information in the Confirm

Information-request message is valid or invalid, contained an Option Request option, the
server MUST NOT send a reply to the
client. For example, if the server does not have a binding for the
client, but the configuration information include options in the Confirm Reply message
appears valid, the server does not reply.

If the server finds that the information for the client does not
match what is any options in
the binding for that client or Option Request option the configuration
information server is not valid, configured to return to the
client. The server sends a Reply message containing
a Status Code option with MAY choose to return other options not specified
in the value ConfNoMatch. Option Request option.

If the server finds that the information for Information-request message received from the client does match
the information in the binding for that client, and the configuration
information is still valid, the server sends a Reply message
containing did
not include a Status Code option with Client Identifier option, the value Success.

The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct respond
with a Reply message containing any configuration parameters
that are not determined by the following values:

msg-type REPLY

transaction-ID The transaction-ID from client's identity. If the Confirm message.

The server MUST include a Server Identifier option containing
chooses not to respond, the
server's DUID in client may continue to retransmit the Reply message.

The Reply
Information-request message from the server MUST contain a Status Code option
and MUST NOT include any other options.

19.2.3. indefinitely.

18.2.6. Receipt of Renew Release messages

The

When the server MAY choose to discard Renew messages received receives a Release message via unicast from a
client to which the server has not sent a unicast option. option, the server
discards the Release message and responds with a Reply message
containing a status code option with value UseMulticast and no other
options.

Upon the receipt of a valid Renew Release message, the server examines the
IAs and the addresses in the IAs for validity. If the IAs in the
message from are in a binding for the client and the addresses in the IAs
have been assigned by the server
can respond to, (implementation-specific administrative policy
satisfied) to those IAs, the server scans deletes
the options field.

When addresses from the IAs and makes the addresses available for
assignment to other clients. The server receives ignores invalid addresses
(though it may choose to log an error if it finds an invalid
address).

After all the addresses have been processed, the server generates a Renew
Reply message and IA option from includes a client it
SHOULD locate the clients binding Status Code option with value Success
and verify a Server Identifier option with the information server's DUID. The server
MUST NOT include any other options in the
IA from the client matches the information stored for that client. Reply message.

If the server cannot find a client entry binding for this IA the client, the server
SHOULD return an IA containing no addresses
sends a Reply message that includes a Status Code option with status set value
NoBinding.

A server may choose to retain a record of assigned addresses and IAs
after the lifetimes on the addresses have expired to allow the server
to reassign the previously assigned addresses to a client.

18.2.7. Receipt of Decline messages

When the server receives a Decline message via unicast from a
client to
NoBinding.

If which the server finds that the addresses in the IA for the client
do has not match the client binding sent a unicast option, the server should return an IA
containing no addresses
discards the Decline message and responds with a Reply message
containing a status set to RenwNoMatch. code option with value UseMulticast and no other
options.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 44] 45]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

Upon the receipt of a valid Decline message, the server cannot Renew addresses for examines the client it SHOULD send
back an IA containing no addresses to
IAs and the client with addresses in the status
field set to AddrUnavail. IAs for validity. If the server finds the addresses IAs in the IA
message are in a binding for the client then and the
server SHOULD send back addresses in the IA IAs
have been assigned by the server to those IA, the client with new lifetimes and
T1/T2 times if server deletes
the default is not being used, and set status to
Success. addresses from the IAs. The server may choose to change SHOULD mark the list of addresses and
declined by the lifetimes of addresses in IAs client so that those addresses are returned not assigned to the client.
other clients, and MAY choose to make a notification that addresses
were declined. The server ignores invalid addresses (though it may
choose to assign fewer temporary addresses than
the client requested with log an RTA option (see section 23.6) and
includes a status code of Success in the IA. If the server chooses to
assign no temporary addresses, error if it finds an invalid address).

After all the server includes a status code of
AddrUnavail.

The server SHOULD process each option for address have been processed, the client in an
implementation-specific manner. The server MUST construct generates a
Reply message containing the following values:

msg-type REPLY

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

The server MUST include and includes a Status Code option with value Success
and a Server Identifier option containing with the server's DUID DUID. The server
MUST NOT include any other options in the Reply message.

19.2.4. Receipt

18.2.8. Transmission of Rebind Reply messages

Upon

If the receipt of Request, Confirm, Renew, Rebind, Release, Decline or
Information-request message from the client was originally received
in a valid Rebind Relay-forward message from a client relay, the server
can respond to, (implementation-specific administrative policy
satisfied) places the server scans Reply
message in the options field.

When the server receives field of a Rebind Relay-response message and IA option from a client it
SHOULD locate copies
the clients binding link-address and verify the information in the
IA client-address fields from the client matches the information stored for that client.

If Relay-forward
message into the Relay-response message.

The server cannot find a client entry for this IA then unicasts the server
SHOULD return an IA containing no addresses with status set Reply or Relay-reply to
NoBinding.

If the server finds that source
address from the addresses IP datagram in which the IA for the client
do not match original message was
received.

19. DHCP Server-Initiated Configuration Exchange

A server initiates a configuration exchange to cause 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 client binding 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.

19.1. Server Behavior

A server should return an IA
containing no addresses sends a Reconfigure message to cause a client to initiate
immediately a Renew/Reply or Information-request/Reply message
exchange with status set to RebdNoMatch.

If the server.

19.1.1. Creation and transmission of Reconfigure messages

The server cannot Rebind addresses for sets the client it SHOULD send
back an IA containing no addresses "msg-type" field to RECONFIGURE. The server sets
the client with the status transaction-id field set to AddrUnavail.

If the 0. The server finds the addresses places its identifier in the IA for the client then the
server SHOULD send back the IA to the client with new lifetimes and a
Server Identifier option.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 45] 46]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

T1/T2 times if the default is not being used, and set status to
Success.

The server may choose MAY include an Option Request option to assign fewer temporary addresses than inform the client requested with an RTA option (see section 23.6) and
includes a status code
of Success what information has been changed or new information that has been
added. In particular, the server specifies the IA option in the IA. If
Option Request option if the server will
assign no temporary addresses, wants the server includes a status code of
AddrUnavail. client to obtain new
address information.

The server SHOULD process each MUST include an authentication option for the client in an
implementation-specific manner. the Reconfigure
message. The server MUST construct include a Reply
message containing the following values:

msg-type REPLY

transaction-ID The transaction-ID from Reconfigure Message option
(defined in section 22.20) to select whether the Confirm client responds with
a Renew message or an Information-Request message.

The server MUST NOT include a Server Identifier option containing any other options in the
server's DUID Reconfigure
except as specifically allowed in the Reply message.

19.2.5. Receipt definition of Information-request messages

When individual
options.

A server sends each Reconfigure message to a single DHCP client,
using an IPv6 unicast address of sufficient scope belonging to the
DHCP client. The server receives an Information-request message, may obtain the address of the client
is requesting configuration through
the information that does not include the assignment of any addresses. The server SHOULD determine all
configuration parameters appropriate to has about clients that have been in
contact with the server, or the server may be configured with the
address of the client through some external agent.

To reconfigure more than one client, based on the server configuration policies known unicasts a separate
message to each client. The server may initiate the reconfiguration
of multiple clients concurrently; for example, a server may
send a Reconfigure message to additional clients while previous
reconfiguration message exchanges are still in progress.

The Reconfigure message causes the client to initiate a Renew/Reply
or Information-request/Reply message exchange with the server.

Upon The
server interprets the receipt of a valid Renew or Information-request
message from a client
the server can respond to, (implementation-specific administrative
policy satisfied) the server scans client as satisfying the options field. The server
then constructs a Reply Reconfigure message
request.

19.1.2. Time out and sends it to retransmission of Reconfigure messages

If the client.

The server SHOULD process each option for does not receive a Renew or Information-request message
from the client in an
implementation-specific manner. The RECREP_MSG_TIMEOUT milliseconds, the server MUST construct a Reply
message containing
retransmits the following values:

msg-type REPLY

transaction-ID The transaction-ID from Reconfigure message, doubles the Confirm message. RECREP_MSG_TIMEOUT
value and waits again. The server MUST include a Server Identifier option containing continues this process until
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point
the
server's DUID in server SHOULD abort the Reply message. reconfigure process for that client.

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

19.1.3. Receipt of Renew messages

The server adds options generates and sends Reply message(s) to the Reply message client as
described in sections 18.2.3 and 18.2.8, including options for all of the
configuration parameters to be returned to the client. parameters.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 46] 47]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

19.2.6. Receipt of Release messages

The server MAY choose to discard Release messages received via
unicast from a client to which the server has not sent a unicast
option.

Upon the receipt of send a valid Release message, the server examines Reply with the IAs and the addresses in the IAs for validity. If the other
parameters to be reconfigured, even if those IAs in the
message are in a binding for the client and the addresses parameters were
not requested in the IAs
have been assigned by Renew message from the client.

19.2. Receipt of Information-request messages

The server generates and sends Reply message(s) to those IAs, the server deletes
the addresses from the IAs client as
described in sections 18.2.5 and makes the addresses available 18.2.8, including options for
assignment to other clients.
configuration parameters.

The server ignores invalid addresses
(though it may MAY choose to log an error if it finds an invalid
address).

After all the addresses have been processed, the server generates send a Reply message and includes a Status Code option with value Success
and a Server Identifier option with the server's DUID. The server
MUST NOT include any other options in the Reply message.

A server is 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 released.

19.2.7. Receipt of Decline messages

The server MAY choose parameters to discard Decline messages received via
unicast
be reconfigured, even if those parameters were not specified in the
Information-request message from a the client.

19.3. Client Behavior

A client MUST accept Reconfigure messages sent to UDP port 546on
interfaces for which the server it has not acquired configuration information
through DHCP. These messages may be sent a unicast
option.

Upon at any time. Since the receipt
results of a valid Decline message, the server examines reconfiguration event may affect application layer
programs, the
IAs client SHOULD log these events, and MAY notify these
programs of the addresses in the IAs for validity. If the IAs in the
message are in change through an implementation-specific interface.

19.3.1. Receipt of Reconfigure messages

Upon receipt of a binding for valid Reconfigure message, the client and the addresses in the IAs
have been assigned by the server to those IA, initiates a
transaction with the server deletes by sending a Reply or Information-request
message. While the addresses from transaction is in progress, the IAs. client silently
discards any Reconfigure messages it receives.

The server SHOULD mark the addresses
declined by the client so that those addresses are not assigned to
other clients, and MAY choose to make responds with either a notification that addresses
were declined. The server ignores invalid addresses (though it may
choose to log an error if it finds Renew message or an invalid address).

After all the address have been processed,
Information-request message as indicated by the server generates a
Reply Reconfigure
Message option (as defined in section 22.20).

DISCUSSION:

The Reconfigure message and includes acts as a Status Code option with value Success
and trigger that signals the
client to complete a Server Identifier option with successful message exchange. Once
the server' DUID. The server MUST
NOT include any other options in client has received a Reconfigure, the Reply message.

19.2.8. Transmission of Reply messages

If client proceeds
with the Request, Confirm, Renew, Rebind, Release, Decline message exchange (retransmitting the Renew or
Information-request message from if necessary); the client was originally received
ignores any additional Reconfigure messages (regardless
of the transaction ID in a Relay-forward message from a relay, the server places Reconfigure message) until
the
Reply message exchange is complete. Subsequent Reconfigure messages
(again independent of the transaction ID) cause the client
to initiate a new exchange.

How does this mechanism work in the options field face of a Relay-response message and duplicated or
retransmitted Reconfigure messages? Duplicate messages
will be ignored because the client will begin the exchange

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 47] 48]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

copies

after the link-address and client-return-address fields from receipt of the
Relay-forward message into first Reconfigure. Retransmitted
messages will either trigger the Relay-response message.

The server then unicasts exchange (if the Reply first
Reconfigure was not received by the client) or Relay-reply will be
ignored. The server can discontinue retransmission of
Reconfigure messages to the source
address from client once the IP datagram in which server receives
the original Renew or Information-request message was
received.

20. DHCP Server-Initiated Configuration Exchange

A server initiates from the client.

It might be possible for a configuration exchange duplicate or retransmitted
Reconfigure to cause DHCP clients be sufficiently delayed (and delivered out of
order) to obtain new addresses and other configuration information. For
example, an administrator may use a server-initiated configuration arrive at the client after the exchange when links in (initiated
by the DHCP domain are to be renumbered. Other
examples include changes in original Reconfigure) has been completed. In this
case, the location of directory servers,
addition client would initiate a redundant exchange. The
likelihood of new services such as printing, delayed and availability out of new
software (system or application).

20.1. Server Behavior

A server sends a Reconfigure message to cause a client order delivery is small
enough to initiate
immediately a Renew/Reply or Information-request/Reply message
exchange with be ignored. The consequence of the server.

20.1.1. redundant
exchange is inefficiency rather than incorrect operation.

19.3.2. Creation and transmission of Reconfigure Renew messages

The server sets the "msg-type" field

When responding to RECONFIGURE. The server
generates a transaction-ID Reconfigure, the client creates and inserts it sends
the Renew message in exactly the "transaction-ID"
field. The server places its identifier same manner as outlined in a Server Identifier
option.

The server MAY include an Option Request option to inform
section 18.1.3, with the client
of what information has been changed or new information that has been
added. In particular, exception: if the server specifies the IA option in the included on Option
Request option if specifying the server wants IA option, the client to obtain new
address information.

The server MUST include an authentication option with the appropriate
settings and add that option as the last option in IA
options containing the "options"
field of addresses the Reconfigure message.

The server MUST NOT include any other options in client currently has assigned to
ALL IAs for the Reconfigure
except as specifically allowed in interface through which the definition of individual
options.

A server sends each Reconfigure message to a single DHCP client,
using an IPv6 unicast address was
received.

19.3.3. Creation and transmission of sufficient scope belonging Information-request messages

When responding to a Reconfigure, the
DHCP client. The server may obtain client creates and sends the address of
Information-request message in exactly the client through same manner as outlined in
section 18.1.5, with the information exception that the server has about clients that have been in
contact client includes a Server
Identifier option with the server, identifier from the Reconfigure message to
which the client is responding.

19.3.4. Time out and retransmission of Renew or Information-request
messages

The client uses the server may be configured same variables and retransmission algorithm as
it does with Renew or Information-request messages generated as part
of a client-initiated configuration exchange. See sections 18.1.3
and 18.1.5 for details.

19.3.5. Receipt of Reply messages

Upon the
address receipt of a valid Reply message, the client through some external agent. extracts the
contents of the "options" field, and sets (or resets) configuration
parameters appropriately. The client records and updates the
lifetimes for any addresses specified in IAs in the Reply message.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 48] 49]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

To reconfigure more than one client,

20. Relay Agent Behavior

For this discussion, the server unicasts a separate
message relay agent MAY be configured to each client. The use a
list of server may initiate destination addresses, which MAY include unicast
addresses, the reconfiguration All_DHCP_Servers multicast address, or other multicast
addresses selected by the network administrator. If the relay agent
has not been explicitly configured, it MUST use the All_DHCP_Servers
multicast address as the default.

20.1. Relaying of multiple clients concurrently; for example, client messages

When a server may
send relay agent receives a Reconfigure message to additional clients while previous
reconfiguration message exchanges are still in progress. valid client message, it constructs
a Relay-forward message. The Reconfigure message causes relay agent places a global or
site-scoped address with a prefix assigned to the link on which the
client should be assigned an address in the client to initiate a Renew/Reply
or Information-request/Reply message exchange with link-address field. This
address will be used by the server. The server interprets to determine the receipt of a Renew or Information-request
message link from which
the client as satisfying the Reconfigure message
request.

20.1.2. Time out should be assigned an address and retransmission of Reconfigure messages other configuration
information.

If the server does not receive a Renew or Information-request message
from relay agent cannot use the client address in RECREP_MSG_TIMEOUT milliseconds, the server
retransmits the Reconfigure message, doubles link-address field
to identify the RECREP_MSG_TIMEOUT
value and waits again. The server continues this process until
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at interface through which point the server SHOULD abort response to the reconfigure process for that client.

Default and initial values for RECREP_MSG_TIMEOUT and
REC_MSG_ATTEMPTS are documented in client
will be forwarded, the relay agent MUST include an Interface-id
option (see section 7.5.

20.1.3. Receipt of Renew messages 22.19) in the Relay-forward message. The server generates and sends Reply message(s) to
will include the client as
described Interface-id option in section 19.2.8, including its Relay-reply message.
The relay agent puts the client's address in the "options" link-address field new
values for configuration parameters.

It is possible that
regardless of whether the client may send a Renew message after relay agent includes an Interface-id option
in the
server has sent a Reconfigure but before Relay-forward message.

The relay agent copies the Reconfigure is source address from the IP datagram
in which the message was received
by from the client. In this case, client into the Renew
client-address field in the Relay-forward message.

The relay agent constructs a Client Message option (see
section 22.10) that contains the entire message from the client
may not include all client in
the data field of the IAs and requests for parameters to be
reconfigured by the server. To accommodate this scenario, option. The relay agent places the server
MAY choose to send a Reply Client
Message option along with the IAs and other parameters to be
reconfigured, even if those IAs and parameters were not any "relay agent-specific" options in the Renew
options field of the Relay-forward message. The relay agent sends
the Relay-forward message from to the client.

20.2. Receipt list of Information-request messages

If the server has assigned destination addresses to one
with which it has been configured or more IAs that belong to the responding client, the server MUST silently discard the
Information-request message.

If the client All_DHCP_Servers address
if it has requested not been explicitly configured with server destination
addresses.

20.2. Relaying of server messages

The relay agent processes any other options included in an Option Request option that
the server is unable to provide to the client, the server MAY send
a Reply
Relay-reply message with only as appropriate to those options it can provide. options. The relay
agents then discards those options.

If the
server sends Relay-reply message includes a Reply Interface-id option, the relay
agent forwards the message that does not include all of from the options server to the client on the link
identified by the Interface-id option. Otherwise, the relay agent

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 49] 50]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

requested by the client, it MUST include a Status Code option with
code OptionUnavail.

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

It is possible that the client may send an Information-request
message after

forwards the server has sent a Reconfigure but before message on the Reconfigure is received link identified by the client. link-address
field.

In this either case, the
Information-request relay agent extracts the server message from the client may not request all of
the parameters to be reconfigured by the server. To accommodate
this scenario,
Server Message option (see section 22.11) and forwards the server MAY choose message to send a Reply with
the other
parameters to be reconfigured, even if those parameters were not
specified address in the Information-request message from client-address field in the client.

20.3. Client Behavior

A client MUST always monitor UDP port 546 for Reconfigure messages
on interfaces for which it has acquired Relay-reply message.

21. Authentication of DHCP parameters. Since messages

Some network administrators may wish to provide authentication of
the
results source and contents of a reconfiguration event DHCP messages. For example, clients may affect application layer
programs,
be subject to denial of service attacks through the client SHOULD log these events, and MAY notify these
programs use of bogus
DHCP servers, or may simply be misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish to
constrain the change through an implementation-specific interface.

20.3.1. Receipt allocation of Reconfigure messages

Upon receipt addresses to authorized hosts to avoid
denial of a valid Reconfigure message, service attacks in "hostile" environments where the client initiates a
transaction with network
medium is not physically secured, such as wireless networks or
college residence halls.

Because of the server. While risk of denial of service attacks against DHCP
clients, the transaction use of authentication is mandated in progress,
the client silently discards any Reconfigure messages it receives.

If the client has IAs with addresses that have been assigned by the
server from which the Reconfigure message was received, the client
messages. A DHCP server MUST respond with a Renew message. Otherwise, the client responds
with include an Information-request message.

DISCUSSION:

The authentication option in
Reconfigure message acts as a trigger that signals messages sent to clients.

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

21.1. DHCP threat model

The threat to complete DHCP is inherently an insider threat (assuming a successful message exchange. Once
properly configured network where DHCPv6 ports are blocked on the client has received a Reconfigure,
perimeter gateways of the client proceeds
with enterprise). Regardless of the message exchange (retransmitting gateway
configuration, however, the Renew or
Information-request message if necessary); potential attacks by insiders and
outsiders are the same.

The attack specific to a DHCP client
ignores any additional Reconfigure messages (regardless
of the transaction ID in is the Reconfigure message) until possibility of the exchange is complete. Subsequent Reconfigure messages
(again independent
establishment of a "rogue" server with the transaction ID) cause intent of providing
incorrect configuration information to the client client. The motivation
for doing so may be to initiate establish a new exchange.

How does this mechanism work "man in the face of duplicated middle" attack or
retransmitted Reconfigure messages? Duplicate messages
will it
may be ignored because the for a "denial of service" attack.

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

The threat specific to a DHCP server is an invalid client
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.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 50] 51]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

after the receipt of the first Reconfigure. Retransmitted
messages will either trigger the exchange (if the first
Reconfigure was not received by the client) or will be
ignored.

The server can discontinue retransmission of
Reconfigure messages threat common to both the client once and the server receives is the Renew resource
"denial of service" (DoS) attack. These attacks typically involve
the exhaustion of valid addresses, or Information-request message from the client.

It might be possible for a duplicate exhaustion of CPU or retransmitted
Reconfigure to be sufficiently delayed (and delivered out
network bandwidth, and are present anytime there is a shared
resource.

21.2. Security of
order) messages sent between servers and relay agents

Relay agents and servers that choose to arrive at the client after the exchange (initiated
by the original Reconfigure) has been completed. In this
case, messages securely
use the client would initiate a redundant exchange. IPsec mechanisms for IPv6 [8]. The
likelihood of delayed way in which IPsec
is employed by relay agents and out of order delivery servers is small
enough to be ignored. The consequence not specified in this
document.

21.3. Summary of the redundant
exchange is inefficiency rather than incorrect operation.

20.3.2. Creation and transmission DHCP authentication

Authentication of Renew DHCP messages

When responding to a Reconfigure, the client creates and sends
the Renew message in exactly the same manner as outlined in
section 19.1.3, with is accomplished through the exception: if use of
the server included on Option
Request Authentication option specifying the IA option, the client MUST include IA
options containing the addresses (see section 22.12). The authentication
information carried in the client currently has assigned Authentication option can be used to
ALL IAs for the interface through which
reliably identify the Reconfigure source of a DHCP message was
received.

20.3.3. Creation and transmission of Information-request messages

When responding to a Reconfigure, confirm that
the client creates and sends contents of the
Information-request DHCP message have not been tampered with.

The Authentication option provides a framework for multiple
authentication protocols. One such protocols is defined here.
Other protocols defined in exactly the same manner as outlined future will be specified in separate
documents.

The protocol field in
section 19.1.5, with the exception that the client includes a Server
Identifier Authentication option with the identifier from identifies the Reconfigure message
specific protocol used to
which generate the client is responding.

20.3.4. Time out and retransmission of Renew or Information-request
messages

The client uses authentication information
carried in the same variables and retransmission option. The algorithm as
it does with Renew or Information-request messages generated as part
of field identifies a client-initiated configuration exchange. See sections 19.1.3
and 19.1.5 specific
algorithm within the authentication protocol; for details.

20.3.5. Receipt of Reply messages

Upon example, the receipt of a valid Reply message,
algorithm field specifies the client extracts hash algorithm used to generate the
contents of
message authentication code (MAC) in the "options" field, and sets (or resets) configuration
parameters appropriately. authentication option. The client records and updates
replay detection method (RDM) field specifies the
lifetimes for any addresses specified type of replay
detection used in IAs the replay detection field.

21.4. Replay detection

The Replay Detection Method (RDM) field determines the type of replay
detection used in the Reply message.
If Replay Detection field.

If the RDM field contains 0x00, the replay detection field MUST
be set to the value of a monotonically increasing counter. Using
a counter value such as the configuration parameters changed were requested by current time of day (for example, an
NTP-format timestamp [10]) can reduce the danger of replay attacks.
This method MUST be supported by all protocols.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 51] 52]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

application layer, the client notifies the application layer of the
changes using an implementation-specific interface.

21. Relay Behavior

For this discussion, the Relay MAY be configured to use a list of
server destination addresses, which MAY include unicast addresses,
the All_DHCP_Servers multicast address, or other multicast addresses
selected by the network administrator.

21.5. Delayed authentication protocol

If the Relay has not been
explicitly configured, it MUST use the All_DHCP_Servers multicast
address as protocol field is 1, the default.

21.1. Relaying of client messages

When a Relay receives a valid client message, it constructs a
Relay-forward message. The relay places an address with a prefix
assigned to message is using the link on which "delayed
authentication" mechanism. In delayed authentication, the client should be assigned an
address
requests authentication in its Solicit message and the link-address field. server replies
with an Advertise message that includes authentication information.
This address will be used authentication information contains a nonce value generated by
the
server source as a message authentication code (MAC) to determine the link from which the client should be assigned
an address provide message
authentication and other configuration information.

If the relay cannot entity authentication.

The use of a particular technique based on the HMAC protocol [9]
using the MD5 hash [18] is defined here.

21.5.1. Management issues in the delayed authentication protocol

The "delayed authentication" protocol does not attempt to address in the link-address field
situations where a client may roam from one administrative domain
to
identify the interface through which another, i.e. interdomain roaming. This protocol is focused on
solving the response to intradomain problem where the client will
be forwarded, out-of-band exchange of a
shared key is feasible.

21.5.2. Use of the relay MUST include an Interface-id Authentication option (see
section 23.17) in the Relay-forward message. The server will include delayed authentication
protocol

In a Solicit message, the Interface-id Authentication option in its Relay-reply message.

The relay copies carries the source address from Protocol,
Algorithm, RDM and Replay detection fields, but no Authentication
information.

In an Advertise, Request, Renew, Rebind, Confirm, Decline, Release
or Information-request message, the IP datagram in which Authentication option carries
the Protocol, Algorithm, RDM and Replay detection fields and
Authentication information.

A DHCP message was received from the client into the client-return-address
field in MUST NOT contain more than one Authentication option
when using the Relay-forward message. delayed authentication protocol. The relay constructs a "client-message" Authentication
option 23.10 that contains should appear as close to the entire message from beginning of the client options area
in the data field DHCP message to facilitate processing of the
option. The relay places authentication
information.The format of the "relay-message" option along with any
"relay-specific" options 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-MD5 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Droms (ed.), et al. Expires 22 Oct 2002 [Page 53]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

The following definitions will be used in the options field description of the Relay-forward
message. The Relay MUST send
authentication information for delayed authentication, algorithm 1:

Replay Detection - as defined by the Relay-forward message to RDM field
K - a key (secret value) shared
between the list
of server source and
destination addresses with which it has been configured.

21.2. Relaying of server messages

When the relay receives a Relay-reply message, it extracts the server
message from the "server-message" option. If the Relay-reply message
includes message;
each key has a Interface-id option, the relay forwards unique
identifier (key ID)
key ID - the message from unique identifier for the server key value
used to generate the client on MAC for this message
HMAC-MD5 - the link identified by MAC generating function.

The sender computes the Interface-id
option. Otherwise, MAC using the relay forwards HMAC generation algorithm [9]
and the MD5 hash function [18]. The entire DHCP message on the link
identified by (except
the link-address field. In either case, MAC field of the relay
forwards authentication option itself), including the
DHCP message to header and the address in options field, is used as input to the client-return-address
HMAC-MD5 computation function. The 'key ID' field in MUST be set to the Relay-reply message.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 52]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

22. Authentication
identifier of DHCP messages

Some network administrators may wish the key used to provide authentication of generate the source and contents MAC.

DISCUSSION:

Algorithm 1 specifies the use of HMAC-MD5. Use of a
different technique, such as HMAC-SHA, will be specified as
a separate protocol.

Delayed authentication requires a shared secret key for each
client on each DHCP messages. For example, clients server with which that client may
be subject wish
to denial of service attacks through the use of bogus the DHCP servers, or may simply protocol. Each key has a unique identifier
that can be misconfigured due used by a receiver to unintentionally
instantiated DHCP servers. Network administrators may wish determine which key was
used to
constrain generate the allocation of addresses to authorized hosts to avoid
denial of service attacks MAC in "hostile" environments where the 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 message. Therefore,
delayed authentication is mandated may not scale well in Reconfigure
messages. A DHCP server MUST include an authentication option architecture
in
Reconfigure messages sent to clients.

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

22.1. which a DHCP threat model

The threat client connects to DHCP is inherently multiple administrative
domains.

21.5.3. Message validation

To validate an insider threat (assuming a
properly configured network where DHCPv6 ports are blocked on the
perimeter gateways of the enterprise). Regardless of incoming message, the gateway
configuration, however, receiver first checks that
the potential attacks by insiders and
outsiders are value in the same.

The attack specific to a DHCP client replay detection field is acceptable according to
the possibility of replay detection method specified by the
establishment of a "rogue" server with RDM field. Next, the intent of providing
incorrect configuration information to
receiver computes the client. The motivation
for doing so may be to establish a "man MAC as described in [9]. The entire DHCP
message (except the middle" attack or it
may be for a "denial MAC field of service" attack.

There the authentication option itself),
is another threat used as input to the HMAC-MDS computation function. If the MAC
computed by the receiver does not match the MAC contained in the
authentication option, the receiver MUST discard the DHCP clients from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters.

The threat specific to a message.

21.5.4. Key utilization

Each DHCP server is an invalid client
masquerading as has a valid client. key, K. The motivation for this may be for
"theft of service", or client uses its key to circumvent auditing for encode
any number of
nefarious purposes.

The threat common messages it sends to both the client and the server is the resource
"denial of service" (DoS) attack. These attacks typically involve
the exhaustion of valid addresses, or the exhaustion of CPU or
network bandwidth, and are present anytime there is a shared
resource. In current practice, redundancy mitigates DoS attacks the
best. to authenticate and verify

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 53] 54]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

22.2. Security of messages sent between servers and relay agents

Relay agents and servers that choose to exchange messages securely
use the IPsec mechanisms for IPv6 [10]. The way in which IPsec
is employed by relay agents and servers is not specified in this
document.

22.3. Summary of DHCP authentication

Authentication of DHCP

any messages is accomplished through the use of it receives from the Authentication option. server. The authentication information carried
in the Authentication option can client's key SHOULD
be used to reliably identify the
source of a DHCP message and initially distributed to confirm that the contents of client through some out-of-band
mechanism, and SHOULD be stored locally on the DHCP
message have not been tampered with.

The Authentication option provides a framework client for multiple
authentication protocols. Two such protocols are defined here.
Other protocols defined use in all
authenticated DHCP messages. Once the future will be specified in separate
documents.

The protocol field in client has been given its key,
it SHOULD use that key for all transactions even if the Authentication option identifies client's
configuration changes; for example, if the
specific protocol used client is assigned a new
network address.

Each DHCP server MUST know, or be able to generate the authentication information
carried obtain in the option. The algorithm field identifies a specific
algorithm within secure manner,
the authentication protocol; keys for example, the
algorithm field specifies the hash algorithm used to generate all authorized clients. If all clients use the same
key, clients can perform both entity and message authentication code (MAC) in the authentication option. The
replay detection method (RDM) field specifies for
all messages received from servers. However, the type sharing of keys
is strongly discouraged as it allows for unauthorized clients to
masquerade as authorized clients by obtaining a copy of replay
detection used in the replay detection field.

22.4. Replay detection

The Replay Detection Method (RDM) field determines shared
key and allows for trivial spoofing of an authenticated DHCP server.
To authenticate the type identity of replay
detection used in individual clients, each client must
be configured with a unique key.

21.5.5. Client considerations for delayed authentication protocol

21.5.5.1. Sending Solicit messages

When the Replay Detection field.

If client sends a Solicit message and wishes to use
authentication, it includes an Authentication option with the desired
protocol, algorithm, RDM field contains 0x00, the and replay detection field MUST be
set to the value of a monotonically increasing counter. Using a
counter value such as described
in section 21.5. The client does not include any authentication
information in the current time of day (e.g., Authentication option.

21.5.5.2. Receiving Advertise messages

The client validates any Advertise messages containing an NTP-format
timestamp [12]) can reduce the danger of replay attacks. This method
MUST be supported by all protocols.

22.5. Configuration token protocol

If
Authentication option specifying the delayed authentication protocol field is 0,
using the validation test described in section 21.5.3.

Client behavior if no Advertise messages include authentication
information field
holds a simple configuration token. The configuration token or pass the validation test is an
opaque, unencoded value known controlled by local policy
on the client. According to both client policy, the sender and receiver. client MAY choose to
respond to a Advertise message that has not been authenticated.

The
sender inserts the configuration token in the DHCP decision to set local policy to accept unauthenticated messages
should be made with care. Accepting an unauthenticated Advertise
message and the
receiver matches the token from can make the message client vulnerable to the shared token. spoofing and other
attacks. If local users are not explicitly informed that the configuration option is present and client
has accepted an unauthenticated Advertise message, the token from users may
incorrectly assume that the message
does client has received an authenticated
address and is not match the shared token, the receiver subject to DHCP attacks through unauthenticated
messages.

A client MUST be configurable to discard unauthenticated messages,
and SHOULD be configured by default to discard unauthenticated
messages if the
message. client has been configured with an authentication

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 54] 55]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

Configuration token may be used to pass a plain-text configuration
token and provides only weak entity authentication and no message
authentication. This protocol is only useful for rudimentary
protection against inadvertently instantiated DHCP servers.

DISCUSSION:

The intent here is to pass a constant, non-computed token
such as a plain-text password. Other types of entity
authentication using computed tokens such as Kerberos
tickets

key or one-time passwords will be defined as separate
protocols.

22.6. Delayed other authentication protocol

If the protocol field is 1, the message is using the "delayed
authentication" mechanism. In delayed authentication, the information. A client
requests authentication in its Solicit message and the server replies
with an MAY choose to
differentiate between Advertise message that includes authentication information.
This messages with no authentication
information contains a nonce value generated by
the source as a message authentication code (MAC) to provide message
authentication and entity authentication.

The use of a particular technique based on the HMAC protocol [11]
using the MD5 hash [20] is defined here.

22.6.1. Management issues in the delayed authentication protocol

The "delayed authentication" protocol does Advertise messages that do not attempt to 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 pass the out-of-band exchange of validation
test; for example, a
shared secret is feasible.

22.6.2. Use of client might accept the Authentication option in former and discard the delayed authentication
protocol

In
latter. If a Solicit client does accept an unauthenticated message, the Authentication option carries the Protocol,
Algorithm, RDM
client SHOULD inform any local users and Replay detection fields, but no Authentication
information.

In an Advertise, SHOULD log the event.

21.5.5.3. Sending Request, Confirm, Renew, Rebind, Confirm, Decline, Release Decline or Information-request message, Release
messages

If the Authentication option carries client authenticated the Protocol, Algorithm, RDM and Replay detection fields and
Authentication information.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 55]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

The format of Advertise message through which 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
client selected the description of server, the client MUST generate authentication
information for delayed authentication, algorithm 1:

Replay Detection - subsequent Request, Confirm, Renew, Rebind or Release
messages sent to the server as defined by described in section 21.5. When the RDM field
K -
client sends a secret value shared between subsequent message, it MUST use the source and
destination of same key used by
the message; each secret server to generate the authentication information.

21.5.5.4. Sending Information-request messages

If the server has selected a
unique identifier (secret ID)
secret ID - the unique identifier key for the secret value
used client in a previous message
exchange (see section 21.5.6.1, the client MUST use the same key
to generate the MAC for this message
HMAC-MD5 - authentication information. If the MAC generating function.

The sender computes client has not
previously been given a key with the MAC using server, the HMAC generation algorithm [11]
and client MUST use
a key that has been selected for the MD5 hash function [20]. The entire DHCP message (except client through some external
mechanism.

21.5.5.5. Receiving Reply messages

If the MAC field of client authenticated the authentication option itself), including Advertise it accepted, the
DHCP message header and client
MUST validate the options field, is used as input to associated Reply message from the
HMAC-MD5 computation function. server. The 'secret ID' field
client MUST be set to discard the identifier of Reply if the secret used message fails to generate pass validation
and MAY log the MAC.

DISCUSSION:

Algorithm 1 specifies validation failure. If the use of HMAC-MD5. Use of a
different technique, such as HMAC-SHA, will be specified as
a separate protocol.

Delayed authentication requires a shared secret key for each
client on each DHCP server with which that client may wish Reply fails to use pass
validation, the client MUST restart the DHCP protocol. Each secret key has a unique
identifier that can be used configuration process by
sending a receiver Solicit message. The client MAY choose to determine remember which
secret was used
server replied with a Reply message that failed to generate the MAC in pass validation
and discard subsequent messages from that server.

If the DHCP message.
Therefore, delayed client accepted an Advertise message that did not include
authentication may information or did not scale well in an
architecture in which a DHCP client connects to multiple
administrative domains.

22.6.3. Message pass the validation

To validate test, the
client MAY accept an incoming message, unauthenticated Reply message from the receiver first checks that server.

21.5.5.6. Receiving Reconfigure messages

The client MUST discard the value in Reconfigure if the replay detection field is acceptable according message fails to pass
validation and MAY log the validation failure.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 56]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

to the replay detection method specified by the RDM field. Next,
the receiver computes the MAC as described in [11]. The receiver
MUST set the 'MAC' field of the authentication option to all 0s

21.5.6. Server considerations for
computation of the MAC. If the MAC computed by the receiver does not
match the MAC contained in the delayed authentication option, the receiver
MUST discard the DHCP message.

22.6.4. Key utilization

Each DHCP client has a key, K. The client uses its key to encode
any protocol

21.5.6.1. Receiving Solicit messages it sends to the server and to authenticate and verify
any Sending Advertise messages it receives from the server.

The client's server selects a key SHOULD
be initially distributed to for the client through some out-of-band
mechanism, and SHOULD be stored locally on includes authentication
information in the Advertise message returned to the client for use as
specified in all
authenticated DHCP messages. Once section 21.5. The server MUST record the identifier of
the key selected for the client has been given its key,
it SHOULD and use that same key for all transactions even if the client's
configuration changes; e.g., if validating
subsequent messages with the client is assigned a new network
address.

Each DHCP server MUST know, client.

21.5.6.2. Receiving Request, Confirm, Renew, Rebind or be able to obtain in a secure manner, Release messages
and Sending Reply messages

The server uses the keys for all authorized clients. If all clients use key identified in the same
key, clients can perform both entity and message authentication for
all messages received from servers. However, and validates the sharing of keys
is strongly discouraged
message as it allows for unauthorized clients specified in section 21.5.3. If the message fails to
masquerade as authorized clients pass
validation or the server does not know the key identified by obtaining a copy of the shared
key. To authenticate 'key
ID' field, the identity of individual clients, each client server MUST be configured with a unique key.

22.6.5. Client considerations for delayed authentication protocol

22.6.5.1. Sending Solicit messages

When discard the client sends a Solicit message and wishes MAY choose to use
authentication, it includes an Authentication option with log
the desired
protocol, algorithm, RDM and replay detection field validation failure.

If the message passes the validation procedure, the server responds
to the specific message as described in section 22.6. 18.2. The client does not server
MUST include any authentication information generated using the key
identified in the Authentication option.

22.6.5.2. Receiving Advertise received message as specified in section 21.5.

21.5.6.3. Sending Reconfigure messages

The client validates any Advertise messages containing server MUST include an Authentication option specifying the delayed authentication protocol in a Reconfigure
message, generated as specified in section 21.5 using the validation test key the
server initially selected for the client to which the Reconfigure
message is to be sent.

If the server has not previously selected a key for the client, the
server MUST use a key that has been selected for the client through
some external mechanism.

22. 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 22.6.3.

Client behavior if no Advertise messages include authentication
information or pass 22.1. All values in options are represented in
network order.

This document describes the validation test is controlled by local policy
on DHCP options defined as part of the base
DHCP specification. Other options may be defined in the client. According to client policy, future in
separate documents.

Unless otherwise noted, each option may appear only in the client MAY choose to
respond to options
area of a Advertise DHCP message that has not been authenticated. and may appear only once. If an option does
appear multiple times, each instance is considered separate and the

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 57]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

The decision to set local policy to accept unauthenticated messages
should be made with care. Accepting an unauthenticated Advertise
message can make the client vulnerable to spoofing and other
attacks. If local users are not explicitly informed that the client
has accepted an unauthenticated Advertise message, the users may
incorrectly assume that

data areas of the client has received an authenticated
address and is not subject to DHCP attacks through unauthenticated
messages.

A client options MUST NOT be configurable to discard unauthenticated messages,
and SHOULD be configured by default to discard unauthenticated
messages. A client MAY choose to differentiate between Advertise
messages with no authentication information and Advertise messages
that do not pass the validation test; for example, a client might
accept the former and discard concatenated or otherwise
combined.

22.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 latter. If a client does accept an
unauthenticated message, specific option
type carried in this option.

option-len An unsigned integer giving the client SHOULD inform any local users and
SHOULD log length of the event.

22.6.5.3. Sending Request, Confirm, Renew, Rebind, Decline or Release
messages

If
option-data field in this option in octets.

option-data The data for the client authenticated option; the Advertise message through which format of this data
depends on the
client selected definition of the server, option.

DHCPv6 options are scoped by using encapsulation. Some options apply
generally to the client MUST generate authentication
information for subsequent Request, Confirm, Renew, Rebind or Release
messages sent client, some are specific to an IA, and some are
specific to the server as described addresses within an IA. These latter two cases are
discussed in section sections 22.4 and 22.6. When the
client sends a subsequent message, it MUST use the same secret

22.2. Client Identifier option

The Client Identifier option is used
by the server to generate the authentication information.

22.6.5.4. Sending Information-request messages

If the client has negotiated carry a secret with the server through DUID identifying a
previous message exchange, the client MUST use the same secret used
by the server to generate the authentication information. If the
client has not negotiated between a secret with the server, the client MUST
use and a secret that has been selected for the client through some
external mechanism.

22.6.5.5. Receiving Reply messages

If the client authenticated the Advertise it accepted, the client
MUST validate the associated Reply message from the server. The
client 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 Client Identifier option
MUST restart appear before any IA options in the DHCP configuration process by
sending a Solicit message. The client MAY choose to remember which
server replied with a Reply message that failed to pass validation
and discard subsequent messages from that server. format of
the Client Identifier option is:

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 58]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

If the client accepted an Advertise message that did not include
authentication information or did not pass the validation test,

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_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_CLIENTID (1)

option-len Length of DUID in octets

DUID The DUID for the client MAY accept an unauthenticated Reply message from the server.

22.6.5.6. Receiving Reconfigure messages

22.3. Server Identifier option

The Server Identifier option is used to carry a DUID identifying
a server between a client MUST validate the Reconfigure message from the and a server. The client MUST discard the Reconfigure if the message fails to pass
validation and MAY log format of the validation failure.

22.6.6. Server considerations for delayed authentication protocol

22.6.6.1. Receiving Solicit messages and Sending Advertise messages
Identifier 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_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_SERVERID (2)

option-len Length of DUID in octets

DUID The server selects a secret DUID for the client server

22.4. Identity Association option

The Identity Association option (IA option) is used to carry an
identity association, the parameters associated with the IA and includes
authentication information in the Advertise message returned to
addresses associated with the
client as specified IA.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 59]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

Addresses appearing in an IA option are not temporary addresses (see
section 22.6. 22.5).

The server MUST record the
identifier format of the secret selected IA option is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_IA (3)

option-len 12 + length of IA-options field

IAID The unique identifier for this IA; the client and use that same
secret for validating subsequent messages with IAID
must be unique among the client.

22.6.6.2. Receiving Request, Confirm, Renew, Rebind or Release messages
and Sending Reply messages identifiers for all
of this client's IAs. The server uses the secret identified in the message and validates
the message as specified in section 22.6.3. If the message fails to
pass validation or the server does not know number space for
IA IAIDs is separate from the secret identified by number space
for IA_TA IAIDs.

T1 The time at which the 'secret ID' field, client contacts the
server MUST discard from which the message and MAY
choose addresses in the IA
were obtained to log extend the validation failure.

If lifetimes of
the message passes addresses assigned to the validation procedure, IA; T1 is a
time duration relative to the current time
expressed in units of seconds

T2 The time at which the client contacts any
available server responds to extend the specific message as described lifetimes of
the addresses assigned to the IA; T2 is a
time duration relative to the current time
expressed in section 19.2. units of seconds

IA-options Options associated with this IA.

The server
MUST include authentication information generated using IA-options field encapsulates those options that are specific
to this IA. For example, all of the secret
identified IA Address Options carrying the
addresses associated with this IA are in the received message as specified IA-options field.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 60]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

An IA option may only appear in section 22.6.

22.6.6.3. Sending Reconfigure messages the options area of a DHCP message.
A DHCP message may contain multiple IA options.

The server MUST include authentication information status of any operations involving this IA is indicated in a Reconfigure
message, generated
Status Code option in the IA-options field.

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 specified having expired. T1 and T2
are included to give servers explicit control over when a client
recontacts the server about a specific IA.

In a message sent by a client to a server, values in section 22.6 using the secret the
server initially negotiated with T1 and
T2 fields indicate the client's preference for those parameters.
The client to which the Reconfigure may send 0 if it has no preference for T1 and T2. In a
message is to be sent.

If the sent by a server has not previously negotiated to a secret with the client, the server client MUST use a secret that has been selected for the client
through some external mechanism.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 59]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

23. 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 23.1. All values
in options is represented in
network order.

This document describes the DHCP options defined as part of the base
DHCP specification. Other options may be defined in T1 and T2 fields for the future T1 and T2 parameters. The values in a
separate document.

23.1. Format of DHCP options

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

option-len An unsigned integer giving T1 and T2 fields are the length number of the
option-data field in this option in octets.

option-data seconds until T1 and T2.

The data for server selects the option; T1 and T2 times to allow the client to extend
the format lifetimes of this data
depends on any addresses in the definition of IA before the option.

DHCPv6 options are scoped by using encapsulation. Some options apply
generally to lifetimes expire,
even if the client, server is unavailable for some are specific to an IA, short period of time.
Recommended values for T1 and some T2 are
specific to .5 and .8 times the shortest
preferred lifetime of the addresses within an IA. These latter two cases are
discussed in sections 23.4 and 23.5.

23.2. Client Identifier option

The Client Identifier option is used to carry a DUID identifying a
client between the IA, respectively. If the
server does not intend for a client and a server. The Client Identifier option
MUST appear before any IA options in to extend the DHCP message. The format lifetimes of the DUID option is:

Droms (ed.), et al. Expires 1 Aug 2002 [Page 60]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

option-code OPTION_CLIENTID (TBD)

option-len Length of DUID
addresses in octets

option-data The DUID for an IA, the client

23.3. Server Identifier option

The Server Identifier option is used server sets T1 and T2 to carry a DUID identifying 0.

T1 is the time at which the client begins the lifetime extension
process by sending a Renew message to the server between a that originally
assigned the addresses to the IA. T2 is the time at which the client and
starts sending a Rebind message to any server. The format of

T1 and T2 are specified as unsigned integers that specify the Server
Identifier option is:

option-code OPTION_SERVERID (TBD)

option-len Length of DUID time
in octets

option-data The DUID for seconds relative to the server

23.4. time at which the messages containing the
option is received.

22.5. Identity association Association for Temporary Addresses option

The identity association Identity Association for Temporary Addresses (IA_TA) option is
used to carry an identity
association, IA, the parameters associated with the IA and the
addresses
assigned to associated with the IA.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 61]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002 All of the addresses in this option
are used by the client as temporary addresses, as defined in RFC
3041.

The format of the IA IA_TA 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 IA OPTION_IA_TA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |

Droms (ed.), et al. Expires 22 Oct 2002 [Page 61]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IA Status | |
+-+-+-+-+-+-+-+-+ |
. Options
. IA-options . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_IA (TBD)

option-len See section 23.

IAID The unique identifier for this IA.

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

T2 The time at which the client contacts any
available server to extend the lifetimes
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_IA_TA (4)

option-len 4 + length of IA-options field

IAID The unique identifier for this IA; the addresses assigned to IAID
must be unique among the IA.

IA status Status identifiers for all
of this client's IAs. The number space for
IA_TA IAIDs is separate from the number space
for IA in this option.

options IAIDs.

IA-options Options associated with this IA.

The Options IA-Options field encapsulates those options that are specific
to this IA. For example, all of the IA Address Options carrying the
addresses associated with this IA are in the Options IA-options field.

Note that an IA has no explicit "lifetime" or "lease length" of
its own. When the lifetimes of all

Each IA_TA carries one "set" of the addresses in an IA have
expired, the IA can be considered as having expired. T1 and T2
are included temporary addresses; that is, at most
one address from each prefix assigned to give servers explicit control over when a client
recontacts the server about a specific IA.

In a message sent by a client link to a server, values in the T1 and
T2 fields indicate which the client's preference for those parameters.
The client
is attached.

An IA_TA option may send 0 if it has no preference for T1 and T2. In a

Droms (ed.), et al. Expires 1 Aug 2002 [Page 62]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

message sent by a server to a client, the client MUST use the values
in the T1 and T2 fields for the T1 and T2 parameters. The values only appear in the T1 and T2 fields are the number options area of seconds until T1 and T2. a DHCP
message. A DHCP message may contain multiple IA_TA options.

The server MUST set the T1 and T2 times to values that will allow
the client to extend as appropriate the lifetimes status of any addresses operations involving this IA is indicated in the IA. If the server does not intend for a client to extend
Status Code option in the IA-options field.

Note that an IA has no explicit "lifetime" or "lease length" of
its own. When the lifetimes of a particular address all of the addresses in an IA, IA have
expired, the IA can be considered as having expired.

A server MAY set the
renewal time values to occur after MUST return the lifetimes on that same set of temporary address
expire.

T1 is the time at which the client SHOULD begin for the lifetime
extension process same
IA_TA (as identified by sending a Renew message to the server that
originally assigned the IAID) as long as those addresses to are
still valid. After the IA. T2 is lifetimes of the time at which addresses in an IA_TA have
expired, the client SHOULD start sending IAID may be reused to identify a new IA_TA with new
temporary addresses.

An identity association for temporary addresses option MUST NOT
appear in a Renew or Rebind message to any server. A
client message. This option MAY begin the lifetime extension process prior to T1 if it
needs additional addresses for some reason.

T1 and T2 are specified as unsigned integers that specify the time appear in seconds relative to a
Confirm message if the time at which lifetimes on the messages containing temporary addresses in the
option is received.

23.5.
associated IA have not expired.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 62]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

22.6. IA Address option

The IA Address option is used to specify IPv6 addresses associated
with an IA. The IA Address option must be encapsulated in the
Options field of an Identity Association option. The Options field
encapsulates those options that are specific to this address.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 63]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002 Identity Association option. The Options field
encapsulates those options that are specific to this address.

The format of the IA Address option is:

option-code OPTION_IADDR (TBD) (5)

option-len See section 23.

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

addr status Status of this address in this IA.

prefix length Prefix 24 + length for this address. of IAaddr-options field

IPv6 address An IPv6 address

preferred lifetime

preferred-lifetime The preferred lifetime for the IPv6 address in
the option.

valid lifetime option, expressed in units of seconds

valid-lifetime The valid lifetime for the IPv6 address in the
option

options
option, expressed in units of seconds

IAaddr-options Options associated with this address

In a message sent by a client to a server, values in the preferred
and valid lifetime fields indicate the client's preference for those
parameters. The client may send 0 if it has no preference for the
preferred and valid lifetimes. In a message sent by a server to a
client, the client MUST use the values in the preferred and valid

Droms (ed.), et al. Expires 1 Aug 2002 [Page 64]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002
lifetime fields for the preferred and valid lifetimes. The values in
the preferred and valid lifetimes are the number of seconds remaining
in each lifetime.

One or more

Droms (ed.), et al. Expires 22 Oct 2002 [Page 63]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

An IA Address Options can option may appear anywhere only in an IA option.

23.6. Requested Temporary Addresses (RTA) Option

The Requested Temporary Addresses (RTA) option is used by a client to
request a server to assign additional temporary addresses to an IA.

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_RTA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-requested |
+-+-+-+-+-+-+-+-+

option-code OPTION_RTA (TBD)

option-len See section 23.

num-requested The number of additional temporary addresses the
client is requesting. This is an unsigned value.

This option MUST only be sent by a client and only in a Solicit,
Request, Renew, or Rebind message. It MUST only an IA_TA
option. More than one IA Address Options can appear encapsulated
within in an Identity association IA option
or an IA_TA option. A client MUST only include

The status of any operations involving this option when it wants to have additional temporary address
allocated; IA Address is indicated
in a client SHOULD NOT send this Status Code option if 'num-requested' is
0.

23.7. in the IAaddr-options field.

22.7. Option Request option

The Option Request option is used to identify a list of options in a
message between a client and a server.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 65]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

The format of the Option Request 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_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_ORO (TBD) (6)

option-len See section 23. 2 * number of requested options

requested-option-code-n The option code for an option requested by
the client.

A client MAY include an Option Request option in a Solicit, Request,
Renew, Rebind, Confirm or Information-request message to inform the
server about options the client wants the server to send to the
client.

23.8.

22.8. Preference 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_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref value pref-value |
+-+-+-+-+-+-+-+-+

option-code OPTION_PREFERENCE (TBD) (7)

Droms (ed.), et al. Expires 22 Oct 2002 [Page 64]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

option-len See section 23.

pref value 1.

pref-value The preference value for the server in this message.

A server MAY include a Preference option in an Advertise message to
control the selection of a server by the client. See section 18.1.3 17.1.3
for the use of the Preference option by the client and the
interpretation of Preference option data value.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 66]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

23.9.

22.9. Elapsed Time

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_ELAPSED_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| elapsed time elapsed-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_ELAPSED_TIME (TBD) (8)

option-len See section 23.

elapsed time 2.

elapsed-time The amount of time since the client began its
current DHCP transaction. This time is expressed in
hundredths of a second (10^-2 seconds).

A client MAY SHOULD include an Elapsed Time option in messages to
indicate how long the client has been trying to complete a DHCP
transaction. Servers and Relay Agents MAY use the data value in this
option as input to policy controlling how a server responds to a client
message.

23.10.
client message. For example, the elapsed time option allows a
secondary DHCP server to respond to a request when a primary server
hasn't answered in a reasonable time.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 65]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

22.10. 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 (9)

option-len Length of DHCP client message.

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

A relay agent forwards a message from a client to a server as the
contents of a Client Message option in a Relay-forward message.

22.11. 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_CLIENT_MSG OPTION_SERVER_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCP client message DHCP-server-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_CLIENT_MSG (TBD) OPTION_SERVER_MSG (10)

option-len See section 23. Length of DHCP client message server message.

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

A relay agent forwards a message from a client to a server client.

A server sends a DHCP message to be forwarded to a client by a relay
agent as the contents of a Server Message option in a Relay-reply
message.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 66]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

22.12. Authentication option

The Authentication option carries authentication information to
authenticate the identity and contents of DHCP messages. The
use of the Authentication option is described in section 21. If
the Authentication option appears in a DHCP message, it should be
included as close to the beginning of the options field as possible
for improved efficiency of authentication processing.

The format of the Authentication 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_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Algorithm | RDM | Replay detect.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | Auth. Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_AUTH (11)

option-len 12 + length of Authentication
Information field

protocol The authentication protocol used in
this authentication option

algorithm The algorithm used in the
authentication protocol

RDM The replay detection method used in
this authentication option

Replay detection The replay detection information for
the RDM

Authentication information The authentication information,
as specified by the
contents of a Client Message option protocol and
algorithm used in a Relay-forward message. this authentication
option

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 67]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

23.11.

22.13. Server message unicast 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-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCP server message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_SERVER_MSG (TBD)

option-len See section 23.

DHCP server message

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

A server sends a DHCP message to be forwarded this option to a client by a relay
agent as to indicate to the contents of a Server Message option in a Relay-reply
message.

23.12. Authentication option

The Authentication option carries authentication information client
that it is allowed to unicast messages to
authenticate the identity and contents of DHCP messages. server. The use of server
specifies the Authentication option IPv6 address to which the client is described to send unicast
messages in section 22. If present, the Authentication option MUST appear as server-address field. When a client receives this
option, where permissible and appropriate, the first option in client sends messages
directly to the server using the DHCP
message.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 68]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

The format address specified in the
server-address field of the Authentication option is: option.

Details about when the client may send messages to the server using
unicast are in section 18.

option-code OPTION_UNICAST (12)

option-len 16

server-address The IP address to which the client should send
messages delivered using unicast

22.14. Status Code Option

This option returns a status indication related to the DHCP message
or option in which it appears.

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_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Information status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. status-message .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_AUTH (TBD) OPTION_STATUS_CODE (13)

Droms (ed.), et al. Expires 22 Oct 2002 [Page 68]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

option-len See section 23.

protocol The authentication protocol used in
this authentication option

algorithm The algorithm used in the
authentication protocol

RDM The replay detection method used in
this authentication option

Replay detection 2 + length of status-message

status-code The replay detection information numeric code for the RDM

Authentication information The authentication information,
as specified by the protocol and
algorithm used status encoded in
this authentication
option

23.13. Server unicast option

The server MAY send this option to a client to indicate to the client
that is allowed to unicast messages to the server. option. The server
specifies the IPv6 address to status codes are defined in
section 5.5.

status-message A UTF-8 encoded text string, which the client is to send unicast
messages MUST NOT
be null-terminated.

A Status Code option may appear in the server-address field. When a client receives this DHCP message option, where permissible, the client MAY send messages directly to
the server using the IPv6 address specified or in the server-address
field
options area of the another option.

Details about when

22.15. Rapid Commit option

A client MAY include this option in a Solicit message if the client may send messages
is prepared to perform the server using
unicast are Solicit-Reply message exchange described
in section 19.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 69]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002 17.1.1.

A server MUST include this option in a Reply message sent in response
to a Solicit message when completing the Solicit-Reply message
exchange.

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_UNICAST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| | OPTION_RAPID_COMMIT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_UNICAST (TBD) OPTION_RAPID_COMMIT (14)

option-len See section 23.

server-address The IP address to which the client should send
messages delivered using unicast

23.14. Status Code 0

22.16. User Class Option

This option returns is used by a status indication related client to identify the DHCP message type or category of
user or applications it represents. The information contained in the
data area of this option is contained in one or more opaque fields
that represent the user class or classes of which it appears.

0 1 2 3 the client is a
member. The user class information carried in this option MUST be
configurable on the client.

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_STATUS_CODE OPTION_USER_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. user-class-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Droms (ed.), et al. Expires 22 Oct 2002 [Page 69]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

option-code OPTION_USER_CLASS (15)

option-len Length of user class data field

user-class-data The user classes carried by the client.

The data area of the user class option MUST contain one or more
instances of user class data. Each instance of the user class data
is formatted as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| status-code | status-message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | user-class-len | ... opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_STATUS_CODE (TBD)

option-len See section 23.

status-code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

The numeric code for user-class-len is two octets long and specifies the status encoded length of the
opaque user class data in
this option. The status codes are defined network order.

Servers can interpret the meanings of multiple class specifications
in
section 7.4.

status-message A UTF-8 encoded text string, an implementation dependent or configuration dependent manner, and
so the use of multiple classes by a DHCP client should be based on
the specific server implementation and configuration which MUST NOT will be null-terminated.

23.15.
used to process that User class option.

22.17. Vendor Class Option

This option is used by a client to identify the type or category of
user or applications it represents. vendor that
manufactured the hardware on which the client is running. The
information contained in the

Droms (ed.), et al. Expires 1 Aug 2002 [Page 70]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002 data area of this option is contained
in one or more opaque fields that represent the user class or classes identify details of which the client is a
member. The user class information carried in this option MUST be
configurable on the client. hardware
configuration.

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_USER_CLASS OPTION_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| user class data | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code TBD OPTION_VENDOR_CLASS (16)

option-len See section 23.

user 4 + length of vendor class data field

enterprise-number The user classes carried by the client. vendor's registered Enterprise Number as
registered with IANA.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 70]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

vendor-class-data The data area hardware configuration of the user class option MUST contain one or more
instances of user class data. host on
which the client is running.

Each instance of the user class data vendor-class-data is formatted as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user class len vendor-class-len | user class data opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

The user class len vendor-class-len is two octets long and specifies the length of
the opaque user vendor class data in network order.

Servers can interpret the meanings of multiple class specifications
in an implementation dependent or configuration dependent manner,
and so the use of multiple classes by a

A DHCP client should be based
on the specific server implementation and configuration which will
be used to process that User class option. Servers not equipped to
interpret the user class information sent by a client message MUST ignore it
(although it may be reported).

23.16. NOT contain more than one Vendor Class Option option.

22.18. Vendor-specific Information option

This option is used by clients and servers to exchange
vendor-specific information. The definition of this information is
vendor specific. The vendor is indicated in the vendor
class identifier option. Servers not equipped to interpret
the vendor-specific information sent by a client MUST ignore it
(although it may be reported). enterprise-number
field. Clients which that do not receive desired vendor-specific
information SHOULD make an attempt to operate without it, although
they may do so (and announce they are doing so) in a degraded mode.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 71]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

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_VENDOR_CLASS OPTION_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vendor-id enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code TBD OPTION_VENDOR_OPTS (17)

option-len See section 23.

vendor-id A domain name belonging to the vendor used to
identify the vendor that defined this vendor
class option. 4 + length of option-data field

enterprise-number The vendor's registered Enterprise Number as
registered with IANA.

option-data An opaque object of option-len octets,
presumably
interpreted by vendor-specific code on the
clients and servers

The vendor-id must adhere to the rules in section 10.

The Encapsulated encapsulated vendor-specific options field MUST be encoded as a
sequence of code/length/value fields of identical format to the DHCP
options field. The option codes are defined by the vendor identified
in the enterprise-number field and are not managed by IANA. Each of
the encapsulated options is formatted as follows.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 71]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| opt-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
. .
. option-data |
| .
. . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

opt-code The code for the encapsulated encapsulated option

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

option-data The data area for the encapsulated option

Multiple instances of the Vendor-specific Information option may
appear in a DHCP message. Each instance of the option

option-len See section 23.

option-data The data area for is interpreted
according to the encapsulated option

23.17. codes defined by the vendor identified by the
Enterprise Number in that option. A DHCP message MUST NOT contain
more than one Vendor-specific Information option with the same
Enterprise Number.

22.19. Interface-Id Option

The relay agent MAY send the Interface-id option to identify the
interface on which the client message was received. If a relay

Droms (ed.), et al. Expires 1 Aug 2002 [Page 72]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002 agent
receives a Relay-reply message with an Interface-id option, the
relay agent forwards the message to the client through the interface
identified by the option 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_INTERFACE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Interface-Id |
. .
. interface-id .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_INTERFACE_ID (TBD) (18)

option-len See section 23.

Interface-Id Length of interface-id field

interface-id An opaque value of arbitrary length generated
by the relay agent to identify one of the
relay agent's interfaces

Droms (ed.), et al. Expires 22 Oct 2002 [Page 72]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

The server MUST copy the Interface-Id option from the Relay-Forward
message into the Relay-Reply message the server sends to the relay
agent in response to the Relay-Forward message. This option MUST NOT
appear in any message except a Relay-Forward or Relay-Reply message.

Servers MAY use the Interface-ID for parameter assignment policies.
The Interface-ID SHOULD be considered an opaque value, with policies
based on exact string match only; that is, the Interface-ID SHOULD
NOT be internally parsed by the server.

24.

22.20. Reconfigure Message option

A server includes a Reconfigure Message option in a Reconfigure
message to indicate to the client whether the client responds with a
Renew message or an Information-request message.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_RECONF_MSG (19)

option-len 1

msg-type 1 for Renew message, 2 for
Information-request message

23. Security Considerations

Section 22 21 describes a threat model and an option that provides an
authentication framework to defend against that threat model.

25.

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

Droms (ed.), et al. Expires 1 Aug 2002 [Page 73]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

26.

25. 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, which are described in the remainder

Droms (ed.), et al. Expires 22 Oct 2002 [Page 73]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

of this section. These name spaces are all to be managed separately
from the name spaces defined for DHCPv4 [7, [5, 1].

New values in each of these name spaces should be approved by the
process of IETF consensus [15].

26.1. [13].

25.1. Multicast addresses

Section 7.1 5.1 defines the following multicast addresses, which have
been assigned by IANA have
been assigned by IANA for use by DHCPv6:

All_DHCP_Relay_Agents_and_Servers address: FF02::1:2

All_DHCP_Servers address: FF05::1:3

IANA is requested to manage definition of additional multicast
addresses in the future.

25.2. Anycast addresses

Section 5.2 defines the following anycast address, which is requested
for use assignment to DHCP by DHCPv6:

All_DHCP_Agents address: FF02::1:2

All_DHCP_Servers address: FF05::1:3 IANA:

DHCP_Anycast: FEC0:0:0:0:FFFF::4

IANA is requested to manage definition of additional multicast anycast
addresses in the future.

26.2.

25.3. DHCPv6 message types

IANA is requested to record the following message types defined (defined in
section 7.3. 5.4). IANA is requested to manage definition of additional
message types in the future.

26.3.

SOLICIT 1

ADVERTISE 2

REQUEST 3

CONFIRM 4

RENEW 5

REBIND 6

REPLY 7

RELEASE 8

Droms (ed.), et al. Expires 22 Oct 2002 [Page 74]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

DECLINE 9

RECONFIGURE 10

INFORMATION-REQUEST 11

RELAY-FORW 12

RELAY-REPL 13

25.4. DUID

IANA is requested to record the following DUID types (as defined in
section 11.1. 9.1). IANA is requested to manage definition of additional
DUID types in the future.

26.4.

Link-layer address plus time 1

VUID-DN 2

VUID-EN 3

Link-layer address 4

25.5. DHCPv6 options

IANA is requested to assign option-codes to record the options following option-codes (as defined
in section 23. 22). IANA is requested to manage the definition of
additional DHCPv6 option-codes in the future.

26.5.

OPTION_CLIENTID 1

OPTION_SERVERID 2

OPTION_IA 3

OPTION_IA_TMP 4

OPTION_IADDR 5

OPTION_ORO 6

OPTION_PREFERENCE 7

OPTION_ELAPSED_TIME 8

OPTION_CLIENT_MSG 9

OPTION_SERVER_MSG 10

OPTION_AUTH 11

Droms (ed.), et al. Expires 22 Oct 2002 [Page 75]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

OPTION_UNICAST 12

OPTION_STATUS_CODE 13

OPTION_RAPID_COMMIT 14

OPTION_USER_CLASS 15

OPTION_VENDOR_CLASS 16

OPTION_VENDOR_OPTS 17

OPTION_INTERFACE_ID 18

OPTION_RECONF_MSG 19

25.6. Status codes

IANA is requested to record the status codes defined in section 7.4. the following
table. IANA is requested to manage the definition of additional
status codes in the future.

Droms (ed.), et al. Expires

Name Code Description
---------- ---- -----------
Success 0 Success
UnspecFail 1 Aug 2002 [Page 74]

Internet Draft DHCP Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
document
AuthFailed 2 Authentication failed or nonexistent
AddrUnavail 3 Addresses unavailable
NoBinding 4 Client record (binding) unavailable
ConfNoMatch 5 Client record Confirm doesn't match IA
NotOnLink 6 One or more prefixes of the addresses
in the IA is not valid for IPv6 (-23) 1 Feb 2002

26.6. the link
from which the client message was received
UseMulticast 7 Sent by a server to a client to force the
client to send messages to the server
using the All\_DHCP\_Relay\_Agents\_and\_Servers
address

25.7. Authentication option

Section 22 21 defines three new name spaces associated with the
Authentication Option (section 23.12), 22.12), which are to be created and
maintained by IANA: Protocol, Algorithm and RDM.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 76]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

Initial values assigned from the Protocol name space are 0 (for the
configuration token Protocol in section 22.5) (reserved)
and 1 (for the delayed authentication Protocol in section 22.6). 21.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 guidelines
for assigning Algorithm name space values for a particular protocol
should be specified along with the definition of a new Protocol.

For the configuration token Protocol, the Algorithm field MUST be
0, as described in section 22.5. For the delayed authentication Protocol, the Algorithm value 1
is assigned to the HMAC-MD5 generating function as defined in
section 22.6. 21.5. Additional algorithms for the delayed authentication
protocol may be defined in the future.

The initial value of 0 from the RDM name space is assigned to the
use of a monotonically increasing value as defined in section 22.4. 21.4.
Additional replay detection methods may be defined in the future.

27.

26. Acknowledgments

Thanks to the DHC Working Group for their time and input into the
specification. In particular, thanks also for the consistent input,
ideas, and review by (in alphabetical order) Thirumalesh Bhat,
Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont, Tony
Lindstrom, Josh Littlefield, Gerald Maguire, Jack McCann, Thomas
Narten, Erik Nordmark, Yakov Rekhter, Mark Stapp, Matt Thomas, Sue
Thomson, 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 22. 21.

And, thanks to Steve Deering for pointing out at IETF 51 in London
that the DHCPv6 specification has the highest revision number of any
Internet Draft.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 75]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

References

[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions, March 1997. RFC 2132.

[2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels, March 1997. RFC 2119.

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

[4] W.J. Croft and J. Gilmore. Bootstrap Protocol, September 1985.
RFC 951.

[5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification, December 1998. RFC 2460.

[6]

Droms (ed.), et al. Expires 22 Oct 2002 [Page 77]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

[4] R. Draves. Default Address Selection for IPv6, September 2001.
work in progress.

[7]

[5] R. Droms. Dynamic Host Configuration Protocol, March 1997. RFC
2131.

[8]

[6] R. Droms, Editor, W. Arbaugh, and Editor. Authentication for
DHCP Messages, June 2001. RFC 3118.

[9]

[7] R. Hinden and S. Deering. IP Version 6 Addressing Architecture,
July 1998. RFC 2373.

[10]

[8] S. Kent and R. Atkinson. Security Architecture for the Internet
Protocol, November 1998. RFC 2401.

[11]

[9] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
for Message Authentication, February 1997. RFC 2104.

[12]

[10] David L. Mills. Network Time Protocol (Version 3)
Specification, Implementation, March 1992. RFC 1305.

[13]

[11] P.V. Mockapetris. Domain names - concepts and facilities,
November 1987. RFC 1034.

[14]

[12] P.V. Mockapetris. Domain names - implementation and
specification, November 1987. RFC 1035.

[15]

[13] T. Narten and H. Alvestrand. Guidelines for Writing an IANA
Considerations Section in RFCs, October 1998. RFC 2434.

[16]

[14] T. Narten and R. Draves. Privacy Extensions for Stateless
Address Autoconfiguration in IPv6, January 2001. RFC 3041.

[17]

[15] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6), December 1998. RFC 2461.

Droms (ed.), et al. Expires 1 Aug 2002 [Page 76]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002

[18]

[16] D.C. Plummer. Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware, November 1982. RFC 826.

[19]

[17] J. Postel. User Datagram Protocol, August 1980. RFC 768.

[20]

[18] R. Rivest. The MD5 Message-Digest Algorithm, April 1992. RFC
1321.

[21]

[19] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration, December 1998. RFC 2462.

[22]

[20] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic
Updates in the Domain Name System (DNS UPDATE), April 1997. RFC
2136.

Droms (ed.), et al. Expires 22 Oct 2002 [Page 78]

Internet Draft DHCP for IPv6 (-24) 22 Apr 2002

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

Authors' Addresses

Questions about this memo can be directed to:

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 77] 79]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

Jim Bound
Compaq Computer Corporation
ZK3-3/W20
110 Spit Brook Road
Nashua, NH 03062-2698
USA
Voice: +1 603 884 0062
E-mail: Jim.Bound@compaq.com

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

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

Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
E-mail: Ted.Lemon@nominum.com

Bernie Volz
Ericsson
959 Concord St
Framingham, MA 01701
Voice: +1-508-875-3162
Fax: +1-508-875-3018
E-mail: bernie.volz@ericsson.com

Ralph Droms
Cisco Systems
300 Apollo Drive
Chelmsford, MA 01824
USA
Voice: +1 978 479 4733
E-mail: rdroms@cisco.com

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 78] 80]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

A. Appearance of Options in Message Types

The following table indicates with a "*" the options are allowed in
each DHCP message type:

Client Server IA RTA IA/ Option Pref Time Client Server
ID ID IA_TA Request Forw. Forw. Msg. Msg.
Solicit * * * *
Advert. * * * * * *
Request * * * * *
Confirm * * * *
Renew * * * * *
Rebind * * * *
Decline * * * * *
Release * * * * *
Reply * * * * * *
Reconf. * * *
Inform. * (see note) *
R-forw. *
R-forw. *
R-repl. * *

NOTE:

Only included in Information-Request messages that are sent
in response to a Reconfigure (see section 20.3.3). 19.3.3).

Auth Server Status Rap. User Vendor Vendor Inter. Recon.
Unica. Code Comm. Class Class Spec. ID Msg.
Solicit * * * * *
Advert. * * * * *
Request * * * *
Confirm * * * *
Renew * * * *
Rebind * * * *
Decline * * * * *
Release * * * * *
Reply * * * * * *
Reconf. * *
Inform. * * * *
R-forw. * * * * *
R-repl. * * * * *

B. Appearance of Options in the Options Field of DHCP Messages Options

The following table indicates with a "*" where options can appear in
the options field or encapsulated in of other options:

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 79] 81]

Internet Draft DHCP for IPv6 (-23) 1 Feb (-24) 22 Apr 2002

Option IA IA/ IAADDR RTA Client Server
Field Forw. Forw. IA_TA Msg. Msg.
Client msg. * ID *
Server msg. * *
DUID ID *
IA
IA/IA_TA *
IAADDR *
RTA *
ORO *
Pref *
Time *
Client Forw. *
Server Forw. *
DSTM Addr. *
DSTM Tunnel *
Authentic. *
Server Uni. *
Dom. Srch. *
Dom. Server *
Status Cod. Code * * * *
Circ. ID *
Rapid Comm. *
User Class *
Vend.
Vendor Class *
Vendor Info. *
Interf. ID * *
Reconf. msg. *

C. Full Copyright Statement

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

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

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

Droms (ed.), et al. Expires 1 Aug 2002 [Page 80]

Internet Draft DHCP for IPv6 (-23) 1 Feb 2002
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.

Droms (ed.), et al. Expires 1 Aug 22 Oct 2002 [Page 81] 82]
----