draft-ietf-dhc-dhcpv6-16.txt   draft-ietf-dhc-dhcpv6-17.txt 
Internet Engineering Task Force J. Bound Internet Engineering Task Force J. Bound
INTERNET DRAFT Compaq Computer Corp. INTERNET DRAFT Nokia
DHC Working Group M. Carney DHC Working Group M. Carney
Obsoletes: draft-ietf-dhc-dhcpv6-15.txt Sun Microsystems, Inc Obsoletes: draft-ietf-dhc-dhcpv6-16.txt Sun Microsystems, Inc
C. Perkins C. Perkins
Nokia Research Center Nokia Research Center
R. Droms(ed.) R. Droms(ed.)
Cisco Systems Cisco Systems
22 November 2000 1 March 2001
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-16.txt draft-ietf-dhc-dhcpv6-17.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
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 such as IPv6 network DHCP servers to pass configuration parameters such as IPv6 network
addresses to IPv6 nodes. It offers the capability of automatic addresses to IPv6 nodes. It offers the capability of automatic
allocation of reusable network addresses and additional configuration allocation of reusable network addresses and additional configuration
flexibility. This protocol is a stateful counterpart to ``IPv6 flexibility. This protocol is a stateful counterpart to "IPv6
Stateless Address Autoconfiguration'' [14], and can be used Stateless Address Autoconfiguration" [13], and can be used separately
separately or concurrently with the latter to obtain configuration or concurrently with the latter to obtain configuration parameters.
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. Requirements 1
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3
3. DHCP Constants 4 3. Background 1
3.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 5
3.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. DHCP message types . . . . . . . . . . . . . . . . . . . 5
3.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 7
3.4.1. Generic Error Values . . . . . . . . . . . . . . 7
3.4.2. Server-specific Error Values . . . . . . . . . . 7
3.5. Configuration Variables . . . . . . . . . . . . . . . . . 8
4. Requirements 8 4. Design Goals 3
5. Background 9 5. Non-Goals 3
6. Design Goals 10 6. Terminology 4
6.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 4
6.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 5
7. Non-Goals 11 7. DHCP Constants 6
7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 7
7.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3. DHCP message types . . . . . . . . . . . . . . . . . . . 7
7.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 9
7.4.1. Generic Error Values . . . . . . . . . . . . . . 9
7.4.2. Server-specific Error Values . . . . . . . . . . 9
7.5. Configuration Variables . . . . . . . . . . . . . . . . . 10
8. Overview 11 8. Overview 10
8.1. How does a node know to use DHCP? . . . . . . . . . . . . 11 8.1. How does a node know to use DHCP? . . . . . . . . . . . . 10
8.2. How does a client find out about DHCP agents? . . . . . . 11 8.2. What if the client and server(s) are on different links? 10
8.3. What if the client and server(s) are on different links? 11 8.3. How does a client request configuration parameters from
8.4. How does a client request configuration parameters from servers? . . . . . . . . . . . . . . . . . . . . . . . 11
servers? . . . . . . . . . . . . . . . . . . . . . . . 12 8.4. How do clients and servers identify and manage addresses? 11
8.5. How do clients and servers identify and manage addresses? 13 8.5. Can a client release its assigned addresses before the lease
8.6. Can a client release its assigned addresses before the lease expires? . . . . . . . . . . . . . . . . . . . . . . . 12
expires? . . . . . . . . . . . . . . . . . . . . . . . 13 8.6. What if the client determines one or more of its assigned
8.7. What if the client determines one or more of its assigned addresses are already being used by another client? . 12
addresses are already being used by another client? . 13 8.7. How are clients notified of server configuration changes? 12
8.8. How are clients notified of server configuration changes? 13
9. Message Formats and Identity Associations 14 9. Message Formats 13
9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 14 9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 13
9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 15 9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 14
9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 16 9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 14
9.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 17 9.4. DHCP Confirm Message Format . . . . . . . . . . . . . . . 14
9.5. DHCP Release Message Format . . . . . . . . . . . . . . . 18 9.5. DHCP Renew Message Format . . . . . . . . . . . . . . . . 15
9.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 18 9.6. DHCP Rebind Message Format . . . . . . . . . . . . . . . 15
9.7. DHCP Reconfigure-reply Message Format . . . . . . . . . . 18 9.7. DHCP Reply Message Format . . . . . . . . . . . . . . . . 16
9.8. DHCP Reconfigure-init Message Format . . . . . . . . . . 19 9.8. DHCP Release Message Format . . . . . . . . . . . . . . . 16
9.9. Relay-forward message . . . . . . . . . . . . . . . . . . 20 9.9. DHCP Decline Message Format . . . . . . . . . . . . . . . 16
9.10. Server-forward message . . . . . . . . . . . . . . . . . 20 9.10. DHCP Reconfigure-init Message Format . . . . . . . . . . 17
9.11. Identity association . . . . . . . . . . . . . . . . . . 21
10. DHCP Server Solicitation 21 10. Relay messages 17
10.1. Solicit Message Validation . . . . . . . . . . . . . . . 21 10.1. Relay-forward message . . . . . . . . . . . . . . . . . . 17
10.2. Advertise Message Validation . . . . . . . . . . . . . . 21 10.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 18
10.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 22
10.3.1. Creation and sending of the Solicit message . . . 22
10.3.2. Time out and retransmission of Solicit Messages . 22
10.3.3. Receipt of Advertise messages . . . . . . . . . . 23
10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 23
10.4.1. Relaying of Solicit messages . . . . . . . . . . 23
10.4.2. Relaying of Advertise messages . . . . . . . . . 24
10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 24
10.5.1. Receipt of Solicit messages . . . . . . . . . . . 24
10.5.2. Creation and sending of Advertise messages . . . 24
11. DHCP Client-Initiated Configuration Exchange 25 11. Identity association 18
11.1. Request Message Validation . . . . . . . . . . . . . . . 25
11.2. Reply Message Validation . . . . . . . . . . . . . . . . 26
11.3. Release Message Validation . . . . . . . . . . . . . . . 26
11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26
11.4.1. Creation and sending of Request messages . . . . 27
11.4.2. Time out and retransmission of Request Messages . 27
11.4.3. Receipt of Reply message in response to a Request 28
11.4.4. Creation and sending of Release messages . . . . 28
11.4.5. Time out and retransmission of Release Messages . 29
11.4.6. Receipt of Reply message in response to a Release 29
11.4.7. When a client should send a Request message . . . 29
11.4.8. Initialization . . . . . . . . . . . . . . . . . 29
11.4.9. Confirming the validity of IPv6 addresses . . . . 29
11.4.10. Extending the lifetimes on IPv6 addresses . . . . 30
11.5. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 31
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 33 12. DHCP Server Solicitation 19
12.1. Reconfigure Message Validation . . . . . . . . . . . . . 33 12.1. Solicit Message Validation . . . . . . . . . . . . . . . 19
12.2. Reconfigure-reply Message Validation . . . . . . . . . . 33 12.2. Advertise Message Validation . . . . . . . . . . . . . . 19
12.3. Reconfigure-init Message Validation . . . . . . . . . . . 33 12.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 19
12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 33 12.3.1. Creation and sending of the Solicit message . . . 19
12.4.1. Creation and sending of Reconfigure messages . . 34 12.3.2. Time out and retransmission of Solicit Messages . 20
12.4.2. Time out and retransmission of Reconfigure 12.3.3. Receipt of Advertise messages . . . . . . . . . . 20
messages . . . . . . . . . . . . . . . . . 34 12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 21
12.4.3. Receipt of Reconfigure-reply messages . . . . . . 34 12.4.1. Receipt of Solicit messages . . . . . . . . . . . 21
12.4.4. Creation and sending of Reconfigure-init messages 34 12.4.2. Creation and sending of Advertise messages . . . 21
12.4.5. Time out and retransmission of Reconfigure-init
messages . . . . . . . . . . . . . . . . . 35
12.4.6. Receipt of Request messages . . . . . . . . . . . 35
12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 35
12.5.1. Receipt of Reconfigure-init messages . . . . . . 35
12.5.2. Creation and sending of Request messages . . . . 36
12.5.3. Time out and retransmission of Request messages . 36
12.5.4. Receipt of Reply messages . . . . . . . . . . . . 36
13. Using DHCP for network renumbering 36 13. DHCP Client-Initiated Configuration Exchange 22
13.1. Client Message Validation . . . . . . . . . . . . . . . . 22
13.2. Server Message Validation . . . . . . . . . . . . . . . . 23
13.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 23
13.3.1. Creation and sending of Request messages . . . . 24
13.3.2. Creation and sending of Confirm messages . . . . 24
13.3.3. Creation and sending of Renew messages . . . . . 26
13.3.4. Creation and sending of Rebind messages . . . . . 27
13.3.5. Receipt of Reply message in response to a Reply,
Confirm, Renew or Rebind message . . . . . 28
13.3.6. Creation and sending of Release messages . . . . 29
13.3.7. Time out and retransmission of Release Messages . 29
13.3.8. Creation and sending of Decline messages . . . . 30
13.3.9. Time out and retransmission of Decline Messages . 30
13.3.10. Receipt of Reply message in response to a Release
message . . . . . . . . . . . . . . . . . 31
13.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31
13.4.1. Receipt of Request messages . . . . . . . . . . . 31
13.4.2. Receipt of Confirm messages . . . . . . . . . . . 32
13.4.3. Receipt of Renew messages . . . . . . . . . . . . 32
13.4.4. Receipt of Rebind messages . . . . . . . . . . . 33
13.4.5. Receipt of Release messages . . . . . . . . . . . 34
13.4.6. Sending of Reply messages . . . . . . . . . . . . 35
14. DHCP Client Implementor Notes 37 14. DHCP Server-Initiated Configuration Exchange 35
14.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 37 14.1. Reconfigure-init Message Validation . . . . . . . . . . . 35
14.2. Advertise Message and Configuration Parameter Caching . . 37 14.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35
14.3. Time out and retransmission variables . . . . . . . . . . 37 14.2.1. Creation and sending of Reconfigure-init messages 36
14.4. Server Preference . . . . . . . . . . . . . . . . . . . . 38 14.2.2. Time out and retransmission of unicast
Reconfigure-init messages . . . . . . . . 37
14.2.3. Time out and retransmission of multicast
Reconfigure-init messages . . . . . . . . 37
14.2.4. Receipt of Request messages . . . . . . . . . . . 37
14.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 37
14.3.1. Receipt of Reconfigure-init messages . . . . . . 37
14.3.2. Creation and sending of Request messages . . . . 38
14.3.3. Time out and retransmission of Request messages . 38
14.3.4. Receipt of Reply messages . . . . . . . . . . . . 38
15. DHCP Server Implementor Notes 38 15. Relay Behavior 38
15.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 38 15.1. Relaying of Solicit messages . . . . . . . . . . . . . . 39
15.2. Reconfigure-init Considerations . . . . . . . . . . . . . 38 15.2. Relaying of Advertise messages . . . . . . . . . . . . . 39
15.3. Server Preference . . . . . . . . . . . . . . . . . . . . 39
15.4. Request Message Transaction-ID Cache . . . . . . . . . . 39
16. DHCP Relay Implementor Notes 39 16. DHCP options 39
16.1. Format of DHCP options . . . . . . . . . . . . . . . . . 40
16.2. Identity association option . . . . . . . . . . . . . . . 40
16.3. Option request option . . . . . . . . . . . . . . . . . . 42
16.4. Client message option . . . . . . . . . . . . . . . . . . 43
16.5. Server message option . . . . . . . . . . . . . . . . . . 43
16.6. Retransmission parameter option . . . . . . . . . . . . . 44
16.7. Authentication option . . . . . . . . . . . . . . . . . . 44
16.8. Reconfigure-delay option . . . . . . . . . . . . . . . . 44
16.9. DSTM Global IPv4 Address Option . . . . . . . . . . . . . 44
17. Open Issues for Working Group Discussion 39 17. DHCP Client Implementor Notes 45
17.1. Authentication . . . . . . . . . . . . . . . . . . . . . 39 17.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 45
17.2. DHCP-DNS interaction . . . . . . . . . . . . . . . . . . 39 17.2. Advertise Message and Configuration Parameter Caching . . 46
17.3. Release vs. Decline . . . . . . . . . . . . . . . . . . 40 17.3. Time out and retransmission variables . . . . . . . . . . 46
17.4. Request messages . . . . . . . . . . . . . . . . . . . . 40 17.4. Server Preference . . . . . . . . . . . . . . . . . . . . 46
17.5. Use of term ``agent'' . . . . . . . . . . . . . . . . . . 40
17.6. Use of terms ``subnet'' and ``network'' . . . . . . . . . 40
18. Security 40 18. DHCP Server Implementor Notes 46
18.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 46
18.2. Reconfigure-init Considerations . . . . . . . . . . . . . 47
18.2.1. Reliable transmission of multicast Reconfigure-init
messages . . . . . . . . . . . . . . . . . 47
18.3. Server Preference . . . . . . . . . . . . . . . . . . . . 47
18.4. Request Message Transaction-ID Cache . . . . . . . . . . 47
19. Year 2000 considerations 41 19. DHCP Relay Implementor Notes 48
20. IANA Considerations 41 20. Open Issues for Working Group Discussion 48
20.1. Authentication . . . . . . . . . . . . . . . . . . . . . 48
20.2. Identification of IAs by servers . . . . . . . . . . . . 48
20.3. DHCP-DNS interaction . . . . . . . . . . . . . . . . . . 48
20.4. Anonymous addresses . . . . . . . . . . . . . . . . . . . 48
20.5. Use of term "agent" . . . . . . . . . . . . . . . . . . . 48
20.6. Client behavior when response to Rebind is not received . 49
20.7. Additional options . . . . . . . . . . . . . . . . . . . 49
20.8. Operational parameters . . . . . . . . . . . . . . . . . 49
21. Acknowledgments 41 21. Security 49
22. DHCP options 42 22. Year 2000 considerations 49
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
23. Changes in this draft 46 23. IANA Considerations 49
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
A. Comparison between DHCPv4 and DHCPv6 49 24. Acknowledgments 50
B. Full Copyright Statement 51 A. Comparison between DHCPv4 and DHCPv6 50
Chair's Address 54 B. Full Copyright Statement 52
Author's Address 54 C. Changes in this draft 53
C.1. New messages for confirming addresses and extending the lease
on an IA . . . . . . . . . . . . . . . . . . . . . . . 53
C.2. New message formats . . . . . . . . . . . . . . . . . . . 53
C.3. Renamed Server-forward message . . . . . . . . . . . . . 53
C.4. Clarified relay forwarding of messages . . . . . . . . . 53
C.5. Addresses and options in Advertise messages . . . . . . . 53
C.6. Clarification of IA option format . . . . . . . . . . . . 53
C.7. Specification of transaction ID in Solicit message . . . 54
C.8. Edits to definitions . . . . . . . . . . . . . . . . . . 54
C.9. Relay agent messages . . . . . . . . . . . . . . . . . . 54
C.10. Relay agent behavior . . . . . . . . . . . . . . . . . . 54
C.11. Transmission of all client messages through relays . . . 54
C.12. Reconfigure-init messages . . . . . . . . . . . . . . . . 54
C.13. Ordering of sections . . . . . . . . . . . . . . . . . . 54
C.14. DSTM option . . . . . . . . . . . . . . . . . . . . . . . 54
Chair's Address 57
Author's Address 57
1. Introduction 1. Introduction
This document describes DHCP for IPv6 (DHCP), a UDP [13] client This document describes DHCP for IPv6 (DHCP), a UDP [12]
/ server protocol designed to reduce the cost of management of client/server protocol designed to reduce the cost of management
IPv6 nodes in environments where network managers require more of IPv6 nodes in environments where network managers require more
control over the allocation of IPv6 addresses and configuration control over the allocation of IPv6 addresses and configuration
of network stack parameters than that offered by ``IPv6 Stateless of network stack parameters than that offered by "IPv6 Stateless
Autoconfiguration'' [14]. DHCP is a stateful counterpart to Autoconfiguration" [13]. DHCP is a stateful counterpart to
stateless autoconfiguration. Note that both stateful and stateless stateless autoconfiguration. Note that both stateful and stateless
autoconfiguration can be used concurrently in the same environment, autoconfiguration can be used concurrently in the same environment,
leveraging the strengths of both mechanisms in order to reduce the leveraging the strengths of both mechanisms in order to reduce the
cost of ownership and management of network nodes. cost of ownership and management of network nodes.
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.
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 ``options'' defined to parameters through the addition of new DHCP "options" defined to
carry this information. (What were called ``extensions'' in the -15 carry this information.
draft are now called ``options''; see section 23.11.)
Those readers familiar with DHCP for IPv4 [6] 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 [4]-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 2. Requirements
used throughout this document. Section 3 defines constant values
used by DHCP. Section 4 briefly discusses requirement levels.
Section 5 points the reader to helpful background specifications
covering related IPv6 protocols. Section 6 discusses the design
goals that influenced DHCP. Section 7 identifies some of the
non-goals of this specification. Section 8 gives a high level
overview of DHCP, its message types, and identifies DHCP functional
entities (client, relay, server). Section 9 describes in detail
the format of each DHCP message type. Section 10 discusses DHCP
server solicitation. Section 11 discusses DHCP client-initiated
configuration information exchange. Section 12 discusses DHCP
server-initiated configuration information exchange. Section 14
presents helpful notes for DHCP client implementors. Section 15
presents helpful notes for DHCP server implementors. Section 16
presents helpful notes for DHCP relay implementors. Section 18
discusses security considerations for DHCP.
Section 23 describes the changes between this version of the DHCPv6 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
specification and draft-ietf-dhc-dhcpv6-15.txt. SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [2].
2. Terminology This document also makes use of internal conceptual variables
to describe protocol behavior and external variables that an
implementation must allow system administrators to change. The
specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demonstrate
protocol behavior. An implementation is not required to have them in
the exact form described here, so long as its external behavior is
consistent with that described in this document.
2.1. IPv6 Terminology 3. Background
Related work in IPv6 that would best serve an implementor to study
is the IPv6 Specification [5], the IPv6 Addressing Architecture [7],
IPv6 Stateless Address Autoconfiguration [13], IPv6 Neighbor
Discovery Processing [10], and Dynamic Updates to DNS [15]. These
specifications enable DHCP to build upon the IPv6 work to provide
both robust stateful autoconfiguration and autoregistration of DNS
Host Names.
The IPv6 Specification provides the base architecture and design of
IPv6. A key point for DHCP implementors to understand is that IPv6
requires that every link in the Internet have an MTU of 1280 octets
or greater (in IPv4 the requirement is 68 octets). This means that
a UDP packet of 536 octets will always pass through an internetwork
(less 40 octets for the IPv6 header), as long as there are no IP
options prior to the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a
packet greater than 1500 octets it can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [8]
to determine the size of the packet that will traverse a network
path.
DHCP clients use Path MTU discovery when they have an address of
sufficient scope to reach the DHCP server. If a DHCP client does not
have such an address, that client MUST fragment its packets if the
resultant message size is greater than the minimum 1280 octets.
Path MTU Discovery for IPv6 is supported for both UDP and TCP and
can cause end-to-end fragmentation when the PMTU changes for a
destination.
The IPv6 Addressing Architecture specification [7] defines the
address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin
communications to discover neighbors on the link. For instance, a
client can send a Solicit message and locate a server or relay.
IPv6 Stateless Address Autoconfiguration [13] (Addrconf) specifies
procedures by which a node may autoconfigure addresses based on
router advertisements [10], and the use of a valid lifetime to
support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with addrconf is a design
requirement of DHCP (see Section 4).
IPv6 Neighbor Discovery [10] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [11]. To understand
IPv6 and Addrconf it is strongly recommended that implementors
understand IPv6 Neighbor Discovery.
Dynamic Updates to DNS [15] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space to
not only support autoconfiguration, but also autoregistration in
IPv6.
4. Design Goals
- DHCP is a mechanism rather than a policy. Network administrators
set their administrative policies through the configuration
parameters they place upon the DHCP servers in the DHCP domain
they're managing. DHCP is simply used to deliver parameters
according to that policy to each of the DHCP clients within the
domain.
- DHCP is compatible with IPv6 stateless autoconf [13].
- DHCP does not require manual configuration of network parameters
on DHCP clients, except in cases where such configuration is
needed for security reasons. A node configuring itself using
DHCP should require no user intervention.
- DHCP does not require a server on each link. To allow for scale
and economy, DHCP must work across DHCP relays.
- DHCP coexists with statically configured, non-participating nodes
and with existing network protocol implementations.
- DHCP clients can operate on a link without IPv6 routers present.
- DHCP will provide the ability to renumber network(s) when
required by network administrators [3].
- A DHCP client can make multiple, different requests for
configuration parameters when necessary from one or more DHCP
servers at any time.
- DHCP will contain the appropriate time out and retransmission
mechanisms to efficiently operate in environments with high
latency and low bandwidth characteristics.
5. Non-Goals
This specification explicitly does not cover the following:
- Specification of a DHCP server to server protocol.
- How a DHCP server stores its DHCP data.
- How to manage a DHCP domain or DHCP server.
- How a DHCP relay is configured or what sort of information it may
log.
6. Terminology
6.1. IPv6 Terminology
IPv6 terminology relevant to this specification from the IPv6 IPv6 terminology relevant to this specification from the IPv6
Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless
Address Autoconfiguration [14] is included below. Address Autoconfiguration [13] is included below.
address An IP layer identifier for an interface or a set of address An IP layer identifier for an interface or
interfaces. a set of interfaces.
unicast address unicast address An identifier for a single interface.
An identifier for a single interface. A packet sent A packet sent to a unicast address is
to a unicast address is delivered to the interface delivered to the interface identified by
identified by that address. that address.
multicast address multicast address An identifier for a set of interfaces
An identifier for a set of interfaces (typically (typically belonging to different nodes).
belonging to different nodes). A packet sent to a A packet sent to a multicast address is
multicast address is delivered to all interfaces delivered to all interfaces identified by
identified by that address. that address.
host Any node that is not a router. host Any node that is not a router.
IP Internet Protocol Version 6 (IPv6). The terms IPv4 and IP Internet Protocol Version 6 (IPv6). The
IPv6 are used only in contexts where it is necessary to terms IPv4 and IPv6 are used only in
avoid ambiguity. contexts where it is necessary to avoid
ambiguity.
interface interface A node's attachment to a link.
A node's attachment to a link.
link A communication facility or medium over which nodes link A communication facility or medium over
can communicate at the link layer, i.e., the layer which nodes can communicate at the link
immediately below IP. Examples are Ethernet (simple or layer, i.e., the layer immediately below
bridged); Token Ring; PPP links, X.25, Frame Relay, or IP. Examples are Ethernet (simple or
ATM networks; and Internet (or higher) layer "tunnels", bridged); Token Ring; PPP links, X.25,
such as tunnels over IPv4 or IPv6 itself. Frame Relay, or ATM networks; and Internet
(or higher) layer "tunnels", such as
tunnels over IPv4 or IPv6 itself.
link-layer identifier link-layer identifier A link-layer identifier for an interface.
a link-layer identifier for an interface. Examples Examples include IEEE 802 addresses for
include IEEE 802 addresses for Ethernet or Token Ring Ethernet or Token Ring network interfaces,
network interfaces, and E.164 addresses for ISDN links. and E.164 addresses for ISDN links.
link-local address link-local address An IP address having link-only
An IP address having link-only scope, indicated by scope, indicated by having the prefix
having the prefix (FE80::0000/64), that can be used (FE80::0000/64), that can be used to reach
to reach neighboring nodes attached to the same link. neighboring nodes attached to the same
Every interface has a link-local address. link. 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,
DHCP agents and clients. exchanged between 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.
prefix A bit string that consists of some number of initial prefix The initial bits of an address, or a set
bits of an address. of IP address that share the same initial
bits.
router A node that forwards IP packets not explicitly prefix length The number of bits in a prefix.
addressed to itself.
2.2. DHCP Terminology router A node that forwards IP packets not
explicitly addressed to itself.
6.2. DHCP Terminology
Terminology specific to DHCP can be found below. Terminology specific to DHCP can be found below.
abort status abort status A status value returned to the
A status value returned to the application that has application that has invoked a DHCP
invoked a DHCP client operation, indicating anything client operation, indicating anything
other than success. other than success.
agent address agent address The address of a neighboring DHCP Agent
The address of a neighboring DHCP Agent on the same 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
data records indexed by <prefix, UUID> containing the group of server data records containing
server's information about the addresses and other the server's information about the
information assigned to the IA. addresses in an IA and any other
configuration information assigned to
the client. A binding is indexed by the
tuple <prefix, DUID>, where the 'prefix'
is a prefix assigned to the link to
which the client is attached and 'DUID'
is the DUID from the IA in the binding.
DHCP Dynamic Host Configuration Protocol for IPv6. The DISCUSSION:
terms DHCPv4 and DHCPv6 are used only in contexts where
it is necessary to avoid ambiguity.
configuration parameter The indexing of an IA by <prefix,
DUID> is still under discussion.
An element of the configuration information set on the DHCP Dynamic Host Configuration Protocol
server and delivered to the client using DHCP. Such for IPv6. The terms DHCPv4 and DHCPv6
parameters may be used to carry information to be used are used only in contexts where it is
by a node to configure its network subsystem and enable necessary to avoid ambiguity.
communication on a link or internetwork, for example.
DHCP client (or client) configuration parameter An element of the configuration
A node that initiates requests on a link to obtain information set on the server and
configuration parameters from one or more DHCP servers. delivered to the client using DHCP.
Such parameters may be used to carry
information to be used by a node to
configure its network subsystem and
enable communication on a link or
internetwork, for example.
DHCP domain DHCP client (or client) A node that initiates requests on a link
A chunk of network topology managed by DHCP and to obtain configuration parameters from
operated by a single administrative entity. one or more DHCP servers.
DHCP server (or server) DHCP domain A set of links managed by DHCP and
A server is a node that responds to requests from operated by a single administrative
clients, and may or may not be on the same link as the entity.
client(s).
DHCP relay (or relay) DHCP server (or server) A server is a node that responds to
A node that acts as an intermediary to deliver DHCP requests from clients, and may or
messages between clients and servers, and is on the may not be on the same link as the
same link as a client. client(s).
DHCP agent (or agent) DHCP relay (or relay) A node that acts as an intermediary to
Either a DHCP server on the same link as a client, or a deliver DHCP messages between clients
DHCP relay. and servers, and is on the same link as
a client.
Identity association (IA) DHCP agent (or agent) Either a DHCP server on the same link as
A collection of addresses assigned to a client. Each a client, or a DHCP relay.
IA has an associated UUID. A server identifies an IA by
the tuple (prefix, UUID), where ``prefix'' is a prefix
assigned to the link to which the client is attached,
An IA may have 0 or more addresses associated with it.
Releasable resource DUID A DHCP unique identifier for a client.
(Removed; see section 23.3.)
transaction-ID DISCUSSION:
An unsigned integer to match responses with replies
initiated either by a client or server.
UUID Rules for choosing a DUID are TBD.
A universally unique identifier for a client.
DISCUSSION: Identity association (IA) A collection of addresses assigned to
a client. Each IA has an associated
DUID. An IA may have 0 or more addresses
associated with it.
Rules for choosing a UUID are TBD. transaction-ID An unsigned integer to match responses
with replies initiated either by a
client or server.
3. DHCP Constants 7. 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 7.1. Multicast Addresses
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-scoped multicast
This link-local multicast address is used by clients to address is used by clients to communicate with the
communicate with the on-link agent(s) when they do not on-link agent(s) when they do not know those agents'
know those agents' link-local address(es). All agents link-local address(es). All agents (servers and
(servers and relays) are members of this multicast relays) are members of this multicast group.
group.
All DHCP Servers address: FF05::1:3 All DHCP Servers address: FF05::1:3 This site-scoped multicast
This site-local multicast address is used by clients or address is used by clients or relays to communicate
relays to communicate with server(s), either because with server(s), either because they want to send
they want to send messages to all servers or because messages to all servers or because they do not know
they do not know the server(s) unicast address(es). the server(s) unicast address(es). Note that in order
Note that in order for a client to use this address, for a client to use this address, it must have an
it must have an address of sufficient scope to be address of sufficient scope to be reachable by the
reachable by the server(s). All servers within the server(s). All servers within the site are members of
site are members of this multicast group. this multicast group.
3.2. UDP ports DISCUSSION:
DHCP uses the following destination UDP [13] port numbers. While Is there a requirement for a site-scoped "All DHCP Clients"
multicast address, to be used as the default in sending
Reconfigure messages.
7.2. UDP ports
DHCP uses the following destination UDP [12] 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 servers as the destination port
clients. Also used by servers to send messages to for messages sent to clients and relays. Used by relay
relays. agents as the destination port for messages sent to
clients.
547 Agent port. Used by clients to send messages to 547 Agent port. Used as the destination port by clients
agents. Also used by relays to send messages to for messages sent to agents. Used as the destination
servers. port by relays for messages sent to servers.
3.3. DHCP message types 7.3. DHCP message types
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
are reserved and MUST be silently ignored. TBD--255 are reserved and MUST be silently ignored. The message code
for each message type is shown with the message name.
01 DHCP Solicit
The DHCP Solicit (or Solicit) message is used by clients
to locate servers. This message is multicast using the
All-DHCP-Agents address. Relay(s) forward Solicits as
necessary to off-link servers.
Section 9.1 contains more details about the Solicit message.
02 DHCP Advertise
The DHCP Advertise (or Advertise) message is used by servers
responding to Solicits. This message is unicast to the
client's link-local address (if the server and client are
on the same link) or unicast to the relay through which the
Solicit was sent for final delivery to the client.
Section 9.2 contains more details about the Advertise message.
03 DHCP Request
The DHCP Request (or Request) message is used by clients to
request configuration parameters from servers. This message is
multicast using the All-DHCP-Agents address. Relay(s) forward
Requests as necessary to off-link servers.
Section 9.3 contains more details about the Request message.
04 DHCP Reply
The DHCP Reply (or Reply) message is used by servers responding
to Request and Release messages. In the case of responding to
a Request message, the Reply contains configuration parameters
destined for the client. This message is unicast to the client
if the client has an address of sufficient scope that is
reachable by the server. Otherwise, it is unicast to the relay
through which the Request or Release message was sent for final
delivery to the client.
Section 9.4 contains more details about the Reply message. TBD DHCP Solicit The DHCP Solicit (or Solicit) message
is used by clients to locate servers.
05 DHCP Release TBD DHCP Advertise The DHCP Advertise (or Advertise)
message is used by servers responding
to Solicits.
The DHCP Release (or Release) message is used by clients to TBD DHCP Request The DHCP Request (or Request)
return one or more IP addresses to servers. The server will message is used by clients to request
acknowledge the receipt of the Release message by sending the configuration parameters from servers.
client a Reply message.
Section 9.5 contains more details about the Release message. TBD DHCP Confirm The DHCP Confirm (or Confirm) message
is used by clients to confirm that
the addresses assigned to an IA and
the lifetimes for those addresses,
as well as the current configuration
parameters assigned by the server to
the client are still valid.
06 DHCP Reconfigure TBD DHCP Renew The DHCP Renew (or Renew) message
is used by clients to obtain the
addresses assigned to an IA and the
lifetimes for those addresses, as
well as the current configuration
parameters assigned by the server to
the client. A client sends a Renew
message to the server that originally
assigned the IA when the lease on an
IA is about to expire.
07 DHCP Reconfigure-reply TBD DHCP Rebind The DHCP Rebind (or Rebind) message
is used by clients to obtain the
addresses assigned to an IA and the
lifetimes for those addresses, as
well as the current configuration
parameters assigned by the server to
the client. A clients sends a Rebind
message to all available DHCP servers
when the lease on an IA is about to
expire.
Removed; see section 23.2. TBD DHCP Reply The DHCP Reply (or Reply) message is
used by servers responding to Request,
Confirm, Renew, Rebind, Release and
Decline messages. In the case of
responding to a Request, Confirm,
Renew or Rebind message, the Reply
contains configuration parameters
destined for the client.
08 DHCP Reconfigure-init TBD DHCP Release The DHCP Release (or Release) message
is used by clients to return one or
more IP addresses to servers.
The DHCP Reconfigure-init (or Reconfigure-init) message is set TBD DHCP Decline The DHCP Decline (or Decline) message
by server(s) to inform client(s) that the server(s) has new or is used by clients to indicate that
updated configuration parameters, and that the client(s) are the client has determined that one or
to initiate a Request/Reply transaction with the server(s) in more addresses in an IA are already in
order to receive the updated information. use on the link to which the client is
connected.
Section 9.8 contains more details about the Reconfigure-init TBD DHCP Reconfigure-init The DHCP Reconfigure-init (or
message. Reconfigure-init) message is set by
server(s) to inform client(s) that
the server(s) has new or updated
configuration parameters, and that
the client(s) are to initiate a
Request/Reply transaction with the
server(s) in order to receive the
updated information.
3.4. Error Values 7.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 7.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______|_Addresses_unavailable_______________|_ |Unavail______|19______|_Addresses_unavailable_______________|_
3.4.2. Server-specific Error Values 7.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__________|_ |ConfNoMatch___|21______|_Client_record_Confirm_not_match_IA_|_
|NoServer______|23______|_Relay_cannot_find_Server_Address___|_
|RenwNoMatch___|22______|_Client_record_Renew_not_match_IA___|_
|RebdNoMatch___|23______|_Client_record_Rebind_not_match_IA__|_
|InvalidSource_|24______|_Invalid_Client_IP_address__________|_
|NoServer______|25______|_Relay_cannot_find_Server_Address___|_
|ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_ |ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_
3.5. Configuration Variables 7.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
Option'' in a Reply message. This option is TBD. Option" in a Reply message.
______________________________________________________________
|Parameter__________|Default|_Description___________________|_
|MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg__|_
|MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg__|_
|ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)_____|_
|ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)________|_
|SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)__|_
|REP_MSG_TIMEOUT____|250____|_REQ_Retrans_timer_(msecs)_____|_
|REQ_MSG_ATTEMPTS___|10_____|_MAX_Request_attempts__________|_
|REL_MSG_ATTEMPTS___|5______|_MAX_Release_attempts__________|_
|RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)_________|_
|REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts__________|_
|REC_REP_MIN________|5______|_Minimum_pause_interval_(secs)_|_
|REC_REP_MAX________|7200___|_Maximum_pause_interval_(secs)_|_
|REC_THRESHOLD______|100____|_%_of_required_clients_________|_
|SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)|_
4. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [2].
This document also makes use of internal conceptual variables
to describe protocol behavior and external variables that an
implementation must allow system administrators to change. The
specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demonstrate
protocol behavior. An implementation is not required to have them in
the exact form described here, so long as its external behavior is
consistent with that described in this document.
5. Background
Related work in IPv6 that would best serve an implementor to study
is the IPv6 Specification [5], the IPv6 Addressing Architecture [7],
IPv6 Stateless Address Autoconfiguration [14], IPv6 Neighbor
Discovery Processing [11], and Dynamic Updates to DNS [16]. These
specifications enable DHCP to build upon the IPv6 work to provide
both robust stateful autoconfiguration and autoregistration of DNS
Host Names.
The IPv6 Specification provides the base architecture and design of
IPv6. A key point for DHCP implementors to understand is that IPv6
requires that every link in the Internet have an MTU of 1280 octets
or greater (in IPv4 the requirement is 68 octets). This means that
a UDP packet of 536 octets will always pass through an internetwork
(less 40 octets for the IPv6 header), as long as there are no IP
options prior to the UDP header in the packet. But, IPv6 does not
support fragmentation at routers, so that fragmentation takes place
end-to-end between hosts. If a DHCP implementation needs to send a
packet greater than 1500 octets it can either fragment the UDP packet
into fragments of 1500 octets or less, or use Path MTU Discovery [9]
to determine the size of the packet that will traverse a network
path.
DHCP clients use Path MTU discovery when they have an address of
sufficient scope to reach the DHCP server. If a DHCP client does not
have such an address, that client MUST fragment its packets if the
resultant message size is greater than the minimum 1280 octets.
Path MTU Discovery for IPv6 is supported for both UDP and TCP and
can cause end-to-end fragmentation when the PMTU changes for a
destination.
The IPv6 Addressing Architecture specification [7] defines the
address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin
communications to discover neighbors on the link. For instance, a
client can send a Solicit message and locate a server or relay.
IPv6 Stateless Address Autoconfiguration [14] (Addrconf) specifies
procedures by which a node may autoconfigure addresses based on
router advertisements [11], and the use of a valid lifetime to
support renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with addrconf is a design
requirement of DHCP (see Section 6).
IPv6 Neighbor Discovery [11] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [12]. To understand
IPv6 and Addrconf it is strongly recommended that implementors
understand IPv6 Neighbor Discovery.
Dynamic Updates to DNS [16] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space
to not only support autoconfiguration, but also autoregistration
in IPv6. The security model to be used with DHCPv6 should conform
as closely as possible to the authentication model outlined in
RFC2402 [8].
6. Design Goals
- DHCP is a mechanism rather than a policy. Network administrators
set their administrative policies through the configuration
parameters they place upon the DHCP servers in the DHCP domain
they're managing. DHCP is simply used to deliver parameters
according to that policy to each of the DHCP clients within the
domain.
- DHCP is compatible with IPv6 stateless autoconf [14].
- DHCP does not require manual configuration of network parameters
on DHCP clients, except in cases where such configuration is
needed for security reasons. A node configuring itself using
DHCP should require no user intervention.
- DHCP does not require a server on each link. To allow for scale
and economy, DHCP must work across DHCP relays.
- DHCP coexists with statically configured, non-participating nodes
and with existing network protocol implementations.
- DHCP clients can operate on a link without IPv6 routers present.
- DHCP will provide the ability to renumber network(s) when
required by network administrators [3].
- A DHCP client can make multiple, different requests for
configuration parameters when necessary from one or more DHCP
servers at any time.
- DHCP will contain the appropriate time out and retransmission
mechanisms to efficiently operate in environments with high
latency and low bandwidth characteristics.
7. Non-Goals
This specification explicitly does not cover the following:
- Specification of a DHCP server to server protocol.
- How a DHCP server stores its DHCP data.
- How to manage a DHCP domain or DHCP server.
- How a DHCP relay is configured or what sort of information it may _________________________________________________________________________
log. |Parameter__________|Default|_Description______________________________|_
|MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_
|MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_
|ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_
|ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_
|SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_
|REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_
|QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_
|REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_
|RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_
|REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_
|REC_REP_MIN________|5______|_Minimum_pause_interval_(secs)____________|_
|REC_REP_MAX________|7200___|_Maximum_pause_interval_(secs)____________|_
|REC_THRESHOLD______|100____|_%_of_required_clients____________________|_
|SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_
8. Overview 8. Overview
This section provides a general overview of the interaction This section provides a general overview of the interaction between
between the functional entities of DHCP. The overview is organized the functional entities of DHCP. The overview is organized as a
as a series of questions and answers. Details of DHCP such series of questions and answers. Details of DHCP such as message
as message formats and retransmissions are left to sections 9, formats and retransmissions can be found in later sections of this
10, 11, 12, 14, 15, and 16. document.
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 [11] and stateless this process can be found in neighbor discovery [10] and stateless
autoconfiguration [14]. autoconfiguration [13].
8.2. How does a client find out about DHCP agents?
(Section removed, see 23.6
8.3. What if the client and server(s) are on different links? 8.2. What if the client and server(s) are on different links?
Use of DHCP in such environments requires one or more DHCP relays 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 receive 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. The client message is forwarded verbatim as the payload DHCP domain. The client message is forwarded verbatim as the payload
in a message from the relay to the server. A relay will include in a message from the relay to the server. A relay will include
one of its own addresses (of sufficient scope) from the interface one of its own addresses (of sufficient scope) from the interface
on the same link as the client, as well as the prefix length of on the same link as the client, as well as the prefix length of
that address, in its message to the server. Servers receiving that address, in its message to the server. Servers receiving
the forwarded traffic use this information to aid in selecting the forwarded traffic use this information to aid in selecting
configuration parameters appropriate to the client's link. The configuration parameters appropriate to the client's link. The
servers also use the relay's address as the destination to forward servers also use the relay's address as the destination to forward
client-destined messages for final delivery by the relay. client-destined messages for final delivery by the relay.
Relays forward client messages to servers using some combination of Relays forward client messages to servers using some combination
the FF05::1:3(All Servers) site-local multicast address, some other of the All DHCP Servers site-local multicast address, some other
(perhaps a combination) of site-local multicast addresses set up (perhaps a combination) of site-local multicast addresses set up
within the DHCP domain to include the servers in that domain, or a within the DHCP domain to include the servers in that domain, or a
list of unicast addresses for servers. The network administrator list of unicast addresses for servers. The network administrator
makes relay configuration decisions based upon the topological makes relay configuration decisions based upon the topological
requirements (scope) of the DHCP domain they are managing. Note requirements (scope) of the DHCP domain they are managing. Note
that if the DHCP domain spans more than the site-local scope, then 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 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 link so as to be reachable by servers outside the relays' site-local
environment. environment.
8.4. How does a client request configuration parameters from servers? 8.3. 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 Option Request Option 22.3 (ORO) relay). The client MAY include a Option Request Option 16.3 (ORO)
along with other options 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.7.
8.5. How do clients and servers identify and manage addresses? 8.4. How do clients and servers identify and manage addresses?
Servers and clients manage addresses in groups called ``identity Servers and clients manage addresses in groups called "identity
associations.'' Each identity associations is identified using associations." Each identity associations is identified using a
a unique identifier. An identity association may contain one or unique identifier. An identity association may contain one or
more IPv6 addresses. DHCP servers assign addresses to identity more IPv6 addresses. DHCP servers assign addresses to identity
associations. DHCP clients use the addresses in an identity associations. DHCP clients use the addresses in an identity
association to configure interfaces. There is always at least one association to configure interfaces. There is always at least one
identity association per interface that a client wishes to configure. identity association per interface that a client wishes to configure.
Each address in an IA has its own preferred and valid lifetime. Over Each address in an IA has its own preferred and valid lifetime. Over
time, the server may change the characteristics of the addresses in time, the server may change the characteristics of the addresses in
an IA; for example, by changing the preferred or valid lifetime for 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 an address in the IA. The server may also add or delete addresses
from an IA; for example, deleting old addresses and adding new from an IA; for example, deleting old addresses and adding new
addresses to renumber a client. A client can request the current addresses to renumber a client. A client can request the current
list of addresses assigned to an IA from a server through an exchange list of addresses assigned to an IA from a server through an exchange
of protocol messages. of protocol messages.
8.6. Can a client release its assigned addresses before the lease 8.5. Can a client release its assigned addresses before the lease
expires? expires?
A client forms a Release message, including options identifying A client forms a Release message, including options identifying
the IA to be released. The client sends the Release to the server the IA to be released. The client sends the Release to the server
which assigned the addresses 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 7.5), the client can abandon the Release attempt. In this
case, the address(es) in the IA will be reclaimed by the server(s) case, the address(es) in the IA will be reclaimed by the server(s)
when the lifetimes on the addresses expire. when the lifetimes on the addresses expire.
8.7. What if the client determines one or more of its assigned addresses 8.6. What if the client determines one or more of its assigned addresses
are already being used by another client? are already being used by another client?
If the client determines through a mechanism like Duplicate Address If the client determines through a mechanism like Duplicate Address
Detection [14] that the address it was assigned by the server is Detection [13] that the address it was assigned by the server is
already in use by another client, the client will form a Release already in use by another client, the client will form a Release
message, including the option carrying the in-use address. The message, including the option carrying the in-use address. The
option's status field MUST be set to the value reflecting the ``in option's status field MUST be set to the value reflecting the "in
use'' status of the address. use" status of the address.
8.8. How are clients notified of server configuration changes? 8.7. 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 / extend the lifetime on an address. or configuration information / extend the lifetime on an address. 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. To signal the need for client reconfiguration, whenever necessary. To signal the need for client reconfiguration,
the server will unicast a Reconfigure-init message to each the server will unicast a Reconfigure-init message to each
client individually. The server may use multicast to signal the client individually. The server may use multicast to signal the
reconfiguration to multiple clients simultaneously. (Note that reconfiguration to multiple clients simultaneously. (Note that
there is no mechanism defined in the protocol to guarantee that there is no mechanism defined in the protocol to guarantee that
every client actually performs a reconfiguration in response to a every client actually performs a reconfiguration in response to a
multicast reconfigure-init message.) A Reconfigure-init is a trigger multicast reconfigure-init message.) A Reconfigure-init is a trigger
which will cause the client(s) to initiate a standard Request/Reply which will cause the client(s) to initiate a standard Request/Reply
exchange with the server in order to acquire the new or updated exchange with the server in order to acquire the new or updated
addresses. addresses.
9. Message Formats and Identity Associations 9. Message Formats
All reserved fields in a message MUST be transmitted as zeroes and
ignored by the receiver of the message.
DISCUSSION:
Each DHCP message has an identical fixed format header; some Each DHCP message has an identical fixed format header; some messages
messages also allow a variable format area for options. Not also allow a variable format area for options. Not all fields in
all fields in the header are used in every message. In this the header are used in every message. In this section, every field
section, every field is included in every message format is described for every message and fields that are not used in a
diagram and fields that are not used in a message are marked message are marked as "unused". All unused fields in a message MUST
as ``unused''. As an alternative, the unused fields could be transmitted as zeroes and ignored by the receiver of the message.
be labeled ``unused'' in the format diagram.
9.1. DHCP Solicit Message Format The DHCP message header:
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 | preference | transaction-ID | | msg-type | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| client-link-local-address | | client-link-local-address |
| (16 octets) | | (16 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| server-address | | server-address |
| (16 octets) | | (16 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
preference . .
(unused) MUST be 0 . options .
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
transaction-ID 9.1. DHCP Solicit Message Format
An unsigned integer generated by the client used to
identify this Solicit message.
client-link-local-address msg-type TBD
The link-local address of the interface for which the
client is using DHCP. preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the
client used to identify this Solicit
message.
client-link-local-address The link-local address of the
interface for which the client is
using DHCP.
server-address (unused) MUST be 0 server-address (unused) MUST be 0
options See section 16.
9.2. DHCP Advertise Message Format 9.2. DHCP Advertise Message Format
0 1 2 3 msg-type TBD
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 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
preference An unsigned integer indicating a server's willingness
to provide service to the client.
transaction-ID An unsigned integer used to identify this Advertise preference An unsigned integer indicating a
message. Copied from the client's Solicit message. server's willingness to provide
service to the client.
client-link-local-address transaction-ID An unsigned integer used to identify
The IP link-local address of the client interface this Advertise message. Copied from
from which the client issued the Solicit message. the client's Solicit message.
server-address client-link-local-address The IP link-local address of the
The IP address of the server. If the DHCP domain client interface from which the client
crosses site boundaries, then this address MUST be issued the Solicit message.
globally-scoped.
options Options are described elsewhere in this document server-address The IP address of the server that
generated this message. If the DHCP
domain crosses site boundaries, then
this address MUST be globally-scoped.
See Sections 14.4 and 15.3 for information about how clients and options See section 16.
servers handle the preference field.
9.3. DHCP Request Message Format 9.3. DHCP Request Message Format
0 1 2 3 msg-type TBD
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 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
preference preference (unused) MUST be 0
(unused) MUST be 0
transaction-ID transaction-ID An unsigned integer generated by the
An unsigned integer generated by the client used to client used to identify this Request
identify this Request message. message.
client-link-local-address client-link-local-address The link-local address of the client
The link-local address of the client interface from interface from which the client will
which the client will issue the Request message. issue the Request message.
server-address server-address The IP address of the server to which
The IP address of the server to which the the client's the this message is directed, copied
Request message is directed, copied from an Advertise from an Advertise message.
options See section 16.
9.4. DHCP Confirm Message Format
msg-type TBD
preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the
client used to identify this Confirm
message. message.
options client-link-local-address The link-local address of the client
Options are described elsewhere in this document. interface from which the client will
issue the Request message.
9.4. DHCP Reply Message Format server-address MUST be zero.
0 1 2 3 options See section 16.
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 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
preference An unsigned integer indicating a server's willingness 9.5. DHCP Renew Message Format
to provide service to the client.
transaction-ID msg-type TBD
An unsigned integer used to identify this Reply
message. Copied from the client's Request message.
client-link-local-address preference (unused) MUST be 0
The link-local address of the interface for which the
client is using DHCP.
server-address transaction-ID An unsigned integer generated by the
The IP address of the server. If the DHCP domain client used to identify this Request
crosses site boundaries, then this address MUST be message.
client-link-local-address The link-local address of the client
interface from which the client will
issue the Request message.
server-address The IP address of the server to which
this Renew message is directed, which
MUST be the address of the server from
which the IAs in this message were
originally assigned.
options See section 16.
9.6. DHCP Rebind Message Format
msg-type TBD
preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the
client used to identify this Request
message.
client-link-local-address The link-local address of the client
interface from which the client will
issue the Request message.
server-address MUST be zero.
options See section 16.
9.7. DHCP Reply Message Format
msg-type TBD
preference An unsigned integer indicating a
server's willingness to provide
service to the client.
transaction-ID An unsigned integer used to identify
this Reply message. Copied from the
client's Request message.
client-link-local-address The link-local address of the
interface for which the client is
using DHCP.
server-address The IP address of the server.
If the DHCP domain crosses site
boundaries, then this address MUST be
globally-scoped. globally-scoped.
options options See section 16.
Options are described elsewhere in this document.
9.5. DHCP Release Message Format 9.8. DHCP Release Message Format
0 1 2 3 msg-type TBD
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type = 5 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
preference (unused) MUST be 0 preference (unused) MUST be 0
transaction-ID transaction-ID An unsigned integer generated by the
An unsigned integer generated by the client used to client used to identify this Release
identify this Release message. message.
P (unused) MUST be 0 client-link-local-address The client's link-local address for
the interface from which the client
issued the Release message.
client-link-local-address server-address The IP address of the server that
The client's link-local address for the interface from assigned the addresses.
which the client issued the Release message.
server-address options See section 16.
The IP address of the server that assigned the
addresses.
options See section 22. 9.9. DHCP Decline Message Format
9.6. DHCP Reconfigure Message Format msg-type TBD
The Reconfigure message has been deleted (see section 23.2). preference (unused) MUST be 0
9.7. DHCP Reconfigure-reply Message Format transaction-ID An unsigned integer generated by the
client used to identify this Release
message.
The Reconfigure-reply message has been deleted (see section 23.2). client-link-local-address The client's link-local address for
the interface from which the client
issued the Release message.
9.8. DHCP Reconfigure-init Message Format server-address The IP address of the server that
assigned the addresses.
0 1 2 3 options See section 16.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.10. DHCP Reconfigure-init Message Format
| msg-type = 8 | preference | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| client-link-local-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
preference (unused) MUST be 0 preference (unused) MUST be 0
transaction-ID transaction-ID An unsigned integer generated
An unsigned integer generated by the server to identify by the server to identify this
this Reconfigure-init message Reconfigure-init message
client-link-local-address client-link-local-address (unused) MUST be 0
(unused) MUST be 0
server-address server-address The IP address of the DHCP server
The IP address of the DHCP server issuing the issuing the Reconfigure-init message.
Reconfigure-init message. MUST be of sufficient scope MUST be of sufficient scope to be
to be reachable by all clients. reachable by all clients.
options SHOULD only include an ``Options request option'' options See section 16.
(ORO) and/or authentication options. No configuration
information SHOULD be included. See section 22 more
information about options.
9.9. Relay-forward message 10. Relay messages
Relay agents exchange messages with servers to forward messages
between clients and servers that are not connected to the same link.
10.1. Relay-forward message
0 1 2 3 0 1 2 3
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 TBD | prefix length | | | msg-type | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| relay-address | | relay-address |
| | | |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number and length) .... | | options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type TBD msg-type TBD
prefix-length The length of the prefix in the address in the
"relay-address" field.
prefix-length relay-address An address assigned to the interface through which
The length of the prefix in the address in the the message from the client was received.
``relay-address'' field.
relay-address
An address assigned to the interface through which the
message from the client was received.
options MUST include a ``Client message option''; see options MUST include a "Client message option"; see
section 22.4. section 16.4.
9.10. Server-forward message 10.2. Relay-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 TBD | prefix length | | | msg-type | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| relay-address | | relay-address |
| | | |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number and length) .... | | options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type TBD msg-type TBD
prefix-length
The length of the prefix in the address in the
``relay-address'' field.
relay-address prefix-length The length of the prefix in the address in the
An address identifying the interface through which the "relay-address" field.
message from the server should be forwarded; copied
from the ``client-forward'' message.
options MUST include a ``Server message option''; see relay-address An address identifying the interface through which
section 22.5. the message from the server should be forwarded;
copied from the "client-forward" message.
9.11. Identity association options MUST include a "Server message option"; see
section 16.5.
An ``identity-association'' (IA) is a construct through which a 11. Identity association
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.
10. DHCP Server Solicitation 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 DUID and a list of associated IPv6 addresses (the list
may be empty). A client associates an IA with one of its interfaces
and uses the IA to obtain IPv6 addresses for that interface from a
server.
See section 16.2 for the representation of an IA in a DHCP message.
12. DHCP Server Solicitation
This section describes how a client locates servers. The behavior of This section describes how a client locates servers. The behavior of
client, server, and relay implementations is discussed, along with client, server, and relay implementations is discussed, along with
the messages they use. the messages they use.
(Prefix advertisements have been deleted; see 23.9.) 12.1. Solicit Message Validation
10.1. Solicit Message Validation
Clients MUST silently discard any received Solicit messages. Clients MUST silently discard any received Solicit messages.
Agents MUST silently discard any received Solicit messages if Agents MUST silently discard any received Solicit messages if the
the ``client-link-local-address'' field does not contain a valid "client-link-local-address" field does not contain a valid link-local
link-local address. address.
10.2. Advertise Message Validation 12.2. Advertise Message Validation
Servers MUST 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 ``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 Solicit message. client used in its Solicit message.
o The ``client-link-local-address'' field value does not match the o The "client-link-local-address" field value does not match the
link-local address of the interface upon which the client sent link-local address of the interface upon which the client sent
the Solicit message. the Solicit message.
10.3. Client Behavior 12.3. Client Behavior
Clients use the Solicit message to discover DHCP servers configured Clients use the Solicit message to discover DHCP servers configured
to serve addresses on the link to which the client is attached. to serve addresses on the link to which the client is attached.
(Prefix advertisement by servers has been deleted; see section 23.9.) 12.3.1. Creation and sending of the Solicit message
10.3.1. Creation and sending of the Solicit message
The client sets the ``msg-type'' field to 1, and places the The client sets the "msg-type" field to TBD, and places the
link-local address of the interface it wishes to configure in the link-local address of the interface it wishes to configure in the
``client-link-local-address'' field. The client sets all other "client-link-local-address" field.
fields to zero.
The client sends the Solicit message to the FF02::1:2 (All DHCP The client generates a transaction ID inserts this value in the
Agents) multicast address, destination port 547. The source port "transaction-ID" field.
selection can be arbitrary, although it SHOULD be possible using a
client configuration facility to set a specific source port value.
10.3.2. Time out and retransmission of Solicit Messages The client MAY include an Option Request Option in the Solicit
message. The client MUST NOT include any other options except those
specifically allowed as defined by specific options.
The client sends the Solicit message to the All DHCP Agents
multicast address, destination port 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
12.3.2. Time out and retransmission of Solicit Messages
The client's first Solicit message on the interface MUST be delayed 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).
The client waits ADV_MSG_TIMEOUT, collecting Advertise messages. The client waits ADV_MSG_TIMEOUT, collecting Advertise messages.
If no Advertise messages are received, the client retransmits If no Advertise messages are received, the client retransmits
the Solicit, and doubles the ADV_MSG_TIMEOUT value. This process the Solicit, and doubles the ADV_MSG_TIMEOUT value. This process
continues until either one or more Advertise messages are received or continues until either one or more Advertise messages are received or
ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value. Thereafter, Solicits ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value. Thereafter, Solicits
are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
made, at which time the client stops trying to DHCP configure the made, at which time the client stops trying to DHCP configure the
interface. An event external to DHCP is required to restart the DHCP interface. An event external to DHCP is required to restart the DHCP
configuration process. configuration process.
Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 3.5. ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5.
10.3.3. Receipt of Advertise messages 12.3.3. Receipt of Advertise messages
Upon receipt of one or more validated Advertise messages, the client Upon receipt of one or more validated Advertise messages, the client
selects one or more Advertise messages based upon the following selects one or more Advertise messages based upon the following
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 17.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 which have an address scope of availability of IP addresses which have an address 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 server typically store information about each server, such as server
preference value, addresses advertised, when the advertisement was preference value, addresses advertised, when the advertisement was
received, and so on. Depending on the requirements of the client's received, and so on. Depending on the requirements of the client's
invoking user, the client MAY initiate a configuration exchange with invoking user, the client MAY initiate a configuration exchange with
the server(s) immediately, or MAY defer this exchange until later. the server(s) immediately, or MAY defer this exchange until later.
10.4. Relay Behavior If the client needs to select an alternate server in the case that a
chosen server does not respond, the client choose the server with the
For this discussion, the Relay may be configured to use a list of next highest preference value.
server destination addresses, which may include unicast addresses,
the FF05::1:3 (All DHCP Servers) multicast address, or other
multicast addresses selected by the network administrator. If
the Relay has not been explicitly configured, it will use the
FF05::1:3 (All DHCP Servers) multicast address as the default.
10.4.1. Relaying of Solicit messages
When a Relay receives a valid Solicit message, it constructs a
Relay-forward message. The client Solicit message is carried as the
payload of a ``client-message'' option. The relay places an address
from the interface on which the Solicit message was received in the
``relay-address'' field and the prefix length for that address in
the ``prefix-length'' field. The Relay then sends the Relay-forward
message to the list of server destination addresses that it has been
configured with.
10.4.2. Relaying of Advertise messages
When the relay receives a Relay-reply message, it extracts the server The client MAY choose a less-preferred server if that server has a
message from the ``server-message'' option and forwards the server better set of advertised parameters.
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 12.4. 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 12.4.1. Receipt of Solicit messages
If the server receives a Solicit message, the client must be on the If the server receives a Solicit message, the client must be on the
same link as the server. If the server receives a Relay-forward same link as the server. If the server receives a Relay-forward
message containing a Solicit message, the client must be on the message containing a Solicit message, the client must be on the
link to which the prefix identified by the ``relay-address'' and link to which the prefix identified by the "relay-address" and
``prefix-length'' fields in the Relay-forward message is assigned. "prefix-length" fields in the Relay-forward message is assigned.
The server records the ``relay-address'' field from the Relay-forward The server records the "relay-address" field from the Relay-forward
message and extracts the solicit message from the ``client-message'' message and extracts the solicit message from the "client-message"
option. 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 12.4.2. Creation and sending of Advertise messages
The server sets the ``msg-type'' field to 2 and copies the values The server sets the "msg-type" field to TBD and copies the values
of the following fields from the client's Solicit to the Advertise of the following fields from the client's Solicit to the Advertise
message: message:
o transaction-ID o transaction-ID
o client-link-local-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
Advertise message. The server sets the ``preference'' field message. The server sets the "preference" field according to its
according to its configuration information. See section 15.3 for a configuration information. See section 18.3 for a description of
description of server preference. server preference.
The server MUST include options to the Advertise message containing
any addresses that would be assigned to IAs contained in the Solicit
message from the client. The server MAY include other options the
server will return to the client in a subsequent Reply message.
The information in these options will be used by the client in the
selection of a server if the client receives more than one Advertise
message.
If the Solicit message was received in a Relay-forward message, the If the Solicit message was received in a Relay-forward message, the
server constructs a Relay-reply message with the Advertise message server constructs a Relay-reply message with the Advertise message in
in the payload of a ``server-message'' option. The server unicasts the payload of a "server-message" option. The server unicasts the
the Relay-reply message to the address in the ``relay-address'' field Relay-reply message to the address in the "relay-address" field from
from the Relay-forward message. the Relay-forward message.
If the Solicit message was received directly by the server, the If the Solicit message was received directly by the server, the
server unicasts the Advertise message directly to the client using server unicasts the Advertise message directly to the client using
the ``client-link-local-address'' field value as the destination the "client-link-local-address" field value as the destination
address. The Advertise message MUST be unicast through the interface address. The Advertise message MUST be unicast through the interface
on which the Solicit message was received. on which the Solicit message was received.
DISCUSSION: 13. DHCP Client-Initiated Configuration Exchange
(From Ted Lemon) There is a danger in using Solicit versus A client initiates a message exchange with the server to acquire
DHCPDISCOVER: in the Solicit paradigm, the client has to or update configuration information of interest. The client may
choose the DHCP server before it knows if the DHCP server initiate the configuration exchange as part of the operating system
will give it an IP address, or which addresses the server is configuration process or when requested to do so by the application
willing to assign to the client. It may be that there are layer.
two or more DHCP servers owned by the same administrative
domain, and both are theoretically willing to give the
client addresses, but only one actually has any addresses to
give.
11. DHCP Client-Initiated Configuration Exchange The client uses the following messages to initiate a configuration
event with the server:
A client uses the Request-Reply message exchange to acquire Request Obtain initial configuration information when the client
configuration information of interest. The client may initiate the has no assigned addresses
configuration exchange as part of the operating system configuration
process or when requested to do so by the application layer. Confirm Confirm the validity of assigned addresses and other
configuration changes when the client's assigned
addresses may not be valid; for example, when the client
reboots or loses its connection to a link
Renew Extend the lease on an IA through the server that
originally assigned the IA
Rebind Extend the lease on an IA through any server willing to
extend the lease
A client uses the Release-Reply message exchange to indicate to the 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 DHCP server that the client will no longer be using the addresses in
the released IA. the released IA.
11.1. Request Message Validation A client uses the Decline-Reply message exchange to indicate to the
DHCP server that the client has detected that one or more addresses
assigned by the server is already in use on the client's link.
Clients MUST silently discard any received Request messages. 13.1. Client Message Validation
Agents MUST discard any Request messages in which the Clients MUST silently discard any received client messages (Request,
``client-link-local-address'' field does not contain a valid Confirm, Renew, Rebind, Release or Decline messages).
link-local address.
Servers MUST discard any received Request message which meets any of Agents MUST discard any received client messages in which the
the following criteria: "client-link-local-address" field does not contain a valid link-local
address.
o The ``server-address'' field value does not match any of the Servers MUST discard any received client messages in which the
server's addresses. "options" field contains an authentication option, and the server
cannot successfully authenticate the client.
o The ``options'' field contains an authentication option, and the Servers MUST discard any received Request or Renew message in which
server cannot successfully authenticate the client. the "server-address" field value does not match any of the server's
addresses.
11.2. Reply Message Validation 13.2. Server Message Validation
Servers MUST silently discard any received Reply messages. Servers MUST silently discard any received server messages (Reply
messages).
Clients MUST discard any Reply message that meets any of the Clients MUST discard any server messages that meet 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 in the server message does
client used in its Request or Release message. not match the value the client used in its Request or Release
message.
o The ``client-link-local-address'' field value does not match the o The "client-link-local-address" field value in the server message
link-local address of the interface upon which the client sent in does not match the link-local address of the interface upon which
its Request or Release message. the client sent in its Request or Release message.
o The Reply message contains an authentication option, and the o The server 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 Relay-reply message in which the Relays MUST discard any Relay-reply message in which the
``client-link-local-address'' in the encapsulated Reply message does "client-link-local-address" in the encapsulated Reply message does
not contain a valid link-local address. not contain a valid link-local address.
11.3. Release Message Validation 13.3. Client Behavior
Clients MUST silently discard any received Release messages.
Agents MUST discard any Release message in which the
``client-link-local-address'' field does not contain a valid
link-local address.
Servers MUST discard any received Release message in which the
``options'' field contains an authentication option, and the server
cannot successfully authenticate the client.
11.4. Client Behavior
A client will generate one or more Request messages to acquire A client will use Request, Confirm, Renew and Rebind messages to
configuration information. A client may initiate such an exchange acquire and confirm the validity of configuration information.
automatically in order to acquire the necessary network parameters A client may initiate such an exchange automatically in order
to communicate with nodes off-link. The client uses the server to acquire the necessary network parameters to communicate with
address information from previous Advertise message(s) for use in nodes off-link. The client uses the server address information
constructing Request message(s). Note that a client may request from previous Advertise message(s) for use in constructing Request
configuration information from one or more servers at any time. message(s). Note that a client may request configuration information
from one or more servers at any time.
A client uses the Release message in the management of IAs when: A client uses the Release message in the management of IAs when
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 determined through DAD or some other method that A client uses the Decline message when the client has determined
one or more of the addresses assigned by the server in the IA is through DAD or some other method that one or more of the addresses
already in use by a different client. assigned by the server in the IA is already in use by a different
client.
o The client has been instructed to release the IA prior to the IA 13.3.1. Creation and sending of Request messages
expiration time since it is no longer needed.
11.4.1. Creation and sending of Request messages If a client has no valid IPv6 addresses of sufficient scope to
communicate with a DHCP server, it may send a Request message to
obtain new addresses. The client includes one or more IAs in the
Request message, to which the server assigns new addresses. The
server then returns to IA(s) to the client in a Reply message.
The client sets the ``msg-type'' field to 3, and places the The client sets the "msg-type" field to TBD, and places the
link-local address of the interface it wishes to acquire link-local address of the interface it wishes to acquire
configuration information for in the ``client-link-local-address'' configuration information for in the "client-link-local-address"
field. field.
The client generates a transaction ID inserts this value in the The client generates a transaction ID 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.
The client adds any appropriate options, including one or more IA The client adds any appropriate options, including one or more IA
options (if the client is requesting that the server assign it some options (if the client is requesting that the server assign it some
network addresses). If the client does include any IA options, network addresses). The list of addresses in each included IA MUST
it MUST include the list of addresses the client currently has be empty.
associated with that IA. If the client is requesting configuration of
a new IA, the list of addresses MUST be empty.
11.4.2. Time out and retransmission of Request Messages The client sends the Request message to the All DHCP Agents
multicast address, destination port 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
The server will respond to the Request message with a Reply The server will respond to the Request message with a Reply
message. If no Reply message is received within REP_MSG_TIMEOUT message. If no Reply message is received within REP_MSG_TIMEOUT
milliseconds, the client retransmits the Request with the same milliseconds, the client retransmits the Request with the same
transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits
again. The client continues this process until a Reply is received again. The client continues this process until a Reply is received
or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
which time the client MUST abort the configuration attempt. The which time the client MUST abort the configuration attempt. The
client SHOULD report the abort 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 7.5.
11.4.3. Receipt of Reply message in response to a Request 13.3.2. Creation and sending of Confirm messages
Upon the receipt of a valid Reply message, the client extracts the Whenever a client may have moved to a new link, its IPv6 addresses
configuration information contained in the Reply. If the ``status'' may no longer be valid. Examples of times when a client may have
field contains a non-zero value, the client reports the error status moved to a new link include:
to the application layer.
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 Confirm/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.
The client sets the "msg-type" field to TBD, and places the
link-local address of the interface it wishes to acquire
configuration information for in the "client-link-local-address"
field.
The client generates a transaction ID inserts this value in the
"transaction-ID" field.
The client sets the "server-address" field to 0.
The client adds any appropriate options, including one or more IA
options (if the client is requesting that the server confirm the
validity of some network addresses). If the client does include
any IA options, it MUST include the list of addresses the client
currently has associated with that IA.
The client sends the Confirm message to the All DHCP Agents
multicast address, destination port 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
Servers will respond to the Confirm message with a Reply message. If
no Confirm message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Confirm with the same transaction-ID,
and doubles the REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received or QRY_MSG_ATTEMPTS
unsuccessful attempts have been made, at which time the client MUST
abort the configuration attempt. The client SHOULD report the abort
status to the application layer.
Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS
are documented in section 7.5.
If the client receives no response to its Confirm message, it MAY
restart the configuration process by locating a different DHCP server
with an Advertise message and sending a Request to that server, as
described in section 13.3.1.
13.3.3. Creation and sending of Renew messages
IPv6 addresses assigned to a client through an IA use 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.
The client sets the "msg-type" field to TBD, and places the
link-local address of the interface it wishes to acquire
configuration information for in the "client-link-local-address"
field.
The client generates a transaction ID inserts this value in the
"transaction-ID" field.
The client places the address of the destination server in the
"server-address" field.
The client adds any appropriate options, including one or more IA
options (if the client is requesting that the server extend the lease
on some IAs; note that the client may check the status of other
configuration parameters without asking for lease extensions). If
the client does include any IA options, it MUST include the list of
addresses the client currently has associated with that IA.
The client sends the Renew message to the All DHCP Agents multicast
address, destination port 547. The source port selection can
be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
The server will respond to the Renew message with a Reply message.
If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Renew with the same transaction-ID, and
doubles the REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received or until time T2 is
reached (see section 13.3.4).
Default and initial values for REP_MSG_TIMEOUT are documented in
section 7.5.
13.3.4. Creation and sending of Rebind messages
At time T2 for an IA (which will only be reached if the server to
which the Request message was sent at time T1 has not responded),
the client initiates a Request/Reply message exchange. The client
includes an IA option with all addresses currently assigned to the IA
in its Request message. The client multicasts this message to the
All DHCP Agents multicast address.
The client sets the "msg-type" field to TBD, and places the
link-local address of the interface it wishes to acquire
configuration information for in the "client-link-local-address"
field.
The client generates a transaction ID inserts this value in the
"transaction-ID" field.
The client sets the "server-address" field to 0.
The client adds any appropriate options, including one or more IA
options. If the client does include any IA options (if the client is
requesting that the server extend the lease on some IAs; note that
the client may check the status of other configuration parameters
without asking for lease extensions), it MUST include the list of
addresses the client currently has associated with that IA.
The client sends the Rebind message to the All DHCP Agents multicast
address, destination port 547. The source port selection can
be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
The server will respond to the Rebind message with a Reply message.
If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Rebind with the same transaction-ID, and
doubles the REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received.
Default and initial values for REP_MSG_TIMEOUT are documented in
section 7.5.
DISCUSSION:
The client has several alternatives to choose from if it
receives no response to its Rebind message.
- When the lease on the IA expires, the client may choose
to use a Solicit message to locate a new DHCP server and
send a Request for the expired IA to the new server
- Some addresses in the IA may have lifetimes that extend
beyond the lease of the IA, so the client may choose
to continue to use those addresses; once all of the
addresses have expired, the client may choose to locate
a new DHCP server
- The client may have other addresses in other IAs, so the
client may choose to discard the expired IA and use the
addresses in the other IAs
13.3.5. Receipt of Reply message in response to a Reply, Confirm, Renew
or Rebind message
Upon the receipt of a valid Reply, Confirm, Renew or Rebind message,
the client extracts the configuration information contained in the
Reply. If the "status" field contains a non-zero value, the client
reports the error status to the application layer.
The client records the T1 and T2 times for each IA in the Reply The client records the T1 and T2 times for each IA in the Reply
message. The client records any addresses included with IAs in message. The client records any addresses included with IAs in
the Reply message. The client updates the preferred and valid the Reply message. The client updates the preferred and valid
lifetimes for the addresses in the IA from the lifetime information lifetimes for the addresses in the IA from the lifetime information
in the IA option. The client leaves any addresses that the client in the IA option. The client leaves any addresses that the client
has associated with the IA that are not included in the IA option has associated with the IA that are not included in the IA option
unchanged. unchanged.
Management of the specific configuration information is detailed in Management of the specific configuration information is detailed in
the definition of each option, in section 22. the definition of each option, in section 16.
11.4.4. Creation and sending of Release messages When the client receives an Unavail error status in an IA from the
server for a Request message the client will have to find a new
server to create an IA Association.
The client sets the ``msg-type'' field to 5, and places the When the client receives a NoBinding error status in an IA from the
server for a Confirm message the client can assume it needs to send a
Request to reestablish an IA Association with the server.
When the client receives a Conf_NoMatch error status in an IA from
the server for a Confirm message the client can send a Renew message
to the server to extend the lease for the addresses.
When the client receives a NoBinding error status in an IA from the
server for a Renew message the client can assume it needs to send a
Request to reestablish an IA Association with the server.
When the client receives a Renw_NoMatch error status in an IA from
the server for a Renew message the client can assume it needs to send
a Request to reestablish an IA Association with the server.
When the client receives an Unavail error status in an IA from the
server for a Renew message the client can assume it needs to send a
Request to reestablish an IA Association set of addresses with the
server.
When the client receives a NoBinding error status in an IA from the
server for a Rebind message the client can assume it needs to send
a Request to reestablish an IA Association with the server or try
another server.
When the client receives a Rebd_NoMatch error status in an IA from
the server for a Rebind message the client can assume it needs to
send a Request to reestablish an IA Association with the server or
try another server.
When the client receives an Unavail error status in an IA from the
server for a Rebind message the client can assume it needs to send a
Request to reestablish an IA Association set of addresses with the
server or try another server.
13.3.6. Creation and sending of Release messages
The client sets the "msg-type" field to TBD, and places the
link-local address of the interface associated with the configuration link-local address of the interface associated with the configuration
information it wishes to release in the ``client-link-local-address'' information it wishes to release in the "client-link-local-address"
field. field.
The client generates a transaction ID and places this value in the The client generates a transaction ID and places this value in the
``transaction-ID'' field. "transaction-ID" field.
The client includes options containing the IAs it is releasing in the
``options'' field. The appropriate ``status'' field in the options
MUST be set to indicate the reason for the release.
The client places the IP address of the server that allocated the The client places the IP address of the server that allocated the
address(es) in the ``server-address'' field. address(es) in the "server-address" field.
The client includes options containing the IAs it is releasing in the
"options" field. The appropriate "status" field in the options MUST
be set to indicate the reason for the release.
If the client is configured to use authentication, the client If the client is configured to use authentication, the client
generates the appropriate authentication option, and adds this option generates the appropriate authentication option, and adds this option
to the ``options'' field. Note that the authentication option MUST to the "options" field. Note that the authentication option MUST be
be the last option in the ``options'' field. See section 22.7 for the last option in the "options" field. See section 16.7 for more
more details about the authentication option. details about the authentication option.
(The client always forwards Release messages to the server through a
relay; see section 11.5.)
11.4.5. Time out and retransmission of Release Messages 13.3.7. Time out and retransmission of Release Messages
If no Reply message is received within REP_MSG_TIMEOUT milliseconds, If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Release, doubles the REP_MSG_TIMEOUT the client retransmits the Release, doubles the REP_MSG_TIMEOUT
value, and waits again. The client continues this process until a value, and waits again. The client continues this process until a
Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been
made, at which time the client SHOULD abort the release attempt. made, at which time the client SHOULD abort the release attempt.
The client SHOULD return the abort status to the application, if an The client SHOULD return the abort status to the application, if an
application initiated the release. application 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 7.5.
Note that if the client fails to release the IA, the addresses Note that if the client fails to release the IA, the addresses
assigned to the IA will be reclaimed by the server when the lease assigned to the IA will be reclaimed by the server when the lease
associated with it expires. associated with it expires.
11.4.6. Receipt of Reply message in response to a Release 13.3.8. Creation and sending of Decline messages
The client sets the "msg-type" field to TBD, and places the
link-local address of the interface associated with the configuration
information it wishes to decline in the "client-link-local-address"
field.
The client generates a transaction ID and places this value in the
"transaction-ID" field.
The client places the IP address of the server that allocated the
address(es) in the "server-address" field.
The client includes options containing the IAs it is declining in the
"options" field. The appropriate "status" field in the options MUST
be set to indicate the reason for declining the address.
If the client is configured to use authentication, the client
generates the appropriate authentication option, and adds this option
to the "options" field. Note that the authentication option MUST be
the last option in the "options" field. See section 16.7 for more
details about the authentication option.
13.3.9. Time out and retransmission of Decline Messages
If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Decline, doubles the REP_MSG_TIMEOUT
value, and waits again. The client continues this process until a
Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have
been made, at which time the client SHOULD abort the attempt to
decline the address. The client SHOULD return the abort status to
the application, if an application initiated the release.
Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented in section 7.5.
13.3.10. Receipt of Reply message in response to a Release message
Upon receipt of a valid Reply message, the client can consider the 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 13.4. Server Behavior
The description of the Request/Reply message exchange in this section For this discussion, the Server is assumed to have been configured in
makes no assumptions about the timing or state of the client when an implementation specific manner with configuration of interest to
it initiates a Request/Reply message exchange. Sections 11.4.8 clients.
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 13.4.1. Receipt of Request messages
If a client has no valid IPv6 addresses of sufficient scope to Upon the receipt of a valid Request message from a client the server
communicate with a DHCP server, it may a Request message to obtain can respond to, (implementation-specific administrative policy
new addresses. The client includes one or more IAs in the Request satisfied) the server scans the options field.
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 The server then constructs a Reply message and sends it to the
client.
Whenever a client may have moved to a new link, its IPv6 addresses The server SHOULD process each option for the client in an
may no longer be valid. Examples of times when a client may have implementation-specific manner. The server MUST construct a Reply
moved to a new link include: message containing the following values:
o The client reboots msg-type TBD
o The client is physically disconnected from a wired connection preference Enter the servers preference to
provide services to the client.
o The client returns from sleep mode transaction-ID Enter the transaction-ID from the
Request message.
o The client using a wireless technology changes cells client-link-local address Enter the client-link-local address
from the Request message.
In any situation when a client may have moved to a new link, the server address Enter the IP address of the server.
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 When the server receives a Request and IA option is included the
client is requesting the configuration of a new IA by the server.
The server MUST take the clients IA and associate a binding for
that client in an implementation-specific manner within the servers
configuration parameter database for DHCP clients.
IPv6 addresses assigned to a client through an IA use the same If the server cannot provide addresses to the client it SHOULD send
preferred and valid lifetimes as IPv6 addresses obtained through back an empty IA to the client with the status field set to Unavail.
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 If the server can provide addresses to the client it MUST send back
to extend the lifetimes on assigned addresses through the T1 and the IA to the client with all fields entered and a status of Success,
T2 parameters assigned to an IA. If the server does not assign an and add the IA as a new client binding.
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 13.4.2. Receipt of Confirm messages
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 Upon the receipt of a valid Confirm message from a client the server
which the Request message was sent at time T1 has not responded), can respond to, (implementation-specific administrative policy
the client initiates a Request/Reply message exchange. The client satisfied) the server scans the options field.
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 The server then constructs a Reply message and sends it to the
client.
11.5.1. Relaying of Request or Release messages The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:
When a Relay receives a valid Request or Release message, it msg-type TBD
constructs a Relay-forward message. The client message is carried
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 preference Enter the servers preference to
provide services to the client.
For this discussion, the Server is assumed to have been configured in transaction-ID Enter the transaction-ID from the
an implementation specific manner with configuration of interest to Confirm message.
clients.
11.6.1. Receipt of Request messages client-link-local address Enter the client-link-local address
from the Confirm message.
Upon the receipt of a valid Request message from a client the server server address Enter the server's address.
When the server receives a Confirm and an IA option is included the
client is requesting confirmation that the addresses in the IA are
valid. The server SHOULD locate the clients binding and verify the
information in the IA from the client matches the information stored
for that client.
If the server cannot find a client entry for this IA the server
SHOULD return an empty IA with status set to NoBinding.
If the server finds that the information for the client does not
match what is in the servers records for that client the server
should send back an empty IA with status set to Conf_NoMatch.
If the server finds a match to the Confirm then the server should
send back the IA to the client with status set to success.
13.4.3. Receipt of Renew messages
Upon the receipt of a valid Renew message from a client the server
can respond to, (implementation-specific administrative policy can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field. satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the The server then constructs a Reply message and sends it to the
client. client.
DISCUSSION: The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:
This section needs text about managing IAs and determining msg-type TBD
options to be returned to client.
11.6.2. Receipt of Release messages preference Enter the servers preference to
provide services to the client.
transaction-ID Enter the transaction-ID from the
Confirm message.
client-link-local address Enter the client-link-local address
from the Confirm message.
server address Enter the server's address.
When the server receives a Renew and IA option from a client it
SHOULD locate the clients binding and verify the information in the
IA from the client matches the information stored for that client.
If the server cannot find a client entry for this IA the server
SHOULD return an empty IA with status set to NoBinding.
If the server finds that the addresses in the IA for the client do
not match the clients binding the server should return an empty IA
with status set to Renw_NoMatch.
If the server cannot Renew addresses for the client it SHOULD send
back an empty IA to the client with the status field set to Unavail.
If the server finds the addresses in the IA for the client then the
server SHOULD send back the IA to the client with new lease times
and T1/T2 times if the default is not being used, and set status to
Success.
13.4.4. Receipt of Rebind messages
Upon the receipt of a valid Rebind message from a client the server
can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the
client.
The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:
msg-type TBD
preference Enter the servers preference to
provide services to the client.
transaction-ID Enter the transaction-ID from the
Confirm message.
client-link-local address Enter the client-link-local address
from the Confirm message.
server address Enter the server's address.
When the server receives a Renew and IA option from a client it
SHOULD locate the clients binding and verify the information in the
IA from the client matches the information stored for that client.
If the server cannot find a client entry for this IA the server
SHOULD return an empty IA with status set to NoBinding.
If the server finds that the addresses in the IA for the client do
not match the clients binding the server should return an empty IA
with status set to Rebd_NoMatch.
If the server cannot Rebind addresses for the client it SHOULD send
back an empty IA to the client with the status field set to Unavail.
If the server finds the addresses in the IA for the client then the
server SHOULD send back the IA to the client with new lease times
and T1/T2 times if the default is not being used, and set status to
Success.
13.4.5. Receipt of Release messages
Upon the receipt of a valid Release message, the server examines the Upon the receipt of a valid Release message, the server examines the
IAs and the addresses in the IAs for validity. If the IAs in the IAs and the addresses in the IAs for validity. If the IAs in the
message are in a binding for the client and the addresses in the IAs message are in a binding for the client and the addresses in the IAs
have been assigned by the server to those IA, the server deletes have been assigned by the server to those IA, the server deletes
the addresses from the IAs and makes the addresses available for the addresses from the IAs and makes the addresses available for
assignment to other clients. assignment to other clients.
The server then generates a Reply message. If all of the IAs were The server then generates a Reply message. If all of the IAs were
valid and the addresses successfully released,, the server sets the valid and the addresses successfully released,, the server sets the
``status'' field to ``Success''. If any of the IAs were invalid or "status" field to "Success". If any of the IAs were invalid or if
if any of the addresses were not successfully released, the server any of the addresses were not successfully released, the server
releases none of the addresses in the message and sets the ``status'' releases none of the addresses in the message and sets the "status"
field to ``NoBinding''(section 3.4). field to "NoBinding"(section 7.4).
DISCUSSION: DISCUSSION:
What is the behavior of the server relative to a ``partially What is the behavior of the server relative to a "partially
released'' IA; i.e., an IA for which some but not all released" IA; i.e., an IA for which some but not all
addresses are released? addresses are released?
Can a client send an empty IA to release all addresses in Can a client send an empty IA to release all addresses in
the IA? the IA?
If the IA becomes empty - all addresses are released - can If the IA becomes empty - all addresses are released - can
the server discard any record of the IA? the server discard any record of the IA?
11.6.3. Creation and sending of Reply messages 13.4.6. Sending of Reply messages
DISCUSSION:
XXX - This section needs to be fixed (see section 11.6.1).
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 client's link-local address
o server-address
The server sets the ``status'' field appropriately (see the table
in section 3.4) based upon the results of processing the client's
request.
If the Request or Release message from the client was originally If the Request or Release message from the client was originally
received by the server, the server unicasts the Reply message to the received by the server, the server unicasts the Reply message to the
link-local address in the ``client-link-local-address'' field. link-local address in the "client-link-local-address" field.
If the message was originally received in a Forward-request or If the message was originally received in a Forward-request or
Forward-release message from a relay, the server places the Reply Forward-release message from a relay, the server places the Reply
message in the options field of a Response-reply message and unicasts message in the options field of a Response-reply message and unicasts
the message to the relay's address from the original message. the message to the relay's address from the original message.
12. DHCP Server-Initiated Configuration Exchange 14. DHCP Server-Initiated Configuration Exchange
A server initiates a configuration exchange on behalf of the
administrator of the DHCP domain. An administrator may initiate such
an exchange when new links are added to the domain or existing links
are to be renumbered. Other examples include changes in the location
of directory servers, addition of new services such as printing, and
availability of new software (system or application).
DISCUSSION:
Changed ``networks'' to ``links'' here (ed.). Why would
adding new links cause a server-initiated configuration
exchange?
12.1. Reconfigure Message Validation
Reconfigure messages have been deleted; see section 23.2.
12.2. Reconfigure-reply Message Validation
Reconfigure-reply messages have been deleted; see section 23.2. A server initiates a configuration exchange to force DHCP clients
to obtain new addresses and other configuration information. For
example, an administrator may use a server-initiated configuration
exchange when links in the DHCP domain are to be renumbered. Other
examples include changes in the location of directory servers,
addition of new services such as printing, and availability of new
software (system or application).
12.3. Reconfigure-init Message Validation 14.1. 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 do Clients MUST discard any Reconfigure-init messages that do
not contain an authentication option or that fail the client's not contain an authentication option or that fail the client's
authentication check. authentication check.
12.4. Server Behavior Clients MUST discard any Reconfigure-init messages that contain a
transaction-ID that matches the transaction-ID in a Reconfigure-init
message previously received from the same DHCP server.
For this discussion, the server is assumed to have a 14.2. Server Behavior
implementation-specific interface by which an administrator
may initiate a reconfiguration event with some set of clients.
A server sends a Reconfigure-init message to trigger a client to A server sends a Reconfigure-init message to trigger a client to
initiate immediately a Request/Reply message exchange with the initiate immediately a Request/Reply message exchange with the
server. A server can send Reconfigure-init messages only to those server. A server may unicast a Reconfigure-init message directly
clients who have an address of sufficient scope to be reachable by to a single client or use multicast to deliver a Reconfigure-init
the server. Thus, those clients who have not requested an IP address message to multiple clients.
and are off-link cannot be reconfigured by the server.
DISCUSSION:
It would be possible to forward Reconfigure-init messages
through relays if the server records the client's link-local
address and the relay's address from the client's Request
message.
12.4.1. Creation and sending of Reconfigure messages
Reconfigure messages have been deleted; see section 23.2.
12.4.2. Time out and retransmission of Reconfigure messages
12.4.3. Receipt of Reconfigure-reply messages
12.4.4. Creation and sending of Reconfigure-init messages 14.2.1. Creation and sending of Reconfigure-init messages
The server sets the ``msg-type'' field to 8. The server generates The server sets the "msg-type" field to TBD. The server generates
a transaction-ID and inserts it in the ``transaction-ID'' field. a transaction-ID and inserts it in the "transaction-ID" field.
The server places its address (of appropriate scope) in the The server places its address (of appropriate scope) in the
``server-address'' field. "server-address" field.
The server MAY include an ORO option 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.
The server MUST include an authentication option with the appropriate The server MUST include an authentication option with the appropriate
settings and add that option as the last option in the ``options'' settings and add that option as the last option in the "options"
field of the Reconfigure-init message. field of the Reconfigure-init message.
Typically, the server will not provide more than an ORO and / or The server MAY include a Reconfigure-delay option in a
Authentication option, since it will provide the new configuration Reconfigure-init message to be unicast to a client, and MUST
information as part of the Request/Reply transaction triggered by the include a Reconfigure-delay option in a Reconfigure-init message to
Reconfigure-init message. be multicast to a group of clients.
The server MUST NOT include any other options in the Reconfigure-init
except as specifically allowed in the definition of individual
options.
The server may either unicast the Reconfigure-init message to one The server may either unicast the Reconfigure-init message to one
client or multicast the message to one or more Reconfigure Multicast client or multicast the message to one or more Reconfigure Multicast
Addresses previously sent as options to the clients. The server Addresses previously sent as options to the clients. The server
may unicast Reconfigure-init messages to more than one client may unicast Reconfigure-init messages to more than one client
concurrently; for example, to reliably reconfigure all clients, the concurrently; for example, to reliably reconfigure all clients, the
server will unicast a Reconfigure-init message to each client. server will unicast a Reconfigure-init message to each client.
If the server unicasts to one or more clients, it waits for a Request If the server unicasts to one or more clients, it waits for a Request
message from those clients confirming that it has received the message from those clients confirming that it has received the
skipping to change at page 35, line 14 skipping to change at page 36, line 52
If the server multicasts the Reconfigure-init message, it must use If the server multicasts the Reconfigure-init message, it must use
some TBD authentication mechanism that can authenticate the server to some TBD authentication mechanism that can authenticate the server to
multiple clients. There is no reliability mechanism for multicast multiple clients. There is no reliability mechanism for multicast
Reconfigure-init messages. A server might use multicast in the Reconfigure-init messages. A server might use multicast in the
case where it does not have a list of its clients; for example, a case where it does not have a list of its clients; for example, a
server that distributes configuration information to clients using server that distributes configuration information to clients using
stateless autoconfiguration might not keep a list of clients it has stateless autoconfiguration might not keep a list of clients it has
communicated with. communicated with.
12.4.5. Time out and retransmission of Reconfigure-init messages DISCUSSION:
It the server does not receive a Request message from the client Authentication of multicast reconfigure-init is still an
open issue.
See section 18.2 for recommendations on the use of multicast
and unicast Reconfigure-init messages for reliable client
reconfiguration.
14.2.2. Time out and retransmission of unicast Reconfigure-init messages
If the server does not receive a Request message from the client
in RECREP_MSG_TIMEOUT milliseconds, the server retransmits in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT
value and waits again. The server continues this process until value and waits again. The server continues this process until
REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point
the server SHOULD abort the reconfigure process. the server SHOULD abort the reconfigure process.
Default and initial values for RECREP_MSG_TIMEOUT and Default and initial values for RECREP_MSG_TIMEOUT and
REC_MSG_ATTEMPTS are documented in section 3.5. REC_MSG_ATTEMPTS are documented in section 7.5.
12.4.6. Receipt of Request messages 14.2.3. Time out and retransmission of multicast Reconfigure-init
messages
After the server transmits the initial Reconfigure-init message,
the server waits RECREP_MSG_TIMEOUT milliseconds. The server
then retransmits the Reconfigure-init message, doubles the
RECREP_MSG_TIMEOUT value and waits again. The server repeats this
process until a total of REC_MSG_ATTEMPTS Reconfigure-init messages
have been transmitted.
Default and initial values for RECREP_MSG_TIMEOUT and
REC_MSG_ATTEMPTS are documented in section 7.5.
14.2.4. Receipt of Request messages
The server generates and sends Reply message(s) to the client as The server generates and sends Reply message(s) to the client as
described in section 11.6.3, including in the ``option'' field new described in section 13.4.6, including in the "option" field new
values for configuration parameters. values for configuration parameters.
12.5. Client Behavior 14.3. Client Behavior
A client MUST always monitor UDP port 546 for Reconfigure-init A client MUST always monitor UDP port 546 for Reconfigure-init
messages on interfaces upon which it has acquired DHCP parameters. messages on interfaces upon which it has acquired DHCP parameters.
Since the results of a reconfiguration event may affect application Since the results of a reconfiguration event may affect application
layer programs, the client SHOULD log these events, and MAY notify layer programs, the client SHOULD log these events, and MAY notify
these programs of the change through an implementation-specific these programs of the change through an implementation-specific
interface. interface.
12.5.1. Receipt of Reconfigure-init messages 14.3.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.2. Creation and sending of Request messages 14.3.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 13.3.1 with the following differences:
transaction-ID transaction-ID The client copies the
The client copies the transaction-ID from the transaction-ID from the
Reconfigure-init message into the Request message. Reconfigure-init message into the
Request message.
IAs IAs The client includes IA options
The client includes IA options containing the addresses containing the addresses the client
the client currently has assigned to those IAs for the currently has assigned to those IAs
interface through which the Reconfigure-init message was for the interface through which
the Reconfigure-init message was
received. received.
Pause before sending Request Pause before sending Request The client pauses before sending
The client pauses before sending the Request for the Request for a random value
a random value within the range REC_REP_MIN and within the range REC_REP_MIN and
REC_REP_MAX seconds. This delay helps reduce the REC_REP_MAX seconds. This delay
load on the server generated by processing large helps reduce the load on the
numbers of triggered Request messages from a multicast server generated by processing
large numbers of triggered
Request messages from a multicast
Reconfigure-init message. Reconfigure-init message.
12.5.3. Time out and retransmission of Request messages 14.3.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 13.3.1 for details.
12.5.4. Receipt of Reply messages 14.3.4. Receipt of Reply messages
Upon the receipt of a valid Reply message, the client extracts the Upon the receipt of a valid Reply message, the client extracts the
contents of the ``option'' field, and sets (or resets) configuration contents of the "option" field, and sets (or resets) configuration
parameters appropriately. The client records and updates the parameters appropriately. The client records and updates the
lifetimes for any addresses specified in IAs in the Reply message. lifetimes for any addresses specified in IAs in the Reply message.
If the configuration parameters changed were requested by the If the configuration parameters changed were requested by the
application layer, the client notifies the application layer of the application layer, the client notifies the application layer of the
changes using an implementation-specific interface. changes using an implementation-specific interface.
13. Using DHCP for network renumbering 15. Relay Behavior
This section has been deleted (to be moved to ``Notes about DHCP''
doc?).
14. DHCP Client Implementor Notes
This section provides helpful information for the client implementor
regarding their implementations. The text described here is not part
of the protocol, but rather a discussion of implementation features
we feel the implementor should consider during implementation.
14.1. Primary Interface
Since configuration parameters acquired through DHCP can be
interface-specific or more general, the client implementor SHOULD
provide a mechanism by which the client implementation can be
configured to specify which interface is the primary interface. The
client SHOULD always query the DHCP data associated with the primary
interface for non-interface specific configuration parameters. An
implementation MAY implement a list of interfaces which would be
scanned in order to satisfy the general request. In either case, the
first interface scanned is considered the primary interface.
By allowing the specification of a primary interface, the client
implementor identifies which interface is authoritative for
non-interface specific parameters, which prevents configuration
information ambiguity within the client implementation.
14.2. Advertise Message and Configuration Parameter Caching
If the hardware the client is running on permits it, the implementor
SHOULD provide a cache for Advertise messages and a cache of
configuration parameters received through DHCP. Providing these
caches prevents unnecessary DHCP traffic and the subsequent load
this generates on the servers. The implementor SHOULD provide a
configuration knob for setting the amount of time the cache(s) are
valid.
14.3. Time out and retransmission variables
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
through the use of the ``DHCP Retransmission Parameter Option'',
which is documented in section 22.6. A client implementation SHOULD
be able to reset these variables using the values from this option.
14.4. Server Preference
A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
Solicit message to collect Advertise messages and compare their
preferences (see section 15.3), unless it receives an Advertise
message with a preference of 255. If the client receives an
Advertise message with a preference of 255, then the client MAY act
immediately on that Advertise without waiting for any more additional
Advertise messages.
15. DHCP Server Implementor Notes
This section provides helpful information for the server implementor.
15.1. Client Bindings
A server implementation MUST use the IA's UUID and the prefix
specification from which the client sent its Request message(s) as an
index for finding configuration parameters assigned to the client.
While it isn't critical to keep track of the other parameters
assigned to a client, the server MUST keep track of the addresses it
has assigned to an IA.
The server should periodically scan its bindings for addresses whose
leases have expired. When the server finds expired addresses, it
MUST delete the assignment of those addresses, thereby making these
addresses available to other clients.
The client bindings MUST be stored in non-volatile storage.
The server implementation should provide policy knobs to control
whether or not the lifetimes on assigned addresses are renewable, and
by how long.
15.2. Reconfigure-init Considerations
A server implementation MUST provide an interface to the
administrator for initiating reconfigure-init events.
A server implementation may provide a mechanism for allowing the
specification of how many clients comprise a reconfigure multicast
group. This enables the administrator to control the hit a server
takes when a reconfigure-init event occurs.
15.3. Server Preference
The server implementation SHOULD allow the setting of a server
preference value by the administrator. The server preference
variable is an unsigned single octet value (0--255), with the lowest
preference being 0 and the highest 255. Clients will choose higher
preference servers over those with lower preference values. If you
don't choose to implement this feature in your server, you MUST set
the server preference field to 0 in the Advertise messages generated
by your server.
15.4. Request Message Transaction-ID Cache
In order to improve performance, a server implementation MAY include
an in memory transaction-ID cache. This cache is indexed by client
binding and transaction-ID, and enables the server to quickly
determine whether a Request is a retransmission or a new Request
without the cost of a database lookup. If an implementor chooses to
implement this cache, then they SHOULD provide a configuration knob
to tune the lifetime of the cache entries.
16. DHCP Relay Implementor Notes
A relay implementation SHOULD allow the specification of a list of
destination addresses for forwarded messages. This list MAY contain
any mixture of unicast addresses and multicast addresses.
If a relay receives an ICMP message in response to a DHCP message it
has forwarded, it SHOULD log this event.
17. Open Issues for Working Group Discussion
This section contains some items for discussion by the working group.
17.1. Authentication
Authentication is not discussed in this document.
17.2. DHCP-DNS interaction
Interaction among DHCP servers, clients and DNS servers is not
discussed in this document.
17.3. Release vs. Decline
Should there be a separate Decline message through which the client
informs the server that it has discovered an address that is in use
by some other host?
17.4. Request messages
In DHCPv4, there has been much confusion about overloading
DHCPREQUEST with the actions of initial address allocation
(INIT), address confirmation (INIT-REBOOT), and extending leases
(RENEW/REBIND).
The model for DHCPv6 messages described in section 11 also uses one
type of message, Request, in each of the scenarios in sections 11.4.8
through 11.4.10. The DHCPv6 specification in this document does not
differentiate the actions taken by a server based on different times
at which a client might initiate a Request/Reply exchange with a
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.
It may be necessary to define different server behaviors for each of
the client scenarios. For example, in the address-reconfirmation
scenario (section 11.4.9), servers cannot safely assign new addresses
to a client. The reconfirmation Request is broadcast to multiple
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.
17.5. Use of term ``agent''
The term ``agent'', taken to mean ``relay agent or server'', may be
confusing. ``relay agent or server'' might be clearer.
17.6. Use of terms ``subnet'' and ``network''
The term ``subnet'' has been eliminated from the document. The term
``network'' is no longer used to describe a link, collection of links
or collection of IPv6 addresses.
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.
19. Year 2000 considerations
Since all times are relative to the current time of the transaction,
there is no problem within the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the current year.
20. IANA Considerations
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
the future.
Section 3.1 lists several multicast addresses used by DHCP.
This document also defines several status codes that are to For this discussion, the Relay may be configured to use a list of
be returned with the Reply and Reconfigure-reply messages (see server destination addresses, which may include unicast addresses,
sections 9.4 and 9.7). The non-zero values for these status codes the All DHCP Servers multicast address, or other multicast addresses
which are currently specified are shown in the table in section 3.4. selected by the network administrator. If the Relay has not been
explicitly configured, it will use the All DHCP Servers multicast
address as the default.
There is a DHCPv6 option described in section 22.6, which allows 15.1. Relaying of Solicit messages
clients and servers to exchange values for some of the timing
and retransmission parameters defined in section 3.5. Adding new
parameters in the future would require extending the values by which
the parameters are indicated in the DHCP option. Since there needs
to be a list kept, the default values for each parameter should also
be stored as part of the list.
All of these protocol elements may be specified to assume new values When a Relay receives a valid Solicit message, it constructs
at some point in the future. New values should be approved by the a Relay-forward message. The relay places an address from
process of IETF Consensus [10]. the interface on which the Solicit message was received in the
"relay-address" field and the prefix length for that address in the
"prefix-length" field. This address will be used by the server to
identify the link to which the client is connected and will be used
by the relay to forward the Advertise message from the server back to
the client.
21. Acknowledgments The relay constructs a "relay-message" option 16.4 that contains
the entire Solicit message from the client in the data field of the
option. The relay places the "relay-message" option along with any
"relay-specific" options in the options field of the Relay-forward
message. The Relay then sends the Relay-forward message to the list
of server destination addresses that it has been configured with.
Thanks to the DHC Working Group for their time and input into the 15.2. Relaying of Advertise messages
specification. Ralph Droms and Thomas Narten have had a major
role in shaping the continued improvement of the protocol by their
careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald
Maguire, and Mike Carney for their studied review as part of the
Last Call process. Thanks also for the consistent input, ideas, and
review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.
Thanks to Steve Deering and Bob Hinden, who have consistently When the relay receives a Relay-reply message, it extracts the
taken the time to discuss the more complex parts of the IPv6 Advertise message from the "server-message" option and forwards the
specifications. server message to the address in the client-link-local-address field
in the Advertise message. The relay forwards the server message
through the interface identified in the "relay-address" field in the
Relay-reply message.
22. DHCP options 16. DHCP options
Options are used to carry additional information and parameters Options are used to carry additional information and parameters
in DHCP messages. Every option shares a common base format, as in DHCP messages. Every option shares a common base format, as
described in section 22.1. described in section 16.1.
this document describes the DHCP options defined as part of the base this document describes the DHCP options defined as part of the base
DHCP specification. Other options may be defined in the future in a DHCP specification. Other options may be defined in the future in a
separate document. separate document.
22.1. Format of DHCP options 16.1. Format of DHCP options
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data | | option-data |
| (option-len octets) | | (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code option-code An unsigned integer identifying the specific option
An unsigned integer identifying the specific option type type carried in this option.
carried in this option.
option-len option-len An unsigned integer giving the length of the data in
An unsigned integer giving the length of the data in
this option in bytes. this option in bytes.
option-data option-data The data for the option; the format of this data
The data for the option; the format of this data depends depends on the definition of the option.
on the definition of the option.
22.2. Identity association option 16.2. Identity association option
The identity association option is used to carry an identity The identity association option is used to carry an identity
association, the parameters associated with the IA and the addresses association, the parameters associated with the IA and the addresses
assigned to the IA. assigned to the IA.
The format of the IA option is: The format of the IA option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | variable | | TBD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IA UUID | | IA DUID |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 | | T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 | | T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addrs | IPv6 address | | IA status | num-addrs | addr status | prefix length |
+-+-+-+-+-+-+-+-+ (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 address |
| (16 octets) |
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | pref. len | preferred lifetime | | preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addr status | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IPv6 address |
| (16 octets) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref. lifetime (cont.) | valid lifetime | | pref. lifetime (cont.) | valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid lifetime (cont.) | IPv6 address | | valid lifetime (cont.) | IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code option-code TBD
TBD
option-len option-len Variable; equal to 17 + num-addrs*25
Variable; equal to 17 + num-addrs*25
IA UUID IA DUID The unique identifier for this IA; chosen by the client
The unique identifier for this IA; chosen by the client
T1 The time at which the client contacts the server from T1 The time at which the client contacts the server from
which the addresses in the IA were obtained to extend which the addresses in the IA were obtained to extend
the lifetimes of the addresses assigned to the IA. the lifetimes of the addresses assigned to the IA.
T2 The time at which the client contacts any available T2 The time at which the client contacts any available
server to extend the lifetimes of the addresses assigned server to extend the lifetimes of the addresses assigned
to the IA. to the IA.
num-addrs IA status Status of the IA in this option.
An unsigned integer giving the number of addresses
num-addrs An unsigned integer giving the number of addresses
carried in this IA option (MAY be zero). carried in this IA option (MAY be zero).
IPv6 address addr status Status of this address.
An IPv6 address assigned to this IA.
preferred lifetime prefix length Prefix length for this address.
The preferred lifetime for the associated IPv6 address.
valid lifetime IPv6 address An IPv6 address assigned to this IA.
The valid lifetime for the associated IPv6 address.
The ``IPv6 address'', ``preferred lifetime'' and ``valid lifetime'' preferred lifetime The preferred lifetime for the associated IPv6
fields are repeated for each address in the IA option (as determined address.
by the ``num-addrs'' field).
DISCUSSION: valid lifetime The valid lifetime for the associated IPv6 address.
The details of the format and the selection of an IA's UUID The "IPv6 address", "preferred lifetime" and "valid lifetime" fields
are TBD. are repeated for each address in the IA option (as determined by the
"num-addrs" field).
DISCUSSION: DISCUSSION:
An IA has no explicit ``lifetime'' or ``lease length'' of The details of the format and the selection of an IA's DUID
its own. When the lifetimes of all of the addresses in an are TBD.
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 Note that an IA has no explicit "lifetime" or "lease length" of
its own. When the lifetimes of all of the addresses in an IA have
expired, the IA can be considered as having expired. T1 and T2
are included to give servers explicit control over when a client
recontacts the server about a specific IA.
16.3. Option request option
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 | | requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 45, line 4 skipping to change at page 42, line 47
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 | | requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD. option-code TBD.
option-len option-len Variable; equal to twice the number of option codes
Variable; equal to twice the number of option codes
carried in this option. carried in this option.
option-data option-data A list of the option codes for the options requested
A list of the option codes for the options requested in in this option.
this option.
22.4. Client message option 16.4. Client message option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP client message | | DHCP client message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD option-code TBD
option-len option-len Variable; equal to the length of the forwarded DHCP
Variable; equal to the length of the forwarded DHCP
client message. client message.
option-data option-data The message received from the client; forwarded
The message received from the client; forwarded verbatim verbatim to the server.
to the server.
22.5. Server message option 16.5. Server message option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP server message | | DHCP server message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD option-code TBD
option-len
Variable; equal to the length of the forwarded DHCP option-len Variable; equal to the length of the forwarded DHCP
server message. server message.
option-data option-data The message received from the server; forwarded
The message received from the server; forwarded verbatim verbatim to the client.
to the client.
22.6. Retransmission parameter option 16.6. Retransmission parameter option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data | | option-data |
| (option-len octets) | | (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code option-code An unsigned integer identifying the specific option
An unsigned integer identifying the specific option type type carried in this option.
carried in this option.
option-len option-len An unsigned integer giving the length of the data in
An unsigned integer giving the length of the data in
this option in bytes. this option in bytes.
option-data option-data The data for the option; the format of this data
The data for the option; the format of this data depends depends on the definition of the option.
on the definition of the option.
22.7. Authentication option 16.7. Authentication option
The authentication option is TBD. The authentication option is TBD.
23. Changes in this draft 16.8. Reconfigure-delay option
This section describes the changes between this version of the DHCPv6 The Reconfigure-delay option specifies the amount of time a client
specification and draft-ietf-dhc-dhcpv6-15.txt. should delay before sending a Request message in response to a
Reconfigure-init message.
23.1. Order of sections 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| minimum delay time (msec) | maximum delay time (msec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
New sections have been added at the end of this document to minimize The client chooses a random number between the minimum delay time and
changes in section numbering. Those sections will be rearranged in a the maximum delay time and delays that number of milliseconds before
future revision. sending its Request message.
23.2. Reconfigure message 16.9. DSTM Global IPv4 Address Option
DHCP Reconfigure and Reconfigure-reply messages and the associated The DSTM Global IPv4 Address Option informs a client or server that
mechanisms have been removed from this draft of the specification. the Identity Association Option (IA) following this option will
contain an IPv4-Mapped IPv6 Address [?] in the case of a Client
receiving the option, or is a Request for an IPv4-Mapped IPv6 Address
from a client in the case of a DHCPv6 Server receiving the option.
The option can also provide an IPv6 address to be used as the Tunnel
Endpoint (TEP) to encapsulate an IPv4 packet within IPv6.
23.3. Releasable resources This option can be used with the Request, Reply, and Reconfigure-Init
Messages for cases where a server wants to assign to clients
IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO).
``Releasable resources'' have been removed from this draft. 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-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel End Point (TEP) |
| (If Present) |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
23.4. DHCP message header option-code: TBD
option-length: Variable: 0 or 16
Tunnel End Point: IPv6 Address if Present
A common fixed DHCP message header has been defined. Not all fields A DSTM IPv4 Global Address Option MUST only apply to the IA following
are used in all messages. this option.
23.5. Design goals 17. DHCP Client Implementor Notes
The second sentence in the 8th design goal bullet has been removed. This section provides helpful information for the client implementor
regarding their implementations. The text described here is not part
of the protocol, but rather a discussion of implementation features
we feel the implementor should consider during implementation.
23.6. Overview 17.1. Primary Interface
Section 8.2 (DHCP agents) has been removed. DHCP clients no longer Since configuration parameters acquired through DHCP can be
need to know about specific DHCP agents. interface-specific or more general, the client implementor SHOULD
provide a mechanism by which the client implementation can be
configured to specify which interface is the primary interface. The
client SHOULD always query the DHCP data associated with the primary
interface for non-interface specific configuration parameters. An
implementation MAY implement a list of interfaces which would be
scanned in order to satisfy the general request. In either case, the
first interface scanned is considered the primary interface.
Section 8.3 has been modified to reflect the new encapsulating By allowing the specification of a primary interface, the client
mechanism through which relays forward client messages to servers. implementor identifies which interface is authoritative for
non-interface specific parameters, which prevents configuration
information ambiguity within the client implementation.
Section 8.6 and 8.7 have been modified to describe ``identity 17.2. Advertise Message and Configuration Parameter Caching
associations''.
Section 8.8 has been modified to reflect the deletion of If the hardware the client is running on permits it, the implementor
``reconfigure'' and ``reconfigure-reply'' messages. SHOULD provide a cache for Advertise messages and a cache of
configuration parameters received through DHCP. Providing these
caches prevents unnecessary DHCP traffic and the subsequent load
this generates on the servers. The implementor SHOULD provide a
configuration knob for setting the amount of time the cache(s) are
valid.
23.7. Message formats, 9 17.3. Time out and retransmission variables
Message formats have been changed. All messages share a common fixed Note that the client time out and retransmission variables outlined
message header followed by options. The various control bits (``P'', in section 7.5 can be configured on the server and sent to the client
``C'') have been removed from the message header. through the use of the "DHCP Retransmission Parameter Option", which
is documented in section 16.6. A client implementation SHOULD be
able to reset these variables using the values from this option.
23.8. Solicit and Advertise messages, (section 10) 17.4. Server Preference
The description of the message exchanges have been changed to A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
reflect: Solicit message to collect Advertise messages and compare their
preferences (see section 18.3), unless it receives an Advertise
message with a preference of 255. If the client receives an
Advertise message with a preference of 255, then the client MAY act
immediately on that Advertise without waiting for any more additional
Advertise messages.
- New relay behavior - encapsulated client messages 18. DHCP Server Implementor Notes
- Use of IAs This section provides helpful information for the server implementor.
23.9. Prefix advertisement 18.1. Client Bindings
Servers no longer advertise prefixes. A server implementation MUST use the IA's DUID and the prefix
specification from which the client sent its Request message(s) as an
index for finding configuration parameters assigned to the client.
While it isn't critical to keep track of the other parameters
assigned to a client, the server MUST keep track of the addresses it
has assigned to an IA.
23.10. Identity Associations The server should periodically scan its bindings for addresses whose
leases have expired. When the server finds expired addresses, it
MUST delete the assignment of those addresses, thereby making these
addresses available to other clients.
Section 9.11 describes IAs in detail. A definition of ``IA'' has The client bindings MUST be stored in non-volatile storage.
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 The server implementation should provide policy knobs to control
whether or not the lifetimes on assigned addresses are renewable, and
by how long.
``extensions'' are now called ``options''; the options referenced in 18.2. Reconfigure-init Considerations
this document are defined in section 22.
23.12. Transaction-ID ranges A server implementation MUST provide an interface to the
administrator for initiating reconfigure-init events.
Solicit, Advertise, Request, Reply, Release and Reconfigure-init A server implementation may provide a mechanism for allowing the
messages all use an unsigned 16-bit integer ``Transaction-ID''. specification of how many clients comprise a reconfigure multicast
Transaction-IDs generated by clients are considered to be chosen from group. This enables the administrator to control the processing load
a different namespace than those chosen by servers. There is no impact of the multicast of a Reconfigure-init message.
need to restrict clients and servers to select Transaction-IDs from
specific ranges to avoid conflicts.
23.13. Release messages and relays 18.2.1. Reliable transmission of multicast Reconfigure-init messages
Release/Reply messages are forwarded through relays. This mechanism Because clients will ignore Reconfigure-init messages with the
eliminates the need for an 'R' bit. same transaction-ID, a server can retransmit a Reconfigure-init
message (using the same transaction-ID) without causing any
client to reply more than once. A server SHOULD retransmit a
multicast Reconfigure-init message several times to maximize the
probability that all clients in the multicast group have received the
Reconfigure-init message.
23.14. Discovering relay agents If a server does not receive a Reply message from some clients in a
multicast group, the server MAY choose to unicast a Reconfigure-init
message to those clients. Because the clients may have received the
multicast Reconfigure-init messages while the server did not receive
the clients' Reply messages, the server SHOULD use a different
transaction-ID in the unicast Reconfigure-init messages to trigger
the client to reconfigure.
Clients no longer learn the identity of relay agents. When the 18.3. Server Preference
client only has a link-local address (e.g., the client has no
assigned addresses), it now multicasts Request message, which is then The server implementation SHOULD allow the setting of a server
forwarded by a relay agent on the same link. preference value by the administrator. The server preference
variable is an unsigned single octet value (0--255), with the lowest
preference being 0 and the highest 255. Clients will choose higher
preference servers over those with lower preference values. If you
don't choose to implement this feature in your server, you MUST set
the server preference field to 0 in the Advertise messages generated
by your server.
18.4. Request Message Transaction-ID Cache
In order to improve performance, a server implementation MAY include
an in memory transaction-ID cache. This cache is indexed by client
binding and transaction-ID, and enables the server to quickly
determine whether a Request is a retransmission or a new Request
without the cost of a database lookup. If an implementor chooses to
implement this cache, then they SHOULD provide a configuration knob
to tune the lifetime of the cache entries.
19. DHCP Relay Implementor Notes
A relay implementation SHOULD allow the specification of a list of
destination addresses for forwarded messages. This list MAY contain
any mixture of unicast addresses and multicast addresses.
If a relay receives an ICMP message in response to a DHCP message it
has forwarded, it SHOULD log this event.
20. Open Issues for Working Group Discussion
This section contains some items for discussion by the working group.
20.1. Authentication
Authentication is not discussed in this document. Authentication
will be modeled on DHCPv4 authentication. Authentication of
multicast Reconfigure-init messages is a special problem.
20.2. Identification of IAs by servers
Do servers identify an IA just by its DUID or by <prefix, DUID>? If
just by DUID, are DUIDs guaranteed unique (within the DHCP universe)?
If so, how is that guarantee implemented?
20.3. DHCP-DNS interaction
Interaction among DHCP servers, clients and DNS servers is not
discussed in this document.
20.4. Anonymous addresses
How does DHCPv6 interact with anonymous addresses? If the server
assigns anonymous addresses (e.g., addresses with short lifetimes),
how can a client application choose an anonymous address as a source
address in preference to a non-anonymous address?
20.5. Use of term "agent"
The term "agent", taken to mean "relay agent or server", may be
confusing. "relay agent or server" might be clearer.
20.6. Client behavior when response to Rebind is not received
Section 13.3.4 describes several plausible ways in which a client
might respond when it does not receive a Reply to a Rebind message.
The acceptable client behaviors need to be defined and described
in 13.3.4.
20.7. Additional options
Which additional options should be included in this base spec
document?
20.8. Operational parameters
Should servers have an option to set operational parameters -
retransmission timeouts, number of retries - in clients?
21. 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.
22. Year 2000 considerations
Since all times are relative to the current time of the transaction,
there is no problem within the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the current year.
23. IANA Considerations
This document defines message types TBD to be received by UDP at port
numbers 546 and 547. Additional message types may be defined in the
future.
Section 7.1 lists several multicast addresses used by DHCP.
This document also defines several status codes that are to be
returned with the Reply message (see section 9.7). The non-zero
values for these status codes which are currently specified are shown
in the table in section 7.4.
There is a DHCPv6 option described in section 16.6, which allows
clients and servers to exchange values for some of the timing
and retransmission parameters defined in section 7.5. Adding new
parameters in the future would require extending the values by which
the parameters are indicated in the DHCP option. Since there needs
to be a list kept, the default values for each parameter should also
be stored as part of the list.
All of these protocol elements may be specified to assume new values
at some point in the future. New values should be approved by the
process of IETF Consensus [9].
24. Acknowledgments
Thanks to the DHC Working Group for their time and input into the
specification. Ralph Droms and Thomas Narten have had a major
role in shaping the continued improvement of the protocol by their
careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald
Maguire, and Mike Carney for their studied review as part of the
Last Call process. Thanks also for the consistent input, ideas, and
review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.
Thanks to Steve Deering and Bob Hinden, who have consistently
taken the time to discuss the more complex parts of the IPv6
specifications.
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 [6, 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.
skipping to change at page 49, line 46 skipping to change at page 51, line 19
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 [15]. the Service Location protocol [14].
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 option as o IPv6 Address allocations are now handled in a message option 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
skipping to change at page 51, line 14 skipping to change at page 52, line 30
o Addresses can be reclaimed using the Reconfigure-init message. o Addresses can be reclaimed using the Reconfigure-init message.
o Integration between stateless and stateful address o Integration between stateless and stateful address
autoconfiguration. autoconfiguration.
o Enabling relays to locate off-link servers. o Enabling relays to locate off-link servers.
B. Full Copyright Statement B. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose or other Internet organizations, except as needed for the purpose
skipping to change at page 51, line 40 skipping to change at page 53, line 5
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.
C. Changes in this draft
This section describes the changes between this version of the DHCPv6
specification and draft-ietf-dhc-dhcpv6-16.txt.
C.1. New messages for confirming addresses and extending the lease on an
IA
Four new messages, DHCP Confirm, DHCP Renew, DHCP Rebind and DHCP
Decline, have been added and are described in section 13. Client
behavior - when and how to send these new messages - and server
behavior - how to respond to each - has been defined. The message
type codes for these messages have been added to section 7.3.
C.2. New message formats
Section 9 has been restructured to include only one copy of the DHCP
message header, because now all the messages have the same header
format. Descriptions of the use of header fields in the Confirm,
Renew, Rebind and Decline messages have been added to 9.
C.3. Renamed Server-forward message
Section 10.2 has been renamed "relay-reply" for consistency with the
rest of the document
C.4. Clarified relay forwarding of messages
Added text to sections on relay behavior to clarify encapsulation and
decapsulation of client messages in Relay-forward and Relay-reply
messages.
C.5. Addresses and options in Advertise messages
Modified section 12.4.2 so that servers include addresses to be
assigned and other options in Advertise messages. Also added text to
section 12.3.1 to disallow option values (except as noted in option
definitions) in Solicit messages.
C.6. Clarification of IA option format
Changed the label of the prefix length field in an IA option to
"prefix length" in the option format diagram, and moved the prefix
before the address for consistency with relay messages and other IPv6
protocols.
C.7. Specification of transaction ID in Solicit message
Add text (which was missing) to specify the insertion of a
transaction ID in Solicit messages.
C.8. Edits to definitions
Some of the definitions in section 6 have been edited for clarity.
C.9. Relay agent messages
The formats of relay agent messages are now described in a separate
section, 10.
C.10. Relay agent behavior
The behavior of relay agents for all client and server messages is
now described in a single section, 15.
C.11. Transmission of all client messages through relays
All client messages are now multicast to the All Agents multicast
address and forwarded by relays as appropriate.
C.12. Reconfigure-init messages
Client behavior in response to a Reconfigure-init messages has
been extended to accommodate receipt of multiple copies of a
Reconfigure-init message due to duplicate messages or retransmission.
Server use of multicast Reconfigure-init has been specified.
Hints about use of multicast and unicast for reliable reconfiguration
have been added to server implementor's hints.
C.13. Ordering of sections
Several sections have been re-ordered for clarity.
C.14. DSTM option
The DSTM option has been added (section 16.9).
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] S. Bradner. Key words for use in RFCs to Indicate Requirement [2] 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.
skipping to change at page 52, line 24 skipping to change at page 55, line 34
Internet Engineering Task Force, December 1998. Internet Engineering Task Force, December 1998.
[6] 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.
[7] 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.
[8] S. Kent and R. Atkinson. IP Authentication Header. Request for [8] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[9] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for
IP version 6. Request for Comments (Proposed Standard) 1981, IP version 6. Request for Comments (Proposed Standard) 1981,
Internet Engineering Task Force, August 1996. Internet Engineering Task Force, August 1996.
[10] T. Narten and H. Alvestrand. Guidelines for Writing an IANA [9] 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.
[11] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for [10] 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.
[12] D. C. Plummer. Ethernet Address Resolution Protocol: Or [11] 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.
[13] J. Postel. User Datagram Protocol. Request for Comments [12] J. Postel. User Datagram Protocol. Request for Comments
(Standard) 768, Internet Engineering Task Force, August 1980. (Standard) 768, Internet Engineering Task Force, August 1980.
[14] S. Thomson and T. Narten. IPv6 Stateless Address [13] 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.
[15] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [14] 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.
[16] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic [15] 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
Cisco Systems Cisco Systems
skipping to change at page 54, line 22 skipping to change at page 57, line 22
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-4733 Phone: (978) 244-4733
E-mail: rdroms@cisco.com 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 Nokia Networks
Mail Stop: ZK03-3/U14 5 Wayside Road
110 Spitbrook Road Burlington, MA 01803
Nashua, NH 03062
USA USA
Phone: +1-603-884-0400 Phone: +1-781-492-6010
Email: bound@zk3.dec.com Email: jim.bound@nokia.com
Mike Carney Mike Carney
Sun Microsystems, Inc Sun Microsystems, Inc
Mail Stop: UMPK17-202 Mail Stop: UMPK17-202
901 San Antonio Road 901 San Antonio Road
Palo Alto, CA 94303-4900 Palo Alto, CA 94303-4900
USA USA
Phone: +1-650-786-4171 Phone: +1-650-786-4171
Email: mwc@eng.sun.com Email: mwc@eng.sun.com
 End of changes. 

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