draft-ietf-dhc-dhcpv6-15.txt   draft-ietf-dhc-dhcpv6-16.txt 
Internet Engineering Task Force J. Bound Internet Engineering Task Force J. Bound
INTERNET DRAFT Compaq Computer Corp. INTERNET DRAFT Compaq Computer Corp.
DHC Working Group M. Carney DHC Working Group M. Carney
Obsoletes: draft-ietf-dhc-dhcpv6-14.txt Sun Microsystems, Inc Obsoletes: draft-ietf-dhc-dhcpv6-15.txt Sun Microsystems, Inc
C. Perkins C. Perkins
Nokia Research Center Nokia Research Center
5 May 2000 R. Droms(ed.)
Cisco Systems
22 November 2000
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-15.txt draft-ietf-dhc-dhcpv6-16.txt
Status of This Memo Status of This Memo
This document is a submission by the Dynamic Host Configuration This document is a submission by the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Comments Working Group of the Internet Engineering Task Force (IETF). Comments
should be submitted to the dhcp-v6@bucknell.edu mailing list. should be submitted to the dhcp-v6@bucknell.edu mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
skipping to change at page 1, line 39 skipping to change at page 1, line 43
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at: The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables
DHCP servers to pass configuration parameters using extensions to DHCP servers to pass configuration parameters such as IPv6 network
IPv6 nodes. It offers the capability of automatic allocation of addresses to IPv6 nodes. It offers the capability of automatic
reusable network addresses and additional configuration flexibility. allocation of reusable network addresses and additional configuration
This protocol is a stateful counterpart to ``IPv6 Stateless Address flexibility. This protocol is a stateful counterpart to ``IPv6
Autoconfiguration'' [15], and can be used separately or concurrently Stateless Address Autoconfiguration'' [14], and can be used
with the latter to obtain configuration parameters. separately or concurrently with the latter to obtain configuration
parameters.
Contents Contents
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Terminology 2 2. Terminology 2
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3 2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 1, line 57 skipping to change at page 1, line 63
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Terminology 2 2. Terminology 2
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3 2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3
3. DHCP Constants 5 3. DHCP Constants 4
3.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 5 3.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 5
3.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. DHCP message types . . . . . . . . . . . . . . . . . . . 6 3.3. DHCP message types . . . . . . . . . . . . . . . . . . . 5
3.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 7
3.4.1. Generic Error Values . . . . . . . . . . . . . . 8 3.4.1. Generic Error Values . . . . . . . . . . . . . . 7
3.4.2. Server-specific Error Values . . . . . . . . . . 8 3.4.2. Server-specific Error Values . . . . . . . . . . 7
3.5. Configuration Variables . . . . . . . . . . . . . . . . . 8 3.5. Configuration Variables . . . . . . . . . . . . . . . . . 8
4. Requirements 9 4. Requirements 8
5. Background 9 5. Background 9
6. Design Goals 11 6. Design Goals 10
7. Non-Goals 11 7. Non-Goals 11
8. Overview 12 8. Overview 11
8.1. How does a node know to use DHCP? . . . . . . . . . . . . 12 8.1. How does a node know to use DHCP? . . . . . . . . . . . . 11
8.2. How does a client find out about DHCP agents? . . . . . . 12 8.2. How does a client find out about DHCP agents? . . . . . . 11
8.3. What if the client and server(s) are on different links? 12 8.3. What if the client and server(s) are on different links? 11
8.4. How does a client request configuration parameters from 8.4. How does a client request configuration parameters from
servers? . . . . . . . . . . . . . . . . . . . . . . . 13 servers? . . . . . . . . . . . . . . . . . . . . . . . 12
8.5. What are releasable resources, and when are they used? . 13 8.5. How do clients and servers identify and manage addresses? 13
8.6. Can a client release its releasable resources before the lease 8.6. Can a client release its assigned addresses before the lease
expires? . . . . . . . . . . . . . . . . . . . . . . . 14 expires? . . . . . . . . . . . . . . . . . . . . . . . 13
8.7. What if the client determines its releasable resource is 8.7. What if the client determines one or more of its assigned
already being used by another client? . . . . . . . . 14 addresses are already being used by another client? . 13
8.8. How are clients notified of server configuration changes? 14 8.8. How are clients notified of server configuration changes? 13
9. Message Formats 15 9. Message Formats and Identity Associations 14
9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 15 9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 14
9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 16 9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 15
9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 18 9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 16
9.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 19 9.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 17
9.5. DHCP Release Message Format . . . . . . . . . . . . . . . 20 9.5. DHCP Release Message Format . . . . . . . . . . . . . . . 18
9.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 22 9.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 18
9.7. DHCP Reconfigure-reply Message Format . . . . . . . . . . 23 9.7. DHCP Reconfigure-reply Message Format . . . . . . . . . . 18
9.8. DHCP Reconfigure-init Message Format . . . . . . . . . . 24 9.8. DHCP Reconfigure-init Message Format . . . . . . . . . . 19
9.9. Relay-forward message . . . . . . . . . . . . . . . . . . 20
9.10. Server-forward message . . . . . . . . . . . . . . . . . 20
9.11. Identity association . . . . . . . . . . . . . . . . . . 21
10. DHCP Server Solicitation and Subnet Prefix Discovery 25 10. DHCP Server Solicitation 21
10.1. Solicit Message Validation . . . . . . . . . . . . . . . 25 10.1. Solicit Message Validation . . . . . . . . . . . . . . . 21
10.2. Advertise Message Validation . . . . . . . . . . . . . . 25 10.2. Advertise Message Validation . . . . . . . . . . . . . . 21
10.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26 10.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 22
10.3.1. Creation and sending of the Solicit message . . . 26 10.3.1. Creation and sending of the Solicit message . . . 22
10.3.2. Time out and retransmission of Solicit Messages . 27 10.3.2. Time out and retransmission of Solicit Messages . 22
10.3.3. Receipt of Advertise messages . . . . . . . . . . 27 10.3.3. Receipt of Advertise messages . . . . . . . . . . 23
10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 28 10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 23
10.4.1. Relaying of Solicit messages . . . . . . . . . . 28 10.4.1. Relaying of Solicit messages . . . . . . . . . . 23
10.4.2. Relaying of Advertise messages . . . . . . . . . 28 10.4.2. Relaying of Advertise messages . . . . . . . . . 24
10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28 10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 24
10.5.1. Receipt of Solicit messages . . . . . . . . . . . 28 10.5.1. Receipt of Solicit messages . . . . . . . . . . . 24
10.5.2. Creation and sending of Advertise messages . . . 29 10.5.2. Creation and sending of Advertise messages . . . 24
11. DHCP Client-Initiated Configuration Exchange 29 11. DHCP Client-Initiated Configuration Exchange 25
11.1. Request Message Validation . . . . . . . . . . . . . . . 29 11.1. Request Message Validation . . . . . . . . . . . . . . . 25
11.2. Reply Message Validation . . . . . . . . . . . . . . . . 30 11.2. Reply Message Validation . . . . . . . . . . . . . . . . 26
11.3. Release Message Validation . . . . . . . . . . . . . . . 31 11.3. Release Message Validation . . . . . . . . . . . . . . . 26
11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26
11.4.1. Creation and sending of Request messages . . . . 32 11.4.1. Creation and sending of Request messages . . . . 27
11.4.2. Time out and retransmission of Request Messages . 33 11.4.2. Time out and retransmission of Request Messages . 27
11.4.3. Receipt of Reply message in response to a Request 33 11.4.3. Receipt of Reply message in response to a Request 28
11.4.4. Creation and sending of Release messages . . . . 33 11.4.4. Creation and sending of Release messages . . . . 28
11.4.5. Time out and retransmission of Release Messages . 34 11.4.5. Time out and retransmission of Release Messages . 29
11.4.6. Receipt of Reply message in response to a Release 35 11.4.6. Receipt of Reply message in response to a Release 29
11.5. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 35 11.4.7. When a client should send a Request message . . . 29
11.5.1. Relaying of Request or Release messages . . . . . 35 11.4.8. Initialization . . . . . . . . . . . . . . . . . 29
11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35 11.4.9. Confirming the validity of IPv6 addresses . . . . 29
11.6.1. Receipt of Request messages . . . . . . . . . . . 35 11.4.10. Extending the lifetimes on IPv6 addresses . . . . 30
11.6.2. Receipt of Release messages . . . . . . . . . . . 36 11.5. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 31
11.6.3. Creation and sending of Reply messages . . . . . 36 11.5.1. Relaying of Request or Release messages . . . . . 31
11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31
11.6.1. Receipt of Request messages . . . . . . . . . . . 31
11.6.2. Receipt of Release messages . . . . . . . . . . . 31
11.6.3. Creation and sending of Reply messages . . . . . 32
12. DHCP Server-Initiated Configuration Exchange 37 12. DHCP Server-Initiated Configuration Exchange 33
12.1. Reconfigure Message Validation . . . . . . . . . . . . . 37 12.1. Reconfigure Message Validation . . . . . . . . . . . . . 33
12.2. Reconfigure-reply Message Validation . . . . . . . . . . 38 12.2. Reconfigure-reply Message Validation . . . . . . . . . . 33
12.3. Reconfigure-init Message Validation . . . . . . . . . . . 38 12.3. Reconfigure-init Message Validation . . . . . . . . . . . 33
12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 38 12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 33
12.4.1. Creation and sending of Reconfigure messages . . 39 12.4.1. Creation and sending of Reconfigure messages . . 34
12.4.2. Time out and retransmission of Reconfigure 12.4.2. Time out and retransmission of Reconfigure
messages . . . . . . . . . . . . . . . . . 40 messages . . . . . . . . . . . . . . . . . 34
12.4.3. Receipt of Reconfigure-reply messages . . . . . . 40 12.4.3. Receipt of Reconfigure-reply messages . . . . . . 34
12.4.4. Creation and sending of Reconfigure-init messages 40 12.4.4. Creation and sending of Reconfigure-init messages 34
12.4.5. Time out and retransmission of Reconfigure-init 12.4.5. Time out and retransmission of Reconfigure-init
messages . . . . . . . . . . . . . . . . . 41 messages . . . . . . . . . . . . . . . . . 35
12.4.6. Receipt of Request messages . . . . . . . . . . . 41 12.4.6. Receipt of Request messages . . . . . . . . . . . 35
12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 41 12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 35
12.5.1. Receipt of Reconfigure messages . . . . . . . . . 42 12.5.1. Receipt of Reconfigure-init messages . . . . . . 35
12.5.2. Creation and sending of Reconfigure-reply messages 42 12.5.2. Creation and sending of Request messages . . . . 36
12.5.3. Receipt of Reconfigure-init messages . . . . . . 43 12.5.3. Time out and retransmission of Request messages . 36
12.5.4. Creation and sending of Request messages . . . . 43 12.5.4. Receipt of Reply messages . . . . . . . . . . . . 36
12.5.5. Time out and retransmission of Request messages . 43
12.5.6. Receipt of Reply messages . . . . . . . . . . . . 43
13. Using DHCP for network renumbering 43 13. Using DHCP for network renumbering 36
13.1. Passive Renumbering . . . . . . . . . . . . . . . . . . . 44
13.2. Active Renumbering . . . . . . . . . . . . . . . . . . . 44
14. DHCP Client Implementator Notes 44 14. DHCP Client Implementor Notes 37
14.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 45 14.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 37
14.2. Advertise Message and Configuration Parameter Caching . . 45 14.2. Advertise Message and Configuration Parameter Caching . . 37
14.3. Time out and retransmission variables . . . . . . . . . . 45 14.3. Time out and retransmission variables . . . . . . . . . . 37
14.4. Server Preference . . . . . . . . . . . . . . . . . . . . 45 14.4. Server Preference . . . . . . . . . . . . . . . . . . . . 38
15. DHCP Server Implementator Notes 46 15. DHCP Server Implementor Notes 38
15.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 46 15.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 38
15.2. Reconfigure Considerations . . . . . . . . . . . . . . . 46 15.2. Reconfigure-init Considerations . . . . . . . . . . . . . 38
15.3. Server Preference . . . . . . . . . . . . . . . . . . . . 46 15.3. Server Preference . . . . . . . . . . . . . . . . . . . . 39
15.4. Request Message Transaction-ID Cache . . . . . . . . . . 47 15.4. Request Message Transaction-ID Cache . . . . . . . . . . 39
16. DHCP Relay Implementator Notes 47 16. DHCP Relay Implementor Notes 39
17. Open Issues for Working Group Discussion 47 17. Open Issues for Working Group Discussion 39
17.1. Trade-offs: Optional fields in DHCP messages . . . . . . 47 17.1. Authentication . . . . . . . . . . . . . . . . . . . . . 39
17.2. Use DHCPv4 authentication or the current DHCPv6 method? . 48 17.2. DHCP-DNS interaction . . . . . . . . . . . . . . . . . . 39
17.3. The Reconfigure Message and Subnet Prefix Extensions . . 48 17.3. Release vs. Decline . . . . . . . . . . . . . . . . . . 40
17.4. ``R'' bit in Request message not needed? . . . . . . . . 48 17.4. Request messages . . . . . . . . . . . . . . . . . . . . 40
17.5. Use of term ``agent'' . . . . . . . . . . . . . . . . . . 40
17.6. Use of terms ``subnet'' and ``network'' . . . . . . . . . 40
18. Security Considerations 48 18. Security 40
19. Year 2000 considerations 49 19. Year 2000 considerations 41
20. IANA Considerations 49 20. IANA Considerations 41
21. Acknowledgements 50 21. Acknowledgments 41
A. Comparison between DHCPv4 and DHCPv6 50 22. DHCP options 42
22.1. Format of DHCP options . . . . . . . . . . . . . . . . . 42
22.2. Identity association option . . . . . . . . . . . . . . . 43
22.3. Option request option . . . . . . . . . . . . . . . . . . 44
22.4. Client message option . . . . . . . . . . . . . . . . . . 45
22.5. Server message option . . . . . . . . . . . . . . . . . . 45
22.6. Retransmission parameter option . . . . . . . . . . . . . 46
22.7. Authentication option . . . . . . . . . . . . . . . . . . 46
B. Full Copyright Statement 52 23. Changes in this draft 46
23.1. Order of sections . . . . . . . . . . . . . . . . . . . . 47
23.2. Reconfigure message . . . . . . . . . . . . . . . . . . . 47
23.3. Releasable resources . . . . . . . . . . . . . . . . . . 47
23.4. DHCP message header . . . . . . . . . . . . . . . . . . . 47
23.5. Design goals . . . . . . . . . . . . . . . . . . . . . . 47
23.6. Overview . . . . . . . . . . . . . . . . . . . . . . . . 47
23.7. Message formats, 9 . . . . . . . . . . . . . . . . . . . 47
23.8. Solicit and Advertise messages, (section 10) . . . . . . 48
23.9. Prefix advertisement . . . . . . . . . . . . . . . . . . 48
23.10. Identity Associations . . . . . . . . . . . . . . . . . . 48
23.11. Extensions renamed options; defined in this document . . 48
23.12. Transaction-ID ranges . . . . . . . . . . . . . . . . . . 48
23.13. Release messages and relays . . . . . . . . . . . . . . . 48
23.14. Discovering relay agents . . . . . . . . . . . . . . . . 48
Chair's Address 55 A. Comparison between DHCPv4 and DHCPv6 49
Author's Address 55 B. Full Copyright Statement 51
Chair's Address 54
Author's Address 54
1. Introduction 1. Introduction
This document describes DHCP for IPv6 (DHCP), a UDP [14] client / This document describes DHCP for IPv6 (DHCP), a UDP [13] client
server protocol designed to reduce the cost of management of IPv6 / server protocol designed to reduce the cost of management of
nodes in environments where network managers require more control IPv6 nodes in environments where network managers require more
over the allocation of network resources more varied than that control over the allocation of IPv6 addresses and configuration
offered by ``IPv6 Stateless Autoconfiguration'' [15]. The DHCP is a of network stack parameters than that offered by ``IPv6 Stateless
stateful counterpart to stateless autoconfiguration. Note that both Autoconfiguration'' [14]. DHCP is a stateful counterpart to
stateful and stateless autoconfiguration can be used concurrently in stateless autoconfiguration. Note that both stateful and stateless
the same environment, leveraging the strengths of both mechanisms autoconfiguration can be used concurrently in the same environment,
in order to reduce the cost of ownership and management of network leveraging the strengths of both mechanisms in order to reduce the
nodes. cost of ownership and management of network nodes.
The DHCP reduces the cost of ownership by centralizing the management DHCP reduces the cost of ownership by centralizing the management
of network resources such as IP addresses, routing information, OS of network resources such as IP addresses, routing information, OS
installation information, directory service information, and other installation information, directory service information, and other
such information on a few DHCP servers, rather than distributing such such information on a few DHCP servers, rather than distributing such
information in local configuration files among each network node. information in local configuration files among each network node.
The DHCP is designed to be easily extended to carry new configuration DHCP is designed to be easily extended to carry new configuration
parameters through the addition of new DHCP ``extensions'' defined to parameters through the addition of new DHCP ``options'' defined to
carry this information. See this document's companion specification, carry this information. (What were called ``extensions'' in the -15
``Extensions for the Dynamic Host Configuration Protocol for draft are now called ``options''; see section 23.11.)
IPv6'' [2] for specifications of existing extensions as well as
information on the process by which an interested party might specify
new extensions.
Those readers familiar with DHCP for IPv4 [7] will find DHCP for IPv6 Those readers familiar with DHCP for IPv4 [6] will find DHCP for IPv6
provides a superset of features, and benefits from the additional provides a superset of features, and benefits from the additional
features of IPv6 and freedom from BOOTP [5]-backward compatibility features of IPv6 and freedom from BOOTP [4]-backward compatibility
constraints. For more information about the differences between DHCP constraints. For more information about the differences between DHCP
for IPv6 and DHCP for IPv4, see Appendix A. for IPv6 and DHCP for IPv4, see Appendix A.
This document is organized as follows. Section 2 defines terminology This document is organized as follows. Section 2 defines terminology
used throughout this document. Section 3 defines constant values used throughout this document. Section 3 defines constant values
used by DHCP. Section 4 briefly discusses requirement levels. used by DHCP. Section 4 briefly discusses requirement levels.
Section 5 points the reader to helpful background specifications Section 5 points the reader to helpful background specifications
covering related IPv6 protocols. Section 6 discusses the design covering related IPv6 protocols. Section 6 discusses the design
goals that influenced DHCP. Section 7 identifies some of the goals that influenced DHCP. Section 7 identifies some of the
non-goals of this specification. Section 8 gives a high level non-goals of this specification. Section 8 gives a high level
overview of DHCP, its message types, and identifies DHCP functional overview of DHCP, its message types, and identifies DHCP functional
entities (client, relay, server). Section 9 describes in detail the entities (client, relay, server). Section 9 describes in detail
format of each DHCP message type. Section 10 discusses DHCP server the format of each DHCP message type. Section 10 discusses DHCP
solicitation and subnet prefix discovery. Section 11 discusses DHCP server solicitation. Section 11 discusses DHCP client-initiated
client-initiated configuration information exchange. Section 12 configuration information exchange. Section 12 discusses DHCP
discusses DHCP server-initiated configuration information exchange. server-initiated configuration information exchange. Section 14
Section 13 describes how DHCP can be used to renumber networks. presents helpful notes for DHCP client implementors. Section 15
Section 14 presents helpful notes for DHCP client implementators. presents helpful notes for DHCP server implementors. Section 16
Section 15 presents helpful notes for DHCP server implementors. presents helpful notes for DHCP relay implementors. Section 18
discusses security considerations for DHCP.
Section 23 describes the changes between this version of the DHCPv6
specification and draft-ietf-dhc-dhcpv6-15.txt.
Section 16 presents helpful notes for DHCP relay implementors.
Section 18 discusses security considerations for DHCP.
2. Terminology 2. Terminology
2.1. IPv6 Terminology 2.1. IPv6 Terminology
IPv6 terminology relevant to this specification from the IPv6 IPv6 terminology relevant to this specification from the IPv6
Protocol [6], IPv6 Addressing Architecture [8], and IPv6 Stateless Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless
Address Autoconfiguration [15] is included below. Address Autoconfiguration [14] is included below.
address An IP layer identifier for an interface or a set of address An IP layer identifier for an interface or a set of
interfaces. interfaces.
unicast address unicast address
An identifier for a single interface. A packet sent An identifier for a single interface. A packet sent
to a unicast address is delivered to the interface to a unicast address is delivered to the interface
identified by that address. identified by that address.
multicast address multicast address
skipping to change at page 3, line 4 skipping to change at page 2, line 50
ATM networks; and Internet (or higher) layer "tunnels", ATM networks; and Internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself. such as tunnels over IPv4 or IPv6 itself.
link-layer identifier link-layer identifier
a link-layer identifier for an interface. Examples a link-layer identifier for an interface. Examples
include IEEE 802 addresses for Ethernet or Token Ring include IEEE 802 addresses for Ethernet or Token Ring
network interfaces, and E.164 addresses for ISDN links. network interfaces, and E.164 addresses for ISDN links.
link-local address link-local address
An IP address having link-only scope, indicated by An IP address having link-only scope, indicated by
having the subnet prefix (FE80::0000/64), that can be having the prefix (FE80::0000/64), that can be used
used to reach neighboring nodes attached to the same to reach neighboring nodes attached to the same link.
link. Every interface has a link-local address. Every interface has a link-local address.
message A unit of data carried in a packet, exchanged between message A unit of data carried in a packet, exchanged between
DHCP agents and clients. DHCP agents and clients.
neighbor A node attached to the same link. neighbor A node attached to the same link.
node A device that implements IP. node A device that implements IP.
packet An IP header plus payload. packet An IP header plus payload.
skipping to change at page 3, line 35 skipping to change at page 3, line 34
abort status abort status
A status value returned to the application that has A status value returned to the application that has
invoked a DHCP client operation, indicating anything invoked a DHCP client operation, indicating anything
other than success. other than success.
agent address agent address
The address of a neighboring DHCP Agent on the same The address of a neighboring DHCP Agent on the same
link as the DHCP client. link as the DHCP client.
binding A binding (or, client binding) is a group of server binding A binding (or, client binding) is a group of server
data records indexed by <client's link-local address, data records indexed by <prefix, UUID> containing the
subnet prefix> containing the releasable resource data server's information about the addresses and other
which a DHCP server has assigned to a client. information assigned to the IA.
Note that the transaction-ID from the Request message
that produced the assignment of the releasable resource
is also stored in the server data record including the
releasable resource identifier.
DHCP Dynamic Host Configuration Protocol for IPv6. The DHCP Dynamic Host Configuration Protocol for IPv6. The
terms DHCPv4 and DHCPv6 are used only in contexts where terms DHCPv4 and DHCPv6 are used only in contexts where
it is necessary to avoid ambiguity. it is necessary to avoid ambiguity.
configuration parameter configuration parameter
An element of the configuration information set on the An element of the configuration information set on the
server and delivered to the client using DHCP. Such server and delivered to the client using DHCP. Such
parameters may be used to carry information to be used parameters may be used to carry information to be used
by a node to configure its network subsystem and enable by a node to configure its network subsystem and enable
communication on a link or internetwork, for example. communication on a link or internetwork, for example.
DHCP client (or client) DHCP client (or client)
A node that initiates requests on a link to obtain A node that initiates requests on a link to obtain
configuration parameters from one or more DHCP servers. configuration parameters from one or more DHCP servers.
skipping to change at page 4, line 34 skipping to change at page 4, line 27
DHCP relay (or relay) DHCP relay (or relay)
A node that acts as an intermediary to deliver DHCP A node that acts as an intermediary to deliver DHCP
messages between clients and servers, and is on the messages between clients and servers, and is on the
same link as a client. same link as a client.
DHCP agent (or agent) DHCP agent (or agent)
Either a DHCP server on the same link as a client, or a Either a DHCP server on the same link as a client, or a
DHCP relay. DHCP relay.
Releasable resource Identity association (IA)
Any configuration resource allocated by a server for A collection of addresses assigned to a client. Each
a finite period of time. As of this writing, the IA has an associated UUID. A server identifies an IA by
only example of such a resource is the IP address. the tuple (prefix, UUID), where ``prefix'' is a prefix
Releasable resources are carried in extensions assigned to the link to which the client is attached,
allocated out of the 1--8192 range. An IA may have 0 or more addresses associated with it.
solicit-ID Releasable resource
An unsigned integer generated by the client and (Removed; see section 23.3.)
inserted into its DHCP Solicit messages, and echoed
back to the client by the server in its resultant DHCP
Advertise message(s). The client uses the solicit-ID
to match received Advertise messages to Solicit
messages it has generated.
transaction-ID transaction-ID
An unsigned integer to match responses with replies An unsigned integer to match responses with replies
initiated either by a client or server. Servers initiated either by a client or server.
allocate their transaction-IDs from the range of
0--1023, and clients allocate their transaction-IDs UUID
from the range of 1024--65535. Limiting clients and A universally unique identifier for a client.
servers to different ranges prevents transaction-ID
collisions (e.g. client and server happen to use the DISCUSSION:
same transaction-ID for unrelated transactions (e.g.
client Request, server Reconfigure-init). Rules for choosing a UUID are TBD.
3. DHCP Constants 3. DHCP Constants
This section describes various program and networking constants used This section describes various program and networking constants used
by DHCP. by DHCP.
3.1. Multicast Addresses 3.1. Multicast Addresses
The DHCP makes use of the following multicast addresses: DHCP makes use of the following multicast addresses:
All DHCP Agents address: FF02::1:2 All DHCP Agents address: FF02::1:2
This link-local multicast address is used by clients to This link-local multicast address is used by clients to
communicate with the on-link agent(s) when they do not communicate with the on-link agent(s) when they do not
know those agents' link-local address(es). All agents know those agents' link-local address(es). All agents
(servers and relays) are members of this multicast (servers and relays) are members of this multicast
group. group.
All DHCP Servers address: FF05::1:3 All DHCP Servers address: FF05::1:3
This site-local multicast address is used by clients or This site-local multicast address is used by clients or
skipping to change at page 5, line 35 skipping to change at page 5, line 25
All DHCP Servers address: FF05::1:3 All DHCP Servers address: FF05::1:3
This site-local multicast address is used by clients or This site-local multicast address is used by clients or
relays to communicate with server(s), either because relays to communicate with server(s), either because
they want to send messages to all servers or because they want to send messages to all servers or because
they do not know the server(s) unicast address(es). they do not know the server(s) unicast address(es).
Note that in order for a client to use this address, Note that in order for a client to use this address,
it must have an address of sufficient scope to be it must have an address of sufficient scope to be
reachable by the server(s). All servers within the reachable by the server(s). All servers within the
site are members of this multicast group. site are members of this multicast group.
3.2. UDP ports 3.2. UDP ports
The DHCP uses the following destination UDP [14] port numbers. While DHCP uses the following destination UDP [13] port numbers. While
source ports MAY be arbitrary, client implementations SHOULD permit source ports MAY be arbitrary, client implementations SHOULD permit
their specification through a local configuration parameter to their specification through a local configuration parameter to
facilitate the use of DHCP through firewalls. facilitate the use of DHCP through firewalls.
546 Client port. Used by agents to send messages to 546 Client port. Used by agents to send messages to
clients. Also used by servers to send messages to clients. Also used by servers to send messages to
relays. relays.
547 Agent port. Used by clients to send messages to 547 Agent port. Used by clients to send messages to
agents. Also used by relays to send messages to agents. Also used by relays to send messages to
skipping to change at page 6, line 8 skipping to change at page 5, line 40
their specification through a local configuration parameter to their specification through a local configuration parameter to
facilitate the use of DHCP through firewalls. facilitate the use of DHCP through firewalls.
546 Client port. Used by agents to send messages to 546 Client port. Used by agents to send messages to
clients. Also used by servers to send messages to clients. Also used by servers to send messages to
relays. relays.
547 Agent port. Used by clients to send messages to 547 Agent port. Used by clients to send messages to
agents. Also used by relays to send messages to agents. Also used by relays to send messages to
servers. servers.
3.3. DHCP message types 3.3. DHCP message types
The DHCP defines the following message types. More detail on these DHCP defines the following message types. More detail on these
message types can be found in Section 9. Message types 0 and 9--255 message types can be found in Section 9. Message types 0 and 9--255
are reserved and MUST be silently ignored. are reserved and MUST be silently ignored.
01 DHCP Solicit 01 DHCP Solicit
The DHCP Solicit (or Solicit) message is used by clients to The DHCP Solicit (or Solicit) message is used by clients
locate servers and (optionally) learn about the subnet prefixes to locate servers. This message is multicast using the
on the client's link for networks that are managed by DHCP. All-DHCP-Agents address. Relay(s) forward Solicits as
This message is multicast using the All-DHCP-Agents address. necessary to off-link servers.
Relay(s) forward Solicits as necessary to off-link servers.
Section 9.1 contains more details about the Solicit message. Section 9.1 contains more details about the Solicit message.
02 DHCP Advertise 02 DHCP Advertise
The DHCP Advertise (or Advertise) message is used by servers The DHCP Advertise (or Advertise) message is used by servers
responding to Solicits. This message is unicast to the responding to Solicits. This message is unicast to the
client's link-local address (if the server and client are client's link-local address (if the server and client are
on the same link) or unicast to the relay through which the on the same link) or unicast to the relay through which the
Solicit was sent for final delivery to the client. Solicit was sent for final delivery to the client.
Section 9.2 contains more details about the Advertise message. Section 9.2 contains more details about the Advertise message.
03 DHCP Request 03 DHCP Request
The DHCP Request (or Request) message is used by clients to The DHCP Request (or Request) message is used by clients to
request configuration parameters from servers. This message request configuration parameters from servers. This message is
is unicast to the server if the client has an address with multicast using the All-DHCP-Agents address. Relay(s) forward
sufficient scope to be reachable by the server, otherwise it Requests as necessary to off-link servers.
is unicast to the on-link relay through which the Advertise
message was relayed.
Section 9.3 contains more details about the Request message. Section 9.3 contains more details about the Request message.
04 DHCP Reply 04 DHCP Reply
The DHCP Reply (or Reply) message is used by servers responding The DHCP Reply (or Reply) message is used by servers responding
to Request and Release messages. In the case of responding to to Request and Release messages. In the case of responding to
a Request message, the Reply contains configuration parameters a Request message, the Reply contains configuration parameters
destined for the client. This message is unicast to the client destined for the client. This message is unicast to the client
if the client has an address of sufficient scope that is if the client has an address of sufficient scope that is
reachable by the server. Otherwise, it is unicast to the relay reachable by the server. Otherwise, it is unicast to the relay
through which the Request or Release message was sent for final through which the Request or Release message was sent for final
delivery to the client. delivery to the client.
Section 9.4 contains more details about the Reply message. Section 9.4 contains more details about the Reply message.
05 DHCP Release 05 DHCP Release
The DHCP Release (or Release) message is used by clients to The DHCP Release (or Release) message is used by clients to
return one or more instances of releasable resources (e.g. IP return one or more IP addresses to servers. The server will
addresses) to servers. This message is unicast to the server
if the client will have an address of sufficient scope after
the Release operation to receive a Reply message. Otherwise,
the Release message is sent through the relay. The server will
acknowledge the receipt of the Release message by sending the acknowledge the receipt of the Release message by sending the
client a Reply message. client a Reply message.
Section 9.5 contains more details about the Release message. Section 9.5 contains more details about the Release message.
06 DHCP Reconfigure 06 DHCP Reconfigure
The DHCP Reconfigure (or Reconfigure) message is sent by
servers to client(s). It contains new or updated configuration
parameters for use by the client(s). This message may be
unicast or multicast to the client(s).
Section 9.6 contains more details about the Reconfigure
message.
07 DHCP Reconfigure-reply 07 DHCP Reconfigure-reply
The DHCP Reconfigure-reply (or Reconfigure-reply) message is Removed; see section 23.2.
unicast by client(s) to the server to acknowledge the receipt
of a Reconfigure message.
Section 9.7 contains more details about the Reconfigure-reply
message.
08 DHCP Reconfigure-init 08 DHCP Reconfigure-init
The DHCP Reconfigure-init (or Reconfigure-init) message is set The DHCP Reconfigure-init (or Reconfigure-init) message is set
by server(s) to inform client(s) that the server(s) has new or by server(s) to inform client(s) that the server(s) has new or
updated configuration parameters, and that the client(s) are updated configuration parameters, and that the client(s) are
to initiate a Request/Reply transaction with the server(s) in to initiate a Request/Reply transaction with the server(s) in
order to receive the updated information. order to receive the updated information.
Section 9.8 contains more details about the Reconfigure-init Section 9.8 contains more details about the Reconfigure-init
skipping to change at page 8, line 9 skipping to change at page 7, line 26
to initiate a Request/Reply transaction with the server(s) in to initiate a Request/Reply transaction with the server(s) in
order to receive the updated information. order to receive the updated information.
Section 9.8 contains more details about the Reconfigure-init Section 9.8 contains more details about the Reconfigure-init
message. message.
3.4. Error Values 3.4. Error Values
This section describes error values exchanged between DHCP This section describes error values exchanged between DHCP
implementations. implementations.
3.4.1. Generic Error Values 3.4.1. Generic Error Values
The following symbolic names are used between client and server The following symbolic names are used between client and server
implementations to convey error conditions. The following table implementations to convey error conditions. The following table
contains the actual numeric values for each name. Note that the contains the actual numeric values for each name. Note that the
numeric values do not start at 1, nor are they consecutive. The numeric values do not start at 1, nor are they consecutive. The
errors are organized in logical groups. errors are organized in logical groups.
_______________________________________________________________ _______________________________________________________________
|_Error_Name___|Error_ID_|Description__________________________| |Error_Name___|Error_ID|_Description_________________________|_
|_Success______|00_______|Success______________________________| |Success______|00______|_Success_____________________________|_
|_UnspecFail___|16_______|Failure,_reason_unspecified__________| |UnspecFail___|16______|_Failure,_reason_unspecified_________|_
|_AuthFailed___|17_______|Authentication_failed_or_nonexistent_| |AuthFailed___|17______|_Authentication_failed_or_nonexistent|_
|_PoorlyFormed_|18_______|Poorly_formed_message________________| |PoorlyFormed_|18______|_Poorly_formed_message_______________|_
|_Unavail______|19_______|Resources_unavailable________________| |Unavail______|19______|_Addresses_unavailable_______________|_
3.4.2. Server-specific Error Values 3.4.2. Server-specific Error Values
The following symbolic names are used by server implementations to The following symbolic names are used by server implementations to
convey error conditions to clients. The following table contains the convey error conditions to clients. The following table contains the
actual numeric values for each name. actual numeric values for each name.
_______________________________________________________________ _______________________________________________________________
|_Error_Name____|Error_ID_|Description_________________________| |Error_Name____|Error_ID|_Description________________________|_
|_NoBinding_____|20_______|Client_record_(binding)_unavailable_| |NoBinding_____|20______|_Client_record_(binding)_unavailable|_
|_InvalidSource_|21_______|Invalid_Client_IP_address___________| |InvalidSource_|21______|_Invalid_Client_IP_address__________|_
|_NoServer______|23_______|Relay_cannot_find_Server_Address____| |NoServer______|23______|_Relay_cannot_find_Server_Address___|_
|_ICMPError_____|64_______|Server_unreachable_(ICMP_error)_____| |ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_
3.5. Configuration Variables 3.5. Configuration Variables
This section presents a table of client and server configuration This section presents a table of client and server configuration
variables and the default or initial values for these variables. The variables and the default or initial values for these variables. The
client-specific variables MAY be configured on the server and MAY be client-specific variables MAY be configured on the server and MAY be
delivered to the client through the ``DHCP Retransmission Parameter delivered to the client through the ``DHCP Retransmission Parameter
Extension''carried in a Reply message. This extension is documented Option'' in a Reply message. This option is TBD.
in the ``extensions document'' [2].
______________________________________________________________ ______________________________________________________________
|_Parameter__________|Default_|Description____________________| |Parameter__________|Default|_Description___________________|_
|_MIN_SOL_DELAY______|1_______|MIN_(secs)_to_delay_1st_mesg___| |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg__|_
|_MAX_SOL_DELAY______|5_______|MAX_(secs)_to_delay_1st_mesg___| |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg__|_
|_ADV_MSG_TIMEOUT____|500_____|SOL_Retrans_timer_(msecs)______| |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)_____|_
|_ADV_MSG_MAX________|30______|MAX_timer_value_(secs)_________| |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)________|_
|_SOL_MAX_ATTEMPTS___|-1______|MAX_attempts_(-1_=_infinite)___| |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)__|_
|_REP_MSG_TIMEOUT____|250_____|REQ_Retrans_timer_(msecs)______| |REP_MSG_TIMEOUT____|250____|_REQ_Retrans_timer_(msecs)_____|_
|_REQ_MSG_ATTEMPTS___|10______|MAX_Request_attempts___________| |REQ_MSG_ATTEMPTS___|10_____|_MAX_Request_attempts__________|_
|_REL_MSG_ATTEMPTS___|5_______|MAX_Release_attempts___________| |REL_MSG_ATTEMPTS___|5______|_MAX_Release_attempts__________|_
|_RECREP_MSG_TIMEOUT_|2000____|Retrans_timer_(msecs)__________| |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)_________|_
|_REC_MSG_ATTEMPTS___|10______|Reconfigure_attempts___________| |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts__________|_
|_REC_REP_MIN________|5_______|Minimum_pause_interval_(secs)__| |REC_REP_MIN________|5______|_Minimum_pause_interval_(secs)_|_
|_REC_REP_MAX________|7200____|Maximum_pause_interval_(secs)__| |REC_REP_MAX________|7200___|_Maximum_pause_interval_(secs)_|_
|_REC_THRESHOLD______|100_____|%_of_required_clients__________| |REC_THRESHOLD______|100____|_%_of_required_clients_________|_
|_SRVR_PREF_WAIT_____|2_______|Advertise_Collect_timer_(secs)_| |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)|_
4. Requirements 4. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [3]. document, are to be interpreted as described in [2].
This document also makes use of internal conceptual variables This document also makes use of internal conceptual variables
to describe protocol behavior and external variables that an to describe protocol behavior and external variables that an
implementation must allow system administrators to change. The implementation must allow system administrators to change. The
specific variable names, how their values change, and how their specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demostrate settings influence protocol behavior are provided to demonstrate
protocol behavior. An implementation is not required to have them in protocol behavior. An implementation is not required to have them in
the exact form described here, so long as its external behavior is the exact form described here, so long as its external behavior is
consistent with that described in this document. consistent with that described in this document.
5. Background 5. Background
Related work in IPv6 that would best serve an implementor to study Related work in IPv6 that would best serve an implementor to study
is the IPv6 Specification [6], the IPv6 Addressing Architecture [8], is the IPv6 Specification [5], the IPv6 Addressing Architecture [7],
IPv6 Stateless Address Autoconfiguration [15], IPv6 Neighbor IPv6 Stateless Address Autoconfiguration [14], IPv6 Neighbor
Discovery Processing [12], and Dynamic Updates to DNS [17]. These Discovery Processing [11], and Dynamic Updates to DNS [16]. These
specifications enable DHCP to build upon the IPv6 work to provide specifications enable DHCP to build upon the IPv6 work to provide
both robust stateful autoconfiguration and autoregistration of DNS both robust stateful autoconfiguration and autoregistration of DNS
Host Names. Host Names.
The IPv6 Specification provides the base architecture and design of The IPv6 Specification provides the base architecture and design of
IPv6. A key point for DHCP implementors to understand is that IPv6 IPv6. A key point for DHCP implementors to understand is that IPv6
requires that every link in the Internet have an MTU of 1280 octets requires that every link in the Internet have an MTU of 1280 octets
or greater (in IPv4 the requirement is 68 octets). This means that or greater (in IPv4 the requirement is 68 octets). This means that
a UDP packet of 536 octets will always pass through an internetwork a UDP packet of 536 octets will always pass through an internetwork
(less 40 octets for the IPv6 header), as long as there are no IP (less 40 octets for the IPv6 header), as long as there are no IP
options prior to the UDP header in the packet. But, IPv6 does not options prior to the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a end-to-end between hosts. If a DHCP implementation needs to send a
packet greater than 1500 octets it can either fragment the UDP packet packet greater than 1500 octets it can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [10] into fragments of 1500 octets or less, or use Path MTU Discovery [9]
to determine the size of the packet that will traverse a network to determine the size of the packet that will traverse a network
path. path.
DHCP clients use Path MTU discovery when they have an address of DHCP clients use Path MTU discovery when they have an address of
sufficient scope to reach the DHCP server. If a DHCP client does not sufficient scope to reach the DHCP server. If a DHCP client does not
have such an address, that client MUST fragment its packets if the have such an address, that client MUST fragment its packets if the
resultant message size is greater than the minimum 1280 octets. resultant message size is greater than the minimum 1280 octets.
Path MTU Discovery for IPv6 is supported for both UDP and TCP and Path MTU Discovery for IPv6 is supported for both UDP and TCP and
can cause end-to-end fragmentation when the PMTU changes for a can cause end-to-end fragmentation when the PMTU changes for a
destination. destination.
The IPv6 Addressing Architecture specification [8] defines the The IPv6 Addressing Architecture specification [7] defines the
address scope that can be used in an IPv6 implementation, and the address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required, and nodes can create link-local addresses for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin its link-local address and a well-known multicast address to begin
communications to discover neighbors on the link. For instance, a communications to discover neighbors on the link. For instance, a
client can send a Solicit message and locate a server or relay. client can send a Solicit message and locate a server or relay.
IPv6 Stateless Address Autoconfiguration [15] (Addrconf) specifies IPv6 Stateless Address Autoconfiguration [14] (Addrconf) specifies
procedures by which a node may autoconfigure addresses based on procedures by which a node may autoconfigure addresses based on
router advertisements [12], and the use of a valid lifetime to router advertisements [11], and the use of a valid lifetime to
support renumbering of addresses on the Internet. In addition the support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. The DHCP is one vehicle to perform autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with addrconf is a design stateful autoconfiguration. Compatibility with addrconf is a design
requirement of DHCP (see Section 6). requirement of DHCP (see Section 6).
IPv6 Neighbor Discovery [12] is the node discovery protocol in IPv6 IPv6 Neighbor Discovery [11] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [13]. To understand which replaces and enhances functions of ARP [12]. To understand
IPv6 and Addrconf it is strongly recommended that implementors IPv6 and Addrconf it is strongly recommended that implementors
understand IPv6 Neighbor Discovery. understand IPv6 Neighbor Discovery.
Dynamic Updates to DNS [17] is a specification that supports the Dynamic Updates to DNS [16] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space the dynamic updates to DNS to integrate addresses and name space
to not only support autoconfiguration, but also autoregistration to not only support autoconfiguration, but also autoregistration
in IPv6. The security model to be used with DHCPv6 should conform in IPv6. The security model to be used with DHCPv6 should conform
as closely as possible to the authentication model outlined in as closely as possible to the authentication model outlined in
RFC2402 [9]. RFC2402 [8].
6. Design Goals 6. Design Goals
- DHCP is a mechanism rather than a policy. Network administrators - DHCP is a mechanism rather than a policy. Network administrators
set their administrative policies through the configuration set their administrative policies through the configuration
parameters they place upon the DHCP servers in the DHCP domain parameters they place upon the DHCP servers in the DHCP domain
they're managing. DHCP is simply used to deliver parameters they're managing. DHCP is simply used to deliver parameters
according to that policy to each of the DHCP clients within the according to that policy to each of the DHCP clients within the
domain. domain.
- DHCP is compatible with IPv6 stateless autoconf [15]. - DHCP is compatible with IPv6 stateless autoconf [14].
- DHCP does not require manual configuration of network parameters - DHCP does not require manual configuration of network parameters
on DHCP clients, except in cases where such configuration is on DHCP clients, except in cases where such configuration is
needed for security reasons. A node configuring itself using needed for security reasons. A node configuring itself using
DHCP should require no user intervention. DHCP should require no user intervention.
- DHCP does not require a server on each link. To allow for scale - DHCP does not require a server on each link. To allow for scale
and economy, DHCP must work across DHCP relays. and economy, DHCP must work across DHCP relays.
- DHCP coexists with statically configured, non-participating nodes - DHCP coexists with statically configured, non-participating nodes
and with existing network protocol implementations. and with existing network protocol implementations.
- DHCP clients can operate on a link without IPv6 routers present. - DHCP clients can operate on a link without IPv6 routers present.
- DHCP will provide the ability to renumber network(s) when - DHCP will provide the ability to renumber network(s) when
required by network administrators [4]. required by network administrators [3].
- A DHCP client can make multiple, different requests for - A DHCP client can make multiple, different requests for
configuration parameters when necessary from one or more DHCP configuration parameters when necessary from one or more DHCP
servers at any time. DHCP will provide enough information servers at any time.
to enable a DHCP server to keep track of a DHCP client's
configuration state.
- DHCP will contain the appropriate time out and retransmission - DHCP will contain the appropriate time out and retransmission
mechanisms to efficiently operate in environments with high mechanisms to efficiently operate in environments with high
latency and low bandwidth characteristics. latency and low bandwidth characteristics.
7. Non-Goals 7. Non-Goals
This specification explicitly does not cover the following: This specification explicitly does not cover the following:
- Specification of a DHCP server to server protocol. - Specification of a DHCP server to server protocol.
- How a DHCP server stores its DHCP data. - How a DHCP server stores its DHCP data.
- How to manage a DHCP domain or DHCP server. - How to manage a DHCP domain or DHCP server.
skipping to change at page 12, line 7 skipping to change at page 11, line 21
This specification explicitly does not cover the following: This specification explicitly does not cover the following:
- Specification of a DHCP server to server protocol. - Specification of a DHCP server to server protocol.
- How a DHCP server stores its DHCP data. - How a DHCP server stores its DHCP data.
- How to manage a DHCP domain or DHCP server. - How to manage a DHCP domain or DHCP server.
- How a DHCP relay is configured or what sort of information it may - How a DHCP relay is configured or what sort of information it may
log. log.
8. Overview 8. Overview
This section provides a general overview of the interaction This section provides a general overview of the interaction
between the functional entities of DHCP. The overview is organized between the functional entities of DHCP. The overview is organized
as a series of questions and answers. Details of DHCP such as a series of questions and answers. Details of DHCP such
as message formats and retransmissions are left to sections 9, as message formats and retransmissions are left to sections 9,
10, 11, 12, 14, 15, and 16. 10, 11, 12, 14, 15, and 16.
8.1. How does a node know to use DHCP? 8.1. How does a node know to use DHCP?
An unconfigured node determines that it is to use DHCP for An unconfigured node determines that it is to use DHCP for
configuration of an interface by detecting the presence (or absence) configuration of an interface by detecting the presence (or absence)
of routers on the link. If router(s) are present, the node examines of routers on the link. If router(s) are present, the node examines
router advertisements to determine if DHCP should be used to router advertisements to determine if DHCP should be used to
configure the interface. If there are no routers present, then configure the interface. If there are no routers present, then
the node MUST use DHCP to configure the interface. Detail on the node MUST use DHCP to configure the interface. Detail on
this process can be found in neighbor discovery [12] and stateless this process can be found in neighbor discovery [11] and stateless
autoconfiguration [15]. autoconfiguration [14].
8.2. How does a client find out about DHCP agents? 8.2. How does a client find out about DHCP agents?
The client forms a Solicit message, and multicasts it to the (Section removed, see 23.6
FF02::1:2(All DHCP Agents) address. Server(s) receiving the Solicit
respond with Advertise message(s). If requested in the client's
Solicit message, the Advertise message(s) can include one or more
subnet prefix extensions [2], informing the client of subnet prefixes
for the networks(s) managed by the server(s) on the client's link.
Now that the client knows the IP address(es) of agents(s) on the
link, it can request configuration parameters from servers.
8.3. What if the client and server(s) are on different links? 8.3. What if the client and server(s) are on different links?
Use of DHCP in such environments requires one or more DHCP relays Use of DHCP in such environments requires one or more DHCP relays
be set up on the client's link, because a client may only have a be set up on the client's link, because a client may only have a
link-local address. Relays pick up the Solicit and Request messages link-local address. Relays receive the Solicit and Request messages
from the client and forward them to some set of servers within the from the client and forward them to some set of servers within the
DHCP domain. A relay will include one of its own addresses (of DHCP domain. The client message is forwarded verbatim as the payload
sufficient scope) of the interface on the same link as the client. in a message from the relay to the server. A relay will include
The relay also includes the subnet prefix length of that address one of its own addresses (of sufficient scope) from the interface
in the client's messages. Servers receiving the forwarded traffic on the same link as the client, as well as the prefix length of
use this information to aid in selecting configuration parameters that address, in its message to the server. Servers receiving
appropriate to the client's link. The servers also use the relay's the forwarded traffic use this information to aid in selecting
address as the destination to forward client-destined messages configuration parameters appropriate to the client's link. The
for final delivery by the relay. Relays forward client messages servers also use the relay's address as the destination to forward
to servers using some combination of the FF05::1:3(All Servers) client-destined messages for final delivery by the relay.
site-local multicast address, some other (perhaps a combination)
of site-local multicast addresses set up within the DHCP domain to Relays forward client messages to servers using some combination of
include the servers in that domain, or a list of unicast addresses the FF05::1:3(All Servers) site-local multicast address, some other
for servers. The network administrator makes relay configuration (perhaps a combination) of site-local multicast addresses set up
decisions based upon the topological requirements (scope) of the within the DHCP domain to include the servers in that domain, or a
DHCP domain they are managing. Note that if the DHCP domain spans list of unicast addresses for servers. The network administrator
more than the site-local scope, then the relays MUST be configured makes relay configuration decisions based upon the topological
with global addresses for the client's link so as to be reachable by requirements (scope) of the DHCP domain they are managing. Note
servers outside the relays' site-local environment. that if the DHCP domain spans more than the site-local scope, then
the relays MUST be configured with global addresses for the client's
link so as to be reachable by servers outside the relays' site-local
environment.
8.4. How does a client request configuration parameters from servers? 8.4. How does a client request configuration parameters from servers?
To request configuration parameters, the client forms a Request To request configuration parameters, the client forms a Request
message, and sends it to the server either directly (client has an message, and sends it to the server either directly (client has an
address of sufficient scope) or indirectly (through the on-link address of sufficient scope) or indirectly (through the on-link
relay). The client MAY include a Extension Request Extension [2] relay). The client MAY include a Option Request Option 22.3 (ORO)
along with other extensions to request specific information from the along with other options to request specific information from the
server. Note that the client MAY form multiple Request messages server. Note that the client MAY form multiple Request messages
and send each of them to different servers to request potentially and send each of them to different servers to request potentially
different information (perhaps based upon what was advertised) in different information (perhaps based upon what was advertised) in
order to satisfy its needs. As a client's needs may change over time order to satisfy its needs. As a client's needs may change over time
(perhaps based upon an application's requirements), the client may (perhaps based upon an application's requirements), the client may
form additional Request messages to request additional information as form additional Request messages to request additional information as
it is needed. it is needed.
The server(s) respond with Reply messages containing the requested The server(s) respond with Reply messages containing the requested
configuration parameters, which can include status information configuration parameters, which can include status information
regarding the information requested by the client. The Reply MAY regarding the information requested by the client. The Reply MAY
also include additional information, such as a reconfiguration event also include additional information, such as a reconfiguration event
multicast group for the client to join to monitor reconfiguration multicast group for the client to join to monitor reconfiguration
events, as described in section 8.8. events, as described in section 8.8.
The receipt of a Reply from a server concludes the basic 8.5. How do clients and servers identify and manage addresses?
request/reply transaction of the protocol.
8.5. What are releasable resources, and when are they used?
A releasable resource is configuration information leased to a client Servers and clients manage addresses in groups called ``identity
by a server for some finite period of time. When negotiating for a associations.'' Each identity associations is identified using
releasable resource, the client and server agree upon a finite period a unique identifier. An identity association may contain one or
of time the client may use the resource. The client MAY request a more IPv6 addresses. DHCP servers assign addresses to identity
renewal of the lease on the resource at any time. The length of time associations. DHCP clients use the addresses in an identity
of the lease (and whether it is renewable) are server-based policy association to configure interfaces. There is always at least one
tunables. The client MUST stop using the resource when the lease on identity association per interface that a client wishes to configure.
the resource expires. The server MUST NOT reallocate an assigned Each address in an IA has its own preferred and valid lifetime. Over
resource before either its lease expires or the client releases the time, the server may change the characteristics of the addresses in
resource. an IA; for example, by changing the preferred or valid lifetime for
an address in the IA. The server may also add or delete addresses
from an IA; for example, deleting old addresses and adding new
addresses to renumber a client. A client can request the current
list of addresses assigned to an IA from a server through an exchange
of protocol messages.
See the ``extensions document'' [2] for more information about 8.6. Can a client release its assigned addresses before the lease
releasable resources.
8.6. Can a client release its releasable resources before the lease
expires? expires?
A client forms a Release message, including extensions carrying the A client forms a Release message, including options identifying
resource(s) to be released. The client sends the Release to the the IA to be released. The client sends the Release to the server
server which leased the resource(s) to the client initially. If that which assigned the addresses to the client initially. If that
server cannot be reached after a certain number of attempts (see server cannot be reached after a certain number of attempts (see
section 3.5), the client can abandon the Release attempt. In this section 3.5), the client can abandon the Release attempt. In this
case, the resource(s) will be reclaimed by the server(s) when the case, the address(es) in the IA will be reclaimed by the server(s)
client's lease(s) expire. when the lifetimes on the addresses expire.
8.7. What if the client determines its releasable resource is already
being used by another client?
If the client determines through a releasable resource-specific 8.7. What if the client determines one or more of its assigned addresses
manner that the resource it was assigned by the server is already are already being used by another client?
in use by another client, the client will form a Release message,
including the extension carrying the in-use resource. The If the client determines through a mechanism like Duplicate Address
extension's status field MUST be set to the extension-specific value Detection [14] that the address it was assigned by the server is
reflecting the ``in use'' status of the resource. already in use by another client, the client will form a Release
message, including the option carrying the in-use address. The
option's status field MUST be set to the value reflecting the ``in
use'' status of the address.
For example, if the releasable resource is an IP address, the client
uses Duplicate Address Detection (DAD) to verify that the IP address
is not in use. If the client determines that the IP address is
already in use, it forms a Release message including the IP address
extension containing the appropriate status value and sends it to the
server. See the ``extensions document''for details on the IP address
extension. [2].
8.8. How are clients notified of server configuration changes? 8.8. How are clients notified of server configuration changes?
There are two possibilities. Either the clients discover the new There are two possibilities. Either the clients discover the new
information when they revisit the server(s) to request additional information when they revisit the server(s) to request additional
configuration information / renew the lease on a releasable resource, configuration information / extend the lifetime on an address. or
or through a server-initiated event known as a reconfigure event. through a server-initiated event known as a reconfigure event.
The reconfiguration feature of DHCP offers network administrators The reconfiguration feature of DHCP offers network administrators
the opportunity to update configuration information on DHCP clients the opportunity to update configuration information on DHCP clients
whenever necessary. If the information to be updated is not whenever necessary. To signal the need for client reconfiguration,
client-specific, the server will form a Reconfigure message and add the server will unicast a Reconfigure-init message to each
the new or changed configuration information to it. The Reconfigure client individually. The server may use multicast to signal the
may be unicast or multicast (to a preassigned multicast address for reconfiguration to multiple clients simultaneously. (Note that
this purpose) to one or more client(s) to which the new or updated there is no mechanism defined in the protocol to guarantee that
information needs to be directed. The client(s) will acknowledge the every client actually performs a reconfiguration in response to a
receipt of the Reconfigure message by forming a Reconfigure-reply multicast reconfigure-init message.) A Reconfigure-init is a trigger
message and unicasting it to the server. If the configuration which will cause the client(s) to initiate a standard Request/Reply
information change is different for each client (e.g. a change in exchange with the server in order to acquire the new or updated
subnet prefix, perhaps, which would affect the IP address releasable addresses.
resource(s)), the server will form a Reconfigure-init message and
unicast / multicast as needed to the client(s). A Reconfigure-init 9. Message Formats and Identity Associations
is a trigger which will cause the client(s) to initiate a standard
Request/Reply exchange with the server in order to acquire the new or
updated resources.
9. Message Formats
All reserved fields in a message MUST be transmitted as zeroes and All reserved fields in a message MUST be transmitted as zeroes and
ignored by the receiver of the message. ignored by the receiver of the message.
9.1. DHCP Solicit Message Format
A client multicasts a DHCP Solicit message to the FF02::1:2(All DHCP DISCUSSION:
agents) address over the interface to be configured to locate one or
more servers which are configured to provide configuration parameters
to nodes on the client's link.
Unless otherwise noted, the value of all fields are set by the Each DHCP message has an identical fixed format header; some
client. messages also allow a variable format area for options. Not
all fields in the header are used in every message. In this
section, every field is included in every message format
diagram and fields that are not used in a message are marked
as ``unused''. As an alternative, the unused fields could
be labeled ``unused'' in the format diagram.
9.1. DHCP Solicit Message Format
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 1 |C|P| reserved | prefix-len | solicit-ID | | msg-type = 1 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | |
| client-link-local-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay-address | | |
| server-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C If set, the client requests that all servers receiving preference
the message deallocate the releasable resources (e.g. (unused) MUST be 0
IP addresses) associated with the client's binding.
P If set, the client requests that all servers receiving
the message SHOULD return a list of subnet prefix
extensions identifying the networks on the client's
link that the server(s) are configured to manage.
reserved 0
prefix-len
An unsigned 7 bit number (0-127) non-zero prefix-len is
the number of leftmost bits of the agent's IPv6 address
which make up the subnet prefix. The prefix-len field
is set by the relay if the relay receives the Solicit
message and forwards it to one or more servers.
solicit-ID transaction-ID
An unsigned 9 bit number (0-511) generated by the An unsigned integer generated by the client used to
client used to identify this Solicit message. identify this Solicit message.
client's link-local address client-link-local-address
The IP link-local address of the client interface The link-local address of the interface for which the
through which the client will issue the Solicit client is using DHCP.
message.
relay-address server-address (unused) MUST be 0
Set by the client to be zero. If received by a relay,
set by the relay to the site-local IP address of the
interface on which the relay received the client's
Solicit message. Note that if the DHCP domain crosses
site boundaries, the relay MUST place a globally-scoped
address in this field.
A client MUST send the Solicit message to the All-DHCP-Agents
multicast group (see section 3.1), setting the relay-address to zero.
9.2. DHCP Advertise Message Format 9.2. DHCP Advertise Message Format
A server sends an Advertise message in response to a client's
Solicit message. The Advertise message notifies the client of the
server's IP address. If the server is so configured by the network
administrator and the client requests it through the ``P'' bit in
its Solicit message, the server SHOULD add a list of subnet prefix
extensions to the Advertise message to notify the client of the
networks it manages on the client's link.
When the client and server are on different links, the server sends
the Advertise message back through the relay whence the corresponding
Solicit came. The solicit-ID is copied from the client's Solicit
Message. The value of all fields in the Advertise message are filled
in by the server and not changed in any way by any intervening relay.
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 2 | reserved | solicit-ID | preference | | msg-type = 2 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay-address | | |
| client-link-local-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address | | server-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ... | | options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0
solicit-ID An unsigned 9 bit number (0-511) used to identify preference An unsigned integer indicating a server's willingness
this Advertise message. Copied from the client's
Solicit message.
preference An octet (unsigned) indicating a server's willingness
to provide service to the client. to provide service to the client.
client's link-local address transaction-ID An unsigned integer used to identify this Advertise
message. Copied from the client's Solicit message.
client-link-local-address
The IP link-local address of the client interface The IP link-local address of the client interface
from which the client issued the Solicit message. from which the client issued the Solicit message.
relay-address
The IP address of the relay interface on the same
link as the client. Copied from the client's
Solicit. If the server is on the same link as the
client, then this field MUST be zero.
server-address server-address
The site-local IP address of the server. If the DHCP The IP address of the server. If the DHCP domain
domain crosses site boundaries, then this address crosses site boundaries, then this address MUST be
MUST be globally-scoped. globally-scoped.
extensions See the ``extensions document'' for details [2]. options Options are described elsewhere in this document
See Sections 14.4 and 15.3 for information about how clients and See Sections 14.4 and 15.3 for information about how clients and
servers handle the preference field. servers handle the preference field.
9.3. DHCP Request Message Format 9.3. DHCP Request Message Format
A client sends a Request message to request configuration parameters
from a server. It MAY append appropriate extensions [2].
When a client reboots, it often does not have a valid IP address of
sufficient scope for the server to communicate with the client. In
such cases, the client MUST NOT unicast the message to the server
because the server could not return a response to the client. The
client MUST send the message to the server indirectly, by using the
on-link relay. The client MUST fill in the relay address field with
the on-link relay's IP address.
If the Request message is being formed in response to a
Reconfigure-init message from the server, then the transaction ID
used must be copied from the Reconfigure-init.
All fields in the DHCP Request message are entered by the client.
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 3 |C|R| reserved | transaction-ID | | msg-type = 3 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay-address | | |
| client-link-local-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address | | server-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | | options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C If set, the client requests the server to remove
all releasable resources associated with the client
binding, except those releasable resources provided as
extensions.
R If set, the client has rebooted and requests that the preference
server clear any transaction-ID cache entries for the (unused) MUST be 0
client.
reserved 0
transaction-ID transaction-ID
An unsigned integer identifier used to identify this An unsigned integer generated by the client used to
request. identify this Request message.
client's link-local address client-link-local-address
The link-local address of the client interface from The link-local address of the client interface from
which the client will issue the Request message. which the client will issue the Request message.
relay-address
The IP address of a relay's interface, copied from an
Advertise message. If the server is on the same link
as the client, then this field MUST BE zero.
server-address server-address
The IP address of the server to which the the client's The IP address of the server to which the the client's
Request message is directed, copied from an Advertise Request message is directed, copied from an Advertise
message. message.
extensions options
See the ``extensions document'' [2]. Options are described elsewhere in this document.
A DHCP client selects the transaction-ID from the range of
1024--65535 used to identify its Request. In contrast, a
transaction-ID from the range of 0--1023is selected by a DHCP server
to identify a Reconfigure-init. In the latter case, the transaction
ID from the Reconfigure-init is copied by the client into its Request
message.
When the client sets the `C' bit and adds extensions documenting
the releasable resources the client wishes to keep, the server is
expected to deallocate all other releasable resources not listed.
The server SHOULD examine the included extensions to check whether
the client is still authorized to use them.
9.4. DHCP Reply Message Format 9.4. DHCP Reply Message Format
A server sends a Reply message in response to a client's Request
message or Release message.
If a Request message is received which contains a non-zero relay
address field, then the client could not unicast the Request message
to the server and thus had to use a on-link relay. In that case, the
server unicasts the Reply message to the relay address found in the
Request message.
If a Release message is received which contains a non-zero relay
address field, then the client will not have an IP address of
sufficient scope after the Release to receive the Reply message. In
this case, the server unicasts the Reply message to the relay address
found in the Release message.
All the fields in the DHCP Reply message are set by the DHCP server.
0 1 2 3 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 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 = 4 |R| status | transaction-ID | | msg-type = 4 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | |
| client-link-local-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| relay-address (if present) | | |
| server-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | | options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R If set, the ``relay-address'' field is present.
status preference An unsigned integer indicating a server's willingness
This 7-bit field contains one of the values in the to provide service to the client.
errors table in section 3.4.
transaction-ID transaction-ID
Copied from the client's Request or Release. An unsigned integer used to identify this Reply
message. Copied from the client's Request message.
client's link-local address
Copied from the client's Request or Release message.
relay-address
The IP address of a relay's interface, copied from the
Request or Release message. If the server is on the
same link as the client, then the ``R'' bit is not set
and this field is not present.
extensions client-link-local-address
See the ``extensions document'' [2]. The link-local address of the interface for which the
9.5. DHCP Release Message Format client is using DHCP.
A client sends a Release message to a server when it wishes to return server-address
one or more releasable resources to the server which allocated The IP address of the server. If the DHCP domain
them. This can occur either because the client no longer needs the crosses site boundaries, then this address MUST be
resource(s) or the client has determined through a resource-specific globally-scoped.
manner that the resource(s) are already in use by different
client(s). The client communicates the reason for the premature
release of the resource in the status field of the resource's
extension. See ``extensions document'' [2] for more details.
When a client sends a Release message, it needs to have a valid IP options
address with sufficient scope to allow access by the target server. Options are described elsewhere in this document.
If such an address is not available, a relay is used. Only those
releasable resources identified by extensions are released. If no
extensions are included in the Release message, then all releasable
resources associated with the client's binding are to be released.
The values of all fields of the Release message are set by the 9.5. DHCP Release Message Format
client. The DHCP server acknowledges the Release message by sending
a Reply message.
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 5 |R| reserved | transaction-ID | | msg-type = 5 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client's link-local address | | |
| client-link-local-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address | | server-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-address | | options (variable number and length) .... |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R If set, the ``X-address'' field contains the address of
relay. If not set, the ``X-address'' field contains a
non-local scope client address.
reserved 0 preference (unused) MUST be 0
transaction-ID transaction-ID
An unsigned integer identifier used to identify this An unsigned integer generated by the client used to
Release message. identify this Release message.
client's link-local address
The client's link-local address for the interface
from which the client issued the Release message (and
to which the releasable resources are bound at the
server).
server-address P (unused) MUST be 0
The IP address of the server which allocated the
resource.
X-address client-link-local-address
If the ``R'' bit is set, the ``X-address'' field The client's link-local address for the interface from
contains the IP address of the relay interface on the which the client issued the Release message.
same link as the client. If the ``R'' bit is not set,
this field contains a non-link-local IP address of the
client interface from which the the client issued the
Release message.
extensions See the ``extensions document'' [2]. server-address
The IP address of the server that assigned the
addresses.
A client selects the transaction-ID from the range of options See section 22.
1024--65535 used to identify the Release message.
A client MUST NOT specify an IP address in the client-address field
that it is releasing in the extensions field.
9.6. DHCP Reconfigure Message Format 9.6. DHCP Reconfigure Message Format
A server sends a Reconfigure message when it wishes to inform one or The Reconfigure message has been deleted (see section 23.2).
more clients of new or updated values for configuration parameters.
The new configuration parameters are carried in the extensions
portion of the Reconfigure message. Note that a Reconfigure message
MUST NOT carry releasable resource extensions.
Reconfigure messages can ONLY be sent to clients which have 9.7. DHCP Reconfigure-reply Message Format
established an IP address of sufficient scope as to be directly
reachable by the server.
Clients acknowledge Reconfigure messages with Reconfigure-reply The Reconfigure-reply message has been deleted (see section 23.2).
messages.
9.8. DHCP Reconfigure-init Message Format
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 6 | reserved | transaction-ID | | msg-type = 8 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address | | server-address |
| (16 octets) | | (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | | options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0
preference (unused) MUST be 0
transaction-ID transaction-ID
An unsigned integer identifier in the range of An unsigned integer generated by the server to identify
0--1023 chosen by the server to identify this this Reconfigure-init message
Reconfigure message.
client-link-local-address
(unused) MUST be 0
server-address server-address
The IP address of the DHCP server issuing the The IP address of the DHCP server issuing the
Reconfigure message. MUST be of sufficient scope to be Reconfigure-init message. MUST be of sufficient scope
reachable by all clients. to be reachable by all clients.
extensions
See the ``extensions document'' [2].
9.7. DHCP Reconfigure-reply Message Format
A client sends a Reconfigure-reply message to acknowledge receipt of
a Reconfigure message from a server.
A Reconfigure-reply message can only be sent if the client has an IP options SHOULD only include an ``Options request option''
address of sufficient scope to contact the server. No interaction (ORO) and/or authentication options. No configuration
with a relay is possible. information SHOULD be included. See section 22 more
information about options.
All fields in the DHCP Reconfigure-reply message are entered by the 9.9. Relay-forward message
client.
0 1 2 3 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 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 = 7 |r| status | transaction-ID | | msg-type TBD | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| client's link-local address | | |
| (16 octets) | | relay-address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| server-address | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r reserved (0)
status
This 7-bit field contains one of the values from the
errors table in section 3.4.
transaction-ID
An unsigned integer identifier copied from the server's
Reconfigure message.
client's link-local address msg-type TBD
The client's link-local address for the interface from
which the client issued the Reconfigure-reply message.
server-address prefix-length
Copied from the Reconfigure message. The length of the prefix in the address in the
9.8. DHCP Reconfigure-init Message Format ``relay-address'' field.
A server sends a Reconfigure-init message when it wishes to notify relay-address
one or more clients of new or updated values for configuration An address assigned to the interface through which the
parameters available on the server. message from the client was received.
Reconfigure-init messages can ONLY be sent to clients which have options MUST include a ``Client message option''; see
established an IP address of sufficient scope as to be directly section 22.4.
reachable by the server.
A ``Reconfigure-init'' serves as a trigger which will cause the 9.10. Server-forward message
clients to initiate a Request/Reply exchange with the server in order
to receive the new information.
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 8 | reserved | transaction-ID | | msg-type TBD | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| server-address | | |
| (16 octets) | | relay-address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| extensions (variable number and length) .... | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reserved 0
transaction-ID msg-type TBD
An unsigned integer identifier in the range of prefix-length
0--1023 chosen by the server to identify this The length of the prefix in the address in the
Reconfigure-init message. ``relay-address'' field.
server-address relay-address
The IP address of the DHCP server issuing the An address identifying the interface through which the
Reconfigure-init message. MUST be of sufficient scope message from the server should be forwarded; copied
to be reachable by all clients. from the ``client-forward'' message.
extensions SHOULD only include an ERE and/or authentication options MUST include a ``Server message option''; see
extensions. No configuration information SHOULD be section 22.5.
included. See the ``extensions document'' [2] for more
information about extensions.
10. DHCP Server Solicitation and Subnet Prefix Discovery
This section describes how a client locates agents (relays and 9.11. Identity association
servers) and how it can learn about the networks on its link that are
managed by these servers. The behavior of client, server, and relay
implementations is discussed, along with the messages they use.
10.1. Solicit Message Validation
Clients MUST silently discard any received Solicit messages. An ``identity-association'' (IA) is a construct through which a
server and a client can identify, group and manage IPv6 addresses.
Each IA consists of a UUID and a list of associated IPv6 addresses
(the list may be empty). A client associates an IA with one of
its interfaces and uses the IA to obtain IPv6 addresses for that
interface from a server.
Agents MUST discard any received Solicit messages if the ``client's 10. DHCP Server Solicitation
link-local address'' field does not contain a valid link-local
address.
Servers MUST discard each received Solicit message which meet the This section describes how a client locates servers. The behavior of
following criteria: client, server, and relay implementations is discussed, along with
the messages they use.
o The ``relay-address'' field does not contain an address of (Prefix advertisements have been deleted; see 23.9.)
sufficient scope that is reachable by the server.
o The ``relay-address'' field is non-zero, but prefix-len is zero. 10.1. Solicit Message Validation
Clients MUST silently discard any received Solicit messages.
Agents MUST silently discard any received Solicit messages if
the ``client-link-local-address'' field does not contain a valid
link-local address.
An error message MAY be logged by the agent. The logging of
such messages SHOULD be controlled by an agent implementation
configuration flag.
10.2. Advertise Message Validation 10.2. Advertise Message Validation
Servers MUST silently discard any received Advertise messages. Servers MUST discard any received Advertise messages.
Clients MUST discard any Advertise messages that meet any of the Clients MUST discard any Advertise messages that meet any of the
following criteria: following criteria:
o The ``Solicit-ID'' field value does not match the value the o The ``Transaction-ID'' field value does not match the value the
client used in its Solicit message. client used in its Solicit message.
o The ``client's link-local address'' field value does not match o The ``client-link-local-address'' field value does not match the
the link-local address of the interface upon which the client link-local address of the interface upon which the client sent
sent the Solicit message. the Solicit message.
Relays MUST discard any Advertise messages that meet any of the
following criteria:
o The ``relay-address'' field does not contain the relay's address
on the same link as the client.
o The ``client's link-local address'' field does not contain a
valid link-local address.
10.3. Client Behavior 10.3. Client Behavior
Clients use the Solicit message primarily to discover DHCP servers Clients use the Solicit message to discover DHCP servers configured
configured to serve networks on the link containing the client. to serve addresses on the link to which the client is attached.
Optionally, the client MAY set the ``P'' bit which has the effect
of requesting that the server return subnet prefix extensions
identifying the networks on the client's link the server is
configured to manage.
10.3.1. Creation and sending of the Solicit message
When creating a Solicit message, the client SHOULD start out with
a buffer initialized with zeroed octets. The client sets the
``msg-type'' field to 1, and places the link-local address of the
interface it wishes to configure in the link-local address field.
If the client is prepared to process multiple Advertise messages (Prefix advertisement by servers has been deleted; see section 23.9.)
in response to its Solicit message, the client will set the
Solicit-ID field to 1. Every time the client initiates a new server
solicitation attempt (not a retransmission), the client increments
the Solicit-ID by one. If the 9-bit field rolls over to 0, then the
client sets the Solicit-ID to 1. A client which will only accept
the first Advertise message it receives leaves the Solicit-ID field
initialized to zero.
The ``C'' bit of the Solicit message is set by the client when the 10.3.1. Creation and sending of the Solicit message
client has no cached knowledge of previous DHCP configuration for the
interface. Setting this bit requests that the server release any
information assigned to the client for the networks on the client's
link.
If the client desires to learn of the networks managed by DHCP on The client sets the ``msg-type'' field to 1, and places the
the link its interface is attached to, it sets the ``P'' bit in the link-local address of the interface it wishes to configure in the
Solicit message. ``client-link-local-address'' field. The client sets all other
fields to zero.
The client transmits the Solicit message to the FF02::1:2 (All DHCP The client sends the Solicit message to the FF02::1:2 (All DHCP
Agents) multicast address, destination port 547. The source port Agents) multicast address, destination port 547. The source port
selection can be arbitrary, although it SHOULD be possible using a selection can be arbitrary, although it SHOULD be possible using a
client configuration facility to set a specific source port value. client configuration facility to set a specific source port value.
10.3.2. Time out and retransmission of Solicit Messages 10.3.2. Time out and retransmission of Solicit Messages
The client's first Solicit message on the interface MUST be delayed The client's first Solicit message on the interface MUST be delayed
by a random amount of time between the interval of MIN_SOL_DELAY and by a random amount of time between the interval of MIN_SOL_DELAY and
MAX_SOL_DELAY. This random delay desynchronizes clients which start MAX_SOL_DELAY. This random delay desynchronizes clients which start
at the same time (e.g., after a power outage). at the same time (e.g., after a power outage).
skipping to change at page 27, line 38 skipping to change at page 23, line 19
criteria. criteria.
- Those Advertise messages with the highest server preference - Those Advertise messages with the highest server preference
value (see section 14.4) are preferred over all other Advertise value (see section 14.4) are preferred over all other Advertise
messages. messages.
- Within a group of Advertise messages with the same server - Within a group of Advertise messages with the same server
preference value, a client MAY select those servers whose preference value, a client MAY select those servers whose
Advertise messages advertise information of interest to Advertise messages advertise information of interest to
the client. For example, one server may be advertising the the client. For example, one server may be advertising the
availability of IP addresses on networks which have an address availability of IP addresses which have an address scope of
scope of interest to the client. interest to the client.
Once a client has selected Advertise message(s), the client will Once a client has selected Advertise message(s), the client will
typically store information about each server, such as relay address typically store information about each server, such as server
and prefix length, server preference value, networks advertised, preference value, addresses advertised, when the advertisement was
when the advertisement was received, and so on. Depending on the received, and so on. Depending on the requirements of the client's
requirements of the client's invoking user, the client MAY initiate a invoking user, the client MAY initiate a configuration exchange with
configuration exchange with the server(s) immediately, or MAY defer the server(s) immediately, or MAY defer this exchange until later.
this exchange until later.
10.4. Relay Behavior 10.4. Relay Behavior
For this discussion, the Relay is assumed to have been configured For this discussion, the Relay may be configured to use a list of
with some list of server destination addresses, which may be unicast, server destination addresses, which may include unicast addresses,
the FF05::1:3 (All DHCP Servers) multicast address, or some other the FF05::1:3 (All DHCP Servers) multicast address, or other
multicast address selected by the network administrator. multicast addresses selected by the network administrator. If
the Relay has not been explicitly configured, it will use the
FF05::1:3 (All DHCP Servers) multicast address as the default.
10.4.1. Relaying of Solicit messages 10.4.1. Relaying of Solicit messages
When a Relay receives a valid Solicit message, it places the IP When a Relay receives a valid Solicit message, it constructs a
address of the interface upon which it received the Solicit message Relay-forward message. The client Solicit message is carried as the
in the ``relay-address'' field of the Solicit. The Relay also places payload of a ``client-message'' option. The relay places an address
the number of bits of that make up the subnet prefix for this address from the interface on which the Solicit message was received in the
in the ``prefix-len'' field of the Solicit. ``relay-address'' field and the prefix length for that address in
the ``prefix-length'' field. The Relay then sends the Relay-forward
message to the list of server destination addresses that it has been
configured with.
The Relay then forwards this Solicit to the list of server
destination addresses that it has been configured with.
10.4.2. Relaying of Advertise messages 10.4.2. Relaying of Advertise messages
When a Relay receives a valid Advertise message, it unicasts the When the relay receives a Relay-reply message, it extracts the server
message to the link-local address found in the ``client's link-local message from the ``server-message'' option and forwards the server
address'' field by way of the appropriate network interface. message to the address in the client-link-local-address field in
the server message. The relay forwards the server message through
the interface identified in the ``relay-address'' field in the
Relay-reply message.
10.5. Server Behavior 10.5. Server Behavior
For this discussion, the Server is assumed to have been configured in For this discussion, the Server is assumed to have been configured in
an implementation specific manner. This configuration is assumed to an implementation specific manner. This configuration is assumed to
contain all network topology information for the DHCP domain, as well contain all network topology information for the DHCP domain, as well
as any necessary authentication information. as any necessary authentication information.
10.5.1. Receipt of Solicit messages 10.5.1. Receipt of Solicit messages
Upon the receipt of a valid Solicit message, the server first If the server receives a Solicit message, the client must be on the
identifies the client's location within the DHCP domain. If the same link as the server. If the server receives a Relay-forward
``relay-address'' and / or ``prefix-len'' fields of the Solicit are message containing a Solicit message, the client must be on the
zeroed, then the client is attached to the same link as the server. link to which the prefix identified by the ``relay-address'' and
If these fields are non-zero, then the client exists on the same link ``prefix-length'' fields in the Relay-forward message is assigned.
as the network identified by these two fields. The server records the ``relay-address'' field from the Relay-forward
message and extracts the solicit message from the ``client-message''
option.
If administrative policy permits the server to respond to a client on If administrative policy permits the server to respond to a client on
that link, the server will generate and send an Advertise message to that link, the server will generate and send an Advertise message to
the client. the client.
10.5.2. Creation and sending of Advertise messages 10.5.2. Creation and sending of Advertise messages
When creating an Advertise message, the server SHOULD start out The server sets the ``msg-type'' field to 2 and copies the values
with a buffer initialized with zeroed octets. The server sets the of the following fields from the client's Solicit to the Advertise
``msg-type'' field to 2 and copies the values of the following fields message:
from the client's Solicit to the Advertise message:
o solicit-ID
o client's link-local address o transaction-ID
o relay-address o client-link-local-address
The server places one of its IP addresses (determined through The server places one of its IP addresses (determined through
administrator setting) in the ``server-address'' field of the administrator setting) in the ``server-address'' field of the
Advertise message. The server initializes the ``preference'' Advertise message. The server sets the ``preference'' field
field from its configuration information. See section 15.3 for a according to its configuration information. See section 15.3 for a
description of server preference. description of server preference.
If the client requests subnet prefix extensions (by setting the ``P'' If the Solicit message was received in a Relay-forward message, the
bit in its Solicit) and the server implements and is configured to server constructs a Relay-reply message with the Advertise message
provide prefix extensions, the server will generate and insert a in the payload of a ``server-message'' option. The server unicasts
subnet prefix extension for each network on the client's link it is the Relay-reply message to the address in the ``relay-address'' field
configured to manage. from the Relay-forward message.
If the Solicit message was received directly by the server, the
server unicasts the Advertise message directly to the client using
the ``client-link-local-address'' field value as the destination
address. The Advertise message MUST be unicast through the interface
on which the Solicit message was received.
DISCUSSION:
(From Ted Lemon) There is a danger in using Solicit versus
DHCPDISCOVER: in the Solicit paradigm, the client has to
choose the DHCP server before it knows if the DHCP server
will give it an IP address, or which addresses the server is
willing to assign to the client. It may be that there are
two or more DHCP servers owned by the same administrative
domain, and both are theoretically willing to give the
client addresses, but only one actually has any addresses to
give.
If the ``relay-address'' field of the Advertise message is zero, then
the server unicasts the Advertise message directly to the client
using the ``client's link-local address'' field value as destination
address. If the ``relay-address'' field is non-zero, then the server
unicasts the Advertise message directly to the relay using the
``relay-address'' field value as the destination address.
11. DHCP Client-Initiated Configuration Exchange 11. DHCP Client-Initiated Configuration Exchange
A client initiates a configuration exchange with one or more servers A client uses the Request-Reply message exchange to acquire
it has found through DHCP server solicitation whenever requested to configuration information of interest. The client may initiate the
do so by the application layer in order to acquire configuration configuration exchange as part of the operating system configuration
information of interest. process or when requested to do so by the application layer.
A client uses the Release-Reply message exchange to indicate to the
DHCP server that the client will no longer be using the addresses in
the released IA.
11.1. Request Message Validation 11.1. Request Message Validation
Clients MUST silently discard any received Request messages. Clients MUST silently discard any received Request messages.
Agents MUST discard any Request messages in which the ``client's Agents MUST discard any Request messages in which the
link-local address'' field does not contain a valid link-local ``client-link-local-address'' field does not contain a valid
address. link-local address.
Relays MUST discard any received Request messages in which the
``relay-address'' field value does not match any of the relay's
addresses.
Servers MUST discard any received Request message which meets any of Servers MUST discard any received Request message which meets any of
the following criteria: the following criteria:
o The ``server-address'' field value does not match any of the o The ``server-address'' field value does not match any of the
server's addresses. server's addresses.
o If the ``relay-address'' field is set, and that field's value o The ``options'' field contains an authentication option, and the
does not contain an address of sufficient scope as to be server cannot successfully authenticate the client.
reachable by the server.
o The ``extensions'' field contains an authentication extension,
and the server cannot successfully authenticate the client.
11.2. Reply Message Validation 11.2. Reply Message Validation
Servers MUST silently discard any received Reply messages. Servers MUST silently discard any received Reply messages.
Clients MUST discard any Reply message that meets any of the Clients MUST discard any Reply message that meets any of the
following criteria: following criteria:
o The ``transaction-ID'' field value does not match the value the o The ``transaction-ID'' field value does not match the value the
client used in its Request or Release message. client used in its Request or Release message.
o The ``client's link-local address'' field value does not match o The ``client-link-local-address'' field value does not match the
the link-local address of the interface upon which the client link-local address of the interface upon which the client sent in
sent in its Request or Release message. its Request or Release message.
o The Reply message contains an authentication extension, and the o The Reply message contains an authentication option, and the
client's attempt to authenticate the message fails. client's attempt to authenticate the message fails.
Relays MUST discard any Reply message that meets any of the following Relays MUST discard any Relay-reply message in which the
criteria: ``client-link-local-address'' in the encapsulated Reply message does
not contain a valid link-local address.
o The ``R'' bit isn't set.
o The ``relay-address'' field value does not contain the relay's
address on the same link as the client.
o The ``client's link-local address'' field value does not contain
a valid link-local address.
11.3. Release Message Validation 11.3. Release Message Validation
Clients MUST silently discard any received Release messages. Clients MUST silently discard any received Release messages.
Agents MUST discard any Release message that meets any of the Agents MUST discard any Release message in which the
following criteria: ``client-link-local-address'' field does not contain a valid
link-local address.
o The ``transaction-ID'' field contains a value not in the
1024--65535 range.
o The ``client's link-local address'' field does not contain a
valid link-local address.
Relays MUST discard any received Release message that meets any of
the following criteria:
o The ``R'' bit is not set.
o The ``X-address'' field value does not match any of the relay's
addresses.
Servers MUST discard any received Release message which meets any of
the following criteria:
o The ``X-address'' field does not contain an address of sufficient Servers MUST discard any received Release message in which the
scope as to be reachable by the server. ``options'' field contains an authentication option, and the server
cannot successfully authenticate the client.
o The ``extensions'' field contains an authentication extension,
and the server cannot successfully authenticate the client.
11.4. Client Behavior 11.4. Client Behavior
A client will generate one or more Request messages when prompted by A client will generate one or more Request messages to acquire
the application layer in order to acquire configuration information. configuration information. A client may initiate such an exchange
A client may initiate such an exchange automatically in order to automatically in order to acquire the necessary network parameters
acquire the necessary network parameters to communicate with nodes to communicate with nodes off-link. The client uses the server
off-link. The client uses the server and relay address information address information from previous Advertise message(s) for use in
from previous Advertise message(s) for use in delivering Request constructing Request message(s). Note that a client may request
message(s). Note that a client may request configuration information configuration information from one or more servers at any time.
from one or more servers at any time.
A client uses the Release message in the management of releasable A client uses the Release message in the management of IAs when:
resources when:
o The client has determined through a resource-specific manner o The client has determined through DAD or some other method that
that the resource assigned by the server is already in use by a one or more of the addresses assigned by the server in the IA is
different client. already in use by a different client.
o The client has been instructed to release the IA prior to the IA
expiration time since it is no longer needed.
o The client has been instructed to release the resource prior to
the lease expiration time since it is no longer needed.
11.4.1. Creation and sending of Request messages 11.4.1. Creation and sending of Request messages
When creating a Request message, the client SHOULD start out with The client sets the ``msg-type'' field to 3, and places the
a buffer initialized with zeroed octets. The client sets the link-local address of the interface it wishes to acquire
``msg-type'' field to 3, and places the link-local address of the configuration information for in the ``client-link-local-address''
interface it wishes to associate with the configuration information field.
with in the ``client's link-local address'' field.
Unless the Request message is created in response to a The client generates a transaction ID inserts this value in the
Reconfigure-init message, the client generates a transaction
ID in the range of 1024--65535 and inserts this value in the
``transaction-ID'' field. ``transaction-ID'' field.
The client places the address of the destination server in the The client places the address of the destination server in the
``server-address'' field. ``server-address'' field.
If the client is not on the same link as the destination The client adds any appropriate options, including one or more IA
server, the client places the appropriate relay's address in the options (if the client is requesting that the server assign it some
``relay-address'' field. network addresses). If the client does include any IA options,
it MUST include the list of addresses the client currently has
If the client is acquiring configuration information on the interface associated with that IA. If the client is requesting configuration of
for the first time, the client SHOULD set the ``C'' bit in the a new IA, the list of addresses MUST be empty.
header. How the client determines if this is the first configuration
attempt on the interface is implementation-specific. A client may
implement a cache of configuration information on a per-interface
basis; if that cache does not exist, that client would set the
``C'' bit. Clients which do not implement caching of per-interface
configuration information MUST always set the ``C'', and include
any extensions carrying releasable resources received from earlier
configuration exchanges in the extensions field of the Request.
If the client has determined through an implementation-specific
manner that the client implementation itself has restarted, it MUST
set the ``R'' bit in the header. After the first successful exchange
with the server, the client MUST NOT set the ``R'' bit in subsequent
Request messages.
Client considerations for extensions are now considered (see the
``extensions document'', [2] for more details).
If the client already has an IP address of sufficient scope to
directly reach the server, then the client SHOULD unicast the Request
to the server. Otherwise, if the server is off-link, the client
unicasts the Request message to the appropriate relay.
11.4.2. Time out and retransmission of Request Messages 11.4.2. Time out and retransmission of Request Messages
The client waits REP_MSG_TIMEOUT milliseconds, collecting The server will respond to the Request message with a Reply
Reply messages. If no Reply messages are received, the client message. If no Reply message is received within REP_MSG_TIMEOUT
retransmits the Request with the same transaction-ID, and doubles milliseconds, the client retransmits the Request with the same
the REP_MSG_TIMEOUT value, and waits again. The client continues transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits
this process until a Reply is received or REQUEST_MSG_ATTEMPTS again. The client continues this process until a Reply is received
unsuccessful attempts have been made, at which time the client MUST or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
abort the configuration attempt. The client SHOULD report the abort which time the client MUST abort the configuration attempt. The
status to the application layer. client SHOULD report the abort status to the application layer.
Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
are documented in section 3.5. are documented in section 3.5.
11.4.3. Receipt of Reply message in response to a Request 11.4.3. Receipt of Reply message in response to a Request
Upon the receipt of a valid Reply message, the client extracts the Upon the receipt of a valid Reply message, the client extracts the
configuration information contained in the Reply. If the ``status'' configuration information contained in the Reply. If the ``status''
field contains a non-zero value, the client reports the error status field contains a non-zero value, the client reports the error status
to the application layer. to the application layer.
If the extensions field contains one or more ``Reconfigure Multicast The client records the T1 and T2 times for each IA in the Reply
Address'' extensions (see ``extensions document'', ``Reconfigure message. The client records any addresses included with IAs in
Multicast Address Extension'' section [2]), the client MUST join the Reply message. The client updates the preferred and valid
these multicast groups, and MUST monitor the UDP 546 port for lifetimes for the addresses in the IA from the lifetime information
Reconfigure or Reconfigure-init messages on the networks configured in the IA option. The client leaves any addresses that the client
by DHCP. has associated with the IA that are not included in the IA option
unchanged.
If the configuration information returned in the Reply contains Management of the specific configuration information is detailed in
releasable resources, then the client MUST take over lease management the definition of each option, in section 22.
of the resource. A client MUST NOT request releasable resources
unless it is prepared to appropriately manage the resource lease.
11.4.4. Creation and sending of Release messages
When creating a Release message, the client SHOULD start out with 11.4.4. Creation and sending of Release messages
a buffer initialized with zeroed octets. The client sets the
``msg-type'' field to 5, and places the link-local address of the
interface the configuration information it wishes to release is
associated with in the ``client's link-local address'' field.
The client generates a transaction ID in the range of The client sets the ``msg-type'' field to 5, and places the
1024--65535 and inserts this value in the ``transaction-ID'' link-local address of the interface associated with the configuration
information it wishes to release in the ``client-link-local-address''
field. field.
The client includes extensions containing the releasable resources it The client generates a transaction ID and places this value in the
is releasing in the ``extensions'' field. The appropriate ``status'' ``transaction-ID'' field.
field in the extensions MUST be set to indicate the reason for the
release.
The client places the IP address of the server who allocated the The client includes options containing the IAs it is releasing in the
resource(s) in the ``server-address'' field. ``options'' field. The appropriate ``status'' field in the options
MUST be set to indicate the reason for the release.
If the client will have an appropriately scoped IP address after the The client places the IP address of the server that allocated the
release transaction is completed, the client clears the ``R'' bit address(es) in the ``server-address'' field.
and places this address in the ``X-address'' field. If the client
will not have an appropriately scoped IP address after the release
transaction is completed, the client sets the ``R'' bit and places
the address of the appropriate relay in the ``X-address'' field.
If the client is configured to use authentication, the client If the client is configured to use authentication, the client
generates the appropriate authentication extension, and adds this generates the appropriate authentication option, and adds this option
extension to the ``extensions'' field. Note that the authentication to the ``options'' field. Note that the authentication option MUST
extension MUST be the last extension in the ``extensions'' be the last option in the ``options'' field. See section 22.7 for
field. See the ``extension document'' for more details about the more details about the authentication option.
authentication extension [2].
(The client always forwards Release messages to the server through a
relay; see section 11.5.)
If the ``R'' bit is set, then the client MUST unicast the Release
to the relay indicated in the ``X-address'' field. Otherwise, the
client unicasts the Release message directly to the server indicated
in the ``server-address'' field.
11.4.5. Time out and retransmission of Release Messages 11.4.5. Time out and retransmission of Release Messages
The client waits REP_MSG_TIMEOUT milliseconds, collecting Reply If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
messages. If no Reply messages are received, the client retransmits the client retransmits the Release, doubles the REP_MSG_TIMEOUT
the Release, and doubles the REP_MSG_TIMEOUT value, and waits again. value, and waits again. The client continues this process until a
The client continues this process until a Reply is received or Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been
REL_MSG_ATTEMPTS unsuccessful attempts have been made, at which made, at which time the client SHOULD abort the release attempt.
time the client SHOULD abort the release attempt. The client The client SHOULD return the abort status to the application, if an
SHOULD return the abort status to the application, if an application application initiated the release.
initiated the release.
Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented in section 3.5. are documented in section 3.5.
Note that if the client fails to release the resource, the resource Note that if the client fails to release the IA, the addresses
will be reclaimed by the server when the lease associated with it assigned to the IA will be reclaimed by the server when the lease
expires. associated with it expires.
11.4.6. Receipt of Reply message in response to a Release 11.4.6. Receipt of Reply message in response to a Release
Upon receipt of a valid Reply message, the client can consider the Upon receipt of a valid Reply message, the client can consider the
Release event successful, and SHOULD return the successful status to Release event successful, and SHOULD return the successful status to
the application layer, if an application initiated the release. the application layer, if an application initiated the release.
11.4.7. When a client should send a Request message
The description of the Request/Reply message exchange in this section
makes no assumptions about the timing or state of the client when
it initiates a Request/Reply message exchange. Sections 11.4.8
through 11.4.10 describe when a client MAY initiate a Request/Reply
message exchange. The procedures for timeout and retransmission of
Request messages are described in section 11.4.2.
11.4.8. Initialization
If a client has no valid IPv6 addresses of sufficient scope to
communicate with a DHCP server, it may a Request message to obtain
new addresses. The client includes one or more IAs in the Request
message, to which the server assigns new addresses. The server then
returns to IA(s) to the client in a Reply message.
11.4.9. Confirming the validity of IPv6 addresses
Whenever a client may have moved to a new link, its IPv6 addresses
may no longer be valid. Examples of times when a client may have
moved to a new link include:
o The client reboots
o The client is physically disconnected from a wired connection
o The client returns from sleep mode
o The client using a wireless technology changes cells
In any situation when a client may have moved to a new link, the
client MUST initiate a Request/Reply message exchange. The client
includes any IAs, along with the addresses associated with those IAs,
in its Request message. The server returns the IAs with updated list
of addresses and associated lifetimes.
11.4.10. Extending the lifetimes on IPv6 addresses
IPv6 addresses assigned to a client through an IA use the same
preferred and valid lifetimes as IPv6 addresses obtained through
stateless autoconfiguration. The server assigns preferred and valid
lifetimes to the IPv6 addresses it assigns to an IA. To extend those
lifetimes, the client sends a Request to the server containing an
``IA option'' for the IA and its associated addresses. The server
determines new lifetimes for the addresses in the IA according to
the server's administrative configuration. The server may also add
new addresses to the IA. The server remove addresses from the IA by
setting the preferred and valid lifetimes of those addresses to zero.
The server controls the time at which the client contacts the server
to extend the lifetimes on assigned addresses through the T1 and
T2 parameters assigned to an IA. If the server does not assign an
explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the
shortest preferred lifetime of any address assigned to the IA and
T2 defaults to 0.875 times the shortest preferred lifetime of any
address assigned to the IA.
At time T1 for an IA, the client initiates a Request/Reply message
exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned
to the IA in its Request message. The client unicasts this Request
message to the server that originally assigned the addresses to the
IA.
At time T2 for an IA (which will only be reached if the server to
which the Request message was sent at time T1 has not responded),
the client initiates a Request/Reply message exchange. The client
includes an IA option with all addresses currently assigned to the
IA in its Request message. The client multicasts this message to
the FF02::1:2 (All DHCP Agents) multicast address.
11.5. Relay Behavior 11.5. Relay Behavior
11.5.1. Relaying of Request or Release messages 11.5.1. Relaying of Request or Release messages
When a Relay receives a valid Request or Release message, it forwards When a Relay receives a valid Request or Release message, it
it to the IP address found in the ``server-address'' field of the constructs a Relay-forward message. The client message is carried
message. as the payload of a ``client-message'' option. The relay places an
address from the interface on which the client message was received
in the ``relay-address'' field and the prefix length for that
address in the ``prefix-length'' field. The Relay then forwards the
Relay-forward message to the list of server destination addresses
that it has been configured with.
11.6. Server Behavior 11.6. Server Behavior
For this discussion, the Server is assumed to have been configured For this discussion, the Server is assumed to have been configured in
in an implementation specific manner with configuration of interest an implementation specific manner with configuration of interest to
to clients. Such configuration information MAY contain releasable clients.
resources such as IP addresses.
11.6.1. Receipt of Request messages 11.6.1. Receipt of Request messages
Upon the receipt of a valid Request message from a client the server Upon the receipt of a valid Request message from a client the server
can respond to, (implementation-specific administrative policy can respond to, (implementation-specific administrative policy
satisfied) the server scans the extensions field. satisfied) the server scans the options field.
If the client has set the ``C'' bit, the server MUST release all
releasable resources currently associated with the client's binding
that do not appear in the ``extensions'' field.
If the client has set the ``R'' bit, the server MUST delete any
transaction-ID cache entries it is maintaining for this client, if
the server implements such a cache.
Server considerations for extensions are now evaluated (see the The server then constructs a Reply message and sends it to the
``extensions document'', [2] for more details). client.
If the configuration information to be returned to the client DISCUSSION:
includes releasable resources, the server checks if a binding
already exists for the client. If so, the server examines the
data records within the binding to determine if the client's
Request is a retransmission of an earlier Request or a new Request.
Releasable resource identifiers are stored within the binding with
the transaction-ID used by the client to request the resource's
assignment. If the transaction-ID's match, this is a retransmission
and the server simply return the contents of the client's binding
which satisfy its request. If the transaction-ID's do not match,
the server records the additional resources it is assigning in the
existing binding with the new Request's transaction-ID.
If the client does not have an existing binding, the server creates a This section needs text about managing IAs and determining
binding for the client and records the resources it is assigning in options to be returned to client.
this binding along with the transaction-ID from the client's Request.
The server then constructs a Reply message and sends it to the
client.
11.6.2. Receipt of Release messages 11.6.2. Receipt of Release messages
Upon the receipt of a valid Release message, the server performs a Upon the receipt of a valid Release message, the server examines the
lookup to find the client's binding. If the binding is found, the IAs and the addresses in the IAs for validity. If the IAs in the
server examines the binding to see if the resource(s) identified by message are in a binding for the client and the addresses in the IAs
the client in the Release message's extensions field are in fact have been assigned by the server to those IA, the server deletes
assigned to the client. If they are, the server deletes these the addresses from the IAs and makes the addresses available for
resources from the client's binding, making them available to other assignment to other clients.
clients.
The server then generates a Reply message. If a binding was The server then generates a Reply message. If all of the IAs were
found and the resources presented to the server were deleted from valid and the addresses successfully released,, the server sets the
the client's binding, the server sets the ``status'' field to ``status'' field to ``Success''. If any of the IAs were invalid or
``Success''. If no binding is found, the server sets the ``status'' if any of the addresses were not successfully released, the server
releases none of the addresses in the message and sets the ``status''
field to ``NoBinding''(section 3.4). field to ``NoBinding''(section 3.4).
DISCUSSION:
What is the behavior of the server relative to a ``partially
released'' IA; i.e., an IA for which some but not all
addresses are released?
Can a client send an empty IA to release all addresses in
the IA?
If the IA becomes empty - all addresses are released - can
the server discard any record of the IA?
11.6.3. Creation and sending of Reply messages 11.6.3. Creation and sending of Reply messages
When creating a Reply message, the server SHOULD start out with DISCUSSION:
a buffer initialized with zeroed octets. The server sets the
``msg-type'' field to 4 and copies the values of the following fields XXX - This section needs to be fixed (see section 11.6.1).
from the client's Request or Release to the Reply message:
The server sets the ``msg-type'' field to 4 and copies the values
of the following fields from the client's Request or Release to the
Reply message:
o transaction-ID o transaction-ID
o client's link-local address o client's link-local address
o If the client's message is a Request with a non-zero o server-address
``relay-address'' field value, the server sets the ``R'' bit in
the Reply and copies the ``relay-address'' field value from the
Request to the Reply. If the client's message is a Release with
the ``R'' bit set, the server sets the ``R'' bit in the Reply and
sets the ``relay-agent'' field to the contents of the Release's
X-address field.
The server sets the ``status'' field appropriately (see the table The server sets the ``status'' field appropriately (see the table
in section 3.4) based upon the results of processing the client's in section 3.4) based upon the results of processing the client's
request. request.
If configured to do so, a server will include ``Reconfigure Multicast If the Request or Release message from the client was originally
Address'' extensions (see ``extensions document'', ``Reconfigure received by the server, the server unicasts the Reply message to the
Multicast Address Extension'' [2]), in Reply messages sent in link-local address in the ``client-link-local-address'' field.
response to a Request, informing the client of one or more multicast
groups it should join to facilitate the receipt of Reconfigure or
Reconfigure-init messages.
If the DHCP domain is using authentication, the server will generate
an authentication extension with the appropriate settings and add
that extension as the last extension in the ``extensions'' field of
the Reply message.
If the ``relay-address'' field of the Reply message is zero, then the If the message was originally received in a Forward-request or
server unicasts the Reply directly to the client using the ``client's Forward-release message from a relay, the server places the Reply
link-local address'' field value as destination address. If the message in the options field of a Response-reply message and unicasts
``relay-address'' field is non-zero, then the server unicasts the the message to the relay's address from the original message.
Reply directly to the relay using the ``relay-address'' field value
as the destination address.
If the server implements a transaction-ID cache, the server would add
an entry for the client to this cache.
12. DHCP Server-Initiated Configuration Exchange 12. DHCP Server-Initiated Configuration Exchange
A server initiates a configuration exchange on behalf of the A server initiates a configuration exchange on behalf of the
administrator of the DHCP domain. An administrator may initiate such administrator of the DHCP domain. An administrator may initiate such
an exchange when new networks are added to the domain or existing an exchange when new links are added to the domain or existing links
networks are to be renumbered. Other examples include changes in are to be renumbered. Other examples include changes in the location
the location of directory servers, addition of new services such as of directory servers, addition of new services such as printing, and
printing, and availability of new software (system or application). availability of new software (system or application).
12.1. Reconfigure Message Validation
Agents MUST silently discard any received Reconfigure messages. DISCUSSION:
Clients MUST discard any Reconfigure message that meets any of the Changed ``networks'' to ``links'' here (ed.). Why would
following criteria: adding new links cause a server-initiated configuration
exchange?
o The ``transaction-ID'' field value is not within 12.1. Reconfigure Message Validation
the 0--1023 range.
o The Reconfigure message contains an authentication extension, and Reconfigure messages have been deleted; see section 23.2.
the client's attempt to authenticate the message fails.
12.2. Reconfigure-reply Message Validation 12.2. Reconfigure-reply Message Validation
Clients and Relays MUST silently discard any received Reconfigure-reply messages have been deleted; see section 23.2.
Reconfigure-reply messages.
Servers MUST discard any Reconfigure-reply message that meets any of
the following criteria:
o The ``transaction-ID'' field value is not that same value the
server used in its Reconfigure message.
o The ``server-address'' field value does not match the value the
server placed in its Reconfigure message.
12.3. Reconfigure-init Message Validation 12.3. Reconfigure-init Message Validation
Agents MUST silently discard any received Reconfigure-init messages. Agents MUST silently discard any received Reconfigure-init messages.
Clients MUST discard any Reconfigure-init messages that meets any of Clients MUST discard any Reconfigure-init messages that do
the following criteria: not contain an authentication option or that fail the client's
authentication check.
o The ``transaction-ID'' field value is not within
the 0--1023 range.
o The Reconfigure-init message contains an authentication
extension, and the client's attempt to authenticate the message
fails.
12.4. Server Behavior 12.4. Server Behavior
For this discussion, the server is assumed to have a For this discussion, the server is assumed to have a
implementation-specific interface by which an administrator implementation-specific interface by which an administrator
may initiate a reconfiguration event with some set of clients. may initiate a reconfiguration event with some set of clients.
There are two methods of initiating a reconfiguration event. Each A server sends a Reconfigure-init message to trigger a client to
has its advantages: initiate immediately a Request/Reply message exchange with the
server. A server can send Reconfigure-init messages only to those
Reconfigure with payload clients who have an address of sufficient scope to be reachable by
This method uses the Reconfigure message. Items the server. Thus, those clients who have not requested an IP address
to be changed are included as extensions in the and are off-link cannot be reconfigured by the server.
``extensions'' field. This method MUST NOT be used
to reconfigure releasable resources. Examples of
information which can be reconfigured using this
method are DNS domain and servers, NTP servers, other
name service parameters. The server generates and
sends the Reconfigure message; clients respond with
Reconfigure-reply messages.
Reconfigure Trigger DISCUSSION:
This method uses the Reconfigure-init message. When
a client receives a Reconfigure-init message, it
initiates a Request/Reply exchange with the server.
Any kind of resource can be reconfigured using this
method, including releasable resources. An example
of an releasable resource is an IP address.
A server can send Reconfigure and Reconfigure-init messages only to It would be possible to forward Reconfigure-init messages
those clients who have an address of sufficient scope to be reachable through relays if the server records the client's link-local
by the server. Thus, those clients who have not requested an IP address and the relay's address from the client's Request
address and are off-link cannot be reconfigured by the server. message.
Before initiating a reconfigure process, the server SHOULD be
configured with a REC_THRESHOLD threshold value which represents
the percentage of clients successfully reconfigured before the
reconfigure process is considered a success. See section 3.5 for the
default setting of REC_THRESHOLD. Note that the server MUST be able
to determine the set of clients that should receive the reconfigure,
in order to determine when the reconfigure process is complete.
12.4.1. Creation and sending of Reconfigure messages 12.4.1. Creation and sending of Reconfigure messages
When creating a Reconfigure message, the server SHOULD start out Reconfigure messages have been deleted; see section 23.2.
with a buffer initialized with zeroed octets. The server sets the
``msg-type'' field to 6. The server generates a transaction-ID
from the 0--1023 range and inserts it in the ``transaction-ID''
field. The server places its address (of appropriate scope) in the
``server-address'' field.
The server then generates extensions for the non-releasable resources
to be changed and places them in the ``extensions'' field.
If the DHCP domain is using authentication, the server will generate
an authentication extension with the appropriate settings and add
that extension as the last extension in the ``extensions'' field of
the Reconfigure message.
The server multicasts the Reconfigure message to one or more
Reconfigure Multicast Addresses previously sent as extensions to the
clients. Note that a server MAY unicast Reconfigure message(s) to
specific clients by walking its list of bindings to determine the
unicast address(es) of the clients. Whether or not the Reconfigure
is multicast or unicast is an implementation detail.
A server waits for Reconfigure-reply messages from clients confirming
that they have received the Reconfigure.
12.4.2. Time out and retransmission of Reconfigure messages 12.4.2. Time out and retransmission of Reconfigure messages
The server waits RECREP_MSG_TIMEOUT milliseconds, collecting
Reconfigure-reply messages. If all the expected Reconfigure-reply
messages are received, then the reconfigure process is successful.
If some or all of the expected Reconfigure-reply messages are not
received, then the server retransmits the Reconfigure, and doubles
the RECREP_MSG_TIMEOUT value, and waits again. The server continues
this process until all Reconfigure-reply messages are received or
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time
the server SHOULD abort the reconfigure process. The server SHOULD
log the result of the reconfigure process.
Default and initial values for RECREP_MSG_TIMEOUT and
REC_MSG_ATTEMPTS are documented in section 3.5.
12.4.3. Receipt of Reconfigure-reply messages 12.4.3. Receipt of Reconfigure-reply messages
Upon receipt of a valid Reconfigure-reply message, the server
removes that client from the list of clients it is expecting a
Reconfigure-reply message from.
12.4.4. Creation and sending of Reconfigure-init messages 12.4.4. Creation and sending of Reconfigure-init messages
When creating a Reconfigure-init message, the server SHOULD start The server sets the ``msg-type'' field to 8. The server generates
out with a buffer initialized with zeroed octets. The server sets a transaction-ID and inserts it in the ``transaction-ID'' field.
the ``msg-type'' field to 8. The server generates a transaction-ID The server places its address (of appropriate scope) in the
from the 0--1023 range and inserts it in the ``transaction-ID''
field. The server places its address (of appropriate scope) in the
``server-address'' field. ``server-address'' field.
The server MAY generate an ERE extension to inform the client of what The server MAY include an ORO option to inform the client of what
information has been changed or new information that has been added. information has been changed or new information that has been added.
If the DHCP domain is using authentication, the server will generate The server MUST include an authentication option with the appropriate
an authentication extension with the appropriate settings and add settings and add that option as the last option in the ``options''
that extension as the last extension in the ``extensions'' field of field of the Reconfigure-init message.
the Reconfigure-init message.
Typically, the server will not provide more than an ERE and / or Typically, the server will not provide more than an ORO and / or
Authentication extension, since it will provide the new configuration Authentication option, since it will provide the new configuration
information as part of the Request/Reply transaction triggered by the information as part of the Request/Reply transaction triggered by the
Reconfigure-init message. Reconfigure-init message.
The server multicasts the Reconfigure-init message to one or more The server may either unicast the Reconfigure-init message to one
Reconfigure Multicast Addresses previously sent as extensions client or multicast the message to one or more Reconfigure Multicast
to the clients. Note that a server MAY unicast Reconfigure-init Addresses previously sent as options to the clients. The server
message(s) to specific clients by walking its list of bindings to may unicast Reconfigure-init messages to more than one client
determine the unicast address(es) of the clients. Whether or not the concurrently; for example, to reliably reconfigure all clients, the
Reconfigure-init is multicast or unicast is an implementation detail. server will unicast a Reconfigure-init message to each client.
A server waits for a Request message from each client confirming that
they have received the Reconfigure-init and are thus initiating a
Request/Reply transaction with the server. The server can determine
that a Request message is in response to a Reconfigure-init because
the transaction-ID in the Request will be the same value as was used
in the Reconfigure-init message.
12.4.5. Time out and retransmission of Reconfigure-init messages
The server uses the same algorithm and configuration values for
sending Reconfigure-init messages as it does with Reconfigure
messages. See Section 12.4.2 for this algorithm.
12.4.6. Receipt of Request messages
Upon receipt of a valid Request message with the same transaction-ID
as the Reconfigure-init messages it sent, the server removes that
client from the list of clients it is expecting to initiate a
Request/Reply transaction.
The server generates and sends Reply message(s) to the client as
described in section 11.6.3, including in the ``extension'' field
new values for configuration parameters. If the extensions include
releasable resources, the server will include two extensions for each
resource - one with the original values with the lease times set to
zero, and another with new values and lease times. Note that the
server can terminate the client's ability to use a resource simply by
including only the first extension value.
12.5. Client Behavior
A client MUST always monitor UDP port 546 for Reconfigure and
Reconfigure-init messages on interfaces upon which it has acquired
DHCP parameters. Since the results of a reconfiguration event may
affect application layer programs, the client SHOULD log these
events, and MAY notify these programs of the change through an
implementation-specific interface.
12.5.1. Receipt of Reconfigure messages
Upon receipt of a valid Reconfigure message, the client extracts
the configuration parameters contained in the ``extensions''
field, and notifies the application layer that new values for these
parameters are available. The client then generates and sends a
Reconfigure-reply message to the server.
12.5.2. Creation and sending of Reconfigure-reply messages
When creating a Reconfigure-reply message, the client SHOULD start If the server unicasts to one or more clients, it waits for a Request
out with a buffer initialized with zeroed octets. The client sets message from those clients confirming that it has received the
the ``msg-type'' field to 7, and places the link-local address of Reconfigure-init and are thus initiating a Request/Reply transaction
the interface upon which it received the Reconfigure message in with the server. The server can determine that a Request message is
the ``client's link-local address'' field. The client copies the in response to a Reconfigure-init because the transaction-ID in the
values of the following fields from the Reconfigure message to the Request will be the same value as was used in the Reconfigure-init
Reconfigure-reply message: message.
o transaction-ID If the server multicasts the Reconfigure-init message, it must use
some TBD authentication mechanism that can authenticate the server to
multiple clients. There is no reliability mechanism for multicast
Reconfigure-init messages. A server might use multicast in the
case where it does not have a list of its clients; for example, a
server that distributes configuration information to clients using
stateless autoconfiguration might not keep a list of clients it has
communicated with.
o server-address 12.4.5. Time out and retransmission of Reconfigure-init messages
The client sets the ``status'' field appropriately (see the table It the server does not receive a Request message from the client
in section 3.4) based upon the results of processing the server's in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
reconfigure-reply. the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT
value and waits again. The server continues this process until
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point
the server SHOULD abort the reconfigure process.
The client places the address of the destination server in the Default and initial values for RECREP_MSG_TIMEOUT and
``server-address'' field. REC_MSG_ATTEMPTS are documented in section 3.5.
If the client is configured to use authentication, the client 12.4.6. Receipt of Request messages
generates the appropriate authentication extension, and adds this
extension to the ``extensions'' field. Note that the authentication
extension MUST be the last extension in the ``extensions'' field.
The client delays the sending of the Reconfigure-reply by some The server generates and sends Reply message(s) to the client as
random value selected in the range of REC_REP_MIN and REC_REP_MAX described in section 11.6.3, including in the ``option'' field new
seconds. This delay helps reduce the load on the server generated by values for configuration parameters.
processing large numbers of Reconfigure-reply messages.
Default and initial values for REC_REP_MIN and REC_REP_MAX are 12.5. Client Behavior
documented in section 3.5.
The client unicasts the Reconfigure-reply to the address identified A client MUST always monitor UDP port 546 for Reconfigure-init
in the ``server-address'' field. Sending the Reconfigure-reply messages on interfaces upon which it has acquired DHCP parameters.
completes the reconfiguration process for the client. Since the results of a reconfiguration event may affect application
layer programs, the client SHOULD log these events, and MAY notify
these programs of the change through an implementation-specific
interface.
12.5.3. Receipt of Reconfigure-init messages 12.5.1. Receipt of Reconfigure-init messages
Upon receipt of a valid Reconfigure-init message, the client Upon receipt of a valid Reconfigure-init message, the client
initiates a Request/Reply transaction with the server. initiates a Request/Reply transaction with the server.
12.5.4. Creation and sending of Request messages
12.5.2. Creation and sending of Request messages
When responding to a Reconfigure-init, the client creates and When responding to a Reconfigure-init, the client creates and
sends the Request message in exactly the same manner as outlined in sends the Request message in exactly the same manner as outlined in
section 11.4.1 with the following differences: section 11.4.1 with the following differences:
transaction-ID transaction-ID
The client copies the transaction-ID from the The client copies the transaction-ID from the
Reconfigure-init message into the Request message. Reconfigure-init message into the Request message.
IAs
The client includes IA options containing the addresses
the client currently has assigned to those IAs for the
interface through which the Reconfigure-init message was
received.
Pause before sending Request Pause before sending Request
The client pauses before sending the Request for The client pauses before sending the Request for
a random value within the range REC_REP_MIN and a random value within the range REC_REP_MIN and
REC_REP_MAX seconds, as outlined in section 12.5.2. REC_REP_MAX seconds. This delay helps reduce the
12.5.5. Time out and retransmission of Request messages load on the server generated by processing large
numbers of triggered Request messages from a multicast
Reconfigure-init message.
12.5.3. Time out and retransmission of Request messages
The client uses the same variables and retransmission algorithm as it The client uses the same variables and retransmission algorithm as it
does with Request messages generated as part of a client-initiated does with Request messages generated as part of a client-initiated
configuration exchange. See section 11.4.2 for details. configuration exchange. See section 11.4.2 for details.
12.5.6. Receipt of Reply messages
Upon the receipt of a valid Reply message, the client extracts
the contents of the ``extension'' field, and sets (or resets)
configuration parameters appropriately. If the configuration
parameters changed were requested by the application layer, the
client notifies the application layer of the changes using an
implementation-specific interface. If the resources changed are
releasable, the client makes the appropriate adjustments to its
management of the leases of these resources.
13. Using DHCP for network renumbering
An administrator can use DHCP to renumber links within her DHCP
domain through two techniques, passive renumbering and active
renumbering.
13.1. Passive Renumbering
The administrator can configure her servers to return relatively 12.5.4. Receipt of Reply messages
short preferred and valid lifetimes for the IP addresses she
makes available to clients. When she determines that she'd like
to renumber a network, she configures her servers through an
implementation-specific manner to disallow the extension of the IP
address lifetimes on the original network, and adds the new network
configuration data to the server's database.
The clients on the original network will fail to acquire lifetime Upon the receipt of a valid Reply message, the client extracts the
extensions on their IP addresses, and will request and acquire contents of the ``option'' field, and sets (or resets) configuration
IP addresses from the new network when the valid lifetime of the parameters appropriately. The client records and updates the
original IP addresses approaches expiration. lifetimes for any addresses specified in IAs in the Reply message.
If the configuration parameters changed were requested by the
application layer, the client notifies the application layer of the
changes using an implementation-specific interface.
When the lifetimes for all of the IP addresses on the original 13. Using DHCP for network renumbering
network expire, the network can be considered renumbered.
13.2. Active Renumbering
The administrator can force the renumbering of networks in her DHCP This section has been deleted (to be moved to ``Notes about DHCP''
domain by using the reconfigure feature of DHCP. She instructs her doc?).
servers of the network renumbering through an implementation-specific
interface. The servers in the domain will generate Reconfigure-init
messages, which will cause the clients to initiate a Request/Reply
transaction with the server. The servers will include two IP address
extensions for each IP address being changed. The first will contain
the original IP address, with the preferred and valid lifetimes set
to zero. The second will contain the new IP address, with non-zero
preferred and valid lifetimes.
A server implementation MAY permit the administrator to set the 14. DHCP Client Implementor Notes
original IP address lifetimes to some small value greater than zero,
to allow applications running on the client to orderly transfer to
the new network over time.
14. DHCP Client Implementator Notes
This section provides helpful information for the client implementor This section provides helpful information for the client implementor
regarding their implementations. The text described here is not part regarding their implementations. The text described here is not part
of the protocol, but rather a discussion of implementation features of the protocol, but rather a discussion of implementation features
we feel the implementor should consider during implementation. we feel the implementor should consider during implementation.
14.1. Primary Interface 14.1. Primary Interface
Since configuration parameters acquired through DHCP can be Since configuration parameters acquired through DHCP can be
interface-specific or more general, the client implementor SHOULD interface-specific or more general, the client implementor SHOULD
skipping to change at page 45, line 21 skipping to change at page 37, line 28
client SHOULD always query the DHCP data associated with the primary client SHOULD always query the DHCP data associated with the primary
interface for non-interface specific configuration parameters. An interface for non-interface specific configuration parameters. An
implementation MAY implement a list of interfaces which would be implementation MAY implement a list of interfaces which would be
scanned in order to satisfy the general request. In either case, the scanned in order to satisfy the general request. In either case, the
first interface scanned is considered the primary interface. first interface scanned is considered the primary interface.
By allowing the specification of a primary interface, the client By allowing the specification of a primary interface, the client
implementor identifies which interface is authoritative for implementor identifies which interface is authoritative for
non-interface specific parameters, which prevents configuration non-interface specific parameters, which prevents configuration
information ambiguity within the client implementation. information ambiguity within the client implementation.
14.2. Advertise Message and Configuration Parameter Caching 14.2. Advertise Message and Configuration Parameter Caching
If the hardware the client is running on permits it, the implementor If the hardware the client is running on permits it, the implementor
SHOULD provide a cache for Advertise messages and a cache of SHOULD provide a cache for Advertise messages and a cache of
configuration parameters received through DHCP. Providing these configuration parameters received through DHCP. Providing these
caches prevents unnecessary DHCP traffic and the subsequent load caches prevents unnecessary DHCP traffic and the subsequent load
this generates on the servers. The implementor SHOULD provide a this generates on the servers. The implementor SHOULD provide a
configuration knob for setting the amount of time the cache(s) are configuration knob for setting the amount of time the cache(s) are
valid. valid.
14.3. Time out and retransmission variables 14.3. Time out and retransmission variables
Note that the client time out and retransmission variables outlined Note that the client time out and retransmission variables outlined
in section 3.5 can be configured on the server and sent to the client in section 3.5 can be configured on the server and sent to the client
through the use of the ``DHCP Retransmission Parameter Extension'', through the use of the ``DHCP Retransmission Parameter Option'',
which is documented in the ``extensions document'' [2]. A client which is documented in section 22.6. A client implementation SHOULD
implementation SHOULD be able to reset these variables using the be able to reset these variables using the values from this option.
values from this extension.
14.4. Server Preference 14.4. Server Preference
A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
Solicit message to collect Advertise messages and compare their Solicit message to collect Advertise messages and compare their
preferences (see section 15.3), unless it receives an Advertise preferences (see section 15.3), unless it receives an Advertise
message with a preference of 255. If the client receives an message with a preference of 255. If the client receives an
Advertise message with a preference of 255, then the client MAY act Advertise message with a preference of 255, then the client MAY act
immediately on that Advertise without waiting for any more additional immediately on that Advertise without waiting for any more additional
Advertise messages. Advertise messages.
15. DHCP Server Implementator Notes 15. DHCP Server Implementor Notes
This section provides helpful information for the server implementor. This section provides helpful information for the server implementor.
15.1. Client Bindings 15.1. Client Bindings
A server implementation can use the client's link-local address A server implementation MUST use the IA's UUID and the prefix
and the subnet prefix specification from which the client sent its specification from which the client sent its Request message(s) as an
Request message(s) as an index for finding configuration parameters index for finding configuration parameters assigned to the client.
assigned to the client. While it isn't critical to keep track While it isn't critical to keep track of the other parameters
of which clients were given information (resources) that isn't assigned to a client, the server MUST keep track of the addresses it
releasable, it IS critical for the server to keep track of which has assigned to an IA.
client it has assigned releasable resources. The server MUST
include the transaction-ID from the client's Request along with
the releasable resource identifier(s) within the binding. This is
done so that the server can detect whether a client Request is a
retransmission of an earlier Request or an entirely new Request.
The server should periodically scan its bindings for releasable The server should periodically scan its bindings for addresses whose
resources whose leases have expired. When the server finds expired leases have expired. When the server finds expired addresses, it
resource assignments, it MUST delete these assignments, thereby MUST delete the assignment of those addresses, thereby making these
making these resources available to other clients. addresses available to other clients.
The client bindings MUST be stored in non-volatile storage. The client bindings MUST be stored in non-volatile storage.
The server implementation should provide policy knobs to control The server implementation should provide policy knobs to control
whether or not the lease on a releasable resource is renewable, and whether or not the lifetimes on assigned addresses are renewable, and
by how long. by how long.
15.2. Reconfigure Considerations
15.2. Reconfigure-init Considerations
A server implementation MUST provide an interface to the A server implementation MUST provide an interface to the
administrator for initiating reconfigure events. administrator for initiating reconfigure-init events.
A server implementation may provide a mechanism for allowing the A server implementation may provide a mechanism for allowing the
specification of how many clients comprise a reconfigure multicast specification of how many clients comprise a reconfigure multicast
group. This enables the administrator to control the hit a server group. This enables the administrator to control the hit a server
takes when a reconfigure event occurs. takes when a reconfigure-init event occurs.
15.3. Server Preference 15.3. Server Preference
The server implementation SHOULD allow the setting of a server The server implementation SHOULD allow the setting of a server
preference value by the administrator. The server preference preference value by the administrator. The server preference
variable is an unsigned single octet value (0--255), with the lowest variable is an unsigned single octet value (0--255), with the lowest
preference being 0 and the highest 255. Clients will choose higher preference being 0 and the highest 255. Clients will choose higher
preference servers over those with lower preference values. If you preference servers over those with lower preference values. If you
don't choose to implement this feature in your server, you MUST set don't choose to implement this feature in your server, you MUST set
the server preference field to 0 in the Advertise messages generated the server preference field to 0 in the Advertise messages generated
by your server. by your server.
skipping to change at page 47, line 7 skipping to change at page 39, line 15
15.3. Server Preference 15.3. Server Preference
The server implementation SHOULD allow the setting of a server The server implementation SHOULD allow the setting of a server
preference value by the administrator. The server preference preference value by the administrator. The server preference
variable is an unsigned single octet value (0--255), with the lowest variable is an unsigned single octet value (0--255), with the lowest
preference being 0 and the highest 255. Clients will choose higher preference being 0 and the highest 255. Clients will choose higher
preference servers over those with lower preference values. If you preference servers over those with lower preference values. If you
don't choose to implement this feature in your server, you MUST set don't choose to implement this feature in your server, you MUST set
the server preference field to 0 in the Advertise messages generated the server preference field to 0 in the Advertise messages generated
by your server. by your server.
15.4. Request Message Transaction-ID Cache 15.4. Request Message Transaction-ID Cache
In order to improve performance, a server implementation MAY include In order to improve performance, a server implementation MAY include
an in memory transaction-ID cache. This cache is indexed by client an in memory transaction-ID cache. This cache is indexed by client
binding and transaction-ID, and enables the server to quickly binding and transaction-ID, and enables the server to quickly
determine whether a Request is a retransmission or a new Request determine whether a Request is a retransmission or a new Request
without the cost of a database lookup. If an implementor chooses to without the cost of a database lookup. If an implementor chooses to
implement this cache, then they SHOULD provide a configuration knob implement this cache, then they SHOULD provide a configuration knob
to tune the lifetime of the cache entries. to tune the lifetime of the cache entries.
16. DHCP Relay Implementator Notes
16. DHCP Relay Implementor Notes
A relay implementation SHOULD allow the specification of a list of A relay implementation SHOULD allow the specification of a list of
destination addresses for Solicit messages. This list MAY contain destination addresses for forwarded messages. This list MAY contain
any mixture of unicast addresses and multicast addresses. any mixture of unicast addresses and multicast addresses.
If a relay receives an ICMP message in response to a DHCP message it If a relay receives an ICMP message in response to a DHCP message it
has forwarded, it SHOULD log this event. has forwarded, it SHOULD log this event.
17. Open Issues for Working Group Discussion 17. Open Issues for Working Group Discussion
This section contains some items for discussion by the working group. This section contains some items for discussion by the working group.
17.1. Trade-offs: Optional fields in DHCP messages
You'll notice that the message formats have changed. In particular, 17.1. Authentication
some of the optional fields are now required. This will increase the
size of DHCP messages in some cases, consuming network bandwidth and
memory on the DHCP client (an issue for small devices such as PDAs).
The changes were made for the following reasons: Authentication is not discussed in this document.
o Fields that were used most of the time were made required. 17.2. DHCP-DNS interaction
o Some fields that were optional were either made required or added Interaction among DHCP servers, clients and DNS servers is not
to messages which previously didn't have them. This was done for discussed in this document.
robustness reasons (receivers can validate that the message is
for them, and in the case of clients, know which interface the
message is intended for).
o Simplicity. 17.3. Release vs. Decline
Please look at the messages as they are now defined, and let us know Should there be a separate Decline message through which the client
your opinion. informs the server that it has discovered an address that is in use
17.2. Use DHCPv4 authentication or the current DHCPv6 method? by some other host?
Now that the DHCPv4 authentication draft is in last call, should 17.4. Request messages
we use the technique described in that document to provide
authentication for DHCPv6, or should we continue with the
authentication technique currently documented in the extensions
draft?
17.3. The Reconfigure Message and Subnet Prefix Extensions
The drafts currently specify that Releasable resources (such as an IP In DHCPv4, there has been much confusion about overloading
address) can only be reconfigured using the Reconfigure-init trigger DHCPREQUEST with the actions of initial address allocation
message. This was done for simplicity (enables clients to perform (INIT), address confirmation (INIT-REBOOT), and extending leases
DAD on the new address and return the appropriate result to the (RENEW/REBIND).
server) using the same mechanism as a standard Request/Reply/Release
exchange. This method also makes no assumptions about the
charactistics of the releasable resource.
However, for IP addresses with interface IDs, one could send out The model for DHCPv6 messages described in section 11 also uses one
two IP address extensions, one for the old prefix and one for the type of message, Request, in each of the scenarios in sections 11.4.8
new, and cause clients to change the prefix and thus renumber over through 11.4.10. The DHCPv6 specification in this document does not
time. This scheme avoids the added DHCP Request traffic - clients differentiate the actions taken by a server based on different times
acknowledge with a Reconfigure-reply message. at which a client might initiate a Request/Reply exchange with a
17.4. ``R'' bit in Request message not needed? server. That is, the description of server actions in section 11.6.1
does not differentiate among Requests received from clients based on
the client behavior described in sections 11.4.8 through 11.4.10.
Now that the transaction-ID is stored along with the releasable It may be necessary to define different server behaviors for each of
resource identifier in a client's binding, the transaction-ID cache the client scenarios. For example, in the address-reconfirmation
becomes an optional feature of the DHCP server implementation, not a scenario (section 11.4.9), servers cannot safely assign new addresses
requirement of the protocol. Should we do away with the ``R'' bit? to a client. The reconfirmation Request is broadcast to multiple
18. Security Considerations servers, which cannot coordinate the assignment of any addresses.
Therefore, in this scenario, servers can only acknowledge or deny the
validity of addresses but cannot allocate any new addresses.
Clients and servers often have to authenticate the messages they 17.5. Use of term ``agent''
exchange. For instance, a server may wish to be certain that a
Request originated from the client identified by the <link-local
address, subnet-prefix> fields included within the Request message
header. Conversely, it is quite often essential for a client to
be certain that the configuration parameters and addresses it has
received were sent to it by an authoritative server. Similarly, a
server should only accept a Release message which seems to be from
one of its clients, if it has some assurance that the client actually
did transmit the Release message. Again, a client might wish to only
accept Reconfigure or Reconfigure-init messages that are certain to
have originated from a server with authority to issue them.
The IPv6 Authentication Header can provide security for DHCPv6 The term ``agent'', taken to mean ``relay agent or server'', may be
messages when both endpoints have a suitable IP address. However, confusing. ``relay agent or server'' might be clearer.
a client often has only a link-local address, and such an address
is not sufficient for a server which is off-link. In those 17.6. Use of terms ``subnet'' and ``network''
circumstances the relay is involved, so that the DHCP message MUST
have the relay's address in the IP destination address field, even The term ``subnet'' has been eliminated from the document. The term
though the client aims to deliver the message to the server. The ``network'' is no longer used to describe a link, collection of links
DHCP Client-Server Authentication Extension [2] is intended to be or collection of IPv6 addresses.
used in these circumstances.
18. Security
This document references an ``authentication option'' which is TBD.
DISCUSSION:
Based on the discussion of security issues at the
8/31/00 design team teleconference and subsequent
DHC WG mailing list discussion, DHCPv6 will use
the security model from DHCPv4, as described in
draft-ietf-dhc-authentication-15.txt.
Note that, if a client receives a DHCP message which fails
authentication, it should continue to wait for another message which
might be correctly authenticated just as if the failed message had
never arrived; however, receiving such failed messages SHOULD be
logged.
19. Year 2000 considerations 19. Year 2000 considerations
Since all times are relative to the current time of the transaction, Since all times are relative to the current time of the transaction,
there is no problem within the DHCPv6 protocol related to any there is no problem within the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the current year. hardcoded dates or two-digit representation of the current year.
20. IANA Considerations 20. IANA Considerations
This document defines message types 1--8 to be received by UDP at This document defines message types 1--8 to be received by UDP at
port numbers 546 and 547. Additional message types may be defined in port numbers 546 and 547. Additional message types may be defined in
the future. the future.
Section 3.1 lists several multicast addresses used by DHCP. Section 3.1 lists several multicast addresses used by DHCP.
This document also defines several status codes that are to This document also defines several status codes that are to
be returned with the Reply and Reconfigure-reply messages (see be returned with the Reply and Reconfigure-reply messages (see
skipping to change at page 49, line 41 skipping to change at page 41, line 32
port numbers 546 and 547. Additional message types may be defined in port numbers 546 and 547. Additional message types may be defined in
the future. the future.
Section 3.1 lists several multicast addresses used by DHCP. Section 3.1 lists several multicast addresses used by DHCP.
This document also defines several status codes that are to This document also defines several status codes that are to
be returned with the Reply and Reconfigure-reply messages (see be returned with the Reply and Reconfigure-reply messages (see
sections 9.4 and 9.7). The non-zero values for these status codes sections 9.4 and 9.7). The non-zero values for these status codes
which are currently specified are shown in the table in section 3.4. which are currently specified are shown in the table in section 3.4.
There is a DHCPv6 extension [2] which allows clients and servers to There is a DHCPv6 option described in section 22.6, which allows
exchange values for some of the timing and retransmission parameters clients and servers to exchange values for some of the timing
defined in section 3.5. Adding new parameters in the future would and retransmission parameters defined in section 3.5. Adding new
require extending the values by which the parameters are indicated in parameters in the future would require extending the values by which
the DHCP extension. Since there needs to be a list kept, the default the parameters are indicated in the DHCP option. Since there needs
values for each parameter should also be stored as part of the list. to be a list kept, the default values for each parameter should also
be stored as part of the list.
All of these protocol elements may be specified to assume new values All of these protocol elements may be specified to assume new values
at some point in the future. New values should be approved by the at some point in the future. New values should be approved by the
process of IETF Consensus [11]. process of IETF Consensus [10].
21. Acknowledgements
21. Acknowledgments
Thanks to the DHC Working Group for their time and input into the Thanks to the DHC Working Group for their time and input into the
specification. Ralph Droms and Thomas Narten have had a major specification. Ralph Droms and Thomas Narten have had a major
role in shaping the continued improvement of the protocol by their role in shaping the continued improvement of the protocol by their
careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald
Maguire, and Mike Carney for their studied review as part of the Maguire, and Mike Carney for their studied review as part of the
Last Call process. Thanks also for the consistent input, ideas, and Last Call process. Thanks also for the consistent input, ideas, and
review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.
Thanks to Steve Deering and Bob Hinden, who have consistently Thanks to Steve Deering and Bob Hinden, who have consistently
taken the time to discuss the more complex parts of the IPv6 taken the time to discuss the more complex parts of the IPv6
specifications. specifications.
22. DHCP options
Options are used to carry additional information and parameters
in DHCP messages. Every option shares a common base format, as
described in section 22.1.
this document describes the DHCP options defined as part of the base
DHCP specification. Other options may be defined in the future in a
separate document.
22.1. Format of DHCP options
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code
An unsigned integer identifying the specific option type
carried in this option.
option-len
An unsigned integer giving the length of the data in
this option in bytes.
option-data
The data for the option; the format of this data depends
on the definition of the option.
22.2. Identity association option
The identity association option is used to carry an identity
association, the parameters associated with the IA and the addresses
assigned to the IA.
The format of the IA option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IA UUID |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addrs | IPv6 address |
+-+-+-+-+-+-+-+-+ (16 octets) |
| |
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | pref. len | preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref. lifetime (cont.) | valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid lifetime (cont.) | IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code
TBD
option-len
Variable; equal to 17 + num-addrs*25
IA UUID
The unique identifier for this IA; chosen by the client
T1 The time at which the client contacts the server from
which the addresses in the IA were obtained to extend
the lifetimes of the addresses assigned to the IA.
T2 The time at which the client contacts any available
server to extend the lifetimes of the addresses assigned
to the IA.
num-addrs
An unsigned integer giving the number of addresses
carried in this IA option (MAY be zero).
IPv6 address
An IPv6 address assigned to this IA.
preferred lifetime
The preferred lifetime for the associated IPv6 address.
valid lifetime
The valid lifetime for the associated IPv6 address.
The ``IPv6 address'', ``preferred lifetime'' and ``valid lifetime''
fields are repeated for each address in the IA option (as determined
by the ``num-addrs'' field).
DISCUSSION:
The details of the format and the selection of an IA's UUID
are TBD.
DISCUSSION:
An IA has no explicit ``lifetime'' or ``lease length'' of
its own. When the lifetimes of all of the addresses in an
IA have expired, the IA can be considered as having expired.
T1 and T2 are included to give servers explicit control over
when a client recontacts the server about a specific IA.
22.3. Option request option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD.
option-len
Variable; equal to twice the number of option codes
carried in this option.
option-data
A list of the option codes for the options requested in
this option.
22.4. Client message option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP client message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD
option-len
Variable; equal to the length of the forwarded DHCP
client message.
option-data
The message received from the client; forwarded verbatim
to the server.
22.5. Server message option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP server message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD
option-len
Variable; equal to the length of the forwarded DHCP
server message.
option-data
The message received from the server; forwarded verbatim
to the client.
22.6. Retransmission parameter option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code
An unsigned integer identifying the specific option type
carried in this option.
option-len
An unsigned integer giving the length of the data in
this option in bytes.
option-data
The data for the option; the format of this data depends
on the definition of the option.
22.7. Authentication option
The authentication option is TBD.
23. Changes in this draft
This section describes the changes between this version of the DHCPv6
specification and draft-ietf-dhc-dhcpv6-15.txt.
23.1. Order of sections
New sections have been added at the end of this document to minimize
changes in section numbering. Those sections will be rearranged in a
future revision.
23.2. Reconfigure message
DHCP Reconfigure and Reconfigure-reply messages and the associated
mechanisms have been removed from this draft of the specification.
23.3. Releasable resources
``Releasable resources'' have been removed from this draft.
23.4. DHCP message header
A common fixed DHCP message header has been defined. Not all fields
are used in all messages.
23.5. Design goals
The second sentence in the 8th design goal bullet has been removed.
23.6. Overview
Section 8.2 (DHCP agents) has been removed. DHCP clients no longer
need to know about specific DHCP agents.
Section 8.3 has been modified to reflect the new encapsulating
mechanism through which relays forward client messages to servers.
Section 8.6 and 8.7 have been modified to describe ``identity
associations''.
Section 8.8 has been modified to reflect the deletion of
``reconfigure'' and ``reconfigure-reply'' messages.
23.7. Message formats, 9
Message formats have been changed. All messages share a common fixed
message header followed by options. The various control bits (``P'',
``C'') have been removed from the message header.
23.8. Solicit and Advertise messages, (section 10)
The description of the message exchanges have been changed to
reflect:
- New relay behavior - encapsulated client messages
- Use of IAs
23.9. Prefix advertisement
Servers no longer advertise prefixes.
23.10. Identity Associations
Section 9.11 describes IAs in detail. A definition of ``IA'' has
been added to section 2. The description of messages exchanges
have been extended to include IAs. The IA option is defined in
section 22.2
23.11. Extensions renamed options; defined in this document
``extensions'' are now called ``options''; the options referenced in
this document are defined in section 22.
23.12. Transaction-ID ranges
Solicit, Advertise, Request, Reply, Release and Reconfigure-init
messages all use an unsigned 16-bit integer ``Transaction-ID''.
Transaction-IDs generated by clients are considered to be chosen from
a different namespace than those chosen by servers. There is no
need to restrict clients and servers to select Transaction-IDs from
specific ranges to avoid conflicts.
23.13. Release messages and relays
Release/Reply messages are forwarded through relays. This mechanism
eliminates the need for an 'R' bit.
23.14. Discovering relay agents
Clients no longer learn the identity of relay agents. When the
client only has a link-local address (e.g., the client has no
assigned addresses), it now multicasts Request message, which is then
forwarded by a relay agent on the same link.
A. Comparison between DHCPv4 and DHCPv6 A. Comparison between DHCPv4 and DHCPv6
This appendix is provided for readers who will find it useful to see This appendix is provided for readers who will find it useful to see
a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6. a model and architecture comparison between DHCPv4 [6, 1] and DHCPv6.
There are three key reasons for the differences: There are three key reasons for the differences:
o IPv6 inherently supports a new model and architecture for o IPv6 inherently supports a new model and architecture for
communications and autoconfiguration of addresses. communications and autoconfiguration of addresses.
o DHCPv6 benefits from the new IPv6 features. o DHCPv6 benefits from the new IPv6 features.
o New features were added to support the expected evolution and o New features were added to support the expected evolution and
the existence of more complicated Internet network service the existence of more complicated Internet network service
requirements. requirements.
skipping to change at page 51, line 15 skipping to change at page 49, line 46
o Stateful autoconfiguration has to coexist and integrate with o Stateful autoconfiguration has to coexist and integrate with
stateless autoconfiguration supporting Duplicate Address stateless autoconfiguration supporting Duplicate Address
Detection and the two IPv6 lifetimes, to facilitate the dynamic Detection and the two IPv6 lifetimes, to facilitate the dynamic
renumbering of addresses and the management of those addresses. renumbering of addresses and the management of those addresses.
o Multiple addresses per interface are inherently supported in o Multiple addresses per interface are inherently supported in
IPv6. IPv6.
o Some DHCPv4 options are unnecessary now because the configuration o Some DHCPv4 options are unnecessary now because the configuration
parameters are either obtained through IPv6 Neighbor Discovery or parameters are either obtained through IPv6 Neighbor Discovery or
the Service Location protocol [16]. the Service Location protocol [15].
DHCPv6 Architecture/Model Changes: DHCPv6 Architecture/Model Changes:
o The message type is the first byte in the packet. o The message type is the first byte in the packet.
o IPv6 Address allocations are now handled in a message extension o IPv6 Address allocations are now handled in a message option as
as opposed to the message header. opposed to the message header.
o Client/Server bindings are now mandatory and take advantage of o Client/Server bindings are now mandatory and take advantage of
the client's link-local address to always permit communications the client's link-local address to always permit communications
either directly from an on-link server, or from a off-link server either directly from an on-link server, or from a off-link server
through an on-link relay. through an on-link relay.
o Servers are discovered by a client Solicit, followed by a server o Servers are discovered by a client Solicit, followed by a server
Advertise message Advertise message
o The client will know if the server is on-link or off-link. o The client will know if the server is on-link or off-link.
skipping to change at page 51, line 49 skipping to change at page 50, line 33
o The server assumes the client receives its responses unless it o The server assumes the client receives its responses unless it
receives a retransmission of the same client request. This receives a retransmission of the same client request. This
permits recovery in the case where the network has faulted. permits recovery in the case where the network has faulted.
o Clients can issue multiple, unrelated Request messages to the o Clients can issue multiple, unrelated Request messages to the
same or different servers. same or different servers.
o The function of DHCPINFORM is inherent in the new packet design; o The function of DHCPINFORM is inherent in the new packet design;
a client can request configuration parameters other than IPv6 a client can request configuration parameters other than IPv6
addresses in the optional extension headers. addresses in the optional option headers.
o Clients MUST listen to their UDP port for the new Reconfigure o Clients MUST listen to their UDP port for the new Reconfigure
message from servers. message from servers.
o New extensions have been defined. o New options have been defined.
With the changes just enumerated, we can support new user features, With the changes just enumerated, we can support new user features,
including including
o Configuration of Dynamic Updates to DNS o Configuration of Dynamic Updates to DNS
o Address deprecation, for dynamic renumbering. o Address deprecation, for dynamic renumbering.
o Relays can be preconfigured with server addresses, or use of o Relays can be preconfigured with server addresses, or use of
multicast. multicast.
skipping to change at page 53, line 6 skipping to change at page 51, line 39
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
References References
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. Request for Comments (Draft Standard) 2132, Extensions. Request for Comments (Draft Standard) 2132,
Internet Engineering Task Force, March 1997. Internet Engineering Task Force, March 1997.
[2] J. Bound, M. Carney, and C. Perkins. Extensions for the Dynamic [2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Host Configuration Protocol for IPv6.
draft-ietf-dhc-dhcpv6ext-12.txt, May 2000. (work in progress).
[3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119, Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997. Internet Engineering Task Force, March 1997.
[4] S. Bradner and A. Mankin. The Recommendation for the IP Next [3] S. Bradner and A. Mankin. The Recommendation for the IP Next
Generation Protocol. Request for Comments (Proposed Standard) Generation Protocol. Request for Comments (Proposed Standard)
1752, Internet Engineering Task Force, January 1995. 1752, Internet Engineering Task Force, January 1995.
[5] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for [4] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for
Comments 951, Internet Engineering Task Force, September 1985. Comments 951, Internet Engineering Task Force, September 1985.
[6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. Request for Comments (Draft Standard) 2460, Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998. Internet Engineering Task Force, December 1998.
[7] R. Droms. Dynamic Host Configuration Protocol. Request for [6] R. Droms. Dynamic Host Configuration Protocol. Request for
Comments (Draft Standard) 2131, Internet Engineering Task Force, Comments (Draft Standard) 2131, Internet Engineering Task Force,
March 1997. March 1997.
[8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. [7] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
Request for Comments (Proposed Standard) 2373, Internet Request for Comments (Proposed Standard) 2373, Internet
Engineering Task Force, July 1998. Engineering Task Force, July 1998.
[9] S. Kent and R. Atkinson. IP Authentication Header. Request for [8] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998. Force, November 1998.
[10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for [9] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for
IP version 6. Request for Comments (Proposed Standard) 1981, IP version 6. Request for Comments (Proposed Standard) 1981,
Internet Engineering Task Force, August 1996. Internet Engineering Task Force, August 1996.
[11] T. Narten and H. Alvestrand. Guidelines for Writing an IANA [10] T. Narten and H. Alvestrand. Guidelines for Writing an IANA
Considerations Section in RFCs. Request for Comments (Best Considerations Section in RFCs. Request for Comments (Best
Current Practice) 2434, Internet Engineering Task Force, October Current Practice) 2434, Internet Engineering Task Force, October
1998. 1998.
[12] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for [11] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) IP Version 6 (IPv6). Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998. 2461, Internet Engineering Task Force, December 1998.
[13] D. C. Plummer. Ethernet Address Resolution Protocol: Or [12] D. C. Plummer. Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware. Request for Comments for transmission on Ethernet hardware. Request for Comments
(Standard) 826, Internet Engineering Task Force, November 1982. (Standard) 826, Internet Engineering Task Force, November 1982.
[14] J. Postel. User Datagram Protocol. Request for Comments [13] J. Postel. User Datagram Protocol. Request for Comments
(Standard) 768, Internet Engineering Task Force, August 1980. (Standard) 768, Internet Engineering Task Force, August 1980.
[15] S. Thomson and T. Narten. IPv6 Stateless Address [14] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard) 2462, Autoconfiguration. Request for Comments (Draft Standard) 2462,
Internet Engineering Task Force, December 1998. Internet Engineering Task Force, December 1998.
[16] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [15] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. Request for Comments (Proposed Standard) Location Protocol. Request for Comments (Proposed Standard)
2165, Internet Engineering Task Force, June 1997. 2165, Internet Engineering Task Force, June 1997.
[17] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic [16] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic
Updates in the Domain Name System (DNS UPDATE). Request for Updates in the Domain Name System (DNS UPDATE). Request for
Comments (Proposed Standard) 2136, Internet Engineering Task Comments (Proposed Standard) 2136, Internet Engineering Task
Force, April 1997. Force, April 1997.
Chair's Address Chair's Address
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Ralph Droms Ralph Droms
Computer Science Department Cisco Systems
323 Dana Engineering 300 Apollo Drive
Bucknell University Chelmsford, MA 01824
Lewisburg, PA 17837
Phone: (570) 577-1145 Phone: (978) 244-4733
E-mail: droms@bucknell.edu E-mail: rdroms@cisco.com
Author's Address Author's Address
Questions about this memo can be directed to: Questions about this memo can be directed to:
Jim Bound Jim Bound
Compaq Computer Corporation Compaq Computer Corporation
Mail Stop: ZK03-3/U14 Mail Stop: ZK03-3/U14
110 Spitbrook Road 110 Spitbrook Road
Nashua, NH 03062 Nashua, NH 03062
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/