WDIFF

draft-ietf-dhc-dhcpv6-28.txt-229383.txt --> rfc3315.txt

Internet Engineering Task Force

Network Working Group R. Droms (ed.), Droms, Ed.
Request for Comments: 3315 Cisco
INTERNET DRAFT
Category: Standards Track J. Bound, Bound
Hewlett Packard
DHC Working Group Bernie Volz,
B. Volz
Ericsson
Obsoletes: draft-ietf-dhc-dhcpv6-27.txt Ted Lemon,
T. Lemon
Nominum
C. Perkins, Perkins
Nokia Research Center
M. Carney, Carney
Sun Microsystems
2 Nov 2002
July 2003

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

Status of This this Memo

This document is a submission by the Dynamic Host Configuration
Working Group of specifies an Internet standards track protocol for the
Internet Engineering Task Force (IETF). Comments
should be submitted community, and requests discussion and suggestions for
improvements. Please refer to the dhcwg@ietf.org mailing list. current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. 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

Copyright (C) The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html. Internet Society (2003). All Rights Reserved.

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), (RFC 2462), and can be used
separately or concurrently with the latter to obtain configuration
parameters.

Droms (ed.),

Droms, et al. Expires 30 Apr 2003 Standards Track [Page i]

Internet Draft 1]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

Contents

Status July 2003

Table of This Memo i

Abstract i Contents

1. Introduction and Overview 1 . . . . . . . . . . . . . . . . . . 5
1.1. Protocols and Addressing . . . . . . . . . . . . . . . . 1 6
1.2. Client-server Exchanges Involving Two Messages . . . . . 2 6
1.3. Client-server Exchanges Involving Four Messages Messages. . . . 7
2. Requirements. . . 2

2. Requirements 3

3. Background 3

4. Terminology 4
4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 4
4.2. DHCP Terminology . . 7
3. Background. . . . . . . . . . . . . . . . . . . 5

5. DHCP Constants 7
5.1. Multicast Addresses . . . . . . . 8
4. Terminology . . . . . . . . . . . . 7
5.2. UDP Ports . . . . . . . . . . . . . 8
4.1. IPv6 Terminology . . . . . . . . . . . 8
5.3. . . . . . . . . 9
4.2. DHCP Message Types Terminology . . . . . . . . . . . . . . . . . . . 8
5.4. Status Codes 10
5. DHCP Constants. . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Transmission and Retransmission Parameters . 12
5.1. Multicast Addresses. . . . . . . 10

6. Client/Server Message Formats 11

7. Relay Agent/Server Message Formats 11
7.1. Relay-forward Message . . . . . . . . . . . . . . . 13
5.2. UDP Ports. . . . 12
7.2. Relay-reply Message . . . . . . . . . . . . . . . . . . . 13

8. Representation and Use of Domain Names 13

9.
5.3. DHCP Unique Identifier (DUID) 13
9.1. DUID Contents . . . . . . . Message Types . . . . . . . . . . . . . . . 14
9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT] . . 14
9.3. DUID Assigned by Vendor Based on Enterprise Number
[DUID-EN] . 13
5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 15
9.4. DUID Based on Link-layer Address [DUID-LL] .
5.5. Transmission and Retransmission Parameters . . . . . . 16

10. Identity Association 17

11. Selecting Addresses for Assignment to an IA 17

12. Management of Temporary Addresses 18

13. Transmission
5.6 Representation of Messages by time values and "Infinity" as a Client 19

14. Reliability of Client Initiated Message Exchanges 19

15. Message Validation 21

Droms (ed.), et al. Expires 30 Apr 2003 [Page ii]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

15.1. Use of Transaction IDs . . . time
value. . . . . . . . . . . . . . . 21
15.2. Solicit Message . . . . . . . . . . 16
6. Client/Server Message Formats . . . . . . . . . . . 21
15.3. Advertise Message . . . . . 16
7. Relay Agent/Server Message Formats. . . . . . . . . . . . . . 17
7.1. Relay-forward Message. . . 21
15.4. Request Message . . . . . . . . . . . . . . 18
7.2. Relay-reply Message. . . . . . . . 22
15.5. Confirm Message . . . . . . . . . . 19
8. Representation and Use of Domain Names. . . . . . . . . . . . 22
15.6. Renew Message 19
9. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 19
9.1. DUID Contents. . . . . . . 22
15.7. Rebind Message . . . . . . . . . . . . . . 20
9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]. 20
9.3. DUID Assigned by Vendor Based on Enterprise Number
[DUID-EN]. . . . . . . . 22
15.8. Decline Messages . . . . . . . . . . . . . . . 22
9.4. DUID Based on Link-layer Address [DUID-LL] . . . . . 23
15.9. Release Message . 22
10. Identity Association. . . . . . . . . . . . . . . . . . . . . 23
15.10. Reply Message . . .
11. Selecting Addresses for Assignment to an IA . . . . . . . . . 24
12. Management of Temporary Addresses . . . . . . . . . . 23
15.11. Reconfigure Message . . . . 25
13. Transmission of Messages by a Client. . . . . . . . . . . . . 25
14. Reliability of Client Initiated Message Exchanges . . . 24
15.12. Information-request Message . . . 26
15. Message Validation. . . . . . . . . . . . . 24
15.13. Relay-forward Message . . . . . . . . . 27
15.1. Use of Transaction IDs . . . . . . . . . 24
15.14. Relay-reply Message . . . . . . . 28
15.2. Solicit Message. . . . . . . . . . . . . 24

16. Client Source Address and Interface Selection 25

17. DHCP Server Solicitation 25
17.1. Client Behavior . . . . . . . 28
15.3. Advertise Message. . . . . . . . . . . . . . . 25
17.1.1. Creation of Solicit Messages . . . . 28
15.4. Request Message. . . . . . . 25
17.1.2. Transmission of Solicit Messages . . . . . . . . 26
17.1.3. Receipt of Advertise Messages . . . . . 29
15.5. Confirm Message. . . . . . 27
17.1.4. Receipt of Reply Message . . . . . . . . . . . . 28
17.2. Server Behavior . . 29
15.6. Renew Message. . . . . . . . . . . . . . . . . . . . 28
17.2.1. Receipt of Solicit Messages . 29
15.7. Rebind Message . . . . . . . . . . 28
17.2.2. Creation and Transmission of Advertise Messages . 29
17.2.3. Creation and Transmission of Reply Messages . . . 30

18. DHCP Client-Initiated Configuration Exchange 31
18.1. Client Behavior . . . . . . 29
15.8. Decline Messages . . . . . . . . . . . . . . . 31
18.1.1. Creation and Transmission of Request Messages . . 31
18.1.2. Creation and Transmission of Confirm Messages . . 32
18.1.3. Creation and Transmission of Renew Messages 30
15.9. Release Message. . . . 33
18.1.4. Creation and Transmission of Rebind Messages . . 34
18.1.5. Creation and Transmission of Information-request
Messages . . . . . . . . . . . . . . 30
15.10. Reply Message. . . . 35
18.1.6. Creation and Transmission of Release Messages . . 36
18.1.7. Creation and Transmission of Decline Messages . . 37
18.1.8. Receipt of Reply Messages . . . . . . . . . . . . 38
18.2. Server Behavior . 30
15.11. Reconfigure Message. . . . . . . . . . . . . . . . . . 31
15.12. Information-request Message. . . . 39
18.2.1. Receipt of Request Messages . . . . . . . . . . 31

Droms, et al. Standards Track [Page 2]

RFC 3315 DHCP for IPv6 July 2003

15.13. Relay-forward Message. . 40
18.2.2. Receipt of Confirm Messages . . . . . . . . . . . 41
18.2.3. Receipt of Renew Messages . . . . 31
15.14. Relay-reply Message. . . . . . . . . 41
18.2.4. Receipt of Rebind Messages . . . . . . . . . 31
16. Client Source Address and Interface Selection . . 42
18.2.5. Receipt of Information-request Messages . . . . . 42
18.2.6. Receipt of Release Messages . 32
17. DHCP Server Solicitation. . . . . . . . . . . 43
18.2.7. Receipt of Decline Messages . . . . . . . . 32
17.1. Client Behavior. . . . . 44
18.2.8. Transmission of Reply Messages . . . . . . . . . 44

19. DHCP Server-Initiated Configuration Exchange 45
19.1. Server Behavior . . . . . . 32
17.1.1. Creation of Solicit Messages . . . . . . . . . 32
17.1.2. Transmission of Solicit Messages . . . . . . . 45
19.1.1. Creation and Transmission of Reconfigure Messages 45

Droms (ed.), et al. Expires 30 Apr 2003 [Page iii]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

19.1.2. Time Out and Retransmission 33
17.1.3. Receipt of Reconfigure
Messages Advertise Messages. . . . . . . . . 35
17.1.4. Receipt of Reply Message . . . . . . . . . . . 46
19.2. Receipt of Renew Messages 35
17.2. Server Behavior. . . . . . . . . . . . . . . . . 46
19.3. . . . 36
17.2.1. Receipt of Information-request Solicit Messages . . . . . . . . . 46
19.4. Client Behavior . . 36
17.2.2. Creation and Transmission of Advertise Messages 36
17.2.3. Creation and Transmission of Reply Messages. . 38
18. DHCP Client-Initiated Configuration Exchange. . . . . . . . . 38
18.1. Client Behavior. . . . . . . . . . . 47
19.4.1. Receipt of Reconfigure Messages . . . . . . . . . 47
19.4.2. 39
18.1.1. Creation and Transmission of Request Messages. 39
18.1.2. Creation and Transmission of Confirm Messages. 40
18.1.3. Creation and Transmission of Renew Messages Messages. . . . 48
19.4.3. 41
18.1.4. Creation and Transmission of Information-request Rebind Messages . 43
18.1.5. Creation and Transmission of Information-
request Messages . . .. . . . . . . . . . . . . . . 48
19.4.4. Time Out 44
18.1.6. Creation and Retransmission Transmission of Renew or
Information-request Messages Release Messages. 44
18.1.7. Creation and Transmission of Decline Messages. 46
18.1.8. Receipt of Reply Messages. . . . . . . . 48
19.4.5. Receipt of Reply Messages . . . 46
18.2. Server Behavior. . . . . . . . . . 48

20. Relay Agent Behavior 48
20.1. Relaying a Client Message or a Relay-forward Message . . 49
20.1.1. Relaying a Message from a Client . . . . . . . . 49
20.1.2. Relaying a Message from a Relay Agent . 48
18.2.1. Receipt of Request Messages. . . . . . 49
20.2. Relaying a Relay-reply Message . . . . 49
18.2.2. Receipt of Confirm Messages. . . . . . . . . . 50
20.3. Construction
18.2.3. Receipt of Relay-reply Messages Renew Messages. . . . . . . . . . . 50

21. Authentication of DHCP Messages 51
21.1. Security
18.2.4. Receipt of Rebind Messages Sent Between Servers and Relay Agents 51
21.2. Summary of DHCP Authentication . . . . . . . . . . 51
18.2.5. Receipt of Information-request Messages. . . . 52
21.3. Replay Detection . .
18.2.6. Receipt of Release Messages. . . . . . . . . . 53
18.2.7. Receipt of Decline Messages. . . . . . . . . . 53
21.4. Delayed Authentication Protocol
18.2.8. Transmission of Reply Messages . . . . . . . . 54
19. DHCP Server-Initiated Configuration Exchange. . . . . . 53
21.4.1. Use of the Authentication Option in the Delayed
Authentication Protocol . . . 54
19.1. Server Behavior. . . . . . . 53
21.4.2. Message Validation . . . . . . . . . . . . . 55
19.1.1. Creation and Transmission of Reconfigure
Messages . . 54
21.4.3. Key Utilization . . . . . . . . . . . . . . . . . 55
21.4.4. Client Considerations for Delayed Authentication
Protocol
19.1.2. Time Out and Retransmission of Reconfigure
Messages . . . . . . . . . . . . . . . . . 55
21.4.5. Server Considerations for Delayed Authentication
Protocol . . 56
19.2. Receipt of Renew Messages. . . . . . . . . . . . . . . 56
19.3. Receipt of Information-request Messages. . 57
21.5. Reconfigure Key Authentication Protocol . . . . . . 56
19.4. Client Behavior. . . . 57
21.5.1. Use of the Authentication Option in the Reconfigure
Key Authentication Protocol . . . . . . . 58
21.5.2. Server considerations for Reconfigure Key protocol 58
21.5.3. Client considerations for Reconfigure Key protocol 59

22. DHCP Options 59
22.1. Format of DHCP Options . . . . . . . . . 57
19.4.1. Receipt of Reconfigure Messages. . . . . . . . 57
19.4.2. Creation and Transmission of Renew Messages. . 60
22.2. Client Identifier Option 58
19.4.3. Creation and Transmission of Information-
request Messages . . . . . . . . . . . . . . . 58
19.4.4. Time Out and Retransmission of Renew or
Information-request Messages . 60
22.3. Server Identifier Option . . . . . . . . 58

Droms, et al. Standards Track [Page 3]

RFC 3315 DHCP for IPv6 July 2003

19.4.5. Receipt of Reply Messages. . . . . . . . . 61
22.4. Identity Association for Non-temporary Addresses Option . 61
22.5. Identity Association for Temporary Addresses Option . 58
20. Relay Agent Behavior. . . 63
22.6. IA Address Option . . . . . . . . . . . . . . . . . . 58
20.1. Relaying a Client Message or a Relay-forward Message . 59
20.1.1. Relaying a Message from a Client . 65
22.7. Option Request Option . . . . . . 59
20.1.2. Relaying a Message from a Relay Agent. . . . . 59
20.2. Relaying a Relay-reply Message . . . . . . . . 66
22.8. Preference Option . . . . 60
20.3. Construction of Relay-reply Messages . . . . . . . . . 60
21. Authentication of DHCP Messages . . . . . . . 66
22.9. Elapsed Time Option . . . . . . . . 61
21.1. Security of Messages Sent Between Servers and Relay
Agents . . . . . . . . . . . 67
22.10. Relay Message Option . . . . . . . . . . . . 61
21.2. Summary of DHCP Authentication . . . . . . 68
22.11. Authentication Option . . . . . . 63
21.3. Replay Detection . . . . . . . . . . . . 68
22.12. Server Unicast Option . . . . . . . 63
21.4. Delayed Authentication Protocol. . . . . . . . . . . . 69
22.13. Status Code 63
21.4.1. Use of the Authentication Option in the Delayed
Authentication Protocol. . . . . . . . . . . . 64
21.4.2. Message Validation . . . . . . . . 70

Droms (ed.), et al. Expires 30 Apr 2003 [Page iv]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

22.14. Rapid Commit Option . . . . . . 65
21.4.3. Key Utilization . . . . . . . . . . . . . 71
22.15. User Class Option . . 65
21.4.4. Client Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . 71
22.16. Vendor Class Option . 66
21.4.5. Server Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . 73
22.17. Vendor-specific Information Option . 67
21.5. Reconfigure Key Authentication Protocol. . . . . . . . 68
21.5.1. Use of the Authentication Option in the
Reconfigure Key Authentication Protocol. . . . 73
22.18. Interface-Id Option 69
21.5.2. Server considerations for Reconfigure Key
protocol . . . . . . . . . . . . . . . . . . . 75
22.19. 69
21.5.3. Client considerations for Reconfigure Message Option . Key
protocol . . . . . . . . . . . . . . 76
22.20. Reconfigure Accept Option . . . . . 70
22. DHCP Options. . . . . . . . . . . . 76

23. Security Considerations 77

24. IANA Considerations 78
24.1. Multicast Addresses . . . . . . . . . . . . . 70
22.1. Format of DHCP Options . . . . . . 79
24.2. DHCP Message Types . . . . . . . . . . 71
22.2. Client Identifier Option . . . . . . . . . 79
24.3. DHCP Options . . . . . . 71
22.3. Server Identifier Option . . . . . . . . . . . . . . . 72
22.4. Identity Association for Non-temporary Addresses Option 72
22.5. Identity Association for Temporary Addresses Option. . 80
24.4. Status Codes 75
22.6. IA Address Option. . . . . . . . . . . . . . . . . . . 76
22.7. Option Request Option. . . . . . . . . . . . . . . . . 78
22.8. Preference Option. . . . . . . . 81
24.5. DUID . . . . . . . . . . . 79
22.9. Elapsed Time Option. . . . . . . . . . . . . . . . . . 79
22.10. Relay Message Option . . . . . . . . . . . . . . . . . 80
22.11. Authentication Option. . . . . . . . . . . . . . . . . 81

25. Acknowledgments
22.12. Server Unicast Option. . . . . . . . . . . . . . . . . 82

26. Changes in draft-ietf-dhc-dhcpv6-27.txt
22.13. Status Code Option . . . . . . . . . . . . . . . . . . 82

27. Changes in draft-ietf-dhc-dhcpv6-28.txt
22.14. Rapid Commit Option. . . . . . . . . . . . . . . . . . 83

References
22.15. User Class Option. . . . . . . . . . . . . . . . . . . 84

Chair's Address
22.16. Vendor Class Option. . . . . . . . . . . . . . . . . . 85

Authors' Addresses
22.17. Vendor-specific Information Option . . . . . . . . . . 86

A. Appearance of Options in Message Types 87

B. Appearance of Options in the Options Field of DHCP Options
22.18. Interface-Id Option. . . . . . . . . . . . . . . . . . 87

C. Full Copyright Statement
22.19. Reconfigure Message Option . . . . . . . . . . . . . . 88

Droms (ed.),

Droms, et al. Expires 30 Apr 2003 Standards Track [Page v]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

1. Introduction and Overview

This document describes 4]

RFC 3315 DHCP for IPv6 (DHCP), a client/server
protocol that provides managed configuration of devices.

DHCP can provide a device with addresses assigned by a DHCP server
and other configuration information, which are carried in options. July 2003

22.20. Reconfigure Accept Option. . . . . . . . . . . . . . . 89
23. Security Considerations . . . . . . . . . . . . . . . . . . . 89
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
24.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 92
24.2. DHCP can be extended through the definition of new options to carry
configuration information not specified in this document. Message Types . . . . . . . . . . . . . . . . . . 93
24.3. DHCP is the "stateful address autoconfiguration protocol" and the
"stateful autoconfiguration protocol" referred to in "IPv6 Stateless
Address Autoconfiguration" [21].

The operational models and relevant configuration information for
DHCPv4 [1][6] and DHCPv6 are sufficiently different that integration
between the two services is not included in this document. If there
is sufficient interest and demand, integration can be specified
in a document that extends DHCPv6 to carry IPv4 addresses and
configuration information.

The remainder of this introduction summarizes DHCP, explaining
the message exchange mechanisms and example message flows. The
message flows in sections 1.2 and 1.3 are intended as illustrations
of DHCP operation rather than an exhaustive list of all possible
client-server interactions. Sections 17, 18 and 19 explain client
and server operation in detail.

1.1. Protocols and Addressing

Clients and servers exchange DHCP messages using UDP [19]. The
client uses a link-local address or addresses determined through
other mechanisms for transmitting and receiving DHCP messages.

DHCP servers receive messages from clients using a reserved,
link-scoped multicast address. A DHCP client transmits most messages
to this reserved multicast address, so that the client need not be
configured with the address or addresses of DHCP servers.

To allow a DHCP client to send a message to a DHCP server that is not
attached to the same link, a DHCP relay agent on the client's link
will relay messages between the client and server. The operation
of the relay agent is transparent to the client and the discussion
of message exchanges in the remainder of this section will omit the
description of message relaying by relay agents.

Once the client has determined the address of a server, it may
under some circumstances send messages directly to the server using
unicast.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 1]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

1.2. Client-server Exchanges Involving Two Messages

When a DHCP client does not need to have a DHCP server assign
it IP addresses, the client can obtain configuration information
such as a list of available DNS servers [8] or NTP servers [22]
through a single message and reply exchanged with a DHCP server.
To obtain configuration information the client first sends an
Information-Request message to the All_DHCP_Relay_Agents_and_Servers
multicast address. Servers respond 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.

When a server has IPv6 addresses and other configuration information
committed to a client, the client and server may be able to complete
the exchange using only two messages, instead of four messages as
described in the next section. In this case, the client sends a
Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting
the assignment of addresses and other configuration information.
This message includes an indication that the client is willing to
accept an immediate Reply message from the server. The server that
is willing to commit the assignment of addresses to the client
immediately responds with a Reply message. The configuration
information and the addresses in the Reply message are then
immediately available for use by the client.

Each address assigned to the client has associated preferred and
valid lifetimes specified by the server. To request an extension
of the lifetimes assigned to an address, the client sends a Renew
message to the server. The server sends a Reply message to the
client with the new lifetimes, allowing the client to continue to use
the address without interruption.

1.3. Client-server Exchanges Involving Four Messages

To request the assignment of one or more IPv6 addresses, a
client first locates a DHCP server and then requests the
assignment of addresses and other configuration 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 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 confirmed assignment of addresses and other configuration
information. The server responds with a Reply message that contains
the confirmed addresses and configuration.

As described in the previous section, the client sends a Renew
message to the server to extend the lifetimes associated with its

Droms (ed.), et al. Expires 30 Apr 2003 [Page 2]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

addresses, allowing the client to continue to use those addresses
without interruption.

2. Requirements

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

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

3. Background

The IPv6 Specification provides the base architecture and design of
IPv6. Related work in IPv6 that would best serve an implementor
to study includes the IPv6 Specification [5], the IPv6 Addressing
Architecture [9], IPv6 Stateless Address Autoconfiguration [21], IPv6
Neighbor Discovery Processing [17], and Dynamic Updates to DNS [23].
These specifications enable DHCP to build upon the IPv6 work to
provide both robust stateful autoconfiguration and autoregistration
of DNS Host Names.

The IPv6 Addressing Architecture specification [9] defines the
address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required and nodes can create link-local addresses
during initialization. The availability of these features means that
a client can use its link-local address and a well-known multicast
address to discover and communicate with DHCP servers or relay agents
on its link.

IPv6 Stateless Address Autoconfiguration [21] specifies procedures
by which a node may autoconfigure addresses based on router
advertisements [17], and the use of a valid lifetime to support
renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with stateless address
autoconfiguration is a design requirement of DHCP.

IPv6 Neighbor Discovery [17] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [18]. To understand

Droms (ed.), et al. Expires 30 Apr 2003 [Page 3]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

IPv6 and stateless address autoconfiguration it is strongly
recommended that implementors understand IPv6 Neighbor Discovery.

Dynamic Updates to DNS [23] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space to
not only support autoconfiguration, but also autoregistration in
IPv6.

4. Terminology

This sections defines terminology specific to IPv6 and DHCP used in
this document.

4.1. IPv6 Terminology

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

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

host Any node that is not a router.

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

interface A node's attachment to a link.

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

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

link-local address An IPv6 address having link-only
scope, indicated by having the prefix
(FE80::/10), that can be used to reach

Droms (ed.), et al. Expires 30 Apr 2003 [Page 4]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

neighboring nodes attached to the same
link. Every interface has a link-local
address.

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

neighbor A node attached to the same link.

node A device that implements IP.

packet An IP header plus payload.

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

prefix length The number of bits in a prefix.

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

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

4.2. DHCP Terminology

Terminology specific to DHCP can be found below.

appropriate to the link An address is "appropriate to the link"
when the address is consistent with the
DHCP server's knowledge of the network
topology, prefix assignment and address
assignment policies.

binding A binding (or, client binding) is a
group of server data records containing
the information the server has about
the addresses in an IA or configuration
information explicitly assigned to the
client. Configuration information that
has been returned to a client through a
policy - for example, the information
returned to all clients on the same
link - does not require a binding. A
binding containing information about

Droms (ed.), et al. Expires 30 Apr 2003 [Page 5]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

an IA is indexed by the tuple <DUID,
IA-type, IAID> (where IA-type is the
type of address in the IA; for example,
temporary). A binding containing
configuration information for a client
is indexed by <DUID>.

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

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

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

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

DHCP realm A name used to identify the DHCP
administrative domain from which a DHCP
authentication key was selected.

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 node that responds to requests from
clients, and may or may not be on the
same link as the client(s). Options . . . . . . . . . . . . . . . . . . . . . 94
24.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 95
24.5. DUID A DHCP Unique IDentifier for a DHCP
participant; each DHCP client and server
has exactly one DUID. See section 9 for
details . . . . . . . . . . . . . . . . . . . . . . . . . 95
25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95
26. References. . . . . . . . . . . . . . . . . . . . . . . . . . 96
26.1. Normative References . . . . . . . . . . . . . . . . . 96
26.2. Informative References . . . . . . . . . . . . . . . . 97
A. Appearance of the ways Options in which a DUID may
be constructed.

Identity association (IA) A collection Message Types . . . . . . . . . . . . 98
B. Appearance of addresses assigned to
a client. Each IA has an associated
IAID. A client may have more than one
IA assigned to it; for example, one for
each Options in the Options Field of its interfaces.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 6]

Internet Draft DHCP Options . . 99
Chair's Address . . . . . . . . . . . . . . . . . . . . . . . . . 99
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 100
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 101

1. Introduction and Overview

This document describes DHCP for IPv6 (-28) 2 Nov 2002

Each IA holds one type of address;
for example, an identity association
for temporary addresses (IA_TA) holds
temporary addresses (see "identity
association for temporary addresses").
Throughout this document, "IA" is used
to refer to an identity association
without identifying the type IPv6 (DHCP), a client/server
protocol that provides managed configuration of devices.

DHCP can provide a device with addresses in the IA.

Identity association identifier (IAID) An identifier for an IA,
chosen assigned by the client. Each IA has an
IAID, a DHCP server
and other configuration information, which is chosen to be unique among
all IAIDs for IAs belonging to that
client.

Identity association for non-temporary addresses (IA_NA) An IA
that carries assigned addresses that are
not temporary addresses (see "identity
association for temporary addresses")

Identity association for temporary addresses (IA_TA) An IA that
carries temporary addresses (see RFC
3041 [16]).

message A unit of data carried as in options.
DHCP can be extended through the payload definition of a UDP datagram, exchanged among new options to carry
configuration information not specified in this document.

DHCP
servers, relay agents is the "stateful address autoconfiguration protocol" and clients.

Reconfigure key An key supplied to a client by a server
used the
"stateful autoconfiguration protocol" referred to provide security in "IPv6 Stateless
Address Autoconfiguration" [17].

The operational models and relevant configuration information for Reconfigure
messages.

relaying A DHCP relay agent relays DHCP messages
DHCPv4 [18][19] and DHCPv6 are sufficiently different that
integration between DHCP participants.

transaction ID An opaque value used to match responses
with replies initiated either by a
client or server.

5. DHCP Constants

This section describes various program the two services is not included in this
document. If there is sufficient interest and demand, integration
can be specified in a document that extends DHCPv6 to carry IPv4
addresses and networking constants used
by DHCP.

5.1. Multicast Addresses

DHCP makes use configuration information.

The remainder of this introduction summarizes DHCP, explaining the following multicast addresses:

All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped
multicast address used by a
message exchange mechanisms and example message flows. The message
flows in sections 1.2 and 1.3 are intended as illustrations of DHCP
operation rather than an exhaustive list of all possible
client-server interactions. Sections 17, 18, and 19 explain client to communicate with

Droms (ed.),
and server operation in detail.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 7]

Internet Draft 5]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

neighboring (i.e., on-link) relay agents July 2003

1.1. Protocols and Addressing

Clients and servers.
All servers exchange DHCP messages using UDP [15]. The
client uses a link-local address or addresses determined through
other mechanisms for transmitting and relay agents are members of this receiving DHCP messages.

DHCP servers receive messages from clients using a reserved,
link-scoped multicast group.

All_DHCP_Servers (FF05::1:3) address. A site-scoped multicast address used
by a relay agent to communicate with servers, either
because the relay agent wants to send DHCP client transmits most messages
to
all servers or because it does this reserved multicast address, so that the client need not know be
configured with the unicast address or addresses of the DHCP servers. Note that in order for

To allow a relay agent DHCP client to use this address, it must have an
address of sufficient scope send a message to be reachable by the
servers. All servers within the site are members of
this multicast group.

5.2. UDP Ports

Clients listen for a DHCP server that is not
attached to the same link, a DHCP messages relay agent on UDP port 546. Servers and the client's link
will relay
agents listen for DHCP messages on UDP port 547.

5.3. DHCP Message Types

DHCP defines between the following message types. More detail on these
message types can be found in sections 6 client and 7. Message types not
listed here are reserved for future use. server. The numeric encoding for
each message type operation of
the relay agent is shown transparent to the client and the discussion of
message exchanges in parentheses.

SOLICIT (1) A the remainder of this section will omit the
description of message relaying by relay agents.

Once the client sends has determined the address of a Solicit message server, it may under
some circumstances send messages directly to locate
servers.

ADVERTISE (2) A the server sends an Advertise message to indicate
that it is available for using
unicast.

1.2. Client-server Exchanges Involving Two Messages

When a DHCP service, in
response client does not need to have a Solicit message received from a
client.

REQUEST (3) A DHCP server assign it IP
addresses, the client sends can obtain configuration information such as a Request
list of available DNS servers [20] or NTP servers [21] through a
single message to request
configuration parameters, including IP
addresses, from and reply exchanged with a specific DHCP server.

CONFIRM (4) A To obtain
configuration information the client first sends a Confirm an
Information-Request message to any
available server to determine whether the
addresses it was assigned are still appropriate
to the link to which the client is connected.

RENEW (5) A client sends All_DHCP_Relay_Agents_and_Servers
multicast address. Servers respond with a Renew Reply message to containing
the server configuration information for the client.

This message exchange assumes that originally provided the client's addresses
and client requires only
configuration parameters to extend the
lifetimes on information and does not require the assignment of any
IPv6 addresses.

When a server has IPv6 addresses assigned and other configuration information
committed to a client, the client and server may be able to update other configuration
parameters.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 8]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

REBIND (6) A complete
the exchange using only two messages, instead of four messages as
described in the next section. In this case, the client sends a Rebind
Solicit message to any
available server to extend the lifetimes on All_DHCP_Relay_Agents_and_Servers requesting
the assignment of addresses assigned to the client and to update other configuration parameters; this information.
This message is
sent after a includes an indication that the client receives no response is willing to a
Renew message.

REPLY (7) A server sends a
accept an immediate Reply message containing
assigned addresses and configuration parameters
in response to a Solicit, Request, Renew,
Rebind message received from a client. A the server. The server sends that
is willing to commit the assignment of addresses to the client

Droms, et al. Standards Track [Page 6]

RFC 3315 DHCP for IPv6 July 2003

immediately responds with a Reply message containing message. The configuration parameters
information and the addresses in response to an
Information-request message. A server sends a the Reply message in response to a Confirm message
confirming or denying that are then
immediately available for use by the addresses client.

Each address assigned to the client are appropriate has associated preferred and
valid lifetimes specified by the server. To request an extension of
the lifetimes assigned to an address, the
link client sends a Renew
message to which the client is connected. A server. The server sends a Reply message to acknowledge
receipt the
client with the new lifetimes, allowing the client to continue to use
the address without interruption.

1.3. Client-server Exchanges Involving Four Messages

To request the assignment of a Release one or Decline message.

RELEASE (8) A more IPv6 addresses, a client
first locates a DHCP server and then requests the assignment of
addresses and other configuration information from the server. The
client sends a Release Solicit message to the
All_DHCP_Relay_Agents_and_Servers address to find available DHCP
servers. Any server that assigned addresses to 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
indicate that the client will no longer use one
or more server asking for
confirmed assignment of addresses and other configuration
information. The server responds with a Reply message that contains
the confirmed addresses and configuration.

As described in the previous section, the assigned addresses.

DECLINE (9) A client sends a Decline Renew
message to a the server to
indicate that extend the lifetimes associated with its
addresses, allowing the client has determined that
one or more to continue to use those addresses assigned by the server
without interruption.

2. Requirements

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

This document also makes use on the link of internal conceptual variables to
describe protocol behavior and external variables that an
implementation must allow system administrators to change. The
specific variable names, how their values change, and how their
settings influence protocol behavior are provided to which the
client demonstrate
protocol behavior. An implementation is connected.

RECONFIGURE (10) A server sends a Reconfigure message to a
client not required to inform have them in
the client exact form described here, so long as its external behavior is
consistent with that described in this document.

Droms, et al. Standards Track [Page 7]

RFC 3315 DHCP for IPv6 July 2003

3. Background

The IPv6 Specification provides the server has
new or updated configuration parameters, base architecture and design of
IPv6. Related work in IPv6 that would best serve an implementor to
study includes the client is IPv6 Specification [3], the IPv6 Addressing
Architecture [5], IPv6 Stateless Address Autoconfiguration [17], IPv6
Neighbor Discovery Processing [13], and Dynamic Updates to initiate a Renew/Reply
or Information-request/Reply transaction with DNS [22].
These specifications enable DHCP to build upon the server in order IPv6 work to receive
provide both robust stateful autoconfiguration and autoregistration
of DNS Host Names.

The IPv6 Addressing Architecture specification [5] defines the updated
information.

INFORMATION-REQUEST (11) A client sends
address scope that can be used in an Information-request
message to a server to request IPv6 implementation, and the
various configuration
parameters without architecture guidelines for network designers
of the assignment IPv6 address space. Two advantages of any IP IPv6 are that support
for multicast is required and nodes can create link-local addresses
during initialization. The availability of these features means that
a client can use its link-local address and a well-known multicast
address to discover and communicate with DHCP servers or relay agents
on its link.

IPv6 Stateless Address Autoconfiguration [17] specifies procedures by
which a node may autoconfigure addresses based on router
advertisements [13], and the client.

RELAY-FORW (12) A relay agent sends use of a Relay-forward message
to relay messages valid lifetime to servers, either directly
or through another relay agent. The received
message, either support
renumbering of addresses on the Internet. In addition, the protocol
interaction by which a client message node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with stateless address
autoconfiguration is a
Relay-forward message from another relay
agent, design requirement of DHCP.

IPv6 Neighbor Discovery [13] is encapsulated in an option in the
Relay-forward message.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 9]

Internet Draft DHCP for node discovery protocol in IPv6 (-28) 2 Nov 2002

RELAY-REPL (13) A server sends a Relay-reply message
which replaces and enhances functions of ARP [14]. To understand
IPv6 and stateless address autoconfiguration, it is strongly
recommended that implementors understand IPv6 Neighbor Discovery.

Dynamic Updates to DNS [22] is a relay
agent containing a message specification that supports the relay
agent delivers to a client. The Relay-reply
message may be relayed by other relay agents
dynamic update of DNS records for delivery to the destination relay agent.
The server encapsulates the client message as
an option in the Relay-reply message, which the
relay agent extracts both IPv4 and relays to IPv6. DHCP can use
the client.

5.4. Status Codes

DHCPv6 uses status codes dynamic updates to communicate the success or failure of
operations requested in messages from clients DNS to integrate addresses and servers, name space to
not only support autoconfiguration, but also autoregistration in
IPv6.

4. Terminology

This sections defines terminology specific to IPv6 and DHCP used in
this document.

Droms, et al. Standards Track [Page 8]

RFC 3315 DHCP for IPv6 July 2003

4.1. IPv6 Terminology

IPv6 terminology relevant to
provide additional information about the specific cause of this specification from the
failure IPv6
Protocol [3], IPv6 Addressing Architecture [5], and IPv6 Stateless
Address Autoconfiguration [17] is included below.

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

host Any node that is not a message. router.

IP Internet Protocol Version 6 (IPv6). The specific status codes are defined in
section 24.4.

5.5. Transmission
terms IPv4 and Retransmission Parameters

This section presents a table of values IPv6 are used only in
contexts where it is necessary to describe avoid
ambiguity.

interface A node's attachment to a link.

link A communication facility or medium over
which nodes can communicate at the message
transmission behavior of clients 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 servers.

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

link-local address An IPv6 address having a link-only
scope, indicated by having the prefix
(FE80::/10), that can be used to reach
neighboring nodes attached to the same
link. Every interface has a link-local
address.

multicast address An identifier for a set of first Information-request
INF_TIMEOUT 1 sec Initial Information-request timeout
INF_MAX_RT 120 secs Max Information-request timeout value
REL_TIMEOUT 1 sec Initial Release timeout
REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 1 sec Initial Decline timeout
DEC_MAX_RC 5 Max Decline attempts
REC_TIMEOUT 2 secs Initial Reconfigure timeout
REC_MAX_RC 8 Max Reconfigure attempts
HOP_COUNT_LIMIT 32 Max hop count in interfaces
(typically belonging to different
nodes). A packet sent to a Relay-forward message

Droms (ed.), multicast
address is delivered to all interfaces
identified by that address.

neighbor A node attached to the same link.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 10]

Internet Draft 9]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

6. Client/Server Message Formats

All July 2003

node A device that implements IP.

packet An IP header plus payload.

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

prefix length The number of bits in a prefix.

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

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

4.2. DHCP Terminology

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

All values in can be found below.

appropriate to the message header and in options are in network byte
order.

Options are stored serially in link An address is "appropriate to the options field, with no padding
between link"
when the options. Options are byte-aligned but are not aligned in
any other way such as on 2 or 4 byte boundaries.

The following diagram illustrates address is consistent with the format of
DHCP messages sent
between clients server's knowledge of the network
topology, prefix assignment 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) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type Identifies address
assignment policies.

binding A binding (or, client binding) is a
group of server data records containing
the DHCP message type; information the
available message types are listed in
section 5.3.

transaction-id The transaction ID for this message exchange.

options Options carried in this message; options are
described server has about
the addresses in section 22.

7. Relay Agent/Server Message Formats

Relay agents exchange messages with servers an IA or configuration
information explicitly assigned to relay messages between
clients and servers the
client. Configuration information that are not connected
has been returned to a client through a
policy - for example, the information
returned to all clients on the same link.

All values in the message header and in options are in network byte
order.

Options are stored serially in
link - does not require a binding. A
binding containing information about
an IA is indexed by the options field, with no padding
between tuple <DUID,
IA-type, IAID> (where IA-type is the options. Options are byte-aligned but are not aligned
type of address in
any other way such as on 2 or 4 byte boundaries.

Droms (ed.), the IA; for example,
temporary). A binding containing
configuration information for a client
is indexed by <DUID>.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 11]

Internet Draft 10]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

There are two relay agent messages, which share July 2003

configuration parameter An element of 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 | hop-count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| peer-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. options (variable number and length) .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following sections describe configuration
information set on the use of server and
delivered to the Relay Agent message
header.

7.1. Relay-forward Message client using DHCP.
Such parameters may be used to carry
information to be used by a node to
configure its network subsystem and
enable communication on a link or
internetwork, for example.

DHCP Dynamic Host Configuration Protocol
for IPv6. The following table defines the use of message fields terms DHCPv4 and DHCPv6
are used only in contexts where it is
necessary to avoid ambiguity.

DHCP client (or client) A node that initiates requests on a
Relay-forward message.

msg-type RELAY-FORW

hop-count Number 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 realm A name used to identify the DHCP
administrative domain from which a DHCP
authentication key was selected.

DHCP relay agents that have relayed this
message

link-address agent (or relay agent) A global or site-local address node that will be used by 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 node that responds to identify requests from
clients, and may or may not be on the
same link on which as the client(s).

DUID A DHCP Unique IDentifier for a DHCP
participant; each DHCP client
is located.

peer-address The address and server
has exactly one DUID. See section 9 for
details of the client or relay agent from ways in which
the message to a DUID may
be relayed was received

options MUST include constructed.

Identity association (IA) A collection of addresses assigned to
a "Relay Message option" (see
section 22.10); MAY include other options added by
the relay agent

Droms (ed.), client. Each IA has an associated
IAID. A client may have more than one
IA assigned to it; for example, one for
each of its interfaces.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 12]

Internet Draft 11]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

7.2. Relay-reply Message

The following table defines July 2003

Each IA holds one type of address;
for example, an identity association
for temporary addresses (IA_TA) holds
temporary addresses (see "identity
association for temporary addresses").
Throughout this document, "IA" is used
to refer to an identity association
without identifying the use type of message fields
addresses in a
Relay-reply message.

msg-type RELAY-REPL

hop-count Copied from the Relay-forward message

link-address Copied from IA.

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

Identity association for non-temporary addresses (IA_NA) An IA
that carries assigned addresses that are
not temporary addresses (see "identity
association for temporary addresses")

Identity association for temporary addresses (IA_TA) An IA that
carries temporary addresses (see RFC
3041 [12]).

message

peer-address Copied from A unit of data carried as the Relay-forward message

options MUST include payload
of a "Relay Message option"; see
section 22.10; MAY include other options

8. Representation UDP datagram, exchanged among DHCP
servers, relay agents and Use of Domain Names

So that domain names may be encoded uniformly, clients.

Reconfigure key A key supplied to a domain name or client by a
list of domain names is encoded using the technique described in
section 3.1 of RFC1035 [14]. server
used to provide security for Reconfigure
messages.

relaying A domain name DHCP relay agent relays DHCP messages
between DHCP participants.

transaction ID An opaque value used to match responses
with replies initiated either by a
client or list of domain names
in server.

5. DHCP MUST NOT be stored in compressed form as described in Constants

This section
4.1.4 of RFC1035.

9. describes various program and networking constants used
by DHCP.

Droms, et al. Standards Track [Page 12]

RFC 3315 DHCP Unique Identifier (DUID)

Each for IPv6 July 2003

5.1. Multicast Addresses

DHCP makes use of the following multicast addresses:

All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped
multicast address used by a client to communicate with
neighboring (i.e., on-link) relay agents and server has a DUID. DHCP servers.
All servers use DUIDs to
identify clients for the selection of configuration parameters and
in the association relay agents are members of IAs this
multicast group.

All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used
by a relay agent to communicate with clients. DHCP clients use DUIDs servers, either
because the relay agent wants to
identify a server in send messages where a server needs to be identified.
See sections 22.2 and 22.3 for
all servers or because it does not know the representation unicast
addresses of a DUID the servers. Note that in a DHCP
message.

Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs order for equality. Clients and
a relay agent to use this address, it must have an
address of sufficient scope to be reachable by the
servers. All servers MUST NOT in any
other way interpret DUIDs. within the site are members of
this multicast group.

5.2. UDP Ports

Clients listen for DHCP messages on UDP port 546. Servers and servers MUST NOT restrict
DUIDs to relay
agents listen for DHCP messages on UDP port 547.

5.3. DHCP Message Types

DHCP defines the following message types. More detail on these
message types defined in this document as additional DUID types
may can be defined found in the future. sections 6 and 7. Message types not
listed here are reserved for future use. The DUID numeric encoding for
each message type is carried shown in parentheses.

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

ADVERTISE (2) A server sends an option because it may be variable length
and because Advertise message to indicate
that it is not required in all available for DHCP messages. The DUID is
designed service, in
response to be unique across all DHCP clients and servers, and stable
for any a Solicit message received from a
client.

REQUEST (3) A client sends a Request message to request
configuration parameters, including IP
addresses, from a specific server.

CONFIRM (4) A client or sends a Confirm message to any
available server - that is, to determine whether the
addresses it was assigned are still appropriate
to the link to which the DUID used by a client or server SHOULD NOT change over time if at all possible; is connected.

Droms, et al. Standards Track [Page 13]

RFC 3315 DHCP for
example, a device's DUID should not change as a result of IPv6 July 2003

RENEW (5) A client sends a change in Renew message to the device's network hardware.

The motivation for having more than one type of DUID is server
that originally provided the client's addresses
and configuration parameters to extend the
lifetimes on the addresses assigned to the
client and to update other configuration
parameters.

REBIND (6) A client sends a Rebind message to any
available server to extend the DUID
must be globally unique, lifetimes on the
addresses assigned to the client and must also be easy to generate. The sort
of globally-unique identifier that update
other configuration parameters; this message is easy
sent after a client receives no response to generate for any given
device can differ quite widely. Also, some devices may not contain

Droms (ed.), et al. Expires 30 Apr 2003 [Page 13]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

any persistent storage. Retaining a generated DUID
Renew message.

REPLY (7) A server sends a Reply message containing
assigned addresses and configuration parameters
in such response to a device
is not possible, so the DUID scheme must accommodate such devices.

9.1. DUID Contents Solicit, Request, Renew,
Rebind message received from a client. A DUID consists of
server sends a two-octet type code represented Reply message containing
configuration parameters in network byte
order, followed by response to an
Information-request message. A server sends a variable number of octets
Reply message in response to a Confirm message
confirming or denying that make up the
actual identifier. A DUID can be no more than 128 octets long (not
including the type code). The following types are currently defined:

1 Link-layer address plus time
2 Vendor-assigned unique ID based on Enterprise Number
3 Link-layer address

Formats for the variable field of the DUID for each of addresses
assigned to the above
types client are shown below.

9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]

This type of DUID consists of a two octet type field containing appropriate to the
value 1, a two octet hardware type code, four octets containing
link to which the client is connected. A
server sends a time value, followed by link-layer address Reply message to acknowledge
receipt of any one network
interface that is connected a Release or Decline message.

RELEASE (8) A client sends a Release message to the DHCP device at server
that assigned addresses to the time client to
indicate that the
DUID is generated. The time value is client will no longer use one
or more of the time assigned addresses.

DECLINE (9) A client sends a Decline message to a server to
indicate that the DUID is
generated represented in seconds since midnight (UTC), January 1,
2000, modulo 2^32. The hardware type MUST be a valid hardware type client has determined that
one or more addresses assigned by the IANA as described server
are already in RFC826 [18]. Both use on the time and link to which the hardware type are stored in network byte order. The link-layer
address
client is stored in canonical form, as described in RFC2464 [4].

The following diagram illustrates the format of connected.

RECONFIGURE (10) A server sends a DUID-LLT:

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) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The choice of network interface can be completely arbitrary, as long
as that interface provides Reconfigure message to a globally unique link-layer address for
client to inform the link type, client that the server has
new or updated configuration parameters, and
that the same DUID-LLT SHOULD be used in configuring
all network interfaces connected client is to initiate a Renew/Reply
or Information-request/Reply transaction with
the device, regardless of which
interface's link-layer address was used server in order to generate receive the DUID-LLT.

Droms (ed.), updated
information.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 14]

Internet Draft

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

Clients and servers using this type July 2003

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

RELAY-FORW (12) A relay agent sends a Relay-forward message
to relay messages to servers, either directly
or through another relay agent. The received
message, either a client message or a
Relay-forward message from another relay
agent, is encapsulated in stable storage, and MUST continue an option in the
Relay-forward message.

RELAY-REPL (13) A server sends a Relay-reply message to use this DUID-LLT even if a relay
agent containing a message that the
network interface used relay
agent delivers to a client. The Relay-reply
message may be relayed by other relay agents
for delivery to generate the DUID-LLT is removed. Clients destination relay agent.

The server encapsulates the client message as
an option in the Relay-reply message, which the
relay agent extracts and servers that do not have any stable storage MUST NOT use this
type relays to the client.

5.4. Status Codes

DHCPv6 uses status codes to communicate the success or failure of DUID.

Clients
operations requested in messages from clients and servers, and servers that use this DUID SHOULD attempt to configure
provide additional information about the time prior to generating specific cause of the DUID, if that is possible, and MUST
use some sort
failure of time source (for example, a real-time clock) message. The specific status codes are defined in
generating the DUID, even if that time source could not be configured
prior
section 24.4.

Droms, et al. Standards Track [Page 15]

RFC 3315 DHCP for IPv6 July 2003

5.5. Transmission and Retransmission Parameters

This section presents a table of values used to generating describe the DUID. The use message
transmission behavior of a time source makes it
unlikely that two identical DUID-LLTs will be generated if the
network interface is removed from the client clients and another client then
uses the same network interface to generate servers.

Parameter Default Description
-------------------------------------
SOL_MAX_DELAY 1 sec Max delay of first Solicit
SOL_TIMEOUT 1 sec Initial Solicit timeout
SOL_MAX_RT 120 secs Max Solicit timeout value
REQ_TIMEOUT 1 sec Initial Request timeout
REQ_MAX_RT 30 secs Max Request timeout value
REQ_MAX_RC 10 Max Request retry attempts
CNF_MAX_DELAY 1 sec Max delay of first Confirm
CNF_TIMEOUT 1 sec Initial Confirm timeout
CNF_MAX_RT 4 secs Max Confirm timeout
CNF_MAX_RD 10 secs Max Confirm duration
REN_TIMEOUT 10 secs Initial Renew timeout
REN_MAX_RT 600 secs Max Renew timeout value
REB_TIMEOUT 10 secs Initial Rebind timeout
REB_MAX_RT 600 secs Max Rebind timeout value
INF_MAX_DELAY 1 sec Max delay of first Information-request
INF_TIMEOUT 1 sec Initial Information-request timeout
INF_MAX_RT 120 secs Max Information-request timeout value
REL_TIMEOUT 1 sec Initial Release timeout
REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 1 sec Initial Decline timeout
DEC_MAX_RC 5 Max Decline attempts
REC_TIMEOUT 2 secs Initial Reconfigure timeout
REC_MAX_RC 8 Max Reconfigure attempts
HOP_COUNT_LIMIT 32 Max hop count in a DUID-LLT. A collision
between two DUID-LLTs is very unlikely even if the clocks haven't
been configured prior to generating the DUID.

This method Relay-forward message

5.6 Representation of DUID generation is recommended for all general purpose
computing devices such as desktop computers and laptop computers, time values and
also for devices such "Infinity" as printers, routers, a time value

All time values for lifetimes, T1 and so on, that contain
some form of writable non-volatile storage.

Despite our best efforts, it T2 are unsigned integers. The
value 0xffffffff is possible that this algorithm for
generating taken to mean "infinity" when used as a DUID could result lifetime
(as in RFC2461 [17]) or a client identifier collision.
A value for T1 or T2.

6. Client/Server Message Formats

All DHCP client that generates a DUID-LLT using this mechanism MUST
provide messages sent between clients and servers share an administrative interface that replaces the existing DUID
with identical
fixed format header and a newly-generated DUID-LLT.

9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]

This form of DUID is assigned by variable format area for options.

All values in the vendor to message header and in options are in network byte
order.

Droms, et al. Standards Track [Page 16]

RFC 3315 DHCP for IPv6 July 2003

Options are stored serially in the device. It
consists of options field, with no padding
between the vendor's registered Private Enterprise Number options. Options are byte-aligned but are not aligned in
any other way such as
maintained by IANA [10] followed by a unique identifier assigned by
the vendor. on 2 or 4 byte boundaries.

The following diagram summarizes illustrates the structure format of a
DUID-EN: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 msg-type | enterprise-number transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier
.
. (variable length) options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The source of the identifier is left up to the vendor defining it,
but each identifier part of each DUID-EN MUST be unique to the device
that is using it, and MUST be assigned to the device at

msg-type Identifies the time of

Droms (ed.), et al. Expires 30 Apr 2003 [Page 15]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

manufacture and stored message type; the
available message types are listed in some form of non-volatile storage.
section 5.3.

transaction-id The
generated DUID SHOULD be recorded transaction ID for this message exchange.

options Options carried in non-erasable storage. The
enterprise-number is the vendor's registered Private Enterprise
Number as maintained by IANA [10]. The enterprise-number is stored
as an unsigned 32 bit number.

An example DUID of this type might look like this:

+---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 0 | 0 | 9| 12|192|
+---+---+---+---+---+---+---+---+
|132|221| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+

This example includes the two-octet type of 2, the Enterprise
Number (9), followed by eight octets of identifier data
(0x0CC084D303000912).

9.4. DUID Based on Link-layer Address [DUID-LL]

This type of DUID consists of two octets containing the DUID type 3,
a two octet network hardware type code, followed by the link-layer
address of any one network interface message; options are
described in section 22.

7. Relay Agent/Server Message Formats

Relay agents exchange messages with servers to relay messages between
clients and servers that is permanently are not connected to the client or server device. For example, a host that has a network
interface implemented same link.

All values in a chip that is unlikely to be removed and
used elsewhere could use a DUID-LL. The hardware type MUST be a valid
hardware type assigned by the IANA as described message header and in RFC826 [18].
The hardware type is stored options are in network byte
order. The link-layer
address is

Options are stored serially in canonical form, as described the options field, with no padding
between the options. Options are byte-aligned but are not aligned in RFC2464 [4].
The following diagram illustrates
any other way such as on 2 or 4 byte boundaries.

Droms, et al. Standards Track [Page 17]

RFC 3315 DHCP for IPv6 July 2003

There are two relay agent messages, which share the format of a DUID-LL: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 msg-type | hardware type (16 bits) hop-count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| peer-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address options (variable number and 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 following sections describe the device on which use of the DUID-LL is being
generated. Relay Agent message
header.

7.1. Relay-forward Message

The same DUID-LL SHOULD be used in configuring all
network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate following table defines the DUID.

DUID-LL is recommended for devices use of message fields in a Relay-
forward message.

msg-type RELAY-FORW

hop-count Number of relay agents that have a permanently-connected
network interface with a link-layer relayed this
message.

link-address A global or site-local address and do not have

Droms (ed.), et al. Expires 30 Apr 2003 [Page 16]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

nonvolatile, writable stable storage. DUID-LL MUST NOT that will be used by
DHCP clients or servers that cannot tell whether or not a network
interface is permanently attached
the server to identify the device link on which the DHCP client
is running.

10. Identity Association

An "identity-association" (IA) is a construct through which a server
and a client can identify, group and manage a set of related IPv6
addresses. Each IA consists of an IAID and associated configuration
information.

A client must associate at least one distinct IA with each located.

peer-address The address of its
network interfaces for which it is to request the assignment of IPv6
addresses from a DHCP server. The client uses the IAs assigned to an
interface to obtain configuration information or relay agent from a server for that
interface. Each IA must be associated with exactly one interface.

The IAID uniquely identifies which
the IA and must be chosen message to be unique
among the IAIDs on relayed was received.

options MUST include a "Relay Message option" (see
section 22.10); MAY include other options added by
the client. relay agent.

Droms, et al. Standards Track [Page 18]

RFC 3315 DHCP for IPv6 July 2003

7.2. Relay-reply Message

The IAID is chosen by following table defines the client.
For any given use of an IA by message fields in a
Relay-reply message.

msg-type RELAY-REPL

hop-count Copied from the Relay-forward message

link-address Copied from the client, Relay-forward message

peer-address Copied from the IAID for that IA Relay-forward message

options MUST
be consistent across restarts include a "Relay Message option"; see
section 22.10; MAY include other options

8. Representation and Use of the DHCP client. The client Domain Names

So that domain names may
maintain consistency either by storing the IAID in non-volatile
storage be encoded uniformly, a domain name or by a
list of domain names is encoded using an algorithm that will consistently produce the
same IAID as long technique described in
section 3.1 of RFC 1035 [10]. A domain name, or list of domain
names, in DHCP MUST NOT be stored in compressed form, as the configuration described in
section 4.1.4 of the RFC 1035.

9. DHCP Unique Identifier (DUID)

Each DHCP client and server has not changed.
There may be no way for a client DUID. DHCP servers use DUIDs to maintain consistency of the IAIDs
if it does not have non-volatile storage and
identify clients for the client's hardware
configuration changes.

The selection of configuration information parameters and in an IA consists
the association of one or more IPv6
addresses along IAs with the times T1 and T2 for the IA. clients. DHCP clients use DUIDs to
identify a server in messages where a server needs to be identified.
See section 22.4 sections 22.2 and 22.3 for the representation of an IA a DUID in a DHCP
message.

Each address in an IA has a preferred lifetime

Clients and a valid lifetime, servers MUST treat DUIDs as defined opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT in RFC2462 [21]. The lifetimes are transmitted from the
DHCP server any
other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the client types defined in this document, as additional DUID types
may be defined in the IA option. future.

The lifetimes apply to
the use of IPv6 addresses as described DUID is carried in section 5.5.4 of RFC2462.

11. Selecting Addresses for Assignment to an IA

A server selects addresses to option because it may be assigned to an IA according variable length
and because it is not required in all DHCP messages. The DUID is
designed to the
address assignment policies determined by the server administrator be unique across all DHCP clients and the servers, and stable
for any specific information the server determines about the client
from some combination of the following sources: or server - The link to which that is, the DUID used by a
client is attached. The or server determines
the link SHOULD NOT change over time if at all possible; for
example, a device's DUID should not change 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 result of a change in
the client

Droms (ed.), device's network hardware.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 17]

Internet Draft 19]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

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 agent July 2003

The motivation for having more than one type of DUID is attached

* If the server receives the message directly from that the client DUID
must be globally unique, and the source address in the IP datagram in which the
message was received must also be easy to generate. The sort
of 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 link-local address, then the
client generated DUID in such a device
is on the link identified by not possible, so the source address DUID scheme must accommodate such devices.

9.1. DUID Contents

A DUID consists of a two-octet type code represented in the
IP datagram (note network byte
order, followed by a variable number of octets that this situation make up the
actual identifier. A DUID can occur only if be no more than 128 octets long (not
including the
server has enabled type code). The following types are currently defined:

1 Link-layer address plus time
2 Vendor-assigned unique ID based on Enterprise Number
3 Link-layer address

Formats for the use variable field of unicast message delivery by the
client and the client has sent a message DUID for which unicast
delivery is allowed)

- The each of the above
types are shown below.

9.2. DUID supplied by Based on Link-layer Address Plus Time [DUID-LLT]

This type of DUID consists of a two octet type field containing the client

- Other information in options supplied
value 1, a 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 the client

- Other information in options supplied by DHCP device at the relay agent

Any address assigned by a server time that the
DUID is generated. The time value is based on an EUI-64
identifier MUST include an interface identifier with the "u"
(universal/local) and "g" (individual/group) bits of time that the interface
identifier set appropriately, as indicated DUID is
generated represented in section 2.5.1 of RFC
2373 [9].

A server seconds since midnight (UTC), January 1,
2000, modulo 2^32. The hardware type MUST NOT assign an address that is otherwise reserved for
some other purpose. For example, be a server MUST NOT assign reserved
anycast addresses, valid hardware type
assigned by the IANA as defined described in RFC2526, from any subnet.

12. Management of Temporary Addresses

A client may request the assignment of temporary addresses (see RFC 3041 [16] for 826 [14]. Both the definition of temporary addresses). DHCPv6
handling of address assignment is no different for temporary
addresses. DHCPv6 says nothing about details of temporary addresses
like lifetimes, how clients use temporary addresses, rules for
generating successive temporary addresses, etc.

Clients ask for temporary addresses time and servers assign them.
Temporary addresses
the hardware type are carried stored in network byte order. The link-layer
address is stored in canonical form, as described in RFC 2464 [2].

The following diagram illustrates the Identity Association for
Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA
option contains at most one temporary format of a DUID-LLT:

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 for each of the
prefixes on the link to which the client is attached.

The IAID number space for the IA_TA option IAID number space is
separate from the IA_NA option IAID number space.

Droms (ed.), (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 18]

Internet Draft 20]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002 July 2003

The server MAY update the DNS for choice of network interface can be completely arbitrary, as long
as that interface provides a temporary globally unique link-layer address as described for
the link type, and the same DUID-LLT SHOULD be used in
section 4 configuring
all network interfaces connected to the device, regardless of RFC3041.

13. Transmission which
interface's link-layer address was used to generate the DUID-LLT.

Clients and servers using this type of Messages by a Client

Unless otherwise specified DUID MUST store the DUID-LLT
in stable storage, and MUST continue to use this document or in a document that
describes how IPv6 DUID-LLT even if the
network interface used to generate the DUID-LLT is carried over a specific removed. Clients
and servers that do not have any stable storage MUST NOT use this
type of link DUID.

Clients and servers that use this DUID SHOULD attempt to configure
the time prior to generating the DUID, if that is possible, and MUST
use some sort of time source (for link
types example, a real-time clock) in
generating the DUID, even if that do time source could not support multicast), a client sends DHCP messages be configured
prior to generating the All_DHCP_Relay_Agents_and_Servers.

A DUID. The use of a time source makes it
unlikely that two identical DUID-LLTs will be generated if the
network interface is removed from the client and another client then
uses multicast the same network interface to reach all servers or an individual server.
An individual server is indicated by specifying that server's DUID in generate a Server Identifier option (see section 22.3) in the client's message
(all servers will receive this message but only DUID-LLT. A collision
between two DUID-LLTs is very unlikely even if the indicated server
will respond). All servers are indicated by clocks have not supplying this
option.

A client may send some messages directly
been configured prior to a server using unicast,
as described in section 22.12.

14. Reliability generating the DUID.

This method of Client Initiated Message Exchanges

DHCP clients are responsible DUID generation is recommended for reliable delivery 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 messages in the
client-initiated message exchanges described writable non-volatile storage.

Despite our best efforts, it is possible that this algorithm for
generating a DUID could result in sections 17 and 18.
If a client identifier collision. A
DHCP client fails to receive an expected response from that generates a server, DUID-LLT using this mechanism MUST
provide an administrative interface that replaces the client must retransmit its message. existing DUID
with a newly-generated DUID-LLT.

Droms, et al. Standards Track [Page 21]

RFC 3315 DHCP for IPv6 July 2003

9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]

This section describes the
retransmission strategy to be used form of DUID is assigned by clients in client-initiated
message exchanges.

Note that the procedure described in this section is slightly
modified when used with vendor to the Solicit message. The modified procedure
is described in section 17.1.2.

The client begins device. It
consists of the message exchange vendor's registered Private Enterprise Number as
maintained by IANA [6] followed by transmitting a message to unique identifier assigned by
the server. vendor. The message exchange terminates when either the client
successfully receives following diagram summarizes the appropriate response or responses from structure of a
server or servers, or when
DUID-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 | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The source of the message exchange identifier is considered to have
failed according left up 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

Droms (ed.), et al. Expires 30 Apr 2003 [Page 19]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

RAND Randomization factor

With vendor defining it,
but each message transmission or retransmission, the client sets RT
according to the rules given below. If RT expires before the message
exchange terminates, identifier part of each DUID-EN MUST be unique to the client recomputes RT device
that is using it, and retransmits MUST be assigned to the
message.

Each of device at the computations of a new RT include a randomization factor
(RAND), which time it
is a random number chosen with a uniform distribution
between -0.1 manufactured and +0.1. The randomization factor is included to
minimize synchronization stored in some form of messages transmitted by DHCP clients. non-volatile storage. The algorithm for choosing a random number does not need to
generated DUID SHOULD be
cryptographically sound. recorded in non-erasable storage. The algorithm SHOULD produce a different
sequence of random numbers from each invocation of the DHCP client.

RT for the first message transmission is based on IRT:

RT = IRT + RAND*IRT

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

RT = 2*RTprev + RAND*RTprev

MRT specifies vendor's registered Private Enterprise
Number as maintained by IANA [6]. The enterprise-number is stored as
an upper bound on unsigned 32 bit number.

An example DUID of this type might look like this:

+---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 0 | 0 | 9| 12|192|
+---+---+---+---+---+---+---+---+
|132|221| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+

This example includes the value two-octet type of RT (disregarding 2, the
randomization added Enterprise Number
(9), followed by the use of RAND). If MRT has a value eight octets of 0,
there is no upper limit identifier data
(0x0CC084D303000912).

9.4. DUID Based on the value Link-layer Address [DUID-LL]

This type of RT. Otherwise:

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

MRC specifies an upper bound on DUID consists of two octets containing the number of times a client may
retransmit DUID type 3,
a message. Unless MRC is zero, two octet network hardware type code, followed by the message exchange fails
once link-layer
address of any one network interface that is permanently connected to
the client or server device. For example, a host that has transmitted the message MRC times.

MRD specifies an upper bound on the length of time a client may
retransmit network
interface implemented in a message. Unless MRD chip that is zero, the message exchange fails
once MRD seconds have elapsed since the client first transmitted the
message.

If both MRC unlikely to be removed and MRD are non-zero, the message exchange fails whenever
either of

Droms, et al. Standards Track [Page 22]

RFC 3315 DHCP for IPv6 July 2003

used elsewhere could use a DUID-LL. The hardware type MUST be a
valid hardware type assigned by the conditions specified IANA, as described in RFC 826
[14]. The hardware type is stored in network byte order. The
link-layer address is stored in canonical form, as described in RFC
2464 [2]. The following diagram illustrates the previous two paragraphs are
met.

If both MRC and MRD are zero, the client continues to transmit the
message until it receives format of a DUID-LL:

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

Droms (ed.), et al. Expires 30 Apr 2003 [Page 20]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

15. Message Validation

Clients unique link-layer address and servers SHOULD discard any messages that contain options
that are not allowed is
permanently attached to appear in the received message. For example,
an IA option device on which the DUID-LL is not allowed to appear being
generated. The same DUID-LL SHOULD be used in an Information-request
message. Clients and server MAY choose configuring all
network interfaces connected to extract information from
such a message if the information is device, regardless of use which
interface's link-layer address was used to generate the recipient.

A server MUST discard any Solicit, Confirm, Rebind or
Information-request messages it receives with a unicast
destination address.

Message validation based on DHCP authentication DUID.

DUID-LL is discussed in
section 21.4.2.

If recommended for devices that have a server receives permanently-connected
network interface with a message that contains options it should link-layer address, and do not
contain (such as an Information-request message with an IA option),
is missing options have
nonvolatile, writable stable storage. DUID-LL MUST NOT be used by
DHCP clients or servers that it should contain, cannot tell whether or is otherwise not valid,
it MAY send a Reply (or Advertise as appropriate) with a Server
Identifier option, a Client Identifier option if one was included in network
interface is permanently attached to the message and a Status Code option with status UnSpecFail.

15.1. Use of Transaction IDs

The "transaction-id" field holds device on which the DHCP
client is running.

10. Identity Association

An "identity-association" (IA) is a construct through which a value used by clients and servers
to synchronize server responses to
and a client messages. can identify, group, and manage a set of related IPv6
addresses. Each IA consists of an IAID and associated configuration
information.

A client
SHOULD generate a random number that cannot easily be guessed or
predicted to use as the transaction ID for must associate at least one distinct IA with each new message it sends.
Note that if a client generates easily predictable transaction
identifiers, of its
network interfaces for which it may become more vulnerable is to certain kinds request the assignment of
attacks IPv6
addresses from off-path intruders. A a DHCP server. The client MUST leave uses 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 or that do include IAs assigned to an
interface to obtain configuration information from a Server Identifier
option.

15.3. Advertise Message

Clients MUST discard any received Advertise messages server for that meet
interface. 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 following conditions:

- client, the message does not include a Server Identifier option

- IAID for that IA MUST
be consistent across restarts of the message does not include a Client Identifier option

Droms (ed.), DHCP client. The client may
maintain consistency either by storing the IAID in non-volatile

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 21]

Internet Draft 23]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

- the contents of July 2003

storage or by using an algorithm that will consistently produce the Client Identifier option does not match
same IAID as long as the
client's DUID

- configuration of the "transaction-id" field value does client has not match the value the changed.
There may be no way for a 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 to maintain consistency of the following conditions:

- the message IAIDs
if it does not include a Server Identifier option

- have non-volatile storage and the contents client's hardware
configuration changes.

The configuration information in an IA consists of one or more IPv6
addresses along with the Server Identifier option do not match times T1 and T2 for the
server's DUID

- IA. See section
22.4 for the message does not include representation of an IA in a Client Identifier option

15.5. Confirm Message

Clients MUST discard any received Confirm messages.

Servers MUST discard any received Confirm messages that do not
include DHCP message.

Each address in an IA has a Client Identifier option or that do include preferred lifetime and a Server
Identifier valid lifetime,
as defined in RFC 2462 [17]. The lifetimes are transmitted from the
DHCP server to the client in the IA option.

15.6. Renew Message

Clients MUST discard any received Renew messages.

Servers MUST discard any received Renew message that meets any The lifetimes apply to
the use of IPv6 addresses, as described in section 5.5.4 of RFC 2462.

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 conditions: sources:

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

* If the server receives the message MUST include a Server Identifier option

- directly from the contents of client and
the Server Identifier option MUST match source address in the
server's identifier

- IP datagram in which the message MUST include a Client Identifier option

15.7. Rebind Message

Clients MUST discard any received Rebind messages.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 22]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

Servers MUST discard any was
received Rebind messages that do not include
a Client Identifier option or that do include is a Server Identifier
option.

15.8. Decline Messages

Clients MUST discard any received Decline messages.

Servers MUST discard any received Decline message that fails to meet
any of link-local address, then the following conditions:

- client is on the message MUST include a Server Identifier option

-
same link to which the contents of interface over which the Server Identifier option MUST match message was
received is attached.

* If the
server's identifier

- server receives the message MUST include from a Client Identifier option

15.9. Release Message

Clients MUST discard any received Release messages.

Servers MUST discard any received Release message that fails forwarding relay
agent, then the client is on the same link as the one to meet
any of which
the following conditions:

- interface, identified by the message MUST include a Server Identifier option

- link-address field in the contents of
message from the Server Identifier option MUST match relay agent, is attached.

* If the
server's identifier

- server receives the message MUST include a Client Identifier option

15.10. Reply Message

Clients MUST discard any received Reply message that fails to meet
any of directly from the following conditions:

- client and
the message MUST include a Server Identifier option

- source address in the "transaction-id" field IP datagram in which the message MUST match was
received is not a link-local address, then the value
used client is on the
link identified by the source address in the original message

- IP datagram (note
that this situation can occur only if the server has enabled
the use of unicast message delivery by the client included and the
client has sent a Client Identifier option message for which unicast delivery is
allowed).

- The DUID supplied by the client.

- Other information in options supplied by the original
message, client.

Droms, et al. Standards Track [Page 24]

RFC 3315 DHCP for IPv6 July 2003

- Other information in options supplied by the message relay agent.

Any address assigned by a server that is based on an EUI-64
identifier MUST include a Client Identifier option an interface identifier with the "u"
(universal/local) and "g" (individual/group) bits of the contents interface
identifier set appropriately, as indicated in section 2.5.1 of RFC
2373 [5].

A server MUST NOT assign an address that is otherwise reserved for
some other purpose. For example, a server MUST NOT assign reserved
anycast addresses, as defined in RFC 2526, from any subnet.

12. Management of Temporary Addresses

A client may request the Client Identifier option MUST match the
DUID assignment of temporary addresses (see RFC
3041 [12] for the client or, if the client did not include a Client
Identifier option definition of temporary addresses). DHCPv6
handling of address assignment is no different for temporary
addresses. DHCPv6 says nothing about details of temporary addresses
like lifetimes, how clients use temporary addresses, rules for
generating successive temporary addresses, etc.

Clients ask for temporary addresses and servers assign them.
Temporary addresses are carried in the original message, the Reply message MUST
NOT include a Client Identifier Identity Association for
Temporary Addresses (IA_TA) option

Servers and relay agents MUST discard any received Reply messages.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 23]

Internet Draft DHCP (see section 22.5). Each IA_TA
option contains at most one temporary address for IPv6 (-28) 2 Nov 2002

15.11. Reconfigure Message

Servers and relay agents MUST discard any received Reconfigure
messages.

Clients MUST discard any Reconfigure messages that fails any each of the
following conditions:

-
prefixes on the message MUST have been unicast link to which the client

- is attached.

The IAID number space for the message MUST include a Server Identifier IA_TA option

- IAID number space is
separate from the message MUST include a Client Identifier IA_NA option that contains
the client's DUID

- IAID number space.

The server MAY update the message MUST contain DNS for a Reconfigure Message option and the
msg-type must be temporary address, as described
in section 4 of RFC 3041.

13. Transmission of Messages by a valid value

- the message MUST NOT include any IA options if the msg-type Client

Unless otherwise specified in
the Reconfigure Message option this document, or in a document that
describes how IPv6 is INFORMATION-REQUEST

- the message MUST include carried over a specific type of link (for link
types that do not support multicast), a client sends DHCP authentication:

* messages to
the message MUST contain All_DHCP_Relay_Agents_and_Servers.

A client uses multicast to reach all servers or an authentication option

* the message MUST pass the authentication validation performed individual server.
An individual server is indicated by the client

15.12. Information-request Message

Clients MUST discard any received Information-request messages.

Servers MUST discard any received Information-request message specifying that
fails to meet any of the following conditions:

- The message includes server's DUID in
a Server Identifier option and the DUID (see section 22.3) in the option does not match the server's DUID

- The client's message includes an IA option

15.13. Relay-forward Message

Clients MUST discard any received Relay-forward messages.

15.14. Relay-reply Message

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

Droms (ed.), will receive this message but only the indicated server
will respond). All servers are indicated by not supplying this
option.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 24]

Internet Draft 25]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

16. July 2003

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

14. Reliability of Client Source Address Initiated Message Exchanges

DHCP clients are responsible for reliable delivery of messages in the
client-initiated message exchanges described in sections 17 and Interface Selection

When 18.
If a DHCP client fails to receive an expected response from a server,
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 when used with the Solicit message. The modified procedure
is described in section 17.1.2.

The client sends begins the message exchange by transmitting a DHCP message to
the
All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the server. The message through exchange terminates when either the interface for which configuration information client
successfully receives the appropriate response or responses from a
server or servers, or when the message exchange is
being requested. However, considered to have
failed according to the retransmission mechanism described below.

The client MAY send 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 through
another interface attached transmission or retransmission, the client sets RT
according to the same link if and only if rules given below. If RT expires before the message
exchange terminates, the client is certain recomputes RT and retransmits the two interfaces are attached to
message.

Each of the same link. 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 client MUST use randomization factor is included to
minimize synchronization of messages transmitted by DHCP clients.

Droms, et al. Standards Track [Page 26]

RFC 3315 DHCP for IPv6 July 2003

The algorithm for choosing a link-local address assigned random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different
sequence of random numbers from each invocation of the interface DHCP client.

RT for which the first message transmission is based on IRT:

RT = IRT + RAND*IRT

RT for each subsequent message transmission is requesting configuration information as the source
address in based on the header previous
value of RT:

RT = 2*RTprev + RAND*RTprev

MRT specifies an upper bound on the IP datagram.

When a client sends a DHCP message directly to a server using unicast
(after receiving the Server Unicast option from that server), value of RT (disregarding the
source address in
randomization added by the header use of RAND). If MRT has a value of 0,
there is no upper limit on the IP datagram MUST be value of RT. Otherwise:

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

MRC specifies an address
assigned to the interface for which upper bound on the number of times a client may
retransmit a message. Unless MRC is interested in
obtaining configuration and which is suitable for use by the server
in responding to zero, the client.

17. DHCP Server Solicitation

This section describes how a client locates servers that will assign
addresses to IAs belonging to message exchange fails
once the client.

The client is responsible for creating IAs and requesting that a
server assign IPv6 addresses to has transmitted the IA. The client first creates
an IA and assigns it an IAID. The client then transmits a Solicit message containing MRC times.

MRD specifies an IA option describing upper bound on the IA. Servers that can
assign addresses to length of time a client may
retransmit a message. Unless MRD is zero, the IA respond to message exchange fails
once MRD seconds have elapsed since the client with an Advertise first transmitted the
message. The client then initiates a configuration exchange as
described in section 18.

If both MRC and MRD are non-zero, the client will accept a Reply message with committed address
assignments and other resources exchange fails whenever
either of the conditions specified in response to the Solicit message, previous two paragraphs are
met.

If both MRC and MRD are zero, the client includes continues to transmit the
message until it receives a Rapid Commit option (see section 22.14) response.

15. Message Validation

Clients and servers SHOULD discard any messages that contain options
that are not allowed to appear in the
Solicit received message.

17.1. Client Behavior

A client uses the Solicit message For example,
an IA option is not allowed to discover DHCP appear in an Information-request
message. Clients and servers configured
to assign addresses or return other configuration parameters on the
link MAY choose to which extract information from
such a message if the client information is attached.

17.1.1. Creation of Solicit Messages

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

Droms (ed.), recipient.

A server MUST discard any Solicit, Confirm, Rebind or
Information-request messages it receives with a unicast destination
address.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 25]

Internet Draft 27]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

The client MUST include July 2003

Message validation based on DHCP authentication is discussed in
section 21.4.2.

If a server receives a message that contains options it should not
contain (such as an Information-request message with an IA option),
is missing options that it should contain, or is otherwise not valid,
it MAY send a Reply (or Advertise as appropriate) with a Server
Identifier option, a Client Identifier option to identify itself
to if one was included in
the server. message and a Status Code option with status UnSpecFail.

15.1. Use of Transaction IDs

The client includes IA options for any IAs "transaction-id" field holds a value used by clients and servers
to which
it wants the synchronize server responses to assign addresses. The client MAY include
addresses in the IAs as messages. A client SHOULD
generate a hint random number that cannot easily be guessed or predicted
to use as the server about addresses transaction ID for
which the client has a preference. The client MUST NOT include any
other options in the Solicit each new message except as specifically allowed
in the definition of individual options.

The it sends. Note
that if a client uses IA_NA options generates easily predictable transaction
identifiers, it may become more vulnerable to request the assignment certain kinds of
non-temporary addresses and uses IA_TA options to request
attacks from off-path intruders. A client MUST leave the
assignment transaction
ID unchanged in retransmissions of temporary addresses. Either IA_NA or IA_TA options, or a combination of both can be included in DHCP message.

15.2. Solicit Message

Clients MUST discard any received Solicit messages.

The client SHOULD

Servers MUST discard any Solicit messages that do not include an Option Request a
Client Identifier option (see section 22.7)
to indicate or that do include a Server Identifier
option.

15.3. Advertise Message

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

- the client is interested in receiving. The
client MAY additionally message does not include a Server Identifier option.

- the message does not include instances a Client Identifier option.

- the contents of those options that are
identified in the Option Request Client Identifier option with data values as hints
to does not match the server about parameter values
client's DUID.

- the client would like to have
returned.

The client includes a Reconfigure Accept option (see section 22.20)
if "transaction-id" field value does not match the client is willing to accept Reconfigure messages from value the
server.

17.1.2. Transmission of Solicit Messages

The first
client used in its Solicit message.

Servers and relay agents MUST discard any received Advertise
messages.

Droms, et al. Standards Track [Page 28]

RFC 3315 DHCP for IPv6 July 2003

15.4. Request Message

Clients MUST discard any received Request messages.

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

- the interface MUST be
delayed by message does not include a random amount of time between 0 and SOL_MAX_DELAY. In Server Identifier option.

- the case contents of a Solicit message transmitted when DHCP is initiated
by IPv6 Neighbor Discovery, the delay gives the amount of time to
wait after IPv6 Neighbor Discovery causes Server Identifier option do not match the client to invoke
server's DUID.

- the
stateful address autoconfiguration protocol (see section 5.5.3 message does not include a Client Identifier option.

15.5. Confirm Message

Clients MUST discard any received Confirm messages.

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

15.6. Renew Message

Clients MUST discard any received Renew messages.

Servers MUST discard any received Renew message that meets any of
RFC2462). This random delay desynchronizes clients which start at the same time (for example, after a power outage).

The client transmits
following conditions:

- the message according to section 14, using does not include a Server Identifier option.

- the
following parameters:

IRT SOL_TIMEOUT

MRT SOL_MAX_RT

MRC 0

MRD 0

If contents of the client has included a Rapid Commit Server Identifier option in its Solicit
message, does not match the client terminates
server's identifier.

- the waiting process as soon as a Reply message with does not include a Rapid Commit Client Identifier option.

15.7. Rebind Message

Clients MUST discard any received Rebind messages.

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

If the client is waiting for an Advertise message, the mechanism in
section 14 is modified as follows for use in the transmission of

Droms (ed.), or that do include a Server Identifier
option.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 26]

Internet Draft 29]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

Solicit July 2003

15.8. Decline Messages

Clients MUST discard any received Decline messages. The

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

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

- the
receipt contents of an Advertise before the first RT has elapsed. Rather, the
client collects Advertise messages until Server Identifier option does not match the first RT has elapsed.
Also,
server's identifier.

- the first RT MUST be selected to be strictly greater than IRT
by choosing RAND to be strictly greater than 0.

A client message does not include a Client Identifier option.

15.9. Release Message

Clients MUST collect Advertise messages for discard any received Release messages.

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

- the first RT seconds,
unless it receives an Advertise message with does not include a preference value Server Identifier option.

- the contents of 255. The preference value is carried in the Preference Server Identifier option
(section 22.8). Any Advertise that does not match the
server's identifier.

- the message does not include a Preference
option is considered to have Client Identifier option.

15.10. Reply Message

Clients MUST discard any received Reply message that meets any of the
following conditions:

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

- the "transaction-id" field in the message does not match the value of 0.
used in the original message.

If the client
receives an Advertise message that includes included a Preference Client Identifier option
with in the original
message, the Reply message MUST include a preference value Client Identifier option
and the contents of 255, the Client Identifier option MUST match the DUID
of the client; OR, if the client immediately begins did not include a
client-initiated message exchange (as described Client Identifier
option in section 18) by
sending the original message, the Reply message MUST NOT include a Request
Client Identifier option.

Servers and relay agents MUST discard any received Reply messages.

Droms, et al. Standards Track [Page 30]

RFC 3315 DHCP for IPv6 July 2003

15.11. Reconfigure Message

Servers and relay agents MUST discard any received Reconfigure
messages.

Clients MUST discard any Reconfigure messages that meets any of the
following conditions:

- the message was not unicast to the server from which client.

- the Advertise message was received. If does not include a Server Identifier option.

- the client receives an Advertise message
that does not include a Preference Client Identifier option with a preference value of
255, the client continues to wait until the first RT elapses. If the
first RT elapses and that
contains the client has received an Advertise message, client's DUID.

- the client SHOULD continue with a client-initiated message exchange
by sending a Request message.

If the client does not receive any Advertise messages before
the first RT has elapsed, it begins the retransmission mechanism
described in section 14. The client terminates the retransmission
process as soon as it receives any Advertise message, contain a Reconfigure Message option and the client
acts on
msg-type must be a valid value.

- the received Advertise message without waiting for includes any
additional Advertise messages.

A DHCP client SHOULD choose MRC IA options and MRD to be 0. If the DHCP client
is configured with either MRC or MRD set to a value other than
0, it MUST stop trying to configure msg-type in the interface if
Reconfigure Message option is INFORMATION-REQUEST.

- the message
exchange fails. After the does not include DHCP client stops trying to configure authentication:

* the interface, it SHOULD restart message does not contain an authentication option.

* the reconfiguration process after
some external event, such as user input, system restart, or when message does not pass the
client is attached to a new link.

17.1.3. Receipt authentication validation
performed by the client.

15.12. Information-request Message

Clients MUST discard any received Information-request messages.

Servers MUST discard any received Information-request message that
meets any of Advertise Messages the following conditions:

- The client MUST ignore any Advertise message that includes a Status
Code Server Identifier option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message to and the
user.

Upon receipt of one or more valid Advertise messages, DUID in
the client
selects one or more Advertise messages based upon option does not match the following
criteria. server's DUID.

- Those Advertise messages with the highest server preference value
are preferred over all other Advertise The message includes an IA option.

15.13. Relay-forward Message

Clients MUST discard any received Relay-forward messages.

Droms (ed.),

15.14. Relay-reply Message

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

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 27]

Internet Draft 31]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

- Within a group of Advertise messages with the same server
preference value, July 2003

16. Client Source Address and Interface Selection

When a client MAY select those servers whose
Advertise messages advertise information of interest sends a DHCP message to the
client. For example,
All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the client may choose a server that
returned an advertisement with message
through the interface for which configuration options of interest
to information is being
requested. However, the client.

- The client MAY choose a less-preferred server send the message through another
interface attached to the same link, if and only if that server has
a better set of advertised parameters, such as the available
addresses advertised in IAs.

Once a client has selected Advertise message(s), is
certain the two interfaces are attached to the same link. The client will
typically store information about each server, such
MUST use a link-local address assigned to the interface for which it
is requesting configuration information as server
preference value, addresses advertised, when the advertisement was
received, and so on.

If source address in the
header of the IP datagram.

When a client needs sends a DHCP message directly to select an alternate a server in using unicast
(after receiving the case Server Unicast option from that a
chosen server does not respond, server), the client chooses
source address in the next server
according header of the IP datagram MUST be an address
assigned to the criteria given above.

17.1.4. Receipt of Reply Message

If interface for which the client includes a Rapid Commit option is interested in
obtaining configuration and which is suitable for use by the Solicit message,
it will expect a Reply message that includes a Rapid Commit option server
in response. The responding to the client.

17. DHCP Server Solicitation

This section describes how a client discards any Reply messages it receives locates servers that do not include a Rapid Commit option. If will assign
addresses to IAs belonging to the client.

The client receives
a valid Reply message is responsible for creating IAs and requesting that includes a Rapid Commit option, it
processes
server assign IPv6 addresses to the message as described in section 18.1.8. If it does
not receive such a Reply message IA. The client first creates an
IA and does receive a valid Advertise
message, the assigns it an IAID. The client processes the Advertise then transmits a Solicit
message as described in
section 17.1.3.

17.2. Server Behavior

A server sends containing an Advertise message in response to valid Solicit
messages it receives to announce IA option describing the availability of IA. Servers that can
assign addresses to the server IA respond to the client.

17.2.1. Receipt of Solicit Messages client with an Advertise
message. The server determines the information about the client and its
location then initiates a configuration exchange as
described in section 11 and checks its administrative
policy about responding to the client. 18.

If the server is not
permitted to respond client will accept a Reply message with committed address
assignments and other resources in response to the client, Solicit message,
the server discards client includes a Rapid Commit option (see section 22.14) in the
Solicit message. For example, if

17.1. Client Behavior

A client uses the administrative policy for Solicit message to discover DHCP servers configured
to assign addresses or return other configuration parameters on the server
is that it may only respond
link to a which the client that is willing to accept
a Reconfigure message, if attached.

17.1.1. Creation of Solicit Messages

The client sets the "msg-type" field to SOLICIT. The client indicates with
generates a Reconfigure
Accept option transaction ID and inserts this value in the Solicit message that it will not accept a
Reconfigure message, the servers discards the Solicit message.

Droms (ed.),
"transaction-id" field.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 28]

Internet Draft 32]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

If the July 2003

The client has included MUST include a Rapid Commit Client Identifier option in to identify itself
to the Solicit
message and server. The client includes IA options for any IAs to which
it wants the server has been configured to respond with committed
address assignments and other resources, assign addresses. The client MAY include
addresses in the server responds IAs as a hint to the Solicit with server about addresses for
which the client has a Reply message preference. The client MUST NOT include any
other options in the Solicit message, except as described specifically allowed
in section 17.2.3.
Otherwise, the server ignores definition of individual options.

The client uses IA_NA options to request the Rapid Commit option assignment of non-
temporary addresses and processes uses IA_TA options to request the remainder assignment
of the message as if no Rapid Commit option were
present.

17.2.2. Creation and Transmission temporary addresses. Either IA_NA or IA_TA options, or a
combination of Advertise Messages both, can be included in DHCP messages.

The server sets the "msg-type" field client SHOULD include an Option Request option (see section 22.7)
to ADVERTISE and copies indicate the
contents options the client is interested in receiving. The
client MAY additionally include instances of those options that are
identified in the transaction-id field from Option Request option, with data values as hints to
the Solicit message
received from server about parameter values the client would like to the Advertise message. have
returned.

The server client includes its server identifier in a Server Identifier Reconfigure Accept option and
copies (see section 22.20)
if the Client Identifier client is willing to accept Reconfigure messages from the
server.

17.1.2. Transmission of Solicit message into the
Advertise message. Messages

The server MAY add a Preference option to carry first Solicit message from the preference value
for client on the Advertise message. The server implementation SHOULD allow interface MUST be
delayed by a random amount of time between 0 and SOL_MAX_DELAY. In
the setting case of a server preference value by the administrator.
The server preference value MUST default to zero unless otherwise
configured Solicit message transmitted when DHCP is initiated by
IPv6 Neighbor Discovery, the server administrator.

The server includes a Reconfigure Accept option if delay gives the server wants amount of time to require that wait
after IPv6 Neighbor Discovery causes the client accept Reconfigure messages.

The server includes options the server will return to invoke the client in
stateful address autoconfiguration protocol (see section 5.5.3 of RFC
2462). This random delay desynchronizes clients which start at the
same time (for example, after a subsequent Reply message. power outage).

The information in these options may
be used by the client in transmits the selection of a server if message according to section 14, using the client
receives more than one Advertise message.
following parameters:

IRT SOL_TIMEOUT

MRT SOL_MAX_RT

MRC 0

MRD 0

Droms, et al. Standards Track [Page 33]

RFC 3315 DHCP for IPv6 July 2003

If the client has included
an Option Request a Rapid Commit option in the its Solicit
message, the server includes
options in client terminates the Advertise waiting process as soon as a Reply
message containing configuration parameters with a Rapid Commit option is received.

If the client is waiting for all of an Advertise message, the options identified mechanism in
section 14 is modified as follows for use in the Option Request option
that transmission of
Solicit messages. The message exchange is not terminated by the server has been configured to return to
receipt of an Advertise before the client. The
server MAY return additional options to first RT has elapsed. Rather, the
client if it collects Advertise messages until the first RT has been
configured to do so. The server SHOULD limit elapsed.
Also, the options returned first RT MUST be selected to be strictly greater than IRT
by choosing RAND to be strictly greater than 0.

A client MUST collect Advertise messages for the first RT seconds,
unless it receives an Advertise message with a preference value of
255. The preference value is carried in the client so Preference option
(section 22.8). Any Advertise that the DHCP message header and options do does not cause
fragmentation. include a Preference
option is considered to have a preference value of 0. If the Solicit client
receives an Advertise message from that includes a Preference option with
a preference value of 255, the client included one or more IA
options, the server MUST include IA options immediately begins a client-
initiated message exchange (as described in the Advertise section 18) by sending a
Request message
containing any addresses that would be assigned to IAs contained in the Solicit message server from which the client. Advertise message was
received. If the client has included
addresses in the IAs in the Solicit message, the server uses those
addresses as hints about the addresses receives an Advertise message that does not
include a Preference option with a preference value of 255, the
client would like continues to
receive.

If wait until the server will not assign any addresses to any IAs in a
subsequent Request from first RT elapses. If the client, first RT
elapses and the server MUST send client has received an Advertise
message to message, the client that includes only a Status Code option
SHOULD continue with code NoAddrsAvail and a status client-initiated message for the user, exchange by sending a Server

Droms (ed.), et al. Expires 30 Apr 2003 [Page 29]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

Identifier option with
Request message.

If the server's DUID client does not receive any Advertise messages before the
first RT has elapsed, it begins the retransmission mechanism
described in section 14. The client terminates the retransmission
process as soon as it receives any Advertise message, and a Client Identifier
option with the client's DUID.

If client
acts on the Solicit message was received directly by the server, the
server unicasts the Advertise message directly without waiting for any
additional Advertise messages.

A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client using
the address in the source address field from
is configured with either MRC or MRD set to a value other than 0, it
MUST stop trying to configure the IP datagram in which interface if the Solicit message was received. The Advertise message MUST be
unicast on exchange
fails. After the link from which DHCP client stops trying to configure the Solicit message was received.

If
interface, it SHOULD restart the Solicit message was received in a Relay-forward message, reconfiguration process after some
external event, such as user input, system restart, or when the
server constructs
client is attached to a Relay-reply message with the new link.

Droms, et al. Standards Track [Page 34]

RFC 3315 DHCP for IPv6 July 2003

17.1.3. Receipt of Advertise Messages

The client MUST ignore any Advertise message
in the payload of that includes a "relay-message" option. If Status
Code option containing the Relay-forward
messages included an Interface-id option, value NoAddrsAvail, with the server copies exception
that option to the Relay-reply message. The server unicasts client MAY display the
Relay-reply associated status message directly to the relay agent using the address
in the source address field from
user.

Upon receipt of one or more valid Advertise messages, the IP datagram in which client
selects one or more Advertise messages based upon the
Relay-forward message was received.

17.2.3. Creation and Transmission of Reply Messages

The server MUST commit following
criteria.

- Those Advertise messages with the assignment of any addresses or highest server preference value
are preferred over all other
configuration information message before sending Advertise messages.

- Within a Reply message to group of Advertise messages with the same server
preference value, a client in response MAY select those servers whose
Advertise messages advertise information of interest to a Solicit message.

DISCUSSION:

When using the Solicit-Reply message exchange,
client. For example, the client may choose a server
commits the assignment that returned
an advertisement with configuration options of any addresses before sending interest to the
Reply message.
client.

- The client can assume it MAY choose a less-preferred server if that server has been assigned a
better set of advertised parameters, such as the available
addresses advertised in the Reply message and does not need to send IAs.

Once a Request message for those addresses.

Typically, servers that are configured to use client has selected Advertise message(s), the
Solicit-Reply message exchange client will be deployed so that only
one
typically store information about each server, such as server will respond
preference value, addresses advertised, when the advertisement was
received, and so on.

If the client needs to select an alternate server in the case that a Solicit message. If more than
one
chosen server responds, does not respond, the client will only use chooses the addresses
from one of next server
according to the servers and criteria given above.

17.1.4. Receipt of Reply Message

If the addresses from client includes a Rapid Commit option in the other
servers Solicit message,
it will be committed to the expect a Reply message that includes a Rapid Commit option in
response. The client but discards any Reply messages it receives that do
not used by the
client.

The server includes include a Rapid Commit option in option. If the client receives a valid
Reply message to
indicate that the Reply is in response to a Solicit message.

The server includes a Reconfigure Accept option if the server wants
to require that the client accept Reconfigure messages.

The server produces Rapid Commit option, it processes the Reply
message as though it had received
a Request message, as described in section 18.2.1. The server
transmits the 18.1.8. If it does not receive such
a Reply message and does receive a valid Advertise message, the
client processes the Advertise message as described in section 18.2.8.

Droms (ed.),
17.1.3.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 30]

Internet Draft 35]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

18. DHCP Client-Initiated Configuration Exchange

A July 2003

If the client initiates subsequently receives a valid Reply message exchange with that
includes a server or servers
to acquire or update configuration information of interest. The
client may initiate Rapid Commit option, it either:

processes the configuration exchange Reply message as part of the
operating system configuration process, when requested described in section 18.1.8, and
discards any Reply messages received in response to do
so by the application layer, when required by Stateless Address
Autoconfiguration Request
message, or as required

processes any Reply messages received in response to extend the lifetime of an address
(Renew Request
message and Rebind messages).

18.1. Client discards the Reply message that includes the Rapid
Commit option.

17.2. Server Behavior

A server sends an Advertise message in response to valid 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 uses Request, Renew, Rebind, Release and Decline messages
during its
location as described in section 11 and checks its administrative
policy about responding to the normal life cycle of addresses. It uses Confirm client. If the server is not
permitted to
validate addresses when respond to the client, the server discards the Solicit
message. For example, if the administrative policy for the server is
that it may have moved only respond to a new link. It uses
Information-Request messages when client that is willing to accept a
Reconfigure message, if the client indicates with a Reconfigure
Accept option in the Solicit message that it needs configuration information
but no addresses. will not accept a
Reconfigure message, the servers discard the Solicit message.

If the client has included a source address of sufficient scope that can be
used by Rapid Commit option in the Solicit
message and the server as a return has been configured to respond with committed
address assignments and other resources, the client has received server responds to the
Solicit with a Server Unicast option (section 22.12) from Reply message as described in section 17.2.3.
Otherwise, the server, server ignores the client
SHOULD unicast any Request, Renew, Release Rapid Commit option and Decline messages to processes
the server.

DISCUSSION:

Use of unicast may avoid delays due to relaying remainder of messages
by relay agents as well the message as avoid overhead if no Rapid Commit option were
present.

17.2.2. Creation and duplicate
responses by servers due Transmission of Advertise Messages

The server sets the "msg-type" field to delivery ADVERTISE and copies the
contents of the transaction-id field from the Solicit message
received from the client messages to
multiple servers. Requiring the client to relay all Advertise message. The server
includes its server identifier in a Server Identifier option and
copies the Client Identifier from the Solicit message into the
Advertise message.

Droms, et al. Standards Track [Page 36]

RFC 3315 DHCP
messages through for IPv6 July 2003

The server MAY add a relay agent enables Preference option to carry the inclusion preference value
for the Advertise message. The server implementation SHOULD allow
the setting of
relay agent options in all messages sent a server preference value by the client. administrator. The
server should enable preference value MUST default to zero unless otherwise
configured by the use of unicast only when relay
agent options will not be used.

18.1.1. Creation and Transmission of Request Messages server administrator.

The client uses server includes a Request message Reconfigure Accept option if the server wants
to populate IAs with addresses and
obtain other configuration information. The require that the client accept Reconfigure messages.

The server includes one or
more IA options in the Request message. The server then returns
addresses and other information about the IAs will return to the client in IA
options in a
subsequent Reply message. The client generates a transaction ID and inserts this value information in these options may be
used by the
"transaction-id" field.

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

The client MUST include a Client Identifier option to identify itself
to server if the server. The client adds any other appropriate options,

Droms (ed.), et al. Expires 30 Apr 2003 [Page 31]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

including one or
receives more IA options (if than one Advertise message. If the client is requesting that has included
an Option Request option in the Solicit message, the server includes
options in the Advertise message containing configuration parameters
for all of the options identified in the server assign it some network addresses).

The client MUST include an Option Request option (see section 22.7)
to indicate that
the options server has been configured to return to the client is interested in receiving. client. The
client server
MAY include return additional options with data values as hints to the server
about parameter values the client would like if it has been configured
to have returned. do so. The client includes a Reconfigure Accept option (see section
indicating whether or not the client is willing to accept Reconfigure
messages from server must be aware of the server.

The client transmits recommendations on packet
sizes and the message according to use of fragmentation in section 14, using the
following parameters:

IRT REQ_TIMEOUT

MRT REQ_MAX_RT

MRC REQ_MAX_RC

MRD 0 5 of RFC 2460.

If the Solicit message exchange fails, from the client takes an action based on
the client's local policy. Examples of actions included one or more IA
options, the client might take
include:

- Select another server from a list of servers known to MUST include IA options in the client;
for example, servers that responded with an Advertise message

- Initiate the server discovery process described in section 17

- Terminate the configuration process and report failure

18.1.2. Creation and Transmission of Confirm Messages

Whenever a client may have moved to a new link, the prefixes from the
containing any addresses assigned to the interfaces on that link may no longer would be
appropriate to the link assigned to which IAs contained in
the client is attached. Examples of
times when a client may have moved to a new link include:

o The client reboots

o The client is physically disconnected Solicit message from a wired connection

o The the client. If the client returns from sleep mode

o The has included
addresses in the IAs in the Solicit message, the server uses those
addresses as hints about the addresses the client using a wireless technology changes access points

In would like to
receive.

If the server will not assign any situation when a client may have moved addresses to any IAs in a new link,
subsequent Request from the
client client, the server MUST initiate a Confirm/Reply send an Advertise
message exchange. The client
includes any IAs assigned to the interface client that may have moved to includes only a

Droms (ed.), et al. Expires 30 Apr 2003 [Page 32]

Internet Draft DHCP Status Code option with
code NoAddrsAvail and a status message for IPv6 (-28) 2 Nov 2002

new link, along the user, a Server
Identifier option with the addresses associated server's DUID, and a Client Identifier
option with those IAs, in its
Confirm message. Any responding servers will indicate whether those
addresses are appropriate to the link to which client's DUID.

If the client is attached
with Solicit message was received directly by the status in server, the Reply
server unicasts the Advertise message it returns directly to the client.

The client sets using
the "msg-type" address in the source address field to CONFIRM. The client generates
a transaction ID and inserts this value from the IP datagram in which
the "transaction-id"
field. Solicit message was received. The client Advertise message MUST include be
unicast on the link from which the Solicit message was received.

If the Solicit message was received in a Client Identifier Relay-forward message, the
server constructs a Relay-reply message with the Advertise message in
the payload of a "relay-message" option. If the Relay-forward
messages included an Interface-id option, the server copies that
option to identify
itself to the server. Relay-reply message. The client includes IA options for all of server unicasts the IAs assigned
Relay-reply message directly to the interface relay agent using the address in

Droms, et al. Standards Track [Page 37]

RFC 3315 DHCP for IPv6 July 2003

the source address field from the IP datagram in which the Confirm Relay-
forward message is
being sent. The IA options include all was received.

17.2.3. Creation and Transmission of the addresses the client
currently has associated with those IAs. Reply Messages

The client SHOULD set server MUST commit the
T1 and T2 fields in assignment of any IA_NA options and the preferred-lifetime and
valid-lifetime fields addresses or other
configuration information message before sending a Reply message to a
client in the IA Address options response to 0, as a Solicit message.

DISCUSSION:

When using the server
will ignore these fields.

The first Confirm Solicit-Reply message from exchange, the client on server commits
the interface MUST be
delayed by a random amount assignment of time between 0 and CNF_MAX_DELAY. any addresses before sending the Reply message.
The client transmits can assume it has been assigned the addresses in the
Reply message according and does not need to section 14, using the
following parameters:

IRT CNF_TIMEOUT

MRT CNF_MAX_RT

MRC 0

MRD CNF_MAX_RD

If the client receives no responses before the send a Request message transmission
process as described in section 14 terminates, the client SHOULD
continue for
those addresses.

Typically, servers that are configured to use any IP addresses, using the last known lifetimes for
those addresses, and SHOULD continue Solicit-Reply
message exchange will be deployed so that only one server will
respond to a Solicit message. If more than one server responds,
the client will only use any other previously
obtained configuration parameters.

18.1.3. Creation and Transmission the addresses from one of Renew Messages

To extend the valid and preferred lifetimes for servers,
while the addresses
associated with an IA, from the other servers will be committed to
the client sends but not used by the client.

The server includes a Renew Rapid Commit option in the Reply message to
indicate that the Reply is in response to a Solicit message.

The server includes a Reconfigure Accept option if the server
from which wants
to require that the client obtained accept Reconfigure messages.

The server produces the addresses Reply message as though it had received a
Request message, as described in section 18.2.1. The server
transmits the IA containing
an IA option for the IA. Reply message as described in 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 includes IA Address options in
may initiate the IA option for configuration exchange as part of the addresses associated with operating
system configuration process, when requested to do so by the IA. The server
determines new lifetimes
application layer, when required by Stateless Address
Autoconfiguration or as required to extend the lifetime of an address
(Renew and Rebind messages).

Droms, et al. Standards Track [Page 38]

RFC 3315 DHCP for IPv6 July 2003

18.1. Client Behavior

A client uses Request, Renew, Rebind, Release and Decline messages
during the normal life cycle of addresses. It uses Confirm to
validate addresses in the IA according when it may have moved to the
administrative a new link. It uses
Information-Request messages when it needs configuration information
but no addresses.

If the client has a source address of sufficient scope that can be
used by the server. The server may also add
new addresses to as a return address, and the IA. The server may remove addresses client has received a
Server Unicast option (section 22.12) from the IA
by setting server, the preferred client
SHOULD unicast any Request, Renew, Release and valid lifetimes of those addresses Decline messages to
zero.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 33]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

The server controls the time at which
the client contacts the server server.

DISCUSSION:

Use of unicast may avoid delays due to extend the lifetimes on assigned addresses through the T1 relaying of messages by
relay agents, as well as avoid overhead and T2
parameters assigned duplicate responses by
servers due to an IA.

At time T1 for an IA, the delivery of client initiates a Renew/Reply message
exchange messages to extend the lifetimes on any addresses in multiple
servers. Requiring the IA. The client includes an IA option with all addresses currently assigned to relay all DHCP messages through
a relay agent enables the IA inclusion of relay agent options in its Renew message.

If T1 or T2 is set to 0 all
messages sent by the client. The server (for an IA_NA) or there are no
T1 or T2 times (for an IA_TA), should enable the use of
unicast only when relay agent options will not be used.

18.1.1. Creation and Transmission of Request Messages

The client may send uses a Renew or Rebind
message, respectively, at the client's discretion. Request message to populate IAs with addresses and
obtain other configuration information. The client sets includes one or
more IA options in the "msg-type" field Request message. The server then returns
addresses and other information about the IAs to RENEW. the client in IA
options in a Reply message.

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. The client MUST include the list
of addresses options (if the client currently has associated with the IAs in is requesting that
the
Renew message. server assign it some network addresses).

The client MUST include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.

Droms, et al. Standards Track [Page 39]

RFC 3315 DHCP for IPv6 July 2003

The client includes a Reconfigure Accept option (see section 22.20)
indicating whether or not the client is willing to accept Reconfigure
messages from the server.

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

IRT REN_TIMEOUT REQ_TIMEOUT

MRT REN_MAX_RT REQ_MAX_RT

MRC 0 REQ_MAX_RC

MRD Remaining time until T2

The 0

If the message exchange is terminated when time T2 is reached (see fails, the client takes an action based on
the client's local policy. Examples of actions the client might take
include:

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

- Initiate the server discovery process described in section 18.1.4), at 17.

- Terminate the configuration process and report failure.

18.1.2. Creation and Transmission of Confirm Messages

Whenever a client may have moved to a new link, the prefixes from the
addresses assigned to the interfaces on that link may no longer be
appropriate for the link to which time the client begins is attached. Examples
of times when a client may have moved to a new link include:

o The client reboots.

o The client is physically connected to a wired connection.

o The client returns from sleep mode.

o The client using a Rebind message
exchange.

18.1.4. Creation and Transmission of Rebind Messages

At time T2 for an IA (which will only be reached if the server wireless technology changes access points.

In any situation when a client may have moved to
which the Renew message was sent at time T1 has not responded), a new link, the
client initiates MUST initiate a Rebind/Reply Confirm/Reply message exchange with any available
server. exchange. The client
includes an IA option with all addresses
currently any IAs assigned to the IA interface that may have moved to a
new link, along with the addresses associated with those IAs, in its Rebind message.

Droms (ed.),

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 34]

Internet Draft 40]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002 July 2003

Confirm message. Any responding servers will indicate whether those
addresses are appropriate for the link to which the client is
attached with the status in the Reply message it returns to the
client.

The client sets the "msg-type" field to REBIND. 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 includes IA options. options for all of the IAs
assigned to the interface for which the Confirm message is being
sent. The client MUST IA options include the list all of the addresses the client
currently has associated with the IAs in the
Rebind message. those IAs. The client MUST include an Option Request option (see section 22.7)
to indicate SHOULD set the options
T1 and T2 fields in any IA_NA options, and the client is interested preferred-lifetime and
valid-lifetime fields in receiving. The
client MAY include the IA Address options with data values as hints to 0, as the server
about parameter values
will ignore these fields.

The first Confirm message from the client would like to have returned. on the interface MUST be
delayed by a random amount of time between 0 and CNF_MAX_DELAY. The
client transmits the message according to section 14, using the
following parameters:

IRT REB_TIMEOUT CNF_TIMEOUT

MRT REB_MAX_RT CNF_MAX_RT

MRC 0

MRD Remaining time until valid CNF_MAX_RD

If the client receives no responses before the message transmission
process terminates, as described in section 14, 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.

18.1.3. Creation and Transmission of all addresses have
expired

The message exchange is terminated when Renew Messages

To extend the valid and preferred lifetimes of all of for the addresses assigned
associated with an IA, the client sends a Renew message to the IA expire (see section 10), at server
from which
time the client has several alternative actions to choose from; obtained the addresses in the IA containing an
IA option for
example:

- the IA. The client may choose to use a Solicit message to locate a new
DHCP includes IA Address options in the
IA option for the addresses associated with the IA. The server and send a Request
determines new lifetimes for the expired addresses in the IA according to the new
administrative configuration of the server. The server

- may also add

Droms, et al. Standards Track [Page 41]

RFC 3315 DHCP for IPv6 July 2003

new addresses to the IA. The client server may have other remove addresses in other IAs, so from the IA
by setting the preferred and valid lifetimes of those addresses to
zero.

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

At time T1 for an IA, the expired IA and use client initiates a Renew/Reply message
exchange to extend the lifetimes on any addresses in the
other IAs

18.1.5. Creation and Transmission of Information-request Messages IA. The
client uses includes an Information-request message to obtain
configuration information without having IA option with all addresses currently assigned to it.
the IA in its Renew message.

If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no
T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind
message, respectively, at the client's discretion.

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

The client SHOULD 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. If the The client does not include a Client
Identifier option, the server will not be able to return adds any

Droms (ed.), et al. Expires 30 Apr 2003 [Page 35]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

client-specific options to the client, appropriate options, including
one or the server may choose
not to respond to the message at all. more IA options. The client MUST include a
Client Identifier option if the Information-Request message will be
authenticated. list of
addresses the client currently has associated with the IAs in the
Renew message.

The first Information-request message from the client on the
interface MUST be delayed by a random amount of time between 0 and
INF_MAX_DELAY. In the case of a Solicit message transmitted when DHCP
is initiated by IPv6 Neighbor Discovery, 22.7)
to indicate the delay gives options the amount
of time client is interested in receiving. The
client MAY include options with data values as hints to wait after IPv6 Neighbor Discovery causes the server
about parameter values the client would like to
invoke the stateful address autoconfiguration protocol (see section
5.5.3 of RFC2462). have returned.

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

IRT INF_TIMEOUT REN_TIMEOUT

MRT INF_MAX_RT REN_MAX_RT

MRC 0

MRD 0

18.1.6. Remaining time until T2

Droms, et al. Standards Track [Page 42]

RFC 3315 DHCP for IPv6 July 2003

The message exchange is terminated when time T2 is reached (see
section 18.1.4), at which time the client begins a Rebind message
exchange.

18.1.4. Creation and Transmission of Release Rebind Messages

To release one or more addresses, a

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 sends initiates a Release Rebind/Reply message exchange with any available
server. The client includes an IA option with all addresses
currently assigned to the server. IA in its Rebind message.

The client sets the "msg-type" field to RELEASE. REBIND. The client generates
a transaction ID and places inserts 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 adds any appropriate options, including
one or more IA options. The client MUST include the list of
addresses it is releasing the client currently has associated with the IAs in the "options" field.
Rebind message.

The addresses
to be released client MUST be included in include an Option Request option (see section 22.7)
to indicate the IAs. Any addresses for options the client is interested in receiving. The
client MAY include options with data values as hints to the
IAs server
about parameter values the client wishes to continue to use MUST NOT be in added would like to the
IAs. have returned.

The client MUST NOT use any of transmits the message according to section 14, using the
following parameters:

IRT REB_TIMEOUT

MRT REB_MAX_RT

MRC 0

MRD Remaining time until valid lifetimes of all addresses it have
expired

The message exchange is releasing as
the source address in terminated when the Release message or in any subsequently
transmitted message.

Because Release messages may be lost, valid lifetimes of all
the client should retransmit addresses assigned to the Release if no Reply is received. However, there are scenarios
where IA expire (see section 10), at which
time the client has several alternative actions to choose from; for
example:

- The client may not wish choose to wait use a Solicit message to locate a new
DHCP server and send a Request for the normal retransmission

Droms (ed.), expired IA to the new
server.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 36]

Internet Draft 43]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

timeout before giving up (e.g., on power down). Implementations
SHOULD retransmit one or more times, but MAY July 2003

- The client may have other addresses in other IAs, so the client
may choose to terminate discard the
retransmission procedure early. expired IA and use the addresses in the
other IAs.

18.1.5. Creation and Transmission of Information-request Messages

The client transmits the uses an Information-request message according to section 14, using the
following parameters:

IRT REL_TIMEOUT

MRT 0

MRC REL_MAX_MRC

MRD 0 obtain
configuration information without having addresses assigned to it.

The client MUST stop using all of sets the addresses being released as
soon as "msg-type" field to INFORMATION-REQUEST. The
client generates a transaction ID and inserts this value in the
"transaction-id" field.

The client begins SHOULD include a Client Identifier option to identify
itself to the Release message exchange process. server. If
addresses are released but the Reply from client does not include a DHCP server is lost, Client
Identifier option, the client server will retransmit not be able to return any client-
specific options to the Release message, and client, or the server may choose not to
respond with a Reply indicating a status of NoBinding. Therefore, to the client does not treat a Reply message with a status of NoBinding
in at all. The client MUST include a Release message exchange as Client
Identifier option if it indicates the Information-Request message will be
authenticated.

The client MUST include an error.

Note that if Option Request option (see section 22.7)
to indicate the options the client fails is interested in receiving. The
client MAY include options with data values as hints to release the addresses, each address
assigned server
about parameter values the client would like to have returned.

The first Information-request message from the IA will client on the
interface MUST be reclaimed delayed by a random amount of time between 0 and
INF_MAX_DELAY. The client transmits the server when message according to section
14, using the valid
lifetime of that address expires.

18.1.7. following parameters:

IRT INF_TIMEOUT

MRT INF_MAX_RT

MRC 0

MRD 0

18.1.6. Creation and Transmission of Decline Release Messages

If a client detects that

To release one or more addresses assigned to it by addresses, a
server are already in use by another node, the client sends a Decline Release message to
the server to inform it that the address is suspect. server.

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

Droms, et al. Standards Track [Page 44]

RFC 3315 DHCP for IPv6 July 2003

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 declining releasing in the "options" field. The addresses
to be declined released MUST be included in the IAs. Any addresses for the
IAs the client wishes to continue to use should not MUST NOT be in added to the
IAs.

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

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

Droms (ed.), et al. Expires 30 Apr 2003 [Page 37]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

IRT DEC_TIMEOUT

MRT 0

MRC DEC_MAX_RC

MRD 0

If addresses are declined but the Reply from a DHCP server is lost,
the client will retransmit the Decline message, and the server may
respond with a Reply indicating a status of NoBinding. Therefore,
the client does not treat a Reply message with a status of NoBinding
in a Decline message exchange as if it indicates an error.

18.1.8. Receipt of Reply Messages

Upon the receipt of a valid Reply message in response to a Solicit
(with a Rapid Commit option), 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] on each
of the addresses in any IAs it receives in the Reply 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 18.1.7.

If the Reply was received in response to a Solicit (with a Rapid
Commit option), Request, Renew or Rebind message, the client updates
the information it has recorded about IAs from

Because Release messages may be lost, the IA options
contained in client should retransmit
the Release if no Reply message:

- Record T1 and T2 times

- Add any new addresses in is received. However, there are scenarios
where the IA option client may not wish to wait for the IA as recorded by normal retransmission
timeout before giving up (e.g., on power down). Implementations
SHOULD retransmit one or more times, but MAY choose to terminate the
retransmission procedure early.

The client

- Update lifetimes for any addresses in transmits the IA option that message according to section 14, using the
following parameters:

IRT REL_TIMEOUT

MRT 0

MRC REL_MAX_RC

MRD 0

The client already has recorded in MUST stop using all of the IA

- Discard any addresses from the IA being released as
soon as recorded by the client that
have a valid lifetime of 0 in begins the IA Address option

Management of Release message exchange process. If
addresses are released but the specific configuration information Reply from a DHCP server is detailed in lost, the definition
client will retransmit the Release message, and the server may
respond with a Reply indicating a status of each option, in section 22.

If NoBinding. Therefore,
the client receives does not treat a Reply message with a Status Code containing
UnspecFail, the server is indicating that it was unable to process
the status of NoBinding
in a Release message due to exchange as if it indicates an unspecified failure condition. If error.

Note that if the client
retransmits fails to release the original message addresses, each address
assigned to the same IA will be reclaimed by the server to retry when the

Droms (ed.), valid
lifetime of that address expires.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 38]

Internet Draft 45]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

desired operation, the July 2003

18.1.7. Creation and Transmission of Decline Messages

If a client MUST limit the rate at which detects that one or more addresses assigned to it
retransmits by a
server are already in use by another node, the client sends a Decline
message and limit the duration of to the time during
which server to inform it retransmits that the message.

When address is suspect.

The client sets the "msg-type" field to DECLINE. The client receives a Reply message with
generates a Status Code option
with transaction ID and places this value UseMulticast, in the
"transaction-id" field.

The client records places the receipt identifier of the
message and sends subsequent messages to the server through that allocated the
interface on which
address(es) in a Server Identifier option.

The client MUST include a Client Identifier option to identify itself
to the message was received using multicast. server. The client resends includes options containing the original message using multicast.

When IAs for
the client receives a NotOnLink status from addresses it is declining in the server "options" field. The addresses
to be declined MUST be included in
response the IAs. Any addresses for the
IAs the client wishes to continue to use should not be in added to a Confirm message,
the IAs.

The client performs DHCP server
solicitation MUST NOT use any of the addresses it is declining as described the
source address in section 17 and client-initiated
configuration as described the Decline message or in any subsequently
transmitted message.

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

IRT DEC_TIMEOUT

MRT 0

MRC DEC_MAX_RC

MRD 0

If addresses are declined but the client receives any
Reply messages that do not indicate Reply from a NotOnLink status, DHCP server is lost,
the client
can use the addresses in will retransmit the IA Decline message, and ignore any messages that do
indicate the server may
respond with a NotOnLink status.

When Reply indicating a status of NoBinding. Therefore,
the client receives does not treat a Reply message with a NotOnLink status from of NoBinding
in a Decline message exchange as if it indicates an error.

18.1.8. Receipt of Reply Messages

Upon the server receipt of a valid Reply message in response to a Solicit
(with a Rapid Commit option), Request, Confirm, Renew, Rebind or
Information-request message, the client can either re-issue the Request
without specifying any addresses or restart extracts the configuration

Droms, et al. Standards Track [Page 46]

RFC 3315 DHCP server discovery
process (see section 17).

When for IPv6 July 2003

information contained in the Reply. The client receives a NoAddrsAvail MAY choose to report
any status code or message from the server status code option in
response to a Request, the Reply
message.

The client can either try another server
(perhaps restarting the DHCP server discovery process) or use the
Information-Request to obtain configuration parameters only.

When SHOULD perform duplicate address detection [17] on each of
the client addresses in any IAs it receives a NoBinding status in an IA from the server
in response to a Renew Reply message or a Rebind message, before
using that address for traffic. If any of the client sends
a Request addresses are found to reestablish an IA with
be in use on the server.

When link, the client receives sends a valid Reply Decline message in response to a
Release message, the client considers the Release event completed,
regardless of the Status Code option(s) returned by the server.

When
server as described in section 18.1.7.

If the client receives a valid Reply message was received in response to a
Decline Solicit (with a Rapid
Commit option), Request, Renew or Rebind message, the client considers the Decline event completed,
regardless of the Status Code option(s) returned by updates
the server.

18.2. Server Behavior

For this discussion, information it has recorded about IAs from the Server is assumed to have been configured IA options
contained in
an implementation specific manner with configuration of interest to
clients.

In most instances, the server will send a Reply message:

- Record T1 and T2 times.

- Add any new addresses in response to a
client message. This Reply message MUST always contain the Server
Identifier IA option containing to the server's DUID and IA as recorded by
the Client
Identifier client.

- Update lifetimes for any addresses in the IA option from that the
client message if one was present.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 39]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

In most Reply messages, the server includes options containing
configuration information for already has recorded in the client. The server SHOULD limit IA.

- Discard any addresses from the options returned to IA, as recorded by the client so client, that
have a valid lifetime of 0 in the DHCP message header
and options do not cause fragmentation. If IA Address option.

- Leave unchanged any information about addresses the client included an
Option Request option has
recorded in its message, the server includes options IA but that were not included in the Reply message containing configuration parameters for all IA from the
server.

Management of the options identified specific configuration information is detailed in
the Option Request definition of each option that in section 22.

If the client receives a Reply message with a Status Code containing
UnspecFail, the server
has been configured to return is indicating that it was unable to process
the client. The server MAY return
additional options message due to an unspecified failure condition. If the client if it has been configured to do so.

18.2.1. Receipt of Request Messages

When
retransmits the server receives a Request original message via unicast from a
client to which the same server has not sent a unicast option, to retry the server
discards
desired operation, the client MUST limit the rate at which it
retransmits the Request message and responds with limit the duration of the time during
which it retransmits the message.

When the client receives a Reply message
containing with a Status Code option
with the value UseMulticast, a Server
Identifier option containing the server's DUID, client records the Client Identifier
option from receipt of the client
message and no other options.

When the server receives a valid Request message, the server creates
the bindings for that client according sends subsequent messages to the server's policy and
configuration information and records the IAs and other information
requested by the client.

The server constructs a Reply message by setting the "msg-type" field
to REPLY, copying through the transaction ID from
interface on which the Request message into
the transaction-id field. was received using multicast. The server MUST include a Server Identifier option containing
client resends the
server's DUID and original message using multicast.

Droms, et al. Standards Track [Page 47]

RFC 3315 DHCP for IPv6 July 2003

When the Client Identifier option client receives a NotOnLink status from the Request
message server in
response to a Confirm message, the Reply message.

If the client performs DHCP server finds that the prefix on one or more IP addresses in
any IA
solicitation, as described in the message from section 17, and client-initiated
configuration as described in section 18. If the client is receives any
Reply messages that do not appropriate to the link
to which indicate a NotOnLink status, the client is connected,
can use the server MUST return addresses in the IA to and ignore any messages that indicate
a NotOnLink status.

When the client with receives a Status Code option with value NotOnLink.

If NotOnLink status from the server cannot assign any addresses to an IA in
response to a Request, the message
from client can either re-issue the client, Request
without specifying any addresses or restart the DHCP server MUST include discovery
process (see section 17).

The client examines the IA status code in each IA individually. If the Reply message
with
status code is NoAddrsAvail, the client has received no usable
addresses in the IA and a Status Code option in the IA
containing status code NoAddrsAvail.

For any IAs may choose to which the server can assign addresses, the server
includes try obtaining addresses for the
IA with from another server. The client uses addresses and other configuration parameters and
records the IA as a new client binding.

The server includes
information from any IAs that do not contain a Reconfigure Accept Status Code option if the server wants
to require that
with the client accept Reconfigure messages.

The server includes other options containing configuration
information to be returned to NoAddrsAvail code. If the client as described receives no addresses in
section 18.2.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 40]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

18.2.2. Receipt
any of Confirm Messages

When the IAs, it may either try another server receives a Confirm message, (perhaps restarting
the DHCP server determines if
the addresses in discovery process) or use the Confirm message are appropriate Information-request
message to obtain other configuration information only.

When the link client receives a Reply message in response to
which a Renew or
Rebind message, the client is attached. If all of the addresses examines each IA independently. For each
IA in the Confirm original Renew or Rebind message, the client:

- sends a Request message pass this test, if the server returns IA contained a status of Success. If
any of Status Code option
with the addresses do NoBinding status (and does not pass this test, the server returns send any additional
Renew/Rebind messages)

- sends a
status of NotOnLink. If Renew/Rebind if the server IA is unable to perform this test
(for example, the server does not have in the Reply message

- otherwise accepts the information about prefixes on in the link to which IA

When the client is connected) or there were no addresses receives a valid Reply message in any response to a
Release message, the client considers the Release event completed,
regardless of the IAs sent Status Code option(s) returned by the client, server.

When the server MUST NOT send client receives a
reply valid Reply message in response to a
Decline message, the client.

The server ignores client considers the T1 and T2 fields in Decline event completed,
regardless of the IA options and Status Code option(s) returned by the
preferred-lifetime and valid-lifetime fields server.

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.

Droms, et al. Standards Track [Page 48]

RFC 3315 DHCP for IPv6 July 2003

In most instances, the IA Address
options.

The server constructs will send a Reply message by setting the "msg-type" field in response to REPLY, copying the transaction ID from the Confirm a
client message. This Reply message into
the transaction-id field.

The server MUST include a always contain the Server
Identifier option containing the server's DUID and the Client
Identifier option from the Confirm client message in the if one was present.

In most Reply message. The messages, the server includes a Status Code options containing
configuration information for the client. The server must be aware
of the recommendations on packet sizes and the use of fragmentation
in section 5 of RFC 2460. If the client included an Option Request
option indicating in its message, the status server includes options in the Reply
message containing configuration parameters for all of the Confirm message.

18.2.3. options
identified in the Option Request option that the server has been
configured to return to the client. The server MAY return additional
options to the client if it has been configured to do so.

18.2.1. Receipt of Renew Request Messages

When the server receives a Renew Request message via unicast from a client
to which the server has not sent a unicast option, the server
discards the Renew Request message and responds with a Reply message
containing a Status Code option with the value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier
option from the client message message, and no other options.

When the server receives a Renew message that contains an IA option
from a client, it locates the client's binding and verifies that the
information in the IA from the client matches the information stored
for that client.

If the server cannot find a client entry for the IA the server
returns the IA containing no addresses with a Status Code option set
to NoBinding in the Reply message.

If the server finds that any of the addresses are not appropriate
to the link to which the client is attached, the server returns the
address to the client with lifetimes of 0.

If the server finds the addresses in the IA for the client then the
server sends back the IA to the client with new lifetimes and T1/T2
times. The valid Request message, the server may choose creates
the bindings for that client according to change the list of addresses server's policy and
configuration information and records the
lifetimes of addresses in IAs that are returned to and other information
requested by the client.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 41]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

The server constructs a Reply message by setting the "msg-type" field
to REPLY, and copying the transaction ID from the Renew Request 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 Request
message in the Reply message.

The server includes other options containing configuration
information to be returned to the client as described in
section 18.2.

18.2.4. Receipt of Rebind Messages

When

If the server receives a Rebind message that contains an IA option
from a client, it locates the client's binding and verifies finds that the
information prefix on one or more IP addresses in the
any IA in the message from the client matches the information stored is not appropriate for that client.

If the server cannot find a client entry for link
to which the IA client is connected, the server
returns MUST return the IA containing no addresses to
the client with a Status Code option set
to NoBinding in with the Reply message. value NotOnLink.

If the server finds that cannot assign any of the addresses are no longer
appropriate to an IA in the link to which message
from the client is attached, client, the server
returns MUST include the address to IA in the client Reply message
with lifetimes of 0.

If the server finds the no addresses in the IA for the client then the
server SHOULD send back the IA to the client with new lifetimes and
T1/T2 times.

The server constructs a Reply message by setting Status Code option in the "msg-type" field IA
containing status code NoAddrsAvail.

Droms, et al. Standards Track [Page 49]

RFC 3315 DHCP for IPv6 July 2003

For any IAs to REPLY, copying the transaction ID from which the Rebind message into server can assign addresses, the
transaction-id field.

The server MUST include a Server Identifier option containing
includes the
server's DUID IA with addresses and other configuration parameters,
and records the Client Identifier IA as a new client binding.

The server includes a Reconfigure Accept option from if the Rebind
message in server wants
to require that the Reply message. client accept Reconfigure messages.

The server includes other options containing configuration
information to be returned to the client as described in section
18.2.

18.2.5.

If the server finds that the client has included an IA in the Request
message for which the server already has a binding that associates
the IA with the client, the client has resent a Request message for
which it did not receive a Reply message. The server either resends
a previously cached Reply message or sends a new Reply message.

18.2.2. Receipt of Information-request Confirm Messages

When the server receives an Information-request a Confirm message, the server determines
whether the addresses in the Confirm message are appropriate for the
link to which the client is requesting configuration information that does not
include attached. If all of the assignment addresses in the
Confirm message pass this test, the server returns a status of
Success. If any addresses. The of the addresses do not pass this test, the server determines all
configuration parameters appropriate
returns a status of NotOnLink. If the server is unable to perform
this test (for example, the server does not have information about
prefixes on the link to which the client is connected), or there were
no addresses in any of the IAs sent by the client, based on the server configuration policies known MUST
NOT send a reply to the server.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 42]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002 client.

The server ignores the T1 and T2 fields in the IA options and the
preferred-lifetime and valid-lifetime fields in the IA Address
options.

The server constructs a Reply message by setting the "msg-type" field
to REPLY, and copying the transaction ID from the Information-request Confirm message
into the transaction-id field.

The server MUST include a Server Identifier option containing the
server's DUID in the Reply message. If and the client included a Client
Identification Identifier option in the Information-request message, from the server
copies that option to Confirm
message in the Reply message. The server includes options containing configuration information to
be returned to the client as described in section 18.2.

If the Information-request message received from the client did
not include a Client Identifier option, the server SHOULD respond
with a Reply message containing any configuration parameters
that are not determined by the client's identity. If the server
chooses not to respond, the client may continue to retransmit the
Information-request message indefinitely.

18.2.6. Receipt of Release Messages

When the server receives a Release message via unicast from a
client to which the server has not sent a unicast option, the server
discards the Release message and responds with a Reply message
containing a Status Code
option with value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier
option from the client message and no other options.

Upon indicating the receipt status of a valid Release message, the server examines
the IAs and the addresses in the IAs for validity. If the IAs in
the message are in a binding for the client and the addresses in
the IAs have been assigned by the server to those IAs, the server
deletes the addresses from the IAs and makes the addresses available Confirm message.

Droms, et al. Standards Track [Page 50]

RFC 3315 DHCP for assignment to other clients. The server ignores addresses not
assigned to IPv6 July 2003

18.2.3. Receipt of Renew Messages

When the IA, although it may choose server receives a Renew message via unicast from a client to log an error.

After all
which the addresses have been processed, server has not sent a unicast option, the server generates discards
the Renew message and responds with a Reply message and includes containing a
Status Code option with the value Success, UseMulticast, a Server Identifier
option with containing the server's DUID and a DUID, the Client Identifier option with
from the client's DUID. For each client message, and no other options.

When the server receives a Renew message that contains an IA option
from a client, it locates the client's binding and verifies that the
information in the Release
message IA from the client matches the information stored
for which that client.

If the server has no binding information, cannot find a client entry for the server
adds an IA option using the IAID from server
returns the Release message and
includes IA containing no addresses with a Status Code option with the value set
to NoBinding in the IA
option. No other options are included in Reply message.

If the IA option.

A server may choose to retain a record finds that any of assigned the addresses and IAs
after are not appropriate for
the link to which the client is attached, the server returns the
address to the client with lifetimes on of 0.

If the server finds the addresses have expired in the IA for the client then the
server sends back the IA to allow the client with new lifetimes and T1/T2
times. The server may choose to reassign change the previously assigned list of addresses to a client.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 43]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

18.2.7. Receipt and the
lifetimes of Decline Messages

When addresses in IAs that are returned to the client.

The server receives constructs a Decline Reply message via unicast from a
client to which by setting the server has not sent a unicast option, "msg-type" field
to REPLY, and copying the server
discards transaction ID from the Decline message and responds with a Reply Renew message
containing a Status Code option with value UseMulticast, into
the transaction-id field.

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

The server includes other options.

Upon options containing configuration
information to be returned to the receipt client as described in section
18.2.

18.2.4. Receipt of a valid Decline message, Rebind Messages

When the server examines receives a Rebind message that contains an IA option
from a client, it locates the
IAs client's binding and verifies that the addresses
information in the IAs IA from the client matches the information stored
for validity. that client.

Droms, et al. Standards Track [Page 51]

RFC 3315 DHCP for IPv6 July 2003

If the IAs in the
message are in server cannot find a binding client entry for the client IA and the server
determines that the addresses in the IAs
have been assigned by IA are not appropriate for the server
link to those IA, which the server deletes client's interface is attached according to the
addresses from
server's explicit configuration information, the IAs. The server ignores addresses not assigned MAY send a
Reply message to the client containing the client's IA, with the
lifetimes for the addresses in the IA (though it may choose set to log zero. This Reply
constitutes an error explicit notification to the client that the addresses
in the IA are no longer valid. In this situation, if the server does
not send a Reply message it silently discards the Rebind message.

If the server finds such an
address).

The client has found that any of the addresses in are no longer
appropriate for the Decline messages link to be
already in use on its link. Therefore, which the client is attached, the server SHOULD mark
returns the
addresses declined by address to the client so that those addresses are not
assigned to other clients, and MAY choose to make a notification that
addresses were declined. Local policy on with lifetimes of 0.

If the server determines when finds the addresses identified in a Decline message may be made available the IA for assignment.

After all the address have been processed, client then the
server generates SHOULD send back the IA to the client with new lifetimes and
T1/T2 times.

The server constructs a Reply message by setting the "msg-type" field
to REPLY, and includes a Status Code option with value Success, copying the transaction ID from the Rebind message into
the transaction-id field.

The server MUST include a Server Identifier option with containing the
server's DUID and a the Client Identifier option with the client's DUID. For each IA in from the Decline Rebind
message for which in the Reply message.

The server has no binding information, includes other options containing configuration
information to be returned to the client as described in section
18.2.

18.2.5. Receipt of Information-request Messages

When the server
adds receives an IA option using Information-request message, the IAID from client
is requesting configuration information that does not include the Release
assignment of any addresses. The server determines all configuration
parameters appropriate to the client, based on the server
configuration policies known to the server.

The server constructs a Reply message by setting the "msg-type" field
to REPLY, and
includes copying the transaction ID from the Information-request
message into the transaction-id field.

The server MUST include a Status Code Server Identifier option with the value NoBinding in containing the IA
option. No other options are included
server's DUID in the IA option.

18.2.8. Transmission of Reply Messages message. If the original message was received directly by client included a Client
Identification option in the server, Information-request message, the server unicasts
copies that option to the Reply message directly message.

Droms, et al. Standards Track [Page 52]

RFC 3315 DHCP for IPv6 July 2003

The server includes options containing configuration information to
be returned to the client using the
address as described in section 18.2.

If the source address field Information-request message received from the IP datagram in which client did not
include a Client Identifier option, the
original message was received. The server SHOULD respond with a
Reply message MUST be unicast
through containing any configuration parameters that are not
determined by the interface on which client's identity. If the original server chooses not to
respond, the client may continue to retransmit the
Information-request message was received.

If indefinitely.

18.2.6. Receipt of Release Messages

When the original server receives a Release message was received in via unicast from a Relay-forward message, client
to which the server constructs has not sent a Relay-reply unicast option, the server
discards the Release message and responds with the a Reply message
in the payload of
containing a Relay Message Status Code option (see section 22.10). If with value UseMulticast, a Server
Identifier option containing the Relay-forward messages included an Interface-id option, server's DUID, the
server copies that Client Identifier
option to from the Relay-reply message. The server
unicasts client message, and no other options.

Upon the Relay-reply message directly to receipt of a valid Release message, the relay agent using server examines the
IAs and the address addresses in the source address field from IAs for validity. If the IP datagram IAs in which the Relay-forward
message was received.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 44]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

19. DHCP Server-Initiated Configuration Exchange

A server initiates are in a configuration exchange to cause DHCP clients
to obtain new addresses binding for the client, and other configuration information. For
example, an administrator may use a server-initiated configuration
exchange when links in the DHCP domain are to be renumbered. Other
examples include changes addresses in the location of directory servers,
addition of new services such as printing, and availability of new
software.

19.1. Server Behavior

A IAs
have been assigned by the server sends a Reconfigure message to cause a client to initiate
immediately a Renew/Reply or Information-request/Reply message
exchange with those IAs, the server.

19.1.1. Creation and Transmission of Reconfigure Messages

The server sets deletes the "msg-type" field
addresses from the IAs and makes the addresses available for
assignment to RECONFIGURE. other clients. The server
sets ignores addresses not
assigned to the transaction-id field IA, although it may choose to 0. The log an error.

After all the addresses have been processed, the server generates a
Reply message and includes a Status Code option with value Success, a
Server Identifier option containing its DUID with the server's DUID, and a Client
Identifier option
containing with the client's DUID DUID. For each IA in the Reconfigure message.

The Release
message for which the server MAY include has no binding information, the server
adds an Option Request IA option to inform using the client
of what information has been changed or new information that has
been added. In particular, IAID from the Release message, and
includes a Status Code option with the server specifies value NoBinding in the IA option
option. No other options are included in the Option Request option if the IA option.

A server wants the client may choose to obtain
new address information. If the server identifies retain a record of assigned addresses and IAs
after the IA option
in lifetimes on the Option Request option, addresses have expired to allow the server MUST include an IA option
that contains no other sub-options to identify each IA that is
to be
reconfigured on reassign the previously assigned addresses to a client.

Because of the risk of denial

18.2.7. Receipt of service attacks against DHCP
clients, Decline Messages

When the use of a security mechanism is mandated in Reconfigure
messages. The server MUST use DHCP authentication in receives a Decline message via unicast from a client
to which the Reconfigure
message.

The server MUST include has not sent a Reconfigure Message option (defined in
section 22.19) to select whether unicast option, the client server
discards the Decline message and responds with a Renew Reply message or an Information-Request message.

The server MUST NOT include any other options in
containing a Status Code option with the Reconfigure
except as specifically allowed in value UseMulticast, a Server
Identifier option containing the definition of individual server's DUID, the Client Identifier
option from the client message, and no other options.

A server sends each Reconfigure message to a single

Droms, et al. Standards Track [Page 53]

RFC 3315 DHCP client,
using an for IPv6 unicast address July 2003

Upon the receipt of sufficient scope belonging to a valid Decline message, the server examines the
IAs and the addresses in the IAs for validity. If the IAs in the
message are in a binding for the
DHCP client. If client, and the server does not addresses in the IAs
have an address to which it can
send been assigned by the Reconfigure message directly server to those IAs, the client, server deletes the
addresses from the IAs. The server uses
a Relay-reply message (as described in section 20.3) ignores addresses not assigned to send
the
Reconfigure message IA (though it may choose to a relay agent that will relay log an error if it finds such an
address).

The client has found any addresses in the message Decline messages to

Droms (ed.), et al. Expires 30 Apr 2003 [Page 45]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002 be
already in use on its link. Therefore, the client. The server may obtain SHOULD mark the address of
addresses declined by the client (and
the appropriate relay agent, if required) through the information so that those addresses are not
assigned to other clients, and MAY choose to make a notification that
addresses were declined. Local policy on the server has about clients that have been determines when
the addresses identified in contact with a Decline message may be made available
for assignment.

After all the
server, or through some external agent.

To reconfigure more than one client, addresses have been processed, the server unicasts generates a separate
Reply message to each client. The server may initiate and includes a Status Code option with the reconfiguration
of multiple clients concurrently; for example, value
Success, a server may
send Server Identifier option with the server's DUID, and a Reconfigure message to additional clients while previous
reconfiguration message exchanges are still in progress.

The Reconfigure message causes
Client Identifier option with the client's DUID. For each IA in the client to initiate a Renew/Reply
or Information-request/Reply
Decline message exchange with for which the server. The server interprets has no binding information, the receipt of a Renew or Information-request
message (whichever was specified in
server adds an IA option using the original Reconfigure message) IAID from the client as satisfying the Reconfigure Release message request.

19.1.2. Time Out and Retransmission
includes a Status Code option with the value NoBinding in the IA
option. No other options are included in the IA option.

18.2.8. Transmission of Reconfigure Reply Messages

If the original message was received directly by the server, the
server does not receive a Renew or Information-request unicasts the Reply message from directly to the client using the
address in REC_TIMEOUT milliseconds, the server
retransmits source address field from the Reconfigure message, doubles IP datagram in which the REC_TIMEOUT value
and waits again.
original message was received. The server continues this process until REC_MAX_RC
unsuccessful attempts have been made, at Reply message MUST be unicast
through the interface on which point the server
SHOULD abort original message was received.

If the reconfigure process for that client.

Default and initial values for REC_TIMEOUT and REC_MAX_RC are
documented original message was received in section 5.5.

19.2. Receipt of Renew Messages

The server generates and sends a Reply message to Relay-forward message, the client as
described in sections 18.2.3 and 18.2.8, including options for
configuration parameters.

The
server MAY include options containing the IAs and new values for
other configuration parameters in constructs a Relay-reply message with the Reply message, even if those
IAs and parameters were not requested message in the Renew message from
payload of a Relay Message option (see section 22.10). If the
Relay-forward messages included an Interface-id option, the
client.

19.3. Receipt of Information-request Messages server
copies that option to the Relay-reply message. The server generates and sends a Reply unicasts
the Relay-reply message directly to the client as
described relay agent using the address
in sections 18.2.5 and 18.2.8, including options for
configuration parameters.

The the source address field from the IP datagram in which the
Relay-forward message was received.

19. DHCP Server-Initiated Configuration Exchange

A server MAY include options containing initiates a configuration exchange to cause DHCP clients to
obtain new values for addresses and other configuration parameters in the Reply message, even if those
parameters were not requested information. For
example, an administrator may use a server-initiated configuration
exchange when links in the Information-request message from
the client.

Droms (ed.), DHCP domain are to be renumbered. Other

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 46]

Internet Draft 54]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

19.4. Client Behavior

A client receives Reconfigure messages sent to UDP port 546 on
interfaces for which it has acquired configuration information
through DHCP. These messages may be sent at any time. Since the
results of a reconfiguration event may affect application layer
programs, July 2003

examples include changes in the client SHOULD log these events, and MAY notify these
programs location of the change through an implementation-specific interface.

19.4.1. Receipt directory servers,
addition of Reconfigure Messages

Upon receipt new services such as printing, and availability of new
software.

19.1. Server Behavior

A server sends a valid Reconfigure message, the message to cause a client responds with
either to initiate
immediately a Renew message Renew/Reply or an Information-request Information-request/Reply message as indicated
by
exchange with the Reconfigure Message option (as defined in section 22.19). server.

19.1.1. Creation and Transmission of Reconfigure Messages

The
client ignores server sets the transaction-id "msg-type" field in to RECONFIGURE. The server sets
the received Reconfigure
message. While transaction-id field to 0. The server includes a Server
Identifier option containing its DUID and a Client Identifier option
containing the transaction is client's DUID in progress, the client silently
discards any Reconfigure messages it receives.

DISCUSSION: message.

The Reconfigure message acts as a trigger that signals the
client server MAY include an Option Request option to complete a successful message exchange. Once inform the client
of what information has received a Reconfigure, been changed or new information that has been
added. In particular, the client proceeds
with server specifies the message exchange (retransmitting IA option in the Renew or
Information-request message
Option Request option if necessary); the client
ignores any additional Reconfigure messages until the
exchange is complete. Subsequent Reconfigure messages cause server wants the client to initiate a obtain new exchange.

How does this mechanism work in
address information. If the face of duplicated or
retransmitted Reconfigure messages? Duplicate messages
will be ignored because server identifies the client will begin IA option in the exchange
after
Option Request option, the receipt server MUST include an IA option that
contains no other sub-options to identify each IA that is to be
reconfigured on the client.

Because of the first Reconfigure. Retransmitted
messages will either trigger risk of denial of service attacks against DHCP
clients, the exchange (if use of a security mechanism is mandated in Reconfigure
messages. The server MUST use DHCP authentication in the first Reconfigure was not received by
message.

The server MUST include a Reconfigure Message option (defined in
section 22.19) to select whether the client) client responds with a Renew
message or will be
ignored. an Information-Request message.

The server can discontinue retransmission MUST NOT include any other options in the Reconfigure
except as specifically allowed in the definition of individual
options.

A server sends each Reconfigure messages message to a single DHCP client,
using an IPv6 unicast address of sufficient scope belonging to the client once
DHCP client. If the server receives does not have an address to which it can
send the Renew or Information-request Reconfigure message from directly to the client.

It might be possible for client, the server uses
a duplicate or retransmitted
Reconfigure Relay-reply message (as described in section 20.3) to be sufficiently delayed (and delivered out of
order) send the
Reconfigure message to arrive at a relay agent that will relay the client after message to
the exchange (initiated
by client. The server may obtain the original Reconfigure) has been completed. In this
case, address of the client would initiate a redundant exchange. The
likelihood of delayed and out of order delivery is small
enough to be ignored. The consequence of (and the redundant
exchange is inefficiency rather than incorrect operation.

Droms (ed.),

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 47]

Internet Draft 55]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

19.4.2. Creation and Transmission July 2003

appropriate relay agent, if required) through the information the
server has about clients that have been in contact with the server,
or through some external agent.

To reconfigure more than one client, the server unicasts a separate
message to each client. The server may initiate the reconfiguration
of Renew Messages

When responding 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 Reconfigure, Renew/Reply
or Information-request/Reply message exchange with the client creates and sends server. The
server interprets the receipt of a Renew or Information-request
message (whichever was specified in exactly the same manner as outlined in
section 18.1.3, with the exception that original Reconfigure message)
from the client copies the Option
Request option and any IA options from as satisfying the Reconfigure message into
the Renew message.

19.4.3. Creation request.

19.1.2. Time Out and Transmission Retransmission of Information-request Reconfigure Messages

When responding to a Reconfigure, the client creates and sends

If the server does not receive a Renew or Information-request message in exactly the same manner as outlined in
section 18.1.5, with the exception that
from the client includes a Server
Identifier option with in REC_TIMEOUT milliseconds, the identifier from server retransmits
the Reconfigure message to message, doubles the REC_TIMEOUT value and waits
again. The server continues this process until REC_MAX_RC
unsuccessful attempts have been made, at which point the client is responding.

19.4.4. Time Out server
SHOULD abort the reconfigure process for that client.

Default and Retransmission initial values for REC_TIMEOUT and REC_MAX_RC are
documented in section 5.5.

19.2. Receipt of Renew or Information-request Messages

The client uses the same variables server generates and retransmission algorithm as
it does with Renew or Information-request messages generated as part
of sends a client-initiated configuration exchange. See Reply message to the client as
described in sections 18.1.3 18.2.3 and 18.1.5 18.2.8, including options for details. If the client does not receive a response
from the
configuration parameters.

The server by the end of MAY include options containing the retransmission process, IAs and new values for
other configuration parameters in the client
ignores Reply message, even if those
IAs and discards parameters were not requested in the Reconfigure message.

19.4.5. Renew message from the
client.

19.3. Receipt of Reply Information-request Messages

Upon the receipt of

The server generates and sends a valid Reply message, message to the client processes the
options as
described in sections 18.2.5 and sets (or resets) 18.2.8, including options for
configuration parameters appropriately.
The client records and updates the lifetimes parameters.

Droms, et al. Standards Track [Page 56]

RFC 3315 DHCP for any addresses
specified in IAs in the Reply message.

20. Relay Agent Behavior IPv6 July 2003

The relay agent MAY be configured to use a list of destination
addresses, which server MAY include unicast addresses, the All_DHCP_Servers
multicast address, or options containing new values for other addresses selected by the network
administrator. If
configuration parameters in the relay agent has Reply message, even if those
parameters were not been explicitly
configured, it MUST use the All_DHCP_Servers multicast address as requested in the
default.

If Information-request message from
the relay agent relays client.

19.4. Client Behavior

A client receives Reconfigure messages sent to the All_DHCP_Servers multicast
address or other multicast addresses, it sets the Hop Limit field to
32.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 48]

Internet Draft DHCP UDP port 546 on
interfaces for IPv6 (-28) 2 Nov 2002

20.1. Relaying a Client Message or a Relay-forward Message

A relay agent relays both messages from clients and Relay-forward which it has acquired configuration information
through DHCP. These messages from other relay agents. When a relay agent receives a
valid message to may be relayed, it constructs a new Relay-forward
message. The relay agent copies sent at any time. Since the source address from
results of a reconfiguration event may affect application layer
programs, the
header client SHOULD log these events, and MAY notify these
programs of the IP datagram in which the message was received to the
peer-address field change through an implementation-specific interface.

19.4.1. Receipt of Reconfigure Messages

Upon receipt of a valid Reconfigure message, the Relay-forward message. The relay agent
copies the received DHCP client responds with
either a Renew message (excluding any IP or UDP headers)
into a Relay an Information-request message as indicated
by the Reconfigure Message option (as defined in section 22.19). The
client ignores the new transaction-id field in the received Reconfigure
message. The relay agent adds
to While the Relay-forward message transaction is in progress, the client silently
discards any other options Reconfigure messages it is configured to
include.

20.1.1. Relaying receives.

DISCUSSION:

The Reconfigure message acts as a Message from trigger that signals the client
to complete a Client

If successful message exchange. Once the relay agent client has
received a Reconfigure, the client proceeds with the message to be relayed from a client,
exchange (retransmitting the relay agent places a global Renew or site-scoped address with a prefix
assigned Information-request message
if necessary); the client ignores any additional Reconfigure
messages until the exchange is complete. Subsequent Reconfigure
messages cause the client to initiate a new exchange.

How does this mechanism work in the link on which face of duplicated or
retransmitted Reconfigure messages? Duplicate messages will be
ignored because the client should will begin the exchange 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 assigned an
address in ignored. The server can
discontinue retransmission of Reconfigure messages to the link-address field. This address will be used by client
once the server to determine receives the link Renew or Information-request message
from which the client should client.

It might be assigned
an address and other configuration information. The hop-count in the
Relay-forward message is set possible for a duplicate or retransmitted Reconfigure
to 0.

If the relay agent cannot use the address in the link-address field be sufficiently delayed (and delivered out of order) to identify arrive
at the interface through which client after the response to exchange (initiated by the original
Reconfigure) has been completed. In this case, the client
will would
initiate a redundant exchange. The likelihood of delayed and out

Droms, et al. Standards Track [Page 57]

RFC 3315 DHCP for IPv6 July 2003

of order delivery is small enough to be relayed, ignored. The consequence
of the relay agent MUST include an Interface-id option
(see section 22.18) in redundant exchange is inefficiency rather than incorrect
operation.

19.4.2. Creation and Transmission of Renew Messages

When responding to a Reconfigure, the Relay-forward message. The server will
include client creates and sends the Interface-id option in its Relay-reply message. The
relay agent fills
Renew message in exactly the link-address field same manner as described outlined in section
18.1.3, with the
previous paragraph regardless of whether exception that the relay agent includes an
Interface-id option in client copies the Relay-forward message.

20.1.2. Relaying a Message Option Request
option and any IA options from a Relay Agent

If the Reconfigure message received by into the relay agent is a Relay-forward
message Renew
message.

19.4.3. Creation and Transmission of Information-request Messages

When responding to a Reconfigure, the hop-count in the message is greater than or equal to
HOP_COUNT_LIMIT, the relay agent discards the received message.

The relay agent copies client creates and sends the source address from
Information-request message in exactly the IP datagram same manner as outlined in
which
section 18.1.5, with the message was received from exception that the client into includes a Server
Identifier option with the peer-address
field in identifier from the Relay-forward Reconfigure message and sets the hop-count field to
which the value client is responding.

19.4.4. Time Out and Retransmission of Renew or Information-request
Messages

The client uses the hop-count field in the received message incremented
by 1. 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. If the source address client does not receive a response from
the IP datagram header server by the end of the received
message is a global or site-local address (and retransmission process, the device on which client
ignores and discards the relay agent is running belongs to only one site), Reconfigure message.

19.4.5. Receipt of Reply Messages

Upon the relay agent
sets receipt of a valid Reply message, the link-address field to 0; otherwise client processes the relay agent
options and sets (or resets) configuration parameters appropriately.
The client records and updates the link-address field to a global or site-local address assigned
to the interface on which the message was received, or includes an

Droms (ed.), et al. Expires 30 Apr 2003 [Page 49]

Internet Draft DHCP lifetimes for IPv6 (-28) 2 Nov 2002

Interface-ID option to identify the interface on which the message
was received.

20.2. Relaying a Relay-reply Message

The relay agent processes any options included addresses
specified in the Relay-reply
message IAs in addition to the Reply message.

20. Relay Message option and then discards
those options. Agent Behavior

The relay agent extracts MAY be configured to use a list of destination
addresses, which MAY include unicast addresses, the message from All_DHCP_Servers
multicast address, or other addresses selected by the Relay Message option
and relays network
administrator. If the relay agent has not been explicitly
configured, it to MUST use the All_DHCP_Servers multicast address contained in the peer-address field of as the Relay-reply message.
default.

Droms, et al. Standards Track [Page 58]

RFC 3315 DHCP for IPv6 July 2003

If the Relay-reply message includes an Interface-id option, the relay agent relays the message from the server messages to the client on
the link identified by the Interface-id option. Otherwise, if All_DHCP_Servers multicast
address or other multicast addresses, it sets the
link-address Hop Limit field is not set to zero, the
32.

20.1. Relaying a Client Message or a Relay-forward Message

A relay agent relays the
message on the link identified by the link-address field.

20.3. Construction of Relay-reply Messages

A server uses both messages from clients and Relay-forward
messages from other relay agents. When a Relay-reply message to return relay agent receives a response
valid message to be relayed, it constructs a client
if new Relay-forward
message. The relay agent copies the original message source address from the client was relayed to header
of the server IP datagram in
a Relay-forward message or to send a Reconfigure message to a client
if the server does not have an address it can use to send which the message
directly to the client.

A response was received to the client MUST be relayed through the same relay
agents as
peer-address field of the original client Relay-forward message. The server causes this to
happen by creating a Relay-reply relay agent
copies the received DHCP message that includes (excluding any IP or UDP headers)
into a Relay Message option containing the message for in the next new message. The relay agent in
the return path adds
to the client. The contained Relay-reply Relay-forward message
contains another Relay any other options it is configured to
include.

20.1.1. Relaying a Message option from a Client

If the relay agent received the message to be sent to relayed from a client,
the next relay
agent, and so on. The server must record agent places a global or site-scoped address with a prefix
assigned to the contents of link on which the
peer-address fields client should be assigned an
address in the received message so it can construct link-address field. This address will be used by the appropriate Relay-reply message carrying
server to determine the response link from which the
server.

For example, if client C sent a message that was relayed by relay
agent A to relay agent B should be assigned
an address and then to the server, the server would
send other configuration information. The hop-count in the following Relay-Reply
Relay-forward message is set to 0.

If the relay agent B:

msg-type: RELAY-REPLY
hop-count: 1
link-address: 0
peer-address: A
Relay Message option, containing:
msg-type: RELAY-REPLY
hop-count: 0
link-address: cannot use the address from link to which C is attached
peer-address: C

Droms (ed.), et al. Expires 30 Apr 2003 [Page 50]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

Relay Message option: <response from server>

When sending a Reconfigure message in the link-address field
to a client identify the interface through a relay
agent, which the server creates a Relay-reply message that includes a
Relay Message option containing response to the Reconfigure message for client
will be relayed, the
next relay agent MUST include an Interface-id option
(see section 22.18) in the return path to the client. Relay-forward message. The server sets will
include the peer-address field Interface-id option in the its Relay-reply message header to the
address of the client, and sets message. The
relay agent fills in the link-address field as required
by described in the
previous paragraph regardless of whether the relay agent to includes an
Interface-id option in the Relay-forward message.

20.1.2. Relaying a Message from a Relay Agent

If the message received by the relay agent is a Relay-forward message
and the hop-count in the Reconfigure message is greater than or equal to
HOP_COUNT_LIMIT, the client. relay agent discards the received message.

The server obtains relay agent copies the addresses of source address from the client and IP datagram in
which the relay agent
through prior interaction with message was received from the client or through some external
mechanism.

21. Authentication of DHCP Messages

Some network administrators may wish to provide authentication of into the source peer-address
field in the Relay-forward message and contents of DHCP messages. For example, clients may
be subject to denial of service attacks through sets the use of bogus
DHCP servers, or may simply be misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish hop-count field to
constrain
the allocation of addresses to authorized hosts to avoid
denial value of service attacks in "hostile" environments where the network
medium is not physically secured, such as wireless networks or
college residence halls.

The DHCP authentication mechanism is based on the design of
authentication for DHCPv4 [7].

21.1. Security of Messages Sent Between Servers and Relay Agents

Relay agents and servers that exchange messages securely use hop-count field in the
IPsec mechanisms received message incremented
by 1.

Droms, et al. Standards Track [Page 59]

RFC 3315 DHCP for IPv6 [11]. Relay agents and servers MUST
support manual configuration and installation of static keys. July 2003

If
a client the source address from the IP datagram header of the received
message is relayed through multiple relay agents, each of a global or site-local address (and the relay agents must have established independent, pairwise trust
relationships. That is, if messages from client C will be relayed by
relay agent A to relay agent B and then to device on which
the server, relay agents A
and B must be configured agent is running belongs to use IPSec for only one site), the messages they exchange,
and relay agent B and
sets the server must be configured link-address field to use IPSec for 0; otherwise the messages they exchange.

Relay agents and servers that support secure relay agent sets the
link-address field to server a global or relay agent site-local address assigned to relay agent communication use IPsec under the
following conditions:

Selectors Relay agents are manually configured with the
addresses of
interface on which the relay agent message was received, or server includes an
Interface-ID option to identify the interface on which
DHCP messages are to be forwarded. Each the message
was received.

20.2. Relaying a Relay-reply Message

The relay agent and server that will be using IPsec for
securing DHCP messages must also be configured

Droms (ed.), et al. Expires 30 Apr 2003 [Page 51]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

with a list of processes any options included in the relay agents Relay-reply
message in addition to which messages
will be returned. the Relay Message option, and then discards
those options.

The selectors for the relay
agents agent extracts the message from the Relay Message option
and servers will be relays it to the pairs address contained in the peer-address field of addresses
defining
the Relay-reply message.

If the Relay-reply message includes an Interface-id option, the relay agents and servers that exchange
DHCP messages
agent relays the message from the server to the client on the DHCPv6 UDP ports 546 and
547.

Mode Relay agents and servers use transport mode and
ESP. The information in DHCP messages link
identified by the Interface-id option. Otherwise, if the
link-address field is not
generally considered confidential, so encryption
need not be used (i.e., NULL encryption can be
used).

Key management Because set to zero, the relay agents and servers must be
manually configured, no automated key management
is required.

Security policy DHCP messages between relay agents and servers
should only be accepted from DHCP peers as agent relays the
message on the link identified in by the local configuration.

Authentication Shared keys, indexed link-address field.

20.3. Construction of Relay-reply Messages

A server uses a Relay-reply message to return a response to a client
if the source IP address of original message from the received DHCP message, are adequate in this
application.

Availability Appropriate IPsec implementations are likely client was relayed to
be available for servers and for relay agents in
more featureful devices used the server in enterprise and
core ISP networks. IPsec is less likely
a Relay-forward message or to send a Reconfigure message to a client
if the server does not have an address it can use to send the message
directly to the client.

A response to the client MUST be
available for relayed through the same relay
agents in low end devices
primarily used in as the home or small office
markets.

21.2. Summary of DHCP Authentication

Authentication of DHCP messages is accomplished through original client message. The server causes this to
happen by creating a Relay-reply message that includes a Relay
Message option containing the use of message for the Authentication option (see section 22.11). The authentication
information carried next relay agent in the Authentication
return path to the client. The contained Relay-reply message
contains another Relay Message option can to be used sent to
reliably identify the source next relay
agent, and so on. The server must record the contents of a the
peer-address fields in the received message so it can construct the
appropriate Relay-reply message carrying the response from the
server.

Droms, et al. Standards Track [Page 60]

RFC 3315 DHCP for IPv6 July 2003

For example, if client C sent a message that was relayed by relay
agent A to relay agent B and then to confirm that the contents of server, the DHCP server would
send the following Relay-Reply message have not been tampered with.

The Authentication option provides to relay agent B:

msg-type: RELAY-REPLY
hop-count: 1
link-address: 0
peer-address: A
Relay Message option, containing:
msg-type: RELAY-REPLY
hop-count: 0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: <response from server>

When sending a framework for multiple
authentication protocols. Two such protocols are defined here.
Other protocols defined in the future will be specified in separate
documents.

Any DHCP Reconfigure message MUST NOT include more than one Authentication
option.

The protocol field in to a client through a relay agent,
the Authentication server creates a Relay-reply message that includes a Relay
Message option identifies containing the
specific protocol used to generate Reconfigure message for the authentication information
carried next relay
agent in the option. The algorithm field identifies a specific

Droms (ed.), et al. Expires 30 Apr 2003 [Page 52]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

algorithm within return path to the authentication protocol; for example, client. The server sets the
algorithm
peer-address field specifies in the hash algorithm used Relay-reply message header to generate the
message authentication code (MAC) in address
of the authentication option. The
replay detection method (RDM) client, and sets the link-address field specifies as required by the type of replay
detection used in
relay agent to relay the replay detection field.

21.3. Replay Detection Reconfigure message to the client. The Replay Detection Method (RDM) field determines
server obtains the type addresses of replay
detection used in the Replay Detection field.

If client and the RDM field contains 0x00, relay agent
through prior interaction with the replay detection field MUST
be set client or through some external
mechanism.

21. Authentication of DHCP Messages

Some network administrators may wish to the value provide authentication of a monotonically increasing counter. Using
a counter value such as the current time
source and contents of day (for DHCP messages. For example, an
NTP-format timestamp [13]) can reduce clients may be
subject to denial of service attacks through the danger use of replay attacks.
This method MUST bogus DHCP
servers, or may simply be supported by all protocols.

21.4. Delayed Authentication Protocol

If misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish to
constrain the allocation of addresses to authorized hosts to avoid
denial of service attacks in "hostile" environments where the protocol field network
medium is 2, the message not physically secured, such as wireless networks or
college residence halls.

The DHCP authentication mechanism is using the "delayed
authentication" mechanism. In delayed authentication, based on the client
requests design of
authentication in its Solicit message for DHCPv4 [4].

21.1. Security of Messages Sent Between Servers and the server replies
with an Advertise message Relay Agents

Relay agents and servers that includes authentication information.
This authentication information contains a nonce value generated by exchange messages securely use the source as
IPsec mechanisms for IPv6 [7]. If a client message authentication code (MAC) to provide message
authentication and entity authentication.

The use of a particular technique based on the HMAC protocol [12]
using the MD5 hash [20] is defined here.

21.4.1. Use relayed
through multiple relay agents, each of the Authentication Option in the Delayed Authentication
Protocol

In a Solicit message, the relay agents must have
established independent, pairwise trust relationships. That is, if
messages from client fills in the protocol, algorithm C will be relayed by relay agent A to relay

Droms, et al. Standards Track [Page 61]

RFC 3315 DHCP for IPv6 July 2003

agent B and RDM fields in the Authentication option with the client's
preferences. The client sets then to the replay detection field server, relay agents A and B must be
configured to zero use IPSec for the messages they exchange, and relay
agent B and
omits the authentication information field. The client sets server must be configured to use IPSec for the
option-len field
messages they exchange.

Relay agents and servers that support secure relay agent to server or
relay agent to 11.

In all other messages, the protocol and algorithm fields identifies relay agent communication use IPsec under the method used to construct
following conditions:

Selectors Relay agents are manually configured with the contents
addresses of the authentication
information field. The RDM field identifies the method used relay agent or server to
construct the contents of the replay detection field.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 53]

Internet Draft which
DHCP messages are to be forwarded. Each relay
agent and server that will be using IPsec for IPv6 (-28) 2 Nov 2002

The format
securing DHCP messages must also be configured
with a list of the Authentication information is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP realm |
| (variable length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-MD5 |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DHCP realm relay agents to which messages
will be returned. The DHCP realm that identifies selectors for the key used to
generate relay
agents and servers will be the HMAC-MD5 value

key ID The key identifier pairs of addresses
defining relay agents and servers that identified the key used to
generate exchange
DHCP messages on the HMAC-MD5 value

HMAC-MD5 DHCPv6 UDP ports 546 and
547.

Mode Relay agents and servers use transport mode and
ESP. The message authentication code generated by applying
MD5 to the information in DHCP message using messages is not
generally considered confidential, so encryption
need not be used (i.e., NULL encryption can be
used).

Key management Because the relay agents and servers are used
within an organization, public key identified by schemes are
not necessary. Because the DHCP realm, client DUID relay agents and
servers must be manually configured, manually
configured key ID

The sender computes the MAC using the HMAC generation algorithm [12] management may suffice, but does
not provide defense against replayed messages.
Accordingly, IKE with preshared secrets SHOULD be
supported. IKE with public keys MAY be
supported.

Security policy DHCP messages between relay agents and the MD5 hash function [20]. The entire servers
should only be accepted from DHCP message (setting
the MAC field of peers as
identified in the authentication option local configuration.

Authentication Shared keys, indexed to zero), including the source IP address of
the received DHCP message header message, are adequate in this
application.

Availability Appropriate IPsec implementations are likely to
be available for servers and the options field, is for relay agents in
more featureful devices used as input in enterprise and

Droms, et al. Standards Track [Page 62]

RFC 3315 DHCP for IPv6 July 2003

core ISP networks. IPsec is less likely to be
available for relay agents in low end devices
primarily used in the
HMAC-MD5 computation function.

DISCUSSION:

Algorithm 1 specifies the use home or small office
markets.

21.2. Summary of HMAC-MD5. Use DHCP Authentication

Authentication of a
different technique, such as HMAC-SHA, will be specified as
a separate protocol.

The DHCP realm used to identify authentication keys messages is
chosen to be unique among administrative domains. Use accomplished through the use of
the DHCP realm allows DHCP administrators to avoid conflict Authentication option (see section 22.11). The authentication
information carried in the use Authentication option can be used to
reliably identify the source of key identifiers, and allows a host using DHCP message and to use authenticated DHCP while roaming among DHCP
administrative domains.

21.4.2. Message Validation

Any confirm that
the contents of the DHCP message that includes more than one authentication have not been tampered with.

The Authentication option
MUST be discarded.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 54]

Internet Draft DHCP provides a framework for IPv6 (-28) 2 Nov 2002

To validate an incoming message, the receiver first checks that
the value multiple
authentication protocols. Two such protocols are defined here.
Other protocols defined in the replay detection field is acceptable according to
the replay detection method future will be specified by the RDM field. Next, the
receiver computes the MAC as described in [12]. The entire separate
documents.

Any DHCP message (setting the MAC MUST NOT include more than one Authentication
option.

The protocol field of in the authentication Authentication option to 0),
is identifies the
specific protocol used as input to generate the HMAC-MD5 computation function. If the MAC
computed by the receiver does not match the MAC contained authentication information
carried in the option. The algorithm field identifies a specific
algorithm within the authentication option, protocol; for example, the receiver MUST discard
algorithm field specifies the DHCP message.

21.4.3. Key Utilization

Each DHCP client has a set of keys. Each key is identifier by <DHCP
realm, client DUID, key id>. Each key also has a lifetime. The key
may not be hash algorithm used past the end of its lifetime. The client's keys
are initially distributed to generate the client through some out-of-band
mechanism. The lifetime for each key is distributed with
message authentication code (MAC) in the key.
Mechanisms for key distribution and lifetime specification are beyond authentication option. The
replay detection method (RDM) field specifies the scope type of this document. replay
detection used in the replay detection field.

21.3. Replay Detection

The client and server use one Replay Detection Method (RDM) field determines the type of replay
detection used in the client's keys Replay Detection field.

If the RDM field contains 0x00, the replay detection field MUST be
set to authenticate
DHCP messages during the value of a session (until monotonically increasing counter. Using a
counter value, such as the next Solicit message
broadcast by current time of day (for example, an NTP-
format timestamp [9]), can reduce the client).

21.4.4. Client Considerations for danger of replay attacks. This
method MUST be supported by all protocols.

21.4. Delayed Authentication Protocol

The

If the protocol field is 2, the message is using the "delayed
authentication" mechanism. In delayed authentication, the client announces its intention to use DHCP
requests authentication by
including an Authentication option in its Solicit message. The
server selects a key for the client based on the client's DUID. The
client message, and the server use
replies with an Advertise message that key to authenticate all includes authentication

Droms, et al. Standards Track [Page 63]

RFC 3315 DHCP messages
exchanged during the session.

21.4.4.1. Sending Solicit Messages

When for IPv6 July 2003

information. This authentication information contains a nonce value
generated by the client sends source as a Solicit message and wishes authentication code (MAC) to
provide message authentication and entity authentication.

The use
authentication, it includes an of a particular technique based on the HMAC protocol [8]
using the MD5 hash [16] is defined here.

21.4.1. Use of the Authentication option with Option in the Delayed Authentication
Protocol

In a Solicit message, the client fills in the desired protocol, algorithm and
RDM as described fields in section 21.4. the Authentication option with the client's
preferences. The client
does not include any sets the replay detection or field to zero and
omits the authentication information
in the Authentication option.

21.4.4.2. Receiving Advertise Messages field. The client validates any Advertise messages containing an
Authentication option specifying sets the
option-len field to 11.

In all other messages, the delayed authentication protocol
using and algorithm fields identify the
method used to construct the contents of the validation test described in section 21.4.2.

Client behavior if no Advertise messages include authentication
information or pass field. The RDM field identifies the validation test is controlled by local policy
on method used to
construct the client. According contents of the replay detection field.

The format of the Authentication information is:

DHCP realm The DHCP realm that identifies the key used to client policy,
generate the client MAY choose HMAC-MD5 value.

key ID The key identifier that identified the key used to
respond
generate the HMAC-MD5 value.

HMAC-MD5 The message authentication code generated by applying
MD5 to a Advertise the DHCP message that has not been authenticated.

Droms (ed.), using the key identified by
the DHCP realm, client DUID, and key ID.

Droms, et al. Expires 30 Apr 2003 al. Standards Track [Page 55]

Internet Draft 64]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002 July 2003

The decision to set local policy to accept unauthenticated messages
should be made with care. Accepting an unauthenticated Advertise
message can make sender computes the client vulnerable to spoofing MAC using the HMAC generation algorithm [8]
and other
attacks. If local users are not explicitly informed that the client
has accepted an unauthenticated Advertise message, MD5 hash function [16]. The entire DHCP message (setting the users may
incorrectly assume that
MAC field of the client has received an authenticated
address and is not subject authentication option to zero), including the DHCP attacks through unauthenticated
messages.

A client MUST be configurable to discard unauthenticated messages,
message header and SHOULD be configured by default the options field, is used as input to discard unauthenticated
messages if the client has been configured with an authentication
key or other authentication information. A client MAY choose HMAC-
MD5 computation function.

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.

The DHCP realm used to
differentiate between Advertise messages with no identify authentication
information and Advertise messages that do not pass keys is chosen to
be unique among administrative domains. Use of the validation
test; for example, a client might accept DHCP realm
allows DHCP administrators to avoid conflict in the former use of key
identifiers, and discard the
latter. If allows a client does accept host using DHCP to use authenticated
DHCP while roaming among DHCP administrative domains.

21.4.2. Message Validation

Any DHCP message that includes more than one authentication option
MUST be discarded.

To validate an unauthenticated incoming message, the
client SHOULD inform any local users and SHOULD log receiver first checks that the event.

21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release
Messages

If
value in the client authenticated replay detection field is acceptable according to the Advertise message through which
replay detection method specified by the
client selected RDM field. Next, the server,
receiver computes the MAC as described in [8]. The entire DHCP
message (setting the MAC field of the client MUST generate authentication
information for subsequent Request, Confirm, Renew, Rebind or Release
messages sent option to the server 0) is
used as described input to the HMAC-MD5 computation function. If the MAC
computed by the receiver does not match the MAC contained in section 21.4. When the
client sends a subsequent message, it
authentication option, the receiver MUST use discard the same DHCP message.

21.4.3. Key Utilization

Each DHCP client has a set of keys. Each key used is identified by <DHCP
realm, client DUID, key id>. Each key also has a lifetime. The key
may not be used past the end of its lifetime. The client's keys are
initially distributed to the client through some out-of-band
mechanism. The lifetime for each key is distributed with the key.
Mechanisms for key distribution and lifetime specification are beyond
the scope of this document.

The client and server use one of the client's keys to generate authenticate
DHCP messages during a session (until the authentication information.

21.4.4.4. Sending Information-request Messages

If next Solicit message sent
by the client).

Droms, et al. Standards Track [Page 65]

RFC 3315 DHCP for IPv6 July 2003

21.4.4. Client Considerations for Delayed Authentication Protocol

The client announces its intention to use DHCP authentication by
including an Authentication option in its Solicit message. The
server has selected selects a key for the client in a previous message
exchange (see section 21.4.5.1), based on the client's DUID. The
client MUST and server use the same that key to
generate the authentication information throughout authenticate all DHCP messages
exchanged during the session.

21.4.4.5. Receiving Reply

21.4.4.1. Sending Solicit Messages

If the client authenticated the Advertise it accepted, the client
MUST validate the associated Reply message from

When the server. The client MUST discard the Reply if the sends a Solicit message fails to pass the
validation test and MAY log the validation failure. If the Reply
fails wishes to pass the validation test, the client MUST restart the DHCP
configuration process by sending a Solicit message.

If use
authentication, it includes an Authentication option with the desired
protocol, algorithm and RDM as described in section 21.4. The client accepted an Advertise message that did
does not include any replay detection or authentication information or did not pass the validation test, the
client MAY accept an unauthenticated Reply message from
in the server.

Droms (ed.), et al. Expires 30 Apr 2003 [Page 56]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

21.4.4.6. Authentication option.

21.4.4.2. Receiving Reconfigure Advertise Messages

The client MUST discard the Reconfigure if validates any Advertise messages containing an
Authentication option specifying the message fails to pass delayed authentication protocol
using the validation test and MAY log described in section 21.4.2.

Client behavior, if no Advertise messages include authentication
information or pass the validation failure.

21.4.5. Server Considerations for Delayed Authentication Protocol

After receiving a Solicit message that contains an Authentication
option, test, is controlled by local
policy on the server selects a key for client. According to client policy, the client based on the client's
DUID and key selection policies with which the server MAY
choose to respond to an Advertise message that has not been
configured.
authenticated.

The server identifies the selected key in the Advertise
message and uses the key decision to validate subsequent set local policy to accept unauthenticated messages between
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 server.

21.4.5.1. Receiving Solicit Messages and Sending client has
accepted an unauthenticated Advertise Messages

The server selects a key for message, the users may
incorrectly assume that the client has received an authenticated
address and includes authentication
information in the Advertise message returned is not subject to the DHCP attacks through unauthenticated
messages.

A client as
specified in section 21.4. The server MUST record the identifier of
the key selected for be configurable to discard unauthenticated messages,
and SHOULD be configured by default to discard unauthenticated
messages if the client and use that same has been configured with an authentication key for validating
subsequent
or other authentication information. A client MAY choose to
differentiate between Advertise messages with the client.

21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages no authentication
information and Sending Reply Messages

The server uses Advertise messages that do not pass the key identified in validation
test; for example, a client might accept the message former and validates discard the
message as specified in section 21.4.2.
latter. If the message fails to pass
the validation test or the server a client does not know the key identified
by the 'key ID' field, the server MUST discard accept an unauthenticated message, the message
client SHOULD inform any local users and MAY
choose to SHOULD log the validation failure. event.

Droms, et al. Standards Track [Page 66]

RFC 3315 DHCP for IPv6 July 2003

21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release
Messages

If the client authenticated the Advertise message passes through which the validation test,
client selected the server responds to server, the specific message as described in section 18.2. The server client MUST
include generate authentication
information generated using the key identified
in for subsequent Request, Confirm, Renew, Rebind or Release
messages sent to the received message server, as specified described in section 21.4.

21.5. Reconfigure Key Authentication Protocol

The Reconfigure key authentication protocol provides protection
against misconfiguration of a When the
client caused by sends a Reconfigure message
sent subsequent message, it MUST use the same key used by a malicious DHCP server. In this protocol, a DHCP
the server
sends a Reconfigure Key to generate the authentication information.

21.4.4.4. Sending Information-request Messages

If the server has selected a key for the client in the initial a previous message
exchange of
DHCP messages. The client records (see section 21.4.5.1), the Reconfigure Key for client MUST use in
authenticating subsequent Reconfigure messages from that server. The
server then includes an HMAC computed from the Reconfigure Key in
subsequent Reconfigure messages.

Both same key to
generate the Reconfigure Key sent from authentication information throughout the server to session.

21.4.4.5. Receiving Reply Messages

If the client and authenticated the HMAC in subsequent Reconfigure messages are carried as Advertise it accepted, the

Droms (ed.), et al. Expires 30 Apr 2003 [Page 57]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

Authentication information in an Authentication option. The format
of client
MUST validate the Authentication information is defined in associated Reply message from the following
section. server. The Reconfigure Key protocol is used (initiated by
client MUST discard the server) only Reply if the client and server are not using any other authentication
protocol and message fails to pass the client
validation test and server have negotiated MAY log the validation failure. If the Reply
fails to use Reconfigure
messages.

21.5.1. Use of pass the Authentication Option in validation test, the Reconfigure Key
Authentication Protocol

The following fields are set in an Authentication option for client MUST restart the
Reconfigure Key Authentication Protocol:

protocol 3

algorithm 1

RDM 0

The format of DHCP
configuration process by sending a Solicit message.

If the Authentication client accepted an Advertise message that did not include
authentication information for or did not pass the validation test, the
client MAY accept an unauthenticated Reply message from the server.

21.4.4.6. Receiving Reconfigure Key
Authentication Protocol 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value (128 bits) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type Type of data in Value field carried in this option:

1 Messages

The client MUST discard the Reconfigure Key value (used in Reply message)

2 HMAC-MD5 digest of if the message (used in Reconfigure
message)

Value Data as defined by field

21.5.2. fails to pass
the validation test and MAY log the validation failure.

21.4.5. Server considerations Considerations for Reconfigure Key protocol

The Delayed Authentication Protocol

After receiving a Solicit message that contains an Authentication
option, the server selects a Reconfigure Key key for a client during the
Request/Reply, Solicit/Reply or Information-request/Reply message
exchange. client, based on the
client's DUID and key selection policies with which the server has
been configured. The server records identifies the Reconfigure Key selected key in the
Advertise message and transmits that uses the key to validate subsequent messages
between the client in an Authentication option in and the Reply message.

Droms (ed.), server.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 58]

Internet Draft 67]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

The Reconfigure Key is 128 bits long, July 2003

21.4.5.1. Receiving Solicit Messages and MUST be a cryptographically
strong random or pseudo-random number that cannot easily be
predicted.

To provide authentication for a Reconfigure message, the Sending Advertise Messages

The server selects a replay detection value according key for the client and includes authentication
information in the Advertise message returned to the RDM selected by client as
specified in section 21.4. The server MUST record the server, and computes an HMAC-MD5 identifier of
the Reconfigure message
using key selected for the Reconfigure Key client and use that same key for validating
subsequent messages with the client.

21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages
and Sending Reply Messages

The server computes uses the
HMAC-MD5 over then entire DHCP Reconfigure message, including key identified in the
Authentication option; message and validates the HMAC-MD5 field
message as specified in section 21.4.2. If the Authentication
option is set message fails to zero for pass
the validation test or the HMAC-MD5 computation. The server
includes does not know the key identified by
the 'key ID' field, the server MUST discard the message and MAY
choose to log the validation failure.

If the message passes the validation test, the server responds to the HMAC-MD5
specific message as described in the section 18.2. The server MUST
include authentication information field in an
Authentication option included in generated using the Reconfigure message sent to key identified
in the
client.

21.5.3. Client considerations for received message, as specified in section 21.4.

21.5. Reconfigure Key protocol Authentication Protocol

The Reconfigure key authentication protocol provides protection
against misconfiguration of a client will receive caused by a Reconfigure message
sent by a malicious DHCP server. In this protocol, a DHCP server
sends a Reconfigure Key from to the server client in the initial Reply message from the server. exchange of DHCP
messages. The client records the Reconfigure Key for use in
authenticating subsequent Reconfigure
messages.

To authenticate a Reconfigure message, the client computes messages from that server. The
server then includes an
HMAC-MD5 over HMAC computed from the DHCP Reconfigure message, using Key in
subsequent Reconfigure messages.

Both the Reconfigure Key received sent from the server. If this computed HMAC-MD5 matches
the value in the Authentication option, server to the client accepts and the
HMAC in subsequent Reconfigure message.

22. DHCP Options

Options messages are used to carry additional information and parameters
in DHCP messages. Every option shares a common base format, carried as
described in section 22.1. All values in options are represented in
network byte order.

This document describes the DHCP options defined as part
Authentication information in an Authentication option. The format
of the base
DHCP specification. Other options may be Authentication information is defined in the future in
separate documents.

Unless otherwise noted, each option may appear following
section.

The Reconfigure Key protocol is used (initiated by the server) only in
if the options
area of a DHCP message client and may appear only once. If an option does
appear multiple times, each instance is considered separate server are not using any other authentication
protocol and the
data areas of the options MUST NOT be concatenated or otherwise
combined.

Droms (ed.), client and server have negotiated to use Reconfigure
messages.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 59]

Internet Draft 68]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002

22.1. Format July 2003

21.5.1. Use of DHCP Options the Authentication Option in the Reconfigure Key
Authentication Protocol

The following fields are set in an Authentication option for the
Reconfigure Key Authentication Protocol:

protocol 3

algorithm 1

RDM 0

The format of DHCP options the Authentication information for the Reconfigure Key
Authentication Protocol 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-code | option-len Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (128 bits) | option-data
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code An unsigned integer identifying
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type Type of data in Value field carried in this option:

1 Reconfigure Key value (used in Reply message).

2 HMAC-MD5 digest of the message (used in Reconfigure
message).

Value Data as defined by field.

21.5.2. Server considerations for Reconfigure Key protocol

The server selects a Reconfigure Key for a client during the
Request/Reply, Solicit/Reply or Information-request/Reply message
exchange. The server records the Reconfigure Key and transmits that
key to the client in an Authentication option in the Reply message.

The Reconfigure Key is 128 bits long, and MUST be a cryptographically
strong random or pseudo-random number that cannot easily be
predicted.

Droms, et al. Standards Track [Page 69]

RFC 3315 DHCP for IPv6 July 2003

To provide authentication for a Reconfigure message, the server
selects a replay detection value according to the RDM selected by the
server, and computes an HMAC-MD5 of the Reconfigure message using the
Reconfigure Key for the client. The server computes the specific option
type carried in this option.

option-len An unsigned integer giving HMAC-MD5
over the length of entire DHCP Reconfigure message, including the
option-data
Authentication option; the HMAC-MD5 field in this the Authentication
option in octets.

option-data The data is set to zero for the option; the format of this data
depends on the definition of HMAC-MD5 computation. The server
includes the option.

DHCPv6 options are scoped by using encapsulation. Some options apply
generally to HMAC-MD5 in the client, some are specific to authentication information field in an IA, and some are
specific
Authentication option included in the Reconfigure message sent to the addresses within an IA. These latter two cases are
discussed in sections 22.4 and 22.6.

22.2.
client.

21.5.3. Client Identifier Option considerations for Reconfigure Key protocol

The Client Identifier option is used to carry a DUID (see section 9)
identifying a client between a client and will receive a Reconfigure Key from the server in the
initial Reply message from the server. The format of client records the Client 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_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_CLIENTID (1)

option-len Length of DUID
Reconfigure Key for use in authenticating subsequent Reconfigure
messages.

To authenticate a Reconfigure message, the client computes an
HMAC-MD5 over the DHCP Reconfigure message, using the Reconfigure Key
received from the server. If this computed HMAC-MD5 matches the
value in octets

Droms (ed.), et al. Expires 30 Apr 2003 [Page 60]

Internet Draft DHCP for IPv6 (-28) 2 Nov 2002

DUID The DUID for the Authentication option, the client

22.3. Server Identifier Option

The Server Identifier option is accepts the
Reconfigure message.

22. DHCP Options

Options are used to carry a DUID (see section 9)
identifying a server between a client additional information and parameters in
DHCP messages. Every option shares a server. The format common base format, as
described in section 22.1. All values in options are represented in
network byte order.

This document describes the DHCP options defined as part of the Server Identifier base
DHCP specification. Other options may be defined in the future in
separate documents.

Unless otherwise noted, each 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 may appear only in octets

DUID The DUID for the server

22.4. Identity Association for Non-temporary Addresses Option

The Identity Association for Non-temporary Addresses options
area of a DHCP message and may appear only once. If an option (IA_NA
option) does
appear multiple times, each instance is used to carry an identity association, the parameters
associated with the IA considered separate and the non-temporary addresses associated
with
data areas of the IA_NA.

Addresses appearing in an IA_NA option are not temporary addresses
(see section 22.5).

Droms (ed.), options MUST NOT be concatenated or otherwise
combined.

Droms, et al. Expires 30 Apr 2003 Standards Track [Page 61]

Internet Draft 70]

RFC 3315 DHCP for IPv6 (-28) 2 Nov 2002 July 2003

22.1. Format of DHCP Options

The format of the IA_NA option DHCP options 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_NA option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-data |
|
. IA_NA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_IA_NA (3)

option-len 12 + length of IA_NA-options field

IAID The unique identifier for this IA; the IAID
must be unique among the identifiers for all
of this client's IAs. The number space for
IA_NA IAIDs is separate from the number space
for IA_TA IAIDs.

T1 The time at which the client contacts the
server from which the addresses in the IA_NA
were obtained to extend the lifetimes of the
addresses assigned to the IA_NA; 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 to extend the lifetimes of
the addresses assigned to the IA_NA; T2 is a
time duration relative to the current time
expressed in units of seconds