draft-ietf-dhc-dhcpv6-25.txt   draft-ietf-dhc-dhcpv6-26.txt 
Internet Engineering Task Force J. Bound Internet Engineering Task Force R. Droms (ed.), Cisco
INTERNET DRAFT Hewlett Packard INTERNET DRAFT J. Bound, Hewlett Packard
DHC Working Group M. Carney DHC Working Group Bernie Volz, Ericsson
Obsoletes: draft-ietf-dhc-dhcpv6-24.txt Sun Microsystems, Inc Obsoletes: draft-ietf-dhc-dhcpv6-25.txt Ted Lemon, Nominum
C. Perkins C. Perkins, Nokia Research Center
Nokia Research Center M. Carney, Sun Microsystems
Ted Lemon June 9, 2002
Nominum
Bernie Volz
Ericsson
R. Droms(ed.)
Cisco Systems
May 24 2002
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-25.txt draft-ietf-dhc-dhcpv6-26.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 dhcwg@ietf.org mailing list. should be submitted to the dhcwg@ietf.org 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 61 skipping to change at page 1, line 55
Stateless Address Autoconfiguration" (RFC2462), and can be used Stateless Address Autoconfiguration" (RFC2462), and can be used
separately or concurrently with the latter to obtain configuration separately 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 and Overview 1 1. Introduction and Overview 2
1.1. Protocols and addressing . . . . . . . . . . . . . . . . 2 1.1. Protocols and addressing . . . . . . . . . . . . . . . . 2
1.2. Protocol implementation . . . . . . . . . . . . . . . . . 2 1.2. Client-server exchanges involving two messages . . . . . 3
1.3. Client-server exchanges involving two messages . . . . . 3 1.3. Client-server exchanges involving four messages . . . . . 3
1.4. Client-server exchanges involving four messages . . . . . 3
2. Requirements 4 2. Requirements 4
3. Background 4 3. Background 4
4. Terminology 5 4. Terminology 5
4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 5 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 5
4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 6 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 6
5. DHCP Constants 8 5. DHCP Constants 8
5.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 8 5.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 8
5.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. DHCP message types . . . . . . . . . . . . . . . . . . . 8 5.3. DHCP message types . . . . . . . . . . . . . . . . . . . 8
5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Configuration Parameters . . . . . . . . . . . . . . . . 10 5.5. Transmission and Retransmission Parameters . . . . . . . 11
6. Message Formats 11 6. Message Formats 11
7. Relay agent messages 12 7. Relay agent messages 12
7.1. Relay-forward message . . . . . . . . . . . . . . . . . . 12 7.1. Relay-forward message . . . . . . . . . . . . . . . . . . 13
7.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 13 7.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 13
8. Representation and use of domain names 13 8. Representation and use of domain names 13
9. DHCP unique identifier (DUID) 13 9. DHCP unique identifier (DUID) 14
9.1. DUID contents . . . . . . . . . . . . . . . . . . . . . . 14 9.1. DUID contents . . . . . . . . . . . . . . . . . . . . . . 14
9.2. DUID based on link-layer address plus time . . . . . . . 14 9.2. DUID based on link-layer address plus time [DUID-LLT] . . 14
9.3. Vendor-assigned unique ID based on Enterprise Number 9.3. DUID assigned by vendor based on Enterprise number
(VUID-EN) . . . . . . . . . . . . . . . . . . . . . . 15 [DUID-EN] . . . . . . . . . . . . . . . . . . . . . . 16
9.4. Link-layer address . . . . . . . . . . . . . . . . . . . 16 9.4. DUID based on link-layer address [DUID-LL] . . . . . . . 17
10. Identity association 17 10. Identity association 17
11. Selecting addresses for assignment to an IA 17 11. Selecting addresses for assignment to an IA 18
12. Management of temporary addresses 18 12. Management of temporary addresses 19
13. Transmission of messages by a client 19 13. Transmission of messages by a client 19
14. Reliability of Client Initiated Message Exchanges 19 14. Reliability of Client Initiated Message Exchanges 20
15. Message validation 21 15. Message validation 21
15.1. Use of Transaction-ID field . . . . . . . . . . . . . . . 21 15.1. Use of Transaction IDs . . . . . . . . . . . . . . . . . 21
15.2. Solicit message . . . . . . . . . . . . . . . . . . . . . 21 15.2. Solicit message . . . . . . . . . . . . . . . . . . . . . 22
15.3. Advertise message . . . . . . . . . . . . . . . . . . . . 21 15.3. Advertise message . . . . . . . . . . . . . . . . . . . . 22
15.4. Request message . . . . . . . . . . . . . . . . . . . . . 22 15.4. Request message . . . . . . . . . . . . . . . . . . . . . 22
15.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 22 15.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 22
15.6. Renew message . . . . . . . . . . . . . . . . . . . . . . 22 15.6. Renew message . . . . . . . . . . . . . . . . . . . . . . 23
15.7. Rebind message . . . . . . . . . . . . . . . . . . . . . 22 15.7. Rebind message . . . . . . . . . . . . . . . . . . . . . 23
15.8. Decline messages . . . . . . . . . . . . . . . . . . . . 23 15.8. Decline messages . . . . . . . . . . . . . . . . . . . . 23
15.9. Release message . . . . . . . . . . . . . . . . . . . . . 23 15.9. Release message . . . . . . . . . . . . . . . . . . . . . 23
15.10. Reply message . . . . . . . . . . . . . . . . . . . . . . 23 15.10. Reply message . . . . . . . . . . . . . . . . . . . . . . 24
15.11. Reconfigure message . . . . . . . . . . . . . . . . . . . 24 15.11. Reconfigure message . . . . . . . . . . . . . . . . . . . 24
15.12. Information-request message . . . . . . . . . . . . . . . 24 15.12. Information-request message . . . . . . . . . . . . . . . 25
15.13. Relay-forward message . . . . . . . . . . . . . . . . . . 24 15.13. Relay-forward message . . . . . . . . . . . . . . . . . . 25
15.14. Relay-reply message . . . . . . . . . . . . . . . . . . . 24 15.14. Relay-reply message . . . . . . . . . . . . . . . . . . . 25
16. Client Source Address and Interface Selection 24 16. Client Source Address and Interface Selection 25
17. DHCP Server Solicitation 25 17. DHCP Server Solicitation 25
17.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 25 17.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26
17.1.1. Creation of Solicit messages . . . . . . . . . . 25 17.1.1. Creation of Solicit messages . . . . . . . . . . 26
17.1.2. Transmission of Solicit Messages . . . . . . . . 26 17.1.2. Transmission of Solicit Messages . . . . . . . . 27
17.1.3. Receipt of Advertise messages . . . . . . . . . . 27 17.1.3. Receipt of Advertise messages . . . . . . . . . . 28
17.1.4. Receipt of Reply message . . . . . . . . . . . . 28 17.1.4. Receipt of Reply message . . . . . . . . . . . . 29
17.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28 17.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 29
17.2.1. Receipt of Solicit messages . . . . . . . . . . . 28 17.2.1. Receipt of Solicit messages . . . . . . . . . . . 29
17.2.2. Creation and transmission of Advertise messages . 29 17.2.2. Creation and transmission of Advertise messages . 29
17.2.3. Creation and Transmission of Reply messages . . . 30 17.2.3. Creation and Transmission of Reply messages . . . 30
18. DHCP Client-Initiated Configuration Exchange 30 18. DHCP Client-Initiated Configuration Exchange 31
18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 18.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31
18.1.1. Creation and transmission of Request messages . . 31 18.1.1. Creation and transmission of Request messages . . 32
18.1.2. Creation and transmission of Confirm messages . . 32 18.1.2. Creation and transmission of Confirm messages . . 33
18.1.3. Creation and transmission of Renew messages . . . 33 18.1.3. Creation and transmission of Renew messages . . . 34
18.1.4. Creation and transmission of Rebind messages . . 35 18.1.4. Creation and transmission of Rebind messages . . 35
18.1.5. Creation and Transmission of Information-request 18.1.5. Creation and Transmission of Information-request
messages . . . . . . . . . . . . . . . . . 36 messages . . . . . . . . . . . . . . . . . 36
18.1.6. Receipt of Reply message in response to a Request, 18.1.6. Creation and transmission of Release messages . . 37
Confirm, Renew, Rebind or Information-request 18.1.7. Creation and transmission of Decline messages . . 38
message . . . . . . . . . . . . . . . . . 36 18.1.8. Receipt of Reply messages . . . . . . . . . . . . 38
18.1.7. Creation and transmission of Release messages . . 37
18.1.8. Receipt of Reply message in response to a Release
message . . . . . . . . . . . . . . . . . 39
18.1.9. Creation and transmission of Decline messages . . 39
18.1.10. Receipt of Reply message in response to a Decline
message . . . . . . . . . . . . . . . . . 40
18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 40 18.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 40
18.2.1. Receipt of Request messages . . . . . . . . . . . 40 18.2.1. Receipt of Request messages . . . . . . . . . . . 40
18.2.2. Receipt of Confirm messages . . . . . . . . . . . 41 18.2.2. Receipt of Confirm messages . . . . . . . . . . . 41
18.2.3. Receipt of Renew messages . . . . . . . . . . . . 42 18.2.3. Receipt of Renew messages . . . . . . . . . . . . 41
18.2.4. Receipt of Rebind messages . . . . . . . . . . . 43 18.2.4. Receipt of Rebind messages . . . . . . . . . . . 42
18.2.5. Receipt of Information-request messages . . . . . 43 18.2.5. Receipt of Information-request messages . . . . . 43
18.2.6. Receipt of Release messages . . . . . . . . . . . 44 18.2.6. Receipt of Release messages . . . . . . . . . . . 44
18.2.7. Receipt of Decline messages . . . . . . . . . . . 45 18.2.7. Receipt of Decline messages . . . . . . . . . . . 44
18.2.8. Transmission of Reply messages . . . . . . . . . 45 18.2.8. Transmission of Reply messages . . . . . . . . . 45
19. DHCP Server-Initiated Configuration Exchange 45 19. DHCP Server-Initiated Configuration Exchange 45
19.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46 19.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 45
19.1.1. Creation and transmission of Reconfigure messages 46 19.1.1. Creation and transmission of Reconfigure messages 45
19.1.2. Time out and retransmission of Reconfigure 19.1.2. Time out and retransmission of Reconfigure
messages . . . . . . . . . . . . . . . . . 47 messages . . . . . . . . . . . . . . . . . 46
19.1.3. Receipt of Renew messages . . . . . . . . . . . . 47 19.2. Receipt of Renew messages . . . . . . . . . . . . . . . . 47
19.2. Receipt of Information-request messages . . . . . . . . . 47 19.3. Receipt of Information-request messages . . . . . . . . . 47
19.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 47 19.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 47
19.3.1. Receipt of Reconfigure messages . . . . . . . . . 48 19.4.1. Receipt of Reconfigure messages . . . . . . . . . 47
19.3.2. Creation and transmission of Renew messages . . . 48 19.4.2. Creation and transmission of Renew messages . . . 48
19.3.3. Creation and transmission of Information-request 19.4.3. Creation and transmission of Information-request
messages . . . . . . . . . . . . . . . . . 49 messages . . . . . . . . . . . . . . . . . 48
19.3.4. Time out and retransmission of Renew or 19.4.4. Time out and retransmission of Renew or
Information-request messages . . . . . . . 49 Information-request messages . . . . . . . 49
19.3.5. Receipt of Reply messages . . . . . . . . . . . . 49 19.4.5. Receipt of Reply messages . . . . . . . . . . . . 49
20. Relay Agent Behavior 49 20. Relay Agent Behavior 49
20.1. Relaying of client messages . . . . . . . . . . . . . . . 49 20.1. Forwarding a client message or a Relay-forward message . 49
20.2. Relaying of server messages . . . . . . . . . . . . . . . 50 20.1.1. Forwarding a message from a client . . . . . . . 49
20.1.2. Forwarding a message from a relay agent . . . . . 50
20.2. Forwarding a Relay-reply message . . . . . . . . . . . . 50
20.3. Construction of Relay-reply messages . . . . . . . . . . 51
21. Authentication of DHCP messages 50 21. Authentication of DHCP messages 51
21.1. DHCP threat model . . . . . . . . . . . . . . . . . . . . 51 21.1. DHCP threat model . . . . . . . . . . . . . . . . . . . . 51
21.2. Security of messages sent between servers and relay agents 51 21.2. Security of messages sent between servers and relay agents 52
21.3. Summary of DHCP authentication . . . . . . . . . . . . . 51 21.3. Summary of DHCP authentication . . . . . . . . . . . . . 52
21.4. Replay detection . . . . . . . . . . . . . . . . . . . . 52 21.4. Replay detection . . . . . . . . . . . . . . . . . . . . 53
21.5. Delayed authentication protocol . . . . . . . . . . . . . 52 21.5. Delayed authentication protocol . . . . . . . . . . . . . 53
21.5.1. Management issues in the delayed authentication 21.5.1. Use of the Authentication option in the delayed
protocol . . . . . . . . . . . . . . . . . 52
21.5.2. Use of the Authentication option in the delayed
authentication protocol . . . . . . . . . 53 authentication protocol . . . . . . . . . 53
21.5.3. Message validation . . . . . . . . . . . . . . . 54 21.5.2. Message validation . . . . . . . . . . . . . . . 55
21.5.4. Key utilization . . . . . . . . . . . . . . . . . 54 21.5.3. Key utilization . . . . . . . . . . . . . . . . . 55
21.5.5. Client considerations for delayed authentication 21.5.4. Client considerations for delayed authentication
protocol . . . . . . . . . . . . . . . . . 55 protocol . . . . . . . . . . . . . . . . . 55
21.5.6. Server considerations for delayed authentication 21.5.5. Server considerations for delayed authentication
protocol . . . . . . . . . . . . . . . . . 56 protocol . . . . . . . . . . . . . . . . . 57
22. DHCP options 57 22. DHCP options 57
22.1. Format of DHCP options . . . . . . . . . . . . . . . . . 57 22.1. Format of DHCP options . . . . . . . . . . . . . . . . . 58
22.2. Client Identifier option . . . . . . . . . . . . . . . . 58 22.2. Client Identifier option . . . . . . . . . . . . . . . . 58
22.3. Server Identifier option . . . . . . . . . . . . . . . . 58 22.3. Server Identifier option . . . . . . . . . . . . . . . . 59
22.4. Identity Association option . . . . . . . . . . . . . . . 59 22.4. Identity Association option . . . . . . . . . . . . . . . 60
22.5. Identity Association for Temporary Addresses option . . . 61 22.5. Identity Association for Temporary Addresses option . . . 61
22.6. IA Address option . . . . . . . . . . . . . . . . . . . . 62 22.6. IA Address option . . . . . . . . . . . . . . . . . . . . 63
22.7. Option Request option . . . . . . . . . . . . . . . . . . 63 22.7. Option Request option . . . . . . . . . . . . . . . . . . 64
22.8. Preference option . . . . . . . . . . . . . . . . . . . . 64 22.8. Preference option . . . . . . . . . . . . . . . . . . . . 65
22.9. Elapsed Time . . . . . . . . . . . . . . . . . . . . . . 64 22.9. Elapsed Time option . . . . . . . . . . . . . . . . . . . 65
22.10. Client message option . . . . . . . . . . . . . . . . . . 65 22.10. Relay Message option . . . . . . . . . . . . . . . . . . 66
22.11. Server message option . . . . . . . . . . . . . . . . . . 65 22.11. Authentication option . . . . . . . . . . . . . . . . . . 66
22.12. Authentication option . . . . . . . . . . . . . . . . . . 66 22.12. Server unicast option . . . . . . . . . . . . . . . . . . 67
22.13. Server unicast option . . . . . . . . . . . . . . . . . . 67 22.13. Status Code Option . . . . . . . . . . . . . . . . . . . 68
22.14. Status Code Option . . . . . . . . . . . . . . . . . . . 67 22.14. Rapid Commit option . . . . . . . . . . . . . . . . . . . 69
22.15. Rapid Commit option . . . . . . . . . . . . . . . . . . . 68 22.15. User Class option . . . . . . . . . . . . . . . . . . . . 70
22.16. User Class Option . . . . . . . . . . . . . . . . . . . . 69 22.16. Vendor Class Option . . . . . . . . . . . . . . . . . . . 71
22.17. Vendor Class Option . . . . . . . . . . . . . . . . . . . 70 22.17. Vendor-specific Information option . . . . . . . . . . . 72
22.18. Vendor-specific Information option . . . . . . . . . . . 71 22.18. Interface-Id Option . . . . . . . . . . . . . . . . . . . 73
22.19. Interface-Id Option . . . . . . . . . . . . . . . . . . . 72 22.19. Reconfigure Message option . . . . . . . . . . . . . . . 74
22.20. Reconfigure Message option . . . . . . . . . . . . . . . 73 22.20. Reconfigure Nonce option . . . . . . . . . . . . . . . . 74
22.21. Reconfigure Nonce option . . . . . . . . . . . . . . . . 73
23. Security Considerations 74 23. Security Considerations 75
24. IANA Considerations 74 24. IANA Considerations 76
24.1. Multicast addresses . . . . . . . . . . . . . . . . . . . 75 24.1. Multicast addresses . . . . . . . . . . . . . . . . . . . 77
24.2. DHCP message types . . . . . . . . . . . . . . . . . . . 75 24.2. DHCP message types . . . . . . . . . . . . . . . . . . . 77
24.3. DHCP options . . . . . . . . . . . . . . . . . . . . . . 76 24.3. DHCP options . . . . . . . . . . . . . . . . . . . . . . 78
24.4. Status codes . . . . . . . . . . . . . . . . . . . . . . 76 24.4. Status codes . . . . . . . . . . . . . . . . . . . . . . 79
24.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 77 24.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 79
24.6. Authentication option . . . . . . . . . . . . . . . . . . 77
25. Acknowledgments 77 25. Acknowledgments 79
26. Changes in draft-ietf-dhc-dhcpv6-25.txt 78 26. Changes in draft-ietf-dhc-dhcpv6-25.txt 80
References 80 27. Changes in draft-ietf-dhc-dhcpv6-26.txt 82
Chair's Address 81 References 83
Authors' Addresses 81 Chair's Address 84
A. Appearance of Options in Message Types 83 Authors' Addresses 85
B. Appearance of Options in the Options Field of DHCP Options 83 A. Appearance of Options in Message Types 86
C. Full Copyright Statement 84 B. Appearance of Options in the Options Field of DHCP Options 86
C. Full Copyright Statement 87
1. Introduction and Overview 1. Introduction and Overview
This document describes DHCP for IPv6 (DHCP), a client/server This document describes DHCP for IPv6 (DHCP), a client/server
protocol that provides managed configuration of devices. protocol that provides managed configuration of devices.
DHCP can provide a device with addresses assigned by a DHCP server DHCP can provide a device with addresses assigned by a DHCP server
and other configuration information. The addresses and additional and other configuration information, which are carried in options.
configuration are carried in options. DHCP can be extended through DHCP can be extended through the definition of new options to carry
the definition of new options to carry configuration information not configuration information not specified in this document.
specified in this document.
DHCP is the "stateful address autoconfiguration protocol" and the DHCP is the "stateful address autoconfiguration protocol" and the
"stateful autoconfiguration protocol" referred to in RFC2462, "IPv6 "stateful autoconfiguration protocol" referred to in "IPv6 Stateless
Stateless Address Autoconfiguration". Address Autoconfiguration" [20].
The operational models and relevant configuration information
for DHCPv4 and DHCPv6 are sufficiently different that integration
between the two services is not included in this document. If there
is sufficient interest and demand, integration can be specified
in a document that extends DHCPv6 to carry IPv4 addresses and
configuration information.
The remainder of this introduction summarizes DHCP, explaining The remainder of this introduction summarizes DHCP, explaining
the message exchange mechanisms and example message flows. The the message exchange mechanisms and example message flows. The
message flows in sections 1.3 and 1.4 are intended as illustrations message flows in sections 1.2 and 1.3 are intended as illustrations
of DHCP operation rather than an exhaustive list of all possible of DHCP operation rather than an exhaustive list of all possible
client-server interactions. Sections 17, 18 and 19 explain client client-server interactions. Sections 17, 18 and 19 explain client
and server operation in detail. and server operation in detail.
1.1. Protocols and addressing 1.1. Protocols and addressing
Clients and servers exchange DHCP messages using UDP [16]. The Clients and servers exchange DHCP messages using UDP [18]. The
client uses its link-local address determined through stateless client uses a link-local address or addresses determined through
autoconfiguration for transmitting and receiving DHCP messages. other mechanisms for transmitting and receiving DHCP messages.
DHCP servers receive messages from clients using a reserved, DHCP servers receive messages from clients using a reserved,
link-scoped multicast address. A DHCP client transmits most messages link-scoped multicast address. A DHCP client transmits most messages
to this reserved multicast address, so that the client need not be to this reserved multicast address, so that the client need not be
configured with the address or addresses of DHCP servers. configured with the address or addresses of DHCP servers.
To allow a DHCP client to send a message to a DHCP server that is not To allow a DHCP client to send a message to a DHCP server that is not
attached to the same link, a DHCP relay agent on the client's link attached to the same link, a DHCP relay agent on the client's link
will forward messages between the client and server. The operation will forward messages between the client and server. The operation
of the relay agent is transparent to the client and the discussion of the relay agent is transparent to the client and the discussion
of message exchanges in the remainder of this section will omit the of message exchanges in the remainder of this section will omit the
description of message forwarding by relay agents. description of message forwarding by relay agents.
Once the client has determined the address of a server, it may Once the client has determined the address of a server, it may
under some circumstances send messages directly to the server using under some circumstances send messages directly to the server using
unicast. unicast.
1.2. Protocol implementation 1.2. Client-server exchanges involving two messages
This specification for DHCP includes messages and descriptions of
client and server behavior for several different functions. Some
clients and servers will be deployed in situations in which not all
of the functions will be required. For example, a client that uses
stateless autoconfiguration to determine its IPv6 addresses would
use only the Information-request and Reply messages to obtain other
configuration information.
Clients and servers that do not use all of the functions of DHCP
need not implement processing for those DHCP messages that will not
be used. A client or server that receives a message that it is not
prepared to process may simply discard that message. For example, a
DHCP server that only provides configuration information and does not
do IPv6 address assignment can respond to only Information-request
messages and discard other messages such as Solicit or Request
messages.
1.3. Client-server exchanges involving two messages
A DHCP client can obtain configuration information such as a list When a DHCP client does not need to have a DHCP server assign
of available DNS servers or NTP servers through a single message it IP addresses, the client can obtain configuration information
and reply exchanged with a DHCP server. To obtain configuration such as a list of available DNS servers [7] or NTP servers [21]
information the client first sends an Information-Request message through a single message and reply exchanged with a DHCP server.
to the All_DHCP_Relay_Agents_and_Servers multicast address. The To obtain configuration information the client first sends an
server responds with a Reply message containing the configuration Information-Request message to the All_DHCP_Relay_Agents_and_Servers
information for the client. multicast address. The server responds with a Reply message
containing the configuration information for the client.
This message exchange assumes that the client requires only This message exchange assumes that the client requires only
configuration information and does not require the assignment of any configuration information and does not require the assignment of any
IPv6 addresses. Because the server need not keep any dynamic state IPv6 addresses.
information about individual clients to support this two message
exchange, a server that provides just configuration information can
be realized with a relatively simple and small implementation.
When a server has IPv6 addresses and other configuration information When a server has IPv6 addresses and other configuration information
committed to a client, the client and server may be able to complete committed to a client, the client and server may be able to complete
the exchange using only two messages, instead of four messages as the exchange using only two messages, instead of four messages as
described in the next section. In this case, the client sends a described in the next section. In this case, the client sends a
Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting
the assignment of addresses and other configuration information. the assignment of addresses and other configuration information.
This message includes an indication that the client is willing to This message includes an indication that the client is willing to
accept an immediate Reply message from the server. The server that accept an immediate Reply message from the server. The server that
is willing to commit the assignment of addresses to the client is willing to commit the assignment of addresses to the client
skipping to change at page 3, line 42 skipping to change at page 3, line 40
information and the addresses in the Reply message are then information and the addresses in the Reply message are then
immediately available for use by the client. immediately available for use by the client.
Each address assigned to the client has associated preferred and Each address assigned to the client has associated preferred and
valid lifetimes specified by the server. To request an extension valid lifetimes specified by the server. To request an extension
of the lifetimes assigned to an address, the client sends a Renew of the lifetimes assigned to an address, the client sends a Renew
message to the server. The server sends a Reply message to the message to the server. The server sends a Reply message to the
client with the new lifetimes, allowing the client to continue to use client with the new lifetimes, allowing the client to continue to use
the address without interruption. the address without interruption.
1.4. Client-server exchanges involving four messages 1.3. Client-server exchanges involving four messages
To request the assignment of one or more IPv6 addresses, a To request the assignment of one or more IPv6 addresses, a
client first locates a DHCP server and then requests the client first locates a DHCP server and then requests the
assignment of addresses and other configuration information assignment of addresses and other configuration information
from the server. The client sends a Solicit message to the from the server. The client sends a Solicit message to the
All_DHCP_Relay_Agents_and_Servers address to find available DHCP All_DHCP_Relay_Agents_and_Servers address to find available DHCP
servers. Any server that can meet the client's requirements servers. Any server that can meet the client's requirements
responds with an Advertise message. The client then chooses one responds with an Advertise message. The client then chooses one
of the servers and sends a Request message to the server asking of the servers and sends a Request message to the server asking
for confirmed assignment of addresses and other configuration for confirmed assignment of addresses and other configuration
skipping to change at page 4, line 29 skipping to change at page 4, line 26
specific variable names, how their values change, and how their specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demonstrate settings influence protocol behavior are provided to demonstrate
protocol behavior. An implementation is not required to have them in protocol behavior. An implementation is not required to have them in
the exact form described here, so long as its external behavior is the exact form described here, so long as its external behavior is
consistent with that described in this document. consistent with that described in this document.
3. Background 3. Background
The IPv6 Specification provides the base architecture and design of The IPv6 Specification provides the base architecture and design of
IPv6. Related work in IPv6 that would best serve an implementor IPv6. Related work in IPv6 that would best serve an implementor
to study includes the IPv6 Specification [3], the IPv6 Addressing to study includes the IPv6 Specification [4], the IPv6 Addressing
Architecture [6], IPv6 Stateless Address Autoconfiguration [18], IPv6 Architecture [8], IPv6 Stateless Address Autoconfiguration [20], IPv6
Neighbor Discovery Processing [14], and Dynamic Updates to DNS [19]. Neighbor Discovery Processing [16], and Dynamic Updates to DNS [22].
These specifications enable DHCP to build upon the IPv6 work to These specifications enable DHCP to build upon the IPv6 work to
provide both robust stateful autoconfiguration and autoregistration provide both robust stateful autoconfiguration and autoregistration
of DNS Host Names. of DNS Host Names.
The IPv6 Addressing Architecture specification [6] defines the The IPv6 Addressing Architecture specification [8] defines the
address scope that can be used in an IPv6 implementation, and the address scope that can be used in an IPv6 implementation, and the
various configuration architecture guidelines for network designers various configuration architecture guidelines for network designers
of the IPv6 address space. Two advantages of IPv6 are that support of the IPv6 address space. Two advantages of IPv6 are that support
for multicast is required, and nodes can create link-local addresses for multicast is required, and nodes can create link-local addresses
during initialization. This means that a client can immediately use during initialization. This means that a client can immediately use
its link-local address and a well-known multicast address to begin its link-local address and a well-known multicast address to begin
communications to discover neighbors on the link. For instance, a communications to discover neighbors on the link. For instance, a
client can send a Solicit message and locate a server or relay agent. client can send a Solicit message and locate a server or relay agent.
IPv6 Stateless Address Autoconfiguration [18] specifies procedures IPv6 Stateless Address Autoconfiguration [20] specifies procedures
by which a node may autoconfigure addresses based on router by which a node may autoconfigure addresses based on router
advertisements [14], and the use of a valid lifetime to support advertisements [16], and the use of a valid lifetime to support
renumbering of addresses on the Internet. In addition the renumbering of addresses on the Internet. In addition the
protocol interaction by which a node begins stateless or stateful protocol interaction by which a node begins stateless or stateful
autoconfiguration is specified. DHCP is one vehicle to perform autoconfiguration is specified. DHCP is one vehicle to perform
stateful autoconfiguration. Compatibility with stateless address stateful autoconfiguration. Compatibility with stateless address
autoconfiguration is a design requirement of DHCP. autoconfiguration is a design requirement of DHCP.
IPv6 Neighbor Discovery [14] is the node discovery protocol in IPv6 IPv6 Neighbor Discovery [16] is the node discovery protocol in IPv6
which replaces and enhances functions of ARP [15]. To understand which replaces and enhances functions of ARP [17]. To understand
IPv6 and stateless address autoconfiguration it is strongly IPv6 and stateless address autoconfiguration it is strongly
recommended that implementors understand IPv6 Neighbor Discovery. recommended that implementors understand IPv6 Neighbor Discovery.
Dynamic Updates to DNS [19] is a specification that supports the Dynamic Updates to DNS [22] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCP can use dynamic update of DNS records for both IPv4 and IPv6. DHCP can use
the dynamic updates to DNS to integrate addresses and name space to the dynamic updates to DNS to integrate addresses and name space to
not only support autoconfiguration, but also autoregistration in not only support autoconfiguration, but also autoregistration in
IPv6. IPv6.
4. Terminology 4. Terminology
This sections defines terminology specific to IPv6 and DHCP used in This sections defines terminology specific to IPv6 and DHCP used in
this document. this document.
4.1. IPv6 Terminology 4.1. IPv6 Terminology
IPv6 terminology relevant to this specification from the IPv6 IPv6 terminology relevant to this specification from the IPv6
Protocol [3], IPv6 Addressing Architecture [6], and IPv6 Stateless Protocol [4], IPv6 Addressing Architecture [8], and IPv6 Stateless
Address Autoconfiguration [18] is included below. Address Autoconfiguration [20] is included below.
address An IP layer identifier for an interface address An IP layer identifier for an interface
or a set of interfaces. or a set of interfaces.
host Any node that is not a router. host Any node that is not a router.
IP Internet Protocol Version 6 (IPv6). The IP Internet Protocol Version 6 (IPv6). The
terms IPv4 and IPv6 are used only in terms IPv4 and IPv6 are used only in
contexts where it is necessary to avoid contexts where it is necessary to avoid
ambiguity. ambiguity.
skipping to change at page 6, line 42 skipping to change at page 6, line 38
unicast address An identifier for a single interface. unicast address An identifier for a single interface.
A packet sent to a unicast address is A packet sent to a unicast address is
delivered to the interface identified by delivered to the interface identified by
that address. that address.
4.2. DHCP Terminology 4.2. DHCP Terminology
Terminology specific to DHCP can be found below. Terminology specific to DHCP can be found below.
appropriate to the link an address is "appropriate to the link"
when the address is consistent with the
DHCP server's knowledge of the network
topology, prefix assignment and address
assignment policies
binding A binding (or, client binding) is a binding A binding (or, client binding) is a
group of server data records containing group of server data records containing
the information the server has about the information the server has about
the addresses in an IA and any other the addresses in an IA or configuration
configuration information assigned to information explicitly assigned to the
the client. A binding is indexed by client. Configuration information that
the tuple <DUID, IA-type, IAID> (where has been returned to a client through a
IA-type is the type of address in the policy - for example, the information
IA; for example, temporary) returned to all clients on the same
link - does not require a binding. A
binding containing information about
an IA is indexed by the tuple <DUID,
IA-type, IAID> (where IA-type is the
type of address in the IA; for example,
temporary). A binding containing
configuration information for a client
is indexed by <DUID>.
configuration parameter An element of the configuration configuration parameter An element of the configuration
information set on the server and information set on the server and
delivered to the client using DHCP. delivered to the client using DHCP.
Such parameters may be used to carry Such parameters may be used to carry
information to be used by a node to information to be used by a node to
configure its network subsystem and configure its network subsystem and
enable communication on a link or enable communication on a link or
internetwork, for example. internetwork, for example.
skipping to change at page 7, line 53 skipping to change at page 8, line 11
Identity association identifier (IAID) An identifier for an IA, Identity association identifier (IAID) An identifier for an IA,
chosen by the client. Each IA has an chosen by the client. Each IA has an
IAID, which is chosen to be unique among IAID, which is chosen to be unique among
all IAIDs for IAs belonging to that all IAIDs for IAs belonging to that
client. client.
message A unit of data carried as the payload message A unit of data carried as the payload
of a UDP datagram, exchanged among DHCP of a UDP datagram, exchanged among DHCP
servers, relay agents and clients. servers, relay agents and clients.
reconfiguration nonce A 64 bit opaque value used to provide reconfiguration nonce An opaque value used to provide security
security for Reconfigure messages. A for Reconfigure messages.
server generates a cryptographically
strong random number as a nonce and
sends that nonce value to the client.
The server then includes the nonce in
any Reconfigure messages it sends to the
client.
transaction-ID An opaque value used to match responses transaction ID An opaque value used to match responses
with replies initiated either by a with replies initiated either by a
client or server. client or server.
5. DHCP Constants 5. DHCP Constants
This section describes various program and networking constants used This section describes various program and networking constants used
by DHCP. by DHCP.
5.1. Multicast Addresses 5.1. Multicast Addresses
DHCP makes use of the following multicast addresses: DHCP makes use of the following multicast addresses:
All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped
multicast address used by a client to communicate with multicast address used by a client to communicate with
neighboring (i.e., on-link) relay agents and servers. neighboring (i.e., on-link) relay agents and servers.
All servers and relay agents are members of this All servers and relay agents are members of this
multicast group. multicast group.
All_DHCP_Servers (FF05::1:3) A site-scoped multicast address All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used
used by a client or relay agent to communicate with by a relay agent to communicate with servers, either
servers, either because the client or relay agent because the relay agent wants to send messages to
wants to send messages to all servers or because it all servers or because it does not know the unicast
does not know the unicast addresses of the servers. addresses of the servers. Note that in order for
Note that in order for a client or relay agent to use a relay agent to use this address, it must have an
this address, it must have an address of sufficient address of sufficient scope to be reachable by the
scope to be reachable by the servers. All servers servers. All servers within the site are members of
within the site are members of this multicast group. this multicast group.
5.2. UDP ports 5.2. UDP ports
Clients listen for DHCP messages on UDP port 546. Servers and relay Clients listen for DHCP messages on UDP port 546. Servers and relay
agents listen for DHCP messages on UDP port 547. agents listen for DHCP messages on UDP port 547.
5.3. DHCP message types 5.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 6. Message types not listed message types can be found in Section 6. Message types not listed
skipping to change at page 9, line 11 skipping to change at page 9, line 16
SOLICIT (1) A client sends a Solicit message to locate SOLICIT (1) A client sends a Solicit message to locate
servers. servers.
ADVERTISE (2) A server sends an Advertise message to indicate ADVERTISE (2) A server sends an Advertise message to indicate
that it is available for DHCP service, in that it is available for DHCP service, in
response to a Solicit message received from a response to a Solicit message received from a
client. client.
REQUEST (3) A client sends a Request message to request REQUEST (3) A client sends a Request message to request
configuration parameters from a server. configuration parameters, including IP
addresses, from a specific server.
CONFIRM (4) A client sends a Confirm message to any CONFIRM (4) A client sends a Confirm message to any
available server when it detects that it may available server to determine whether the
have moved to a new link to request that the addresses it was assigned are still appropriate
servers verify that the addresses and current to the link to which the client is connected.
configuration parameters assigned by the server
to the client are still valid.
RENEW (5) A client sends a Renew message to the server RENEW (5) A client sends a Renew message to the server
that originally provided the client's addresses that originally provided the client's addresses
and configuration parameters to extend the and configuration parameters to extend the
leases on the addresses assigned to the client leases on the addresses assigned to the client
and to update other configuration parameters. and to update other configuration parameters.
REBIND (6) A client sends a Rebind message to any REBIND (6) A client sends a Rebind message to any
available server to extend the leases on the available server to extend the leases on the
addresses assigned to the client and to update addresses assigned to the client and to update
other configuration parameters; this message is other configuration parameters; this message is
sent after a client receives no response to a sent after a client receives no response to a
Renew message. Renew message.
REPLY (7) A server sends a Reply message containing REPLY (7) A server sends a Reply message containing
assigned addresses and configuration parameters assigned addresses and configuration parameters
in response to a Solicit, Request, Renew, in response to a Solicit, Request, Renew,
Rebind or Information-request message received Rebind message received from a client. A
from a client. A server sends a Reply message server sends a Reply message containing
confirming or denying the validity of the configuration parameters in response to an
client's addresses and configuration parameters Information-request message. A server sends a
in response to a Confirm message. A server Reply message confirming or denying the that
sends a Reply message to acknowledge receipt of the client's addresses are appropriate to
a Release or Decline message. the link to which the client is connected in
response to a Confirm message. A server sends
a Reply message to acknowledge receipt of a
Release or Decline message.
A server sends a Reply message containing
assigned addresses and configuration parameters
in response to a Solicit, Request, Renew,
Rebind message received from a client. A
server sends a Reply message containing
configuration parameters in response to an
Information-request message. A server sends a
Reply message in response to a Confirm message
confirming or denying that the addresses
assigned to the client are appropriate to the
link to which the client is connected. A
server sends a Reply message to acknowledge
receipt of a Release or Decline message.
RELEASE (8) A client sends a Release message to the server RELEASE (8) A client sends a Release message to the server
that assigned addresses to the client to that assigned addresses to the client to
indicate that the client will no longer use one indicate that the client will no longer use one
or more of the assigned addresses. or more of the assigned addresses.
DECLINE (9) A client sends a Decline message to a server to DECLINE (9) A client sends a Decline message to a server to
indicate that the client has determined that indicate that the client has determined that
one or more addresses assigned by the server one or more addresses assigned by the server
are already in use on the link to which the are already in use on the link to which the
skipping to change at page 10, line 14 skipping to change at page 10, line 36
that the client is to initiate a Renew/Reply that the client is to initiate a Renew/Reply
or Information-request/Reply transaction with or Information-request/Reply transaction with
the server in order to receive the updated the server in order to receive the updated
information. information.
INFORMATION-REQUEST (11) A client sends an Information-request INFORMATION-REQUEST (11) A client sends an Information-request
message to a server to request configuration message to a server to request configuration
parameters without the assignment of any IP parameters without the assignment of any IP
addresses to the client. addresses to the client.
RELAY-FORW (12) A relay agent sends a Relay-forward message to RELAY-FORW (12) A relay agent sends a Relay-forward message
forward client messages to servers. The client to forward client messages to servers, either
message is encapsulated in an option in the directly or through another relay agent. The
Relay-forward message. client message is encapsulated in an option in
the Relay-forward message.
RELAY-REPL (13) A server sends a Relay-reply message to a relay RELAY-REPL (13) A server sends a Relay-reply message to a relay
agent to send messages to clients through the agent, either directly or through another relay
relay agent. The server encapsulates the agent, to send messages to clients through
the relay agent. The server encapsulates the
client message as an option in the Relay-reply client message as an option in the Relay-reply
message, which the relay agent extracts and message, which the relay agent extracts and
forwards to the client. forwards to the client.
5.4. Status Codes 5.4. Status Codes
DHCPv6 uses status codes to communicate the success or failure of DHCPv6 uses status codes to communicate the success or failure of
operations requested in messages from clients and servers, and to operations requested in messages from clients and servers, and to
provide additional information about the specific cause of the provide additional information about the specific cause of the
failure of a message. The specific status codes are defined in failure of a message. The specific status codes are defined in
section 24.4. section 24.4.
5.5. Configuration Parameters 5.5. Transmission and Retransmission Parameters
This section presents a table of configuration parameters used to This section presents a table of values used to describe the message
describe the message transmission behavior of clients and servers. transmission behavior of clients and servers.
Parameter Default Description Parameter Default Description
------------------------------------- -------------------------------------
MIN_SOL_DELAY 1 sec Min delay of first Solicit MAX_SOL_DELAY 1 sec Max delay of first Solicit
MAX_SOL_DELAY 5 secs Max delay of first Solicit SOL_TIMEOUT 1 sec Initial Solicit timeout
SOL_TIMEOUT 500 msecs Initial Solicit timeout SOL_MAX_RT 120 secs Max Solicit timeout value
SOL_MAX_RT 30 secs Max Solicit timeout value REQ_TIMEOUT 1 sec Initial Request timeout
REQ_TIMEOUT 250 msecs Initial Request timeout
REQ_MAX_RT 30 secs Max Request timeout value REQ_MAX_RT 30 secs Max Request timeout value
REQ_MAX_RC 10 Max Request retry attempts REQ_MAX_RC 10 Max Request retry attempts
CNF_TIMEOUT 250 msecs Initial Confirm timeout CNF_TIMEOUT 1 sec Initial Confirm timeout
CNF_MAX_RT 1 sec Max Confirm timeout CNF_MAX_RT 4 secs Max Confirm timeout
CNF_MAX_RD 10 secs Max Confirm duration CNF_MAX_RD 10 secs Max Confirm duration
REN_TIMEOUT 10 sec Initial Renew timeout REN_TIMEOUT 10 sec Initial Renew timeout
REN_MAX_RT 600 secs Max Renew timeout value REN_MAX_RT 600 secs Max Renew timeout value
REB_TIMEOUT 10 secs Initial Rebind timeout REB_TIMEOUT 10 secs Initial Rebind timeout
REB_MAX_RT 600 secs Max Rebind timeout value REB_MAX_RT 600 secs Max Rebind timeout value
INF_TIMEOUT 500 ms Initial Information-request timeout INF_TIMEOUT 1 sec Initial Information-request timeout
INF_MAX_RT 30 secs Max Information-request timeout value INF_MAX_RT 120 secs Max Information-request timeout value
REL_TIMEOUT 250 msecs Initial Release timeout REL_TIMEOUT 1 sec Initial Release timeout
REL_MAX_RT 1 sec Max Release timeout REL_MAX_RT 0 Max Release timeout
REL_MAX_RC 5 MAX Release attempts REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 250 msecs Initial Decline timeout DEC_TIMEOUT 1 sec Initial Decline timeout
DEC_MAX_RT 1 sec Max Decline timeout DEC_MAX_RT 0 Max Decline timeout
DEC_MAX_RC 5 Max Decline attempts DEC_MAX_RC 5 Max Decline attempts
REC_TIMEOUT 1 sec Initial Reconfigure timeout REC_TIMEOUT 2 sec Initial Reconfigure timeout
REC_MAX_RC 8 Max Reconfigure attempts REC_MAX_RC 8 Max Reconfigure attempts
HOP_COUNT_LIMIT 4 Max hop count in a Relay-forward message
6. Message Formats 6. Message Formats
All DHCP messages sent between clients and servers share an identical All DHCP messages sent between clients and servers share an identical
fixed format header and a variable format area for options. fixed format header and a variable format area for options.
All values in the message header and in options are in network byte All values in the message header and in options are in network byte
order. order.
Options are stored serially in the options field, with no padding Options are stored serially in the options field, with no padding
between the options. Options are byte-aligned but are not aligned in between the options. Options are byte-aligned but are not aligned in
any other way such as on 2 or 4 byte boundaries. any other way such as on 2 or 4 byte boundaries.
The following diagram illustrates the format of DHCP messages sent The following diagram illustrates the format of DHCP messages sent
between clients and servers: between clients and servers:
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 | transaction-ID | | msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. options . . options .
. (variable) . . (variable) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type Identifies the DHCP message type; the msg-type Identifies the DHCP message type; the
available message types are listed in available message types are listed in
section 5.3. section 5.3.
transaction-id An unsigned integer used by a client or transaction-id The transaction ID for this message exchange.
server to match a response message to a
request message.
options Options carried in this message; options are options Options carried in this message; options are
described in section 22. described in section 22.
7. Relay agent messages 7. Relay agent messages
Relay agents exchange messages with servers to forward messages Relay agents exchange messages with servers to forward messages
between clients and servers that are not connected to the same link. between clients and servers that are not connected to the same link.
There are two relay agent messages, which share the following format: There are two relay agent messages, which share the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | | | msg-type | hop-count | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| link-address |
| | | |
| link-address |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | | | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| client-address |
| | | |
| peer-address |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | | | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. . . .
. options (variable number and length) .... . . options (variable number and length) .... .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following sections describe the use of the Relay Agent message The following sections describe the use of the Relay Agent message
header. header.
7.1. Relay-forward message 7.1. Relay-forward message
The following table defines the use of message fields in a The following table defines the use of message fields in a
Relay-forward message. Relay-forward message.
msg-type RELAY-FORW msg-type RELAY-FORW
skipping to change at page 12, line 44 skipping to change at page 13, line 14
The following sections describe the use of the Relay Agent message The following sections describe the use of the Relay Agent message
header. header.
7.1. Relay-forward message 7.1. Relay-forward message
The following table defines the use of message fields in a The following table defines the use of message fields in a
Relay-forward message. Relay-forward message.
msg-type RELAY-FORW msg-type RELAY-FORW
link-address A global or site-local address that will be used hop-count Number of relay agents that have forwarded this
by the server to identify the link on which the message
client is located.
client-address The address of the client from which the message link-address A global or site-local address that will be used by
to be forwarded was received the server to identify the link on which the client
is located.
options MUST include a "Client message option" (see peer-address The address of the client or relay agent from which
section 22.10); MAY include other options added the message to be forwarded was received
by the relay agent
options MUST include a "Relay Message option" (see
section 22.10); MAY include other options added by
the relay agent
7.2. Relay-reply message 7.2. Relay-reply message
The following table defines the use of message fields in a The following table defines the use of message fields in a
Relay-reply message. Relay-reply message.
msg-type RELAY-REPL msg-type RELAY-REPL
link-address The link-address copied from the Relay-forward hop-count Number of relay agents that have forwarded this
message message
client-address The client's address, copied from the link-address Copied from the Relay-forward message
relay-forward message
options MUST include a "Server message option"; see peer-address The client or relay agent address to which the
section 22.11; MAY include other options message contained in the Relay Message option in
this Relay-reply message is to be forwarded
options MUST include a "Relay Message option"; see
section 22.10; MAY include other options
8. Representation and use of domain names 8. Representation and use of domain names
So that domain names may be encoded uniformly, a domain name or a So that domain names may be encoded uniformly, a domain name or a
list of domain names is encoded using the technique described in list of domain names is encoded using the technique described in
section 3.1 of RFC1035 [11]. A domain name or list of domain names section 3.1 of RFC1035 [13]. A domain name or list of domain names
in DHCP MUST NOT be stored in compressed form as described in section in DHCP MUST NOT be stored in compressed form as described in section
4.1.4 of RFC1035. 4.1.4 of RFC1035.
9. DHCP unique identifier (DUID) 9. DHCP unique identifier (DUID)
Each DHCP client and server has a DUID. DHCP servers use DUIDs to Each DHCP client and server has a DUID. DHCP servers use DUIDs to
identify clients for the selection of configuration parameters and identify clients for the selection of configuration parameters and
in the association of IAs with clients. DHCP clients use DUIDs to in the association of IAs with clients. DHCP clients use DUIDs to
identify a server in messages where a server needs to be identified. identify a server in messages where a server needs to be identified.
See sections 22.2 and 22.3 for the representation of a DUID in a DHCP See sections 22.2 and 22.3 for the representation of a DUID in a DHCP
message. message.
Clients and servers MUST treat DUIDs as opaque values and MUST only Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT in any compare DUIDs for equality. Clients and servers MUST NOT in any
other way interpret DUIDs. Clients and servers MUST NOT restrict other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the types defined in this document as additional DUID types DUIDs to the types defined in this document as additional DUID types
may be defined in the future. may be defined in the future.
The DUID is carried in an option because it may be variable length The DUID is carried in an option because it may be variable length
and because it is not required in all DHCP messages. The DUID is and because it is not required in all DHCP messages. The DUID is
designed to be unique across all DHCP clients and servers, and designed to be unique across all DHCP clients and servers, and stable
consistent for any specific client or server - that is, the DUID used for any specific client or server - that is, the DUID used by a
by a client or server SHOULD NOT change over time if at all possible; client or server SHOULD NOT change over time if at all possible; for
for example, a device's DUID should not change as a result of a example, a device's DUID should not change as a result of a change in
change in the device's network hardware. the device's network hardware.
The motivation for having more than one type of DUID is that the DUID The motivation for having more than one type of DUID is that the DUID
must be globally unique, and must also be easy to generate. The sort must be globally unique, and must also be easy to generate. The sort
of globally-unique identifier that is easy to generate for any given of globally-unique identifier that is easy to generate for any given
device can differ quite widely. Also, some devices may not contain device can differ quite widely. Also, some devices may not contain
any persistent storage. Retaining a generated DUID in such a device any persistent storage. Retaining a generated DUID in such a device
is not possible, so the DUID scheme must accommodate such devices. is not possible, so the DUID scheme must accommodate such devices.
9.1. DUID contents 9.1. DUID contents
A DUID consists of a two octet type code represented in network byte A DUID consists of a two octet type code represented in network byte
order, followed by a variable number of octets that make up the order, followed by a variable number of octets that make up the
actual identifier. A DUID can be no more than 256 octets long. The actual identifier. A DUID can be no more than 256 octets long (not
following types are currently defined: including the type code). The following types are currently defined:
1 Link-layer address plus time 1 Link-layer address plus time
2 Vendor-assigned unique ID based on domain name 2 Vendor-assigned unique ID based on Enterprise Number
3 Vendor-assigned unique ID based on Enterprise Number 3 Link-layer address
4 Link-layer address
Formats for the variable field of the DUID for each of the above Formats for the variable field of the DUID for each of the above
types are shown below. types are shown below.
9.2. DUID based on link-layer address plus time 9.2. DUID based on link-layer address plus time [DUID-LLT]
This type of DUID consists of a two octet type field containing the This type of DUID consists of a two octet type field containing the
value 1, a two octet hardware type code, four octets containing value 1, a two octet hardware type code, four octets containing
a time value, followed by link-layer address of any one network a time value, followed by link-layer address of any one network
interface that is connected to the DHCP device at the time that the interface that is connected to the DHCP device at the time that the
DUID is generated. The time value is the time that the DUID is DUID is generated. The time value is the time that the DUID is
generated represented in seconds since midnight (UTC), January 1, generated represented in seconds since midnight (UTC), January 1,
2000, modulo 2^32. The hardware type MUST be a valid hardware type 2000, modulo 2^32. The hardware type MUST be a valid hardware type
assigned by the IANA as described in the section on ARP in RFC 826. assigned by the IANA as described in the section on ARP in RFC 826.
Both the time and the hardware type are stored in network byte order. Both the time and the hardware type are stored in network byte order.
The link-layer address is stored in canonical form, as described in
RFC2464 [3].
The following diagram illustrates the format of a DUID based on The following diagram illustrates the format of a DUID-LLT:
link-layer address plus time:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Hardware type (16 bits) | | 1 | Hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time (32 bits) | | Time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. link-layer address (variable length) . . link-layer address (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The choice of network interface can be completely arbitrary, as long The choice of network interface can be completely arbitrary, as long
as that interface provides a globally unique link-layer address for as that interface provides a globally unique link-layer address for
the link type, and the same DUID should be used in configuring all the link type, and the same DUID-LLT should be used in configuring
network interfaces connected to the device, regardless of which all network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate the DUID. interface's link-layer address was used to generate the DUID-LLT.
Clients and servers using this type of DUID MUST store the DUID Clients and servers using this type of DUID MUST store the DUID-LLT
in stable storage, and MUST continue to use this DUID even if the in stable storage, and MUST continue to use this DUID-LLT even if the
network interface used to generate the DUID is removed. Clients and network interface used to generate the DUID-LLT is removed. Clients
servers that do not have any stable storage MUST NOT use this type of and servers that do not have any stable storage MUST NOT use this
DUID. type of DUID.
Clients and servers that use this DUID SHOULD attempt to configure Clients and servers that use this DUID SHOULD attempt to configure
the time prior to generating the DUID, if that is possible, and MUST the time prior to generating the DUID, if that is possible, and MUST
use some sort of time source (for example, a real-time clock) in use some sort of time source (for example, a real-time clock) in
generating the DUID, even if that time source could not be configured generating the DUID, even if that time source could not be configured
prior to generating the DUID. The use of a time source makes it prior to generating the DUID. The use of a time source makes it
unlikely that two identical DUIDs will be generated if the network unlikely that two identical DUID-LLTs will be generated if the
interface is removed from the client and another client then uses network interface is removed from the client and another client then
the same network interface to generate a DUID. A DUID collision is uses the same network interface to generate a DUID-LLT. A collision
very unlikely even if the clocks haven't been configured prior to between two DUID-LLTs is very unlikely even if the clocks haven't
generating the DUID. been configured prior to generating the DUID.
This method of DUID generation is recommended for all general purpose This method of DUID generation is recommended for all general purpose
computing devices such as desktop computers and laptop computers, and computing devices such as desktop computers and laptop computers, and
also for devices such as printers, routers, and so on, that contain also for devices such as printers, routers, and so on, that contain
some form of writable non-volatile storage. some form of writable non-volatile storage.
Despite our best efforts, it is possible that this algorithm for Despite our best efforts, it is possible that this algorithm for
generating a DUID could result in a client identifier collision. A generating a DUID could result in a client identifier collision.
DHCP client that generates a DUID using this mechanism MUST provide
an administrative interface that replaces the existing DUID with a
newly-generated DUID of this type.
9.3. Vendor-assigned unique ID based on Enterprise Number (VUID-EN) A DHCP client that generates a DUID-LLT using this mechanism MUST
provide an administrative interface that replaces the existing DUID
with a newly-generated DUID-LLT.
The vendor-assigned unique ID based on Enterprise Number consists of 9.3. DUID assigned by vendor based on Enterprise number [DUID-EN]
the vendor's registered Private Enterprise Number as maintained by
IANA [7] followed by the value of the identifier.
The following diagram summarizes the structure of a VUID-EN: This form of DUID is assigned by the vendor to the device. It
consists of the vendor's registered Private Enterprise Number as
maintained by IANA [9] followed by a unique identifier assigned by
the vendor.
The following diagram summarizes the structure of a DUID-EN:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | enterprise-number | | 2 | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | | | enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier . . identifier .
. (variable length) . . (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The source of the identifier is left up to the vendor defining it, The source of the identifier is left up to the vendor defining it,
but each identifier part of each VUID-EN MUST be unique to the but each identifier part of each DUID-EN MUST be unique to the device
device that is using it, and MUST be assigned to the device at that is using it, and MUST be assigned to the device at the time of
the time of manufacture and stored in some form of non-volatile manufacture and stored in some form of non-volatile storage. The
storage. The VUID SHOULD be recorded in non-erasable storage. The generated DUID SHOULD be recorded in non-erasable storage. The
enterprise-number is the vendor's registered Private Enterprise enterprise-number is the vendor's registered Private Enterprise
Number as maintained by IANA [7]. The enterprise-number is stored as Number as maintained by IANA [9]. The enterprise-number is stored as
an unsigned 32 bit number. an unsigned 32 bit number.
An example DUID of this type might look like this: An example DUID of this type might look like this:
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 3 | 0 | 0 | 0 | 9| 12|192| | 0 | 2 | 0 | 0 | 0 | 9| 12|192|
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
|132|221| 3 | 0 | 9 | 18| |132|221| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+ +---+---+---+---+---+---+
This example includes the two-octet type of 3, the Enterprise Number This example includes the two-octet type of 2, the Enterprise
(9), followed by eight octets of identifier data. Number (9), followed by eight octets of identifier data
(0x0CC084D303000912).
9.4. Link-layer address 9.4. DUID based on link-layer address [DUID-LL]
This type of DUID consists of two octets containing the DUID type 4, This type of DUID consists of two octets containing the DUID type 3,
a two octet network hardware type code, followed by the link-layer a two octet network hardware type code, followed by the link-layer
address of any one network interface that is permanently connected to address of any one network interface that is permanently connected to
the client or server device. For example, this DUID could be used the client or server device. For example, a host that has a network
by a host that has a network interface implemented in a chip that is interface implemented in a chip that is unlikely to be removed and
unlikely to be removed and used elsewhere. The hardware type MUST used elsewhere could use a DUID-LL. The hardware type MUST be a valid
be a valid hardware type assigned by the IANA as described in the hardware type assigned by the IANA as described in the section on
section on ARP in RFC 826. The hardware type is stored in network ARP in RFC 826. The hardware type is stored in network byte order.
byte order. The link-layer address is stored in canonical form, as described in
RFC2464 [3].
The following diagram illustrates the format of a DUID based on The following diagram illustrates the format of a DUID-LL:
link-layer address:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Hardware type (16 bits) | | 3 | Hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. link-layer address (variable length) . . link-layer address (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The choice of network interface can be completely arbitrary, as The choice of network interface can be completely arbitrary, as
long as that interface provides a unique link-layer address and long as that interface provides a unique link-layer address and is
is permanently attached to the device on which the DUID is being permanently attached to the device on which the DUID-LL is being
generated. The same DUID should be used in configuring all network generated. The same DUID should be used in configuring all network
interfaces connected to the device, regardless of which interface's interfaces connected to the device, regardless of which interface's
link-layer address was used to generate the DUID. link-layer address was used to generate the DUID.
This type of DUID is recommended for devices that have a DUID-LL is recommended for devices that have a permanently-connected
permanently-connected network interface with a link-layer address and network interface with a link-layer address and do not have
do not have nonvolatile, writable stable storage. This type of DUID nonvolatile, writable stable storage. DUID-LL MUST NOT be used by
MUST NOT be used by DHCP clients or servers that cannot tell whether DHCP clients or servers that cannot tell whether or not a network
or not a network interface is permanently attached to the device on interface is permanently attached to the device on which the DHCP
which the DHCP client is running. client is running.
10. Identity association 10. Identity association
An "identity-association" (IA) is a construct through which a server An "identity-association" (IA) is a construct through which a server
and a client can identify, group and manage IPv6 addresses. Each IA and a client can identify, group and manage a set of related IPv6
consists of an IAID and associated configuration information. addresses. Each IA consists of an IAID and associated configuration
information.
A client must associate at least one distinct IA with each of A client must associate at least one distinct IA with each of
its network interfaces and uses that IA to obtain configuration its network interfaces and uses that IA to obtain configuration
information from a server for that interface. Each IA must be information from a server for that interface. Each IA must be
associated with exactly one interface. associated with exactly one interface.
The IAID uniquely identifies the IA and must be chosen to be unique The IAID uniquely identifies the IA and must be chosen to be unique
among the IAIDs on the client. The IAID is chosen by the client. among the IAIDs on the client. The IAID is chosen by the client.
For any given use of an IA by the client, the IAID for that IA MUST For any given use of an IA by the client, the IAID for that IA MUST
be consistent across restarts of the DHCP client. The client may be consistent across restarts of the DHCP client. The client may
maintain consistency either by storing the IAID in non-volatile maintain consistency either by storing the IAID in non-volatile
storage or by using an algorithm that will consistently produce the storage or by using an algorithm that will consistently produce the
same IAID as long as the configuration of the client has not changed. same IAID as long as the configuration of the client has not changed.
There may be no way for a client to maintain consistency of the IAIDs There may be no way for a client to maintain consistency of the IAIDs
if it does not have non-volatile storage and the client's hardware if it does not have non-volatile storage and the client's hardware
configuration changes. configuration changes.
The configuration information in an IA consists of one or more IPv6 The configuration information in an IA consists of one or more IPv6
addresses and other parameters. The parameters are specified as DHCP addresses along with the times T1 and T2 for the IA. See section 22.4
options within the IA, and are associated with the addresses in the for the representation of an IA in a DHCP message.
IA and the interface to which the IA belongs. Other parameters that
are not associated with a particular interface may be specified in
the options section of a DHCP message, outside the scope of any IA.
Each address in an IA has a preferred lifetime and a valid lifetime, Each address in an IA has a preferred lifetime and a valid lifetime,
as defined in RFC2462 [18]. The lifetimes are transmitted from the as defined in RFC2462 [20]. The lifetimes are transmitted from the
DHCP server to the client in the IA option. The lifetimes apply to DHCP server to the client in the IA option. The lifetimes apply to
the use of IPv6 addresses as described in section 5.5.4 of RFC2462. the use of IPv6 addresses as described in section 5.5.4 of RFC2462.
See section 22.4 for the representation of an IA in a DHCP message.
11. Selecting addresses for assignment to an IA 11. Selecting addresses for assignment to an IA
A server selects addresses to be assigned to an IA according to the A server selects addresses to be assigned to an IA according to the
address assignment policies determined by the server administrator address assignment policies determined by the server administrator
and the specific information the server determines about the client and the specific information the server determines about the client
from some combination of the following sources: from some combination of the following sources:
- The link to which the client is attached. The server determines - The link to which the client is attached. The server determines
the link as follows: the link as follows:
skipping to change at page 18, line 31 skipping to change at page 19, line 4
* If the server receives the message directly from the client * If the server receives the message directly from the client
and the source address in the IP datagram in which the and the source address in the IP datagram in which the
message was received is not a link-local address, then the message was received is not a link-local address, then the
client is on the link identified by the source address in the client is on the link identified by the source address in the
IP datagram (note that this situation can occur only if the IP datagram (note that this situation can occur only if the
server has enabled the use of unicast message delivery by the server has enabled the use of unicast message delivery by the
client and the client has sent a message for which unicast client and the client has sent a message for which unicast
delivery is allowed) delivery is allowed)
- The DUID supplied by the client - The DUID supplied by the client
- Other information in options supplied by the client - Other information in options supplied by the client
- Other information in options supplied by the relay agent - Other information in options supplied by the relay agent
Any unicast address assigned by a server that is based on an Any unicast address assigned by a server that is based on an
EUI-64 identifier MUST include an interface identifier with the "u" EUI-64 identifier MUST include an interface identifier with the "u"
(universal/local) and "g" (individual/group) bits of the interface (universal/local) and "g" (individual/group) bits of the interface
identifier set appropriately, as indicated in section 2.5.1 of RFC identifier set appropriately, as indicated in section 2.5.1 of RFC
2373. 2373 [8].
A server MUST NOT assign an address that is otherwise reserved for A server MUST NOT assign an address that is otherwise reserved for
some other purpose. These reserved addresses may be specified as some other purpose. For example, a server MUST NOT assign reserved
128-bit IPv6 addresses or as interface identifiers that are reserved
for all subnets. For example, a server MUST NOT assign reserved
anycast addresses, as defined in RFC2526, from any subnet. anycast addresses, as defined in RFC2526, from any subnet.
12. Management of temporary addresses 12. Management of temporary addresses
A client may be assigned temporary addresses (temporary addresses A client may be assigned temporary addresses (temporary addresses are
are defined in RFC 3041 [13]). Clients and servers simply identify defined in RFC 3041 [15]). DHCPv6 handling of address assignment
addresses as "temporary". DHCPv6 handling of address assignment is is no different for temporary addresses. DHCPv6 says nothing about
no different for temporary addresses. DHCPv6 says nothing about
details of temporary addresses like lifetimes, how clients use details of temporary addresses like lifetimes, how clients use
temporary addresses, rules for generating successive temporary temporary addresses, rules for generating successive temporary
addresses, etc. addresses, etc.
Clients ask for temporary addresses and servers assign them. Clients ask for temporary addresses and servers assign them.
Temporary addresses are carried in the Identity Association for Temporary addresses are carried in the Identity Association for
Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA
option contains at most one temporary address for each of the option contains at most one temporary address for each of the
prefixes on the link to which the client is attached. prefixes on the link to which the client is attached.
Unless otherwise stated, an IA_TA option is used in the same way in Unless otherwise stated, an IA_TA option is used in the same way
as an IA option. In the protocol specification, unless otherwise as an IA option. In the protocol specification, unless otherwise
stated, a reference to an IA should be read as either an IA or an stated, a reference to an IA should be read as either an IA or an
IA_TA. IA_TA.
The IAID number space for the IA_TA option IAID number space is The IAID number space for the IA_TA option IAID number space is
separate from the IA option IAID number space. separate from the IA option IAID number space.
The server MAY update the DNS for a temporary address as described in The server MAY update the DNS for a temporary address as described in
section 4 of RFC3041. section 4 of RFC3041.
13. Transmission of messages by a client 13. Transmission of messages by a client
Unless otherwise specified, a client sends DHCP messages to the Unless otherwise specified in this document or in a document that
All_DHCP_Relay_Agents_and_Servers. describes how IPv6 is carried over a specific type of link (for link
types that do not support multicast), a client sends DHCP messages to
the All_DHCP_Relay_Agents_and_Servers.
If the client is attached to a link that supports multicast A client uses multicast to reach all servers or an individual server.
transmission, the client sends DHCP messages to the An individual server is indicated by specifying that server's DUID in
All_DHCP_Relay_Agents_and_Servers address. a Server Identifier option (see section 22.3) in the client's message
(all servers will receive this message but only the indicated server
will respond). All servers are indicated by not supplying this
option.
A client may send some messages directly to a server using unicast, A client may send some messages directly to a server using unicast,
as described in section 22.13. as described in section 22.12.
14. Reliability of Client Initiated Message Exchanges 14. Reliability of Client Initiated Message Exchanges
DHCP clients are responsible for reliable delivery of messages in the DHCP clients are responsible for reliable delivery of messages in the
client-initiated message exchanges described in sections 17 and 18. client-initiated message exchanges described in sections 17 and 18.
If a DHCP client fails to receive an expected response from a server, If a DHCP client fails to receive an expected response from a server,
the client must retransmit its message. This section describes the the client must retransmit its message. This section describes the
retransmission strategy to be used by clients in client-initiated retransmission strategy to be used by clients in client-initiated
message exchanges. message exchanges.
skipping to change at page 21, line 23 skipping to change at page 21, line 45
15. Message validation 15. Message validation
Clients and servers SHOULD discard any messages that contain options Clients and servers SHOULD discard any messages that contain options
that are not allowed to appear in the received message. For example, that are not allowed to appear in the received message. For example,
an Information-request message must not include an IA option. an Information-request message must not include an IA option.
Clients and server MAY choose to extract information from such a Clients and server MAY choose to extract information from such a
message if the information is of use to the recipient. message if the information is of use to the recipient.
Message validation based on DHCP authentication is discussed in Message validation based on DHCP authentication is discussed in
section 21.5.3. section 21.5.2.
15.1. Use of Transaction-ID field 15.1. Use of Transaction IDs
The "transaction-ID" field holds a value used by clients and servers The "transaction-id" field holds a value used by clients and servers
to synchronize server responses to client messages. A client SHOULD to synchronize server responses to client messages. A client
choose a different transaction-ID for each new message it sends. A SHOULD generate a random number that cannot easily be guessed or
client MUST leave the transaction-ID unchanged in retransmissions of predicted to use as the transaction ID for each new message it sends.
a message.
Note that if a client generates easily predictable transaction
identifiers, it may become more vulnerable to certain kinds of
attacks from off-path intruders. A client MUST leave the transaction
ID unchanged in retransmissions of a message.
15.2. Solicit message 15.2. Solicit message
Clients MUST discard any received Solicit messages. Clients MUST discard any received Solicit messages.
Servers MUST discard any Solicit messages that do not include a Servers MUST discard any Solicit messages that do not include a
Client Identifier option or that do include a Server Identifier Client Identifier option or that do include a Server Identifier
option. option.
15.3. Advertise message 15.3. Advertise message
Clients MUST discard any received Advertise messages that meet any of Clients MUST discard any received Advertise messages that meet any of
the following conditions: the following conditions:
- the message does not include a Server Identifier option - the message does not include a Server Identifier option
- the message does not include a Client Identifier option - the message does not include a Client Identifier option
- the contents of the Client Identifier option does not match the - the contents of the Client Identifier option does not match the
client's DUID client's DUID
- the "Transaction-ID" field value does not match the value the
- the "transaction-id" field value does not match the value the
client used in its Solicit message client used in its Solicit message
Servers and relay agents MUST discard any received Advertise Servers and relay agents MUST discard any received Advertise
messages. messages.
15.4. Request message 15.4. Request message
Clients MUST discard any received Request messages. Clients MUST discard any received Request messages.
Servers MUST discard any received Request message that meet any of Servers MUST discard any received Request message that meet any of
the following conditions: the following conditions:
- the message does not include a Server Identifier option - the message does not include a Server Identifier option
- the contents of the Server Identifier option do not match the - the contents of the Server Identifier option do not match the
server's identifier server's DUID
- the message does not include a Client Identifier option - the message does not include a Client Identifier option
15.5. Confirm message 15.5. Confirm message
Clients MUST discard any received Confirm messages. Clients MUST discard any received Confirm messages.
Servers MUST discard any Confirm messages received that do not Servers MUST discard any received Confirm messages that do not
include a Client Identifier option or that do include a Server include a Client Identifier option or that do include a Server
Identifier option. Identifier option.
15.6. Renew message 15.6. Renew message
Clients MUST discard any received Renew messages. Clients MUST discard any received Renew messages.
Servers MUST discard any received Renew message that meets any of the Servers MUST discard any received Renew message that fails to meet
following conditions: any of the following conditions:
- the message does not include a Server Identifier option - the message MUST include a Server Identifier option
- the contents of the Server Identifier option do not match the - the contents of the Server Identifier option MUST match the
server's identifier server's identifier
- the message does not include a Client Identifier option - the message MUST include a Client Identifier option
15.7. Rebind message 15.7. Rebind message
Clients MUST discard any received Rebind messages. Clients MUST discard any received Rebind messages.
Servers MUST discard any received Rebind messages that do not include Servers MUST discard any received Rebind messages that do not include
a Client Identifier option or that do include a Server Identifier a Client Identifier option or that do include a Server Identifier
option. option.
15.8. Decline messages 15.8. Decline messages
Clients MUST discard any received Decline messages. Clients MUST discard any received Decline messages.
Servers MUST discard any received Decline message that meets any of Servers MUST discard any received Decline message that fails to meet
the following conditions: any of the following conditions:
- the message does not include a Server Identifier option - the message MUST include a Server Identifier option
- the contents of the Server Identifier option do not match the - the contents of the Server Identifier option MUST match the
server's identifier server's identifier
- the message does not include a Client Identifier option - the message MUST include a Client Identifier option
15.9. Release message 15.9. Release message
Clients MUST discard any received Release messages. Clients MUST discard any received Release messages.
Servers MUST discard any received Release message that meets any of Servers MUST discard any received Release message that fails to meet
the following conditions: any of the following conditions:
- the message does not include a Server Identifier option
- the contents of the Server Identifier option do not match the - the message MUST include a Server Identifier option
- the contents of the Server Identifier option MUST match the
server's identifier server's identifier
- the message does not include a Client Identifier option - the message MUST include a Client Identifier option
15.10. Reply message 15.10. Reply message
Clients MUST discard any received Reply messages that meet any of the Clients MUST discard any received Reply message that fails to meet
following conditions: any of the following conditions:
- the message does not include a Server Identifier option - the message MUST include a Server Identifier option
- the "transaction-ID" field in the message does not match the - the "transaction-id" field in the message MUST match the value
value used in the original message used in the original message
- the message does not include a Client Identifier option and the - the message MUST include a Client Identifier option and the
original message from the client contained a Client Identifier original message from the client contained a Client Identifier
option option
- the message includes a Client Identifier option and the contents - if the client included a Client Identifier option in the original
of the Client Identifier option does not match the DUID of the message, the message MUST include a Client Identifier option
client or the client did not include a Client Identifier option and the contents of the Client Identifier option MUST match the
in the original message DUID of the client or, if the client did not include a Client
Identifier option in the original message, the Reply message MUST
NOT include a Client Identifier option
Servers and relay agents MUST discard any received Reply messages. Servers and relay agents MUST discard any received Reply messages.
15.11. Reconfigure message 15.11. Reconfigure message
Servers and relay agents MUST discard any received Reconfigure Servers and relay agents MUST discard any received Reconfigure
messages. messages.
Clients MUST discard any Reconfigure messages that fails any of the Clients MUST discard any Reconfigure messages that fails any of the
following conditions: following conditions:
- the message MUST include a Server Identifier option - the message MUST include a Server Identifier option
- the message MUST include a Client Identifier option that contains
the client's DUID
- the message MUST include one of the available security - the message MUST include one of the available security
mechanisms: mechanisms:
* the server sends a Reconfigure Nonce option whose value * the server sends a Reconfigure Nonce option whose value
matches the current server nonce value known to the client matches the current server nonce value known to the client
* the server uses DHCP authentication: beginitemize * the server uses DHCP authentication:
* the message MUST contain an authentication option
* the message MUST pass the authentication validation performed + the message MUST contain an authentication option
by the client + the message MUST pass the authentication validation
performed by the client
15.12. Information-request message 15.12. Information-request message
Clients MUST discard any received Information-request messages. Clients MUST discard any received Information-request messages.
Servers MUST discard any received Information-request message that Servers MUST discard any received Information-request message that
includes a Server Identifier option and the DUID in the option does includes a Server Identifier option and the DUID in the option does
not match the server's DUID. not match the server's DUID.
15.13. Relay-forward message 15.13. Relay-forward message
skipping to change at page 24, line 50 skipping to change at page 25, line 29
15.14. Relay-reply message 15.14. Relay-reply message
Clients and servers MUST discard any received Relay-reply messages. Clients and servers MUST discard any received Relay-reply messages.
16. Client Source Address and Interface Selection 16. Client Source Address and Interface Selection
When a client sends a DHCP message to the When a client sends a DHCP message to the
All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the
message through the interface for which configuration information is message through the interface for which configuration information is
being requested. However, the client MAY send the message through being requested. However, the client MAY send the message through
another interface attached to the same link if and only if the client another interface attached to the same link if and only if the
is certain the two interface are attached to the same link. In client is certain the two interface are attached to the same link.
addition, the client MUST use the IPv6 link-local address assigned to In addition, the client SHOULD use an IP address assigned to the
the interface for which it is requesting configuration information as interface for which it is requesting configuration information as
the source address in the header of the IP datagram. the source address in the header of the IP datagram. If the client
uses a different address as the source address, the address MUST
be assigned to an interface that will be attached to the same link
as the interface for which the client is requesting configuration
information when the response is received from the server.
When a client sends a DHCP message directly to a server using unicast When a client sends a DHCP message directly to a server using unicast
(after receiving the Server Unicast option from that server), the (after receiving the Server Unicast option from that server), the
source address in the header of the IP datagram MUST be an address source address in the header of the IP datagram MUST be an address
assigned to the interface for which the client is interested in assigned to the interface for which the client is interested in
obtaining configuration and which is suitable for use by the server obtaining configuration and which is suitable for use by the server
in responding to the client. in responding to the client.
17. DHCP Server Solicitation 17. DHCP Server Solicitation
skipping to change at page 25, line 35 skipping to change at page 26, line 21
client then initiates a configuration exchange as described in client then initiates a configuration exchange as described in
section 18. section 18.
Whenever a client initiates server solicitation with a Solicit Whenever a client initiates server solicitation with a Solicit
message, it discards any reconfigure nonce values it may have message, it discards any reconfigure nonce values it may have
previously recorded. previously recorded.
17.1. Client Behavior 17.1. Client Behavior
A client uses the Solicit message to discover DHCP servers configured A client uses the Solicit message to discover DHCP servers configured
to serve addresses on the link to which the client is attached. to assign addresses or return other configuration parameters on the
link to which the client is attached.
17.1.1. Creation of Solicit messages 17.1.1. Creation of Solicit messages
The client sets the "msg-type" field to SOLICIT. The client generates The client sets the "msg-type" field to SOLICIT. The client generates
a transaction ID and inserts this value in the "transaction-ID" a transaction ID and inserts this value in the "transaction-id"
field. field.
The client MUST include a Client Identifier option to identify itself The client MUST include a Client Identifier option to identify itself
to the server. The client MUST include one or more IA options for to the server. The client includes IA options for any IAs to which
any IAs to which it wants the server to assign addresses. The it wants the server to assign addresses. The client MAY include
client MAY include addresses in the IAs as a hint to the server addresses in the IAs as a hint to the server about addresses for
about addresses for which the client has a preference. The client which the client has a preference. The client MUST NOT include any
MUST NOT include any other options in the Solicit message except as other options in the Solicit message except as specifically allowed
specifically allowed in the definition of individual options. in the definition of individual options.
The client uses IA options to request the assignment of non-temporary The client uses IA options to request the assignment of non-temporary
addresses and uses IA_TA options to request the assignment of addresses and uses IA_TA options to request the assignment of
temporary addresses. Either IA or IA_TA options, or a combination of temporary addresses. Either IA or IA_TA options, or a combination of
both can be included in DHCP messages. both can be included in DHCP messages.
The client MAY request specific options from the server by including The client MUST include an Option Request option (see section 22.7)
an Option Request option (see section 22.7) as a hint about the to indicate the options the client is interested in receiving. The
options the client is interested in receiving. If the client client MAY include options with data values as hints to the server
requires a consistent prioritization of the options it receives, it about parameter values the client would like to have returned.
includes an Option Request option indicating the options it needs
(see section 17.2.2). The client MAY include options with data
values as hints to the server about parameter values the client would
like to have returned.
If the client will accept a Reply message with committed address If the client will accept a Reply message with committed address
assignments and other resources in response to the Solicit message, assignments and other resources in response to the Solicit message,
the client includes a Rapid Commit option (see section 22.15) in the the client includes a Rapid Commit option (see section 22.14) in the
Solicit message. Solicit message.
17.1.2. Transmission of Solicit Messages 17.1.2. Transmission of Solicit Messages
The first Solicit message from the client on the interface MUST The first Solicit message from the client on the interface MUST be
be delayed by a random amount of time between MIN_SOL_DELAY and delayed by a random amount of time between 0 and MAX_SOL_DELAY. In
MAX_SOL_DELAY. In the case of a Solicit message transmitted when DHCP the case of a Solicit message transmitted when DHCP is initiated
is initiated by IPv6 Neighbor Discovery, the delay gives the amount by IPv6 Neighbor Discovery, the delay gives the amount of time to
of time to wait after IPv6 Neighbor Discovery causes the client to wait after IPv6 Neighbor Discovery causes the client to invoke the
invoke the stateful address autoconfiguration protocol (see section stateful address autoconfiguration protocol (see section 5.5.3 of
5.5.3 of RFC2462). This random delay desynchronizes clients which RFC2462). This random delay desynchronizes clients which start at
start at the same time (for example, after a power outage). the same time (for example, after a power outage).
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT SOL_TIMEOUT IRT SOL_TIMEOUT
MRT SOL_MAX_RT MRT SOL_MAX_RT
MRC 0 MRC 0
MRD 0 MRD 0
If the client has included a Rapid Commit option and is waiting for If the client has included a Rapid Commit option in its Solicit
a Reply message, the client terminates the retransmission process message, the client terminates the waiting process as soon as a
as soon as a Reply message is received. If the client receives an Reply message with a Rapid Commit option is received. If the client
Advertise message that includes a Preference option with a preference receives an Advertise message that includes a Preference option
value of 255, the client immediately begins a client-initiated with a preference value of 255, the client immediately begins a
message exchange (as described in section 18) by sending a Request client-initiated message exchange (as described in section 18) by
message to the server from which the Advertise message was received. sending a Request message to the server from which the Advertise
If the client receives an Advertise message that does not include message was received. If the client receives an Advertise message
a Preference option with a preference value of 255, the client that does not include a Preference option with a preference value of
continues to wait until the first RT elapses. If the first RT 255, the client continues to wait until the first RT elapses. If the
elapses and the client has received an Advertise message, the client first RT elapses and the client has received an Advertise message,
SHOULD continue with a client-initiated message exchange by sending a the client SHOULD continue with a client-initiated message exchange
Request message. by sending a Request message.
If the client is waiting for an Advertise message, the mechanism in If the client is waiting for an Advertise message, the mechanism in
section 14 is modified as follows for use in the transmission of section 14 is modified as follows for use in the transmission of
Solicit messages. The message exchange is not terminated by the Solicit messages. The message exchange is not terminated by the
receipt of an Advertise before the first RT has elapsed. Rather, the receipt of an Advertise before the first RT has elapsed. Rather, the
client collects Advertise messages until the first RT has elapsed. client collects Advertise messages until the first RT has elapsed.
Also, the first RT MUST be selected to be strictly greater than IRT Also, the first RT MUST be selected to be strictly greater than IRT
by choosing RAND to be strictly greater than 0. by choosing RAND to be strictly greater than 0.
A client MUST collect Advertise messages for the first RT seconds, A client MUST collect Advertise messages for the first RT seconds,
unless it receives an Advertise message with a preference value unless it receives an Advertise message with a preference value
of 255. The preference value is carried in the Preference option of 255. The preference value is carried in the Preference option
(section 22.8). Any Solicit that does not include a Preference (section 22.8). Any Advertise that does not include a Preference
option is considered to have a preference value of 0. If the client option is considered to have a preference value of 0. If the client
receives an Advertise message with a preference value of 255, then receives an Advertise message with a preference value of 255, then
the client SHOULD act immediately on that Advertise message without the client SHOULD act immediately on that Advertise message without
waiting for any additional Advertise messages. waiting for any additional Advertise messages.
If the client does not receive any Advertise messages before If the client does not receive any Advertise messages before
the first RT has elapsed, it begins the retransmission mechanism the first RT has elapsed, it begins the retransmission mechanism
described in section 14. The client terminates the retransmission described in section 14. The client terminates the retransmission
process as soon as it receives any Advertise message, and the client process as soon as it receives any Advertise message, and the client
acts on the received Advertise message without waiting for any acts on the received Advertise message without waiting for any
additional Advertise messages. additional Advertise messages.
A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client
is configured with either MRC or MRD set to a value other than is configured with either MRC or MRD set to a value other than
0, it MUST stop trying to configure the interface if the message 0, it MUST stop trying to configure the interface if the message
exchange fails. After the DHCP client stops trying to configure the exchange fails. After the DHCP client stops trying to configure
interface, it SHOULD choose to restart the reconfiguration process the interface, it SHOULD restart the reconfiguration process after
after some external event, such as user input, system restart, or some external event, such as user input, system restart, or when the
when the client is attached to a new link. client is attached to a new link.
17.1.3. Receipt of Advertise messages 17.1.3. Receipt of Advertise messages
The client MUST ignore any Advertise message that includes a Status The client MUST ignore any Advertise message that includes a Status
Code option containing the value AddrUnavail, with the exception that Code option containing the value NoAddrsAvail, with the exception
the client MAY display the associated status message to the user. that the client MAY display the associated status message to the
user.
Upon receipt of one or more valid Advertise messages, the client Upon receipt of one or more valid 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 value - Those Advertise messages with the highest server preference value
are preferred over all other Advertise messages. are preferred over all other Advertise 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
skipping to change at page 28, line 21 skipping to change at page 29, line 8
preference value, addresses advertised, when the advertisement was preference value, addresses advertised, when the advertisement was
received, and so on. received, and so on.
If the client needs to select an alternate server in the case that a If the client needs to select an alternate server in the case that a
chosen server does not respond, the client chooses the next server chosen server does not respond, the client chooses the next server
according to the criteria given above. according to the criteria given above.
17.1.4. Receipt of Reply message 17.1.4. Receipt of Reply message
If the client includes a Rapid Commit option in the Solicit message, If the client includes a Rapid Commit option in the Solicit message,
it will expect a Reply message that includes a Rapid Commit option in it will expect a Reply message that includes a Rapid Commit option
response. If the client receives a valid Reply message that includes in response. The client discards any Reply messages it receives
a Rapid Commit option, it processes the message as described in that do not include a Rapid Commit option. If the client receives
section 18.1.6. a valid Reply message that includes a Rapid Commit option, it
processes the message as described in section 18.1.8. If it does
not receive such a Reply message and does receive a valid Advertise
message, the client processes the Advertise message as described in
section 17.1.3.
17.2. Server Behavior 17.2. Server Behavior
A server sends an Advertise message in response to valid Solicit A server sends an Advertise message in response to valid Solicit
messages it receives to announce the availability of the server to messages it receives to announce the availability of the server to
the client. the client.
17.2.1. Receipt of Solicit messages 17.2.1. Receipt of Solicit messages
The server determines the information about the client and its The server determines the information about the client and its
location as described in section 11 and checks its administrative location as described in section 11 and checks its administrative
policy about responding to the client. If the server is not policy about responding to the client. If the server is not
permitted to respond to the client, the server discards the Solicit permitted to respond to the client, the server discards the Solicit
message. message.
If the client has included a Rapid Commit option in the Solicit If the client has included a Rapid Commit option in the Solicit
message and the server has been configured to respond with committed message and the server has been configured to respond with committed
address assignments and other resources, the server responds to the address assignments and other resources, the server responds to
Solicit with a Reply message as described in section 17.2.3. If the the Solicit with a Reply message as described in section 17.2.3.
server has been configured to respond to the client but has not been Otherwise, the server ignores the Rapid Commit option and processes
configured to respond with committed address assignments and other the remainder of the message as if no Rapid Commit option were
resources, the server responds with an Advertise message. present.
Otherwise, the server generates and sends an Advertise message to the
client.
17.2.2. Creation and transmission of Advertise messages 17.2.2. Creation and transmission of Advertise messages
The server sets the "msg-type" field to ADVERTISE and copies the The server sets the "msg-type" field to ADVERTISE and copies the
contents of the transaction-ID field from the Solicit message contents of the transaction-id field from the Solicit message
received from the client to the Advertise message. The server received from the client to the Advertise message. The server
includes its server identifier in a Server Identifier option and includes its server identifier in a Server Identifier option and
copies the Client Identifier from the Solicit message into the copies the Client Identifier from the Solicit message into the
Advertise message. Advertise message.
The server MAY add a Preference option to carry the preference value The server MAY add a Preference option to carry the preference value
for the Advertise message. The server implementation SHOULD allow for the Advertise message. The server implementation SHOULD allow
the setting of a server preference value by the administrator. the setting of a server preference value by the administrator.
The server preference value MUST default to zero unless otherwise The server preference value MUST default to zero unless otherwise
configured by the server administrator. configured by the server administrator.
The server MUST include IA options in the Advertise message The server includes options the server will return to the client in
containing any addresses that would be assigned to IAs contained in a subsequent Reply message. The information in these options may
the Solicit message from the client. be used by the client in the selection of a server if the client
receives more than one Advertise message. If the client has included
an Option Request option in the Solicit message, the server includes
options in the Advertise message containing configuration parameters
for all of the options identified in the Option Request option
that the server has been configured to return to the client. The
server MAY return additional options to the client if it has been
configured to do so. The server SHOULD limit the options returned to
the client so that the DHCP message header and options do not cause
fragmentation.
If the server will not assign any addresses to IAs in a subsequent If the Solicit message from the client included one or more IA
Request from the client, the server MUST send an Advertise message to options, the server MUST include IA or IAID options in the Advertise
the client that includes only a status code option with the status message containing any addresses that would be assigned to IAs
code set to AddrUnavail and a status message for the user. contained in the Solicit message from the client.
The server includes other options the server will return to the If the server will not assign any addresses to any IAs in a
client in a subsequent Reply message. The server SHOULD limit the subsequent Request from the client, the server MUST send an Advertise
options returned to the client so that the DHCP message header and message to the client that includes only a Status Code option with
options do not cause fragmentation. The information in these options code NoAddrsAvail, a status message for the user, a Server Identifier
will be used by the client in the selection of a server if the client option with the server's DUID and a Client Identifier option with the
receives more than one Advertise message. If the client has included client's DUID.
an Option Request option in the Solicit message, the server uses that
option as a hint about the options the client has a preference for
receiving from the server.
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 address in the source address field from the IP datagram in the address in the source address field from the IP datagram in which
which the Solicit message was received. The Advertise message MUST the Solicit message was received. The Advertise message MUST be
be unicast through the interface on which the Solicit message was unicast on the link from which the Solicit message was received.
received.
If the Solicit message was received in a Relay-forward message, If the Solicit message was received in a Relay-forward message,
the server constructs a Relay-reply message with the Advertise the server constructs a Relay-reply message with the Advertise
message in the payload of a "server-message" option. If the message in the payload of a "server-message" option. If the
Relay-forward messages included an Interface-id option, the server Relay-forward messages included an Interface-id option, the server
copies that option to the Relay-reply message. The server unicasts copies that option to the Relay-reply message. The server unicasts
the Relay-reply message directly to the relay agent using the the Relay-reply message directly to the relay agent using the
address in the source address field from the IP datagram in which the address in the source address field from the IP datagram in which the
Relay-forward message was received. Relay-forward message was received.
17.2.3. Creation and Transmission of Reply messages 17.2.3. Creation and Transmission of Reply messages
The server MUST commit the assignment of any addresses or other The server MUST commit the assignment of any addresses or other
configuration information message before sending a Reply message to a configuration information message before sending a Reply message to a
client in response to a Solicit message. client in response to a Solicit message.
DISCUSSION: DISCUSSION:
When using the Solicit-Advertise message exchange, a server
need not commit the assignment of configuration information
to the client or otherwise keep state about the client
before the server sends the Advertise message to the client.
The client will choose one of the responding servers and
send a Request message to obtain configuration information.
The other servers can make any addresses they might have
offered to the client available for assignment to other
clients.
When using the Solicit-Reply message exchange, the server When using the Solicit-Reply message exchange, the server
commits the assignment of any addresses before sending the commits the assignment of any addresses before sending the
Reply message. The client can assume it has been assigned Reply message. The client can assume it has been assigned
the addresses in the Reply message and does not need to send the addresses in the Reply message and does not need to send
a Request message for those addresses. a Request message for those addresses.
Typically, servers that are configured to use the Typically, servers that are configured to use the
Solicit-Reply message exchange will be deployed so that only Solicit-Reply message exchange will be deployed so that only
one server will respond to a Solicit message. If more than one server will respond to a Solicit message. If more than
one server responds, the client will only use the addresses one server responds, the client will only use the addresses
skipping to change at page 31, line 5 skipping to change at page 31, line 35
transmits the Reply message as described in section 18.2.8. transmits the Reply message as described in section 18.2.8.
18. DHCP Client-Initiated Configuration Exchange 18. DHCP Client-Initiated Configuration Exchange
A client initiates a message exchange with a server or servers A client initiates a message exchange with a server or servers
to acquire or update configuration information of interest. The to acquire or update configuration information of interest. The
client may initiate the configuration exchange as part of the client may initiate the configuration exchange as part of the
operating system configuration process, when requested to do operating system configuration process, when requested to do
so by the application layer, when required by Stateless Address so by the application layer, when required by Stateless Address
Autoconfiguration or as required to extend the lifetime of an address Autoconfiguration or as required to extend the lifetime of an address
(Rebind and Renew messages). (Renew and Rebind messages).
18.1. Client Behavior 18.1. Client Behavior
A client will use Request, Confirm, Renew, Rebind and A client uses Request, Confirm, Renew, Rebind and Information-request
Information-request messages to acquire and confirm the messages to acquire and confirm the validity of configuration
validity of configuration information. The client uses the server information.
identifier information and information about IAs from previous
Advertise messages for use in constructing these messages. If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received
a Server Unicast option (section 22.12) from the server, the client
SHOULD unicast any Request, Renew, Release and Decline messages to
the server.
DISCUSSION:
Use of unicast may avoid delays due to forwarding of
messages by relay agents as well as avoid overhead and
duplicate responses by servers due to delivery of client
messages to multiple servers. Requiring the client to
relay all DHCP messages through a relay agent enables the
inclusion of relay agent options in all messages sent by the
client. The server should enable the use of unicast only
when relay agent options will not be used.
18.1.1. Creation and transmission of Request messages 18.1.1. Creation and transmission of Request messages
The client uses a Request message to populate IAs with addresses The client uses a Request message to populate IAs with addresses and
and obtain other configuration information. The client includes obtain other configuration information. The client includes one or
one or more IA options in the Request message, with addresses and more IA options in the Request message. The server then returns
information about the IAs that were obtained from the server in a addresses and other information about the IAs to the client in IA
previous Advertise message. The server then returns addresses and options in a Reply message.
other information about the IAs to the client in IA options in a
Reply message.
The client generates a transaction ID and inserts this value in the The client generates a transaction ID and inserts this value in the
"transaction-ID" field. "transaction-id" field.
The client places the identifier of the destination server in a The client places the identifier of the destination server in a
Server Identifier option. Server Identifier option.
The client MUST include a Client Identifier option to identify itself The client MUST include a Client Identifier option to identify itself
to the server. The client adds any other appropriate options, to the server. The client adds any other appropriate options,
including one or more IA options (if the client is requesting that including one or more IA options (if the client is requesting that
the server assign it some network addresses). the server assign it some network addresses).
The client MAY request specific options from the server by including The client MUST include an Option Request option (see section 22.7)
an Option Request option (see section 22.7) as a hint about the to indicate the options the client is interested in receiving. The
options the client is interested in receiving. If the client client MAY include options with data values as hints to the server
requires a consistent prioritization of the options it receives, it about parameter values the client would like to have returned.
includes an Option Request option indicating the options it needs
(see section 18.2.1). The client MAY include options with data
values as hints to the server about parameter values the client would
like to have returned.
If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received
a Server Unicast option (section 22.13) from the server, the client
SHOULD unicast the Request message to the server.
DISCUSSION:
Use of multicast on a link and relay agents enables the
inclusion of relay agent options in all messages sent by the
client. The server should enable the use of unicast only
when relay agent options will not be used.
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT REQ_TIMEOUT IRT REQ_TIMEOUT
MRT REQ_MAX_RT MRT REQ_MAX_RT
MRC REQ_MAX_RC MRC REQ_MAX_RC
MRD 0 MRD 0
If the message exchange fails, the client MAY choose one of the If the message exchange fails, the client takes an action based on
following actions: the client's local policy. Examples of actions the client might take
include:
- Select another server from a list of servers known to the client; - Select another server from a list of servers known to the client;
for example, servers that responded with an Advertise message for example, servers that responded with an Advertise message
- Initiate the server discovery process described in section 17 - Initiate the server discovery process described in section 17
- Terminate the configuration process and report failure - Terminate the configuration process and report failure
18.1.2. Creation and transmission of Confirm messages 18.1.2. Creation and transmission of Confirm messages
Whenever a client may have moved to a new link, its IPv6 addresses Whenever a client may have moved to a new link, the prefixes from the
and other configuration information may no longer be valid. Examples addresses assigned to the interfaces on that link may no longer be
of times when a client may have moved to a new link include: appropriate to the link. Examples of times when a client may have
moved to a new link include:
Whenever a client may have moved to a new link, the prefixes from the
addresses assigned to the interfaces on that link may no longer be
appropriate to the link to which the client is attached. Examples of
times when a client may have moved to a new link include:
o The client reboots o The client reboots
o The client is physically disconnected from a wired connection o The client is physically disconnected from a wired connection
o The client returns from sleep mode o The client returns from sleep mode
o The client using a wireless technology changes access points o The client using a wireless technology changes access points
In any situation when a client may have moved to a new link, the In any situation when a client may have moved to a new link, the
client MUST initiate a Confirm/Reply message exchange. The client client MUST initiate a Confirm/Reply message exchange. The client
includes any IAs, along with the addresses associated with those IAs, includes any IAs, along with the addresses associated with those IAs,
in its Confirm message. Any responding servers will indicate the in its Confirm message. Any responding servers will indicate whether
acceptability of the addresses with the status in the Reply message those addresses are appropriate to the link to which the client is
it returns to the client. attached with the status in the Reply message it returns to the
client.
In any situation when a client may have moved to a new link, the
client MUST initiate a Confirm/Reply message exchange. The client
includes any IAs, along with the addresses associated with those IAs,
in its Confirm message. Any responding servers will indicate whether
those addresses are appropriate to the link to which the client is
attached with the status in the Reply message it returns to the
client.
The client sets the "msg-type" field to CONFIRM. The client generates The client sets the "msg-type" field to CONFIRM. The client generates
a transaction ID and inserts this value in the "transaction-ID" a transaction ID and inserts this value in the "transaction-id"
field. field.
The client MUST include a Client Identifier option to identify itself The client MUST include a Client Identifier option to identify itself
to the server. The client adds any appropriate options, including to the server. The client includes IA options for all of the IAs
one or more IA options. The client MUST include the addresses the currently in use by the client. The IA options include all of the
client currently has associated with those IAs. The client fills in addresses the client currently has associated with those IAs. The
the T1 and T2 fields in the IA options and the preferred-lifetime and client SHOULD set the T1 and T2 fields in the IA options and the
valid-lifetime fields in the IA Address options with preferred values preferred-lifetime and valid-lifetime fields in the IA Address
or 0 if the client has no preference about those values. options to 0, and the server will ignore these fields.
The client MAY request specific options from the server by including
an Option Request option (see section 22.7) as a hint about the
options the client is interested in receiving. If the client
requires a consistent prioritization of the options it receives, it
includes an Option Request option indicating the options it needs
(see section 18.2.2). The client MAY include options with data
values as hints to the server about parameter values the client would
like to have returned.
When the client sends the Confirm message, it MUST use an IPv6
address that the client has confirmed to be valid on the link to
which it is currently attached and that is assigned to the interface
for which the client is interested in obtaining configuration
information as the source address in the IP header of the datagram
carrying the Confirm message.
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT CNF_TIMEOUT IRT CNF_TIMEOUT
MRT CNF_MAX_RT MRT CNF_MAX_RT
MRC 0 MRC 0
MRD CNF_MAX_RD MRD CNF_MAX_RD
If the client receives no responses before the message transmission If the client receives no responses before the message transmission
process as described in section 14 terminates, the client SHOULD process as described in section 14 terminates, the client SHOULD
continue to use any IP addresses, using the last known lifetimes for continue to use any IP addresses, using the last known lifetimes for
those addresses, and SHOULD continue to use any other previously those addresses, and SHOULD continue to use any other previously
skipping to change at page 33, line 44 skipping to change at page 34, line 18
MRD CNF_MAX_RD MRD CNF_MAX_RD
If the client receives no responses before the message transmission If the client receives no responses before the message transmission
process as described in section 14 terminates, the client SHOULD process as described in section 14 terminates, the client SHOULD
continue to use any IP addresses, using the last known lifetimes for continue to use any IP addresses, using the last known lifetimes for
those addresses, and SHOULD continue to use any other previously those addresses, and SHOULD continue to use any other previously
obtained configuration parameters. obtained configuration parameters.
18.1.3. Creation and transmission of Renew messages 18.1.3. Creation and transmission of Renew messages
To extend the valid and preferred lifetimes associated with To extend the valid and preferred lifetimes for the addresses
addresses, the client sends a Renew message to the server containing associated with an IA, the client sends a Renew message to the server
an IA option for the IA and its associated addresses. The server from which the client obtained the addresses in the IA containing
an IA option for the IA. The client includes IA Address options in
the IA option for the addresses associated with the IA. The server
determines new lifetimes for the addresses in the IA according to the determines new lifetimes for the addresses in the IA according to the
administrative configuration of the server. The server may also add administrative configuration of the server. The server may also add
new addresses to the IA. The server may remove addresses from the IA new addresses to the IA. The server may remove addresses from the IA
by setting the preferred and valid lifetimes of those addresses to by setting the preferred and valid lifetimes of those addresses to
zero. zero.
The server controls the time at which the client contacts the server The server controls the time at which the client contacts the server
to extend the lifetimes on assigned addresses through the T1 and T2 to extend the lifetimes on assigned addresses through the T1 and T2
parameters assigned to an IA. parameters assigned to an IA.
If T1 or T2 is set to 0 by the server, the client does not send a If T1 or T2 is set to 0 by the server, the client does not send a
Renew or Rebind message, respectively, for the IA. Renew or Rebind message, respectively, for the IA.
At time T1 for an IA, the client initiates a Renew/Reply message At time T1 for an IA, the client initiates a Renew/Reply message
exchange to extend the lifetimes on any addresses in the IA. The exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned to client includes an IA option with all addresses currently assigned to
the IA in its Renew message. the IA in its Renew message.
The client sets the "msg-type" field to RENEW. The client generates a The client sets the "msg-type" field to RENEW. The client generates a
transaction ID and inserts this value in the "transaction-ID" field. transaction ID and inserts this value in the "transaction-id" field.
The client places the identifier of the destination server in a The client places the identifier of the destination server in a
Server Identifier option. Server Identifier option.
The client MUST include a Client Identifier option to identify The client MUST include a Client Identifier option to identify
itself to the server. The client adds any appropriate options, itself to the server. The client adds any appropriate options,
including one or more IA options. The client MUST include the list including one or more IA options. The client MUST include the list
of addresses the client currently has associated with the IAs in the of addresses the client currently has associated with the IAs in the
Renew message. Renew message.
The client MAY request specific options from the server by including The client MUST include an Option Request option (see section 22.7)
an Option Request option (see section 22.7) as a hint about the to indicate the options the client is interested in receiving. The
options the client is interested in receiving. If the client client MAY include options with data values as hints to the server
requires a consistent prioritization of the options it receives, it about parameter values the client would like to have returned.
includes an Option Request option indicating the options it needs
(see section 18.2.3). The client MAY include options with data
values as hints to the server about parameter values the client would
like to have returned.
If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received a
Server Unicast option (see section 22.13) from the server, the client
SHOULD unicast the Renew message to the server.
DISCUSSION:
Use of multicast on a link and relay agents enables the
inclusion of relay agent options in all messages sent by
the client. The server MUST NOT enable the use of unicast
for a client when relay agent options are required for that
client.
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT REN_TIMEOUT IRT REN_TIMEOUT
MRT REP_MAX_RT MRT REN_MAX_RT
MRC 0 MRC 0
MRD Remaining time until T2 MRD Remaining time until T2
The message exchange is terminated when time T2 is reached (see The message exchange is terminated when time T2 is reached (see
section 18.1.4), at which time the client begins a Rebind message section 18.1.4), at which time the client begins a Rebind message
exchange. exchange.
18.1.4. Creation and transmission of Rebind messages 18.1.4. Creation and transmission of Rebind messages
At time T2 for an IA (which will only be reached if the server to At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded), which the Renew message was sent at time T1 has not responded),
the client initiates a Rebind/Reply message exchange with any the client initiates a Rebind/Reply message exchange with any
available server. The client sends the Rebind message to the available server. The client sends the Rebind message to the
skipping to change at page 35, line 19 skipping to change at page 35, line 33
At time T2 for an IA (which will only be reached if the server to At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded), which the Renew message was sent at time T1 has not responded),
the client initiates a Rebind/Reply message exchange with any the client initiates a Rebind/Reply message exchange with any
available server. The client sends the Rebind message to the available server. The client sends the Rebind message to the
All_DHCP_Relay_Agents_and_Servers multicast address. The client All_DHCP_Relay_Agents_and_Servers multicast address. The client
includes an IA option with all addresses currently assigned to the IA includes an IA option with all addresses currently assigned to the IA
in its Rebind message. in its Rebind message.
The client sets the "msg-type" field to REBIND. The client generates The client sets the "msg-type" field to REBIND. The client generates
a transaction ID and inserts this value in the "transaction-ID" a transaction ID and inserts this value in the "transaction-id"
field. field.
The client MUST include a Client Identifier option to identify The client MUST include a Client Identifier option to identify
itself to the server. The client adds any appropriate options, itself to the server. The client adds any appropriate options,
including one or more IA options. The client MUST include the list including one or more IA options. The client MUST include the list
of addresses the client currently has associated with the IAs in the of addresses the client currently has associated with the IAs in the
Rebind message. Rebind message.
The client MAY request specific options from the server by including The client MUST include an Option Request option (see section 22.7)
an Option Request option (see section 22.7) as a hint about the to indicate the options the client is interested in receiving. The
options the client is interested in receiving. If the client client MAY include options with data values as hints to the server
requires a consistent prioritization of the options it receives, it about parameter values the client would like to have returned.
includes an Option Request option indicating the options it needs
(see section 18.2.4). The client MAY include options with data
values as hints to the server about parameter values the client would
like to have returned.
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT REB_TIMEOUT IRT REB_TIMEOUT
MRT REB_MAX_RT MRT REB_MAX_RT
MRC 0 MRC 0
MRD Remaining time until valid lifetimes of all addresses have MRD Remaining time until valid lifetimes of all addresses have
expired expired
The mechanism in section 14 is modified as follows for use in the The mechanism in section 14 is modified as follows for use in the
transmission of Rebind messages. The message exchange is terminated transmission of Rebind messages. The message exchange is terminated
when the valid lifetimes of all of the addresses assigned to the when the valid lifetimes of all of the addresses assigned to the
IA expire (see section 10), at which time the client has several IA expire (see section 10), at which time the client has several
alternative actions to choose from: alternative actions to choose from:
- The client may choose to use a Solicit message to locate a new - The client may choose to use a Solicit message to locate a new
skipping to change at page 36, line 20 skipping to change at page 36, line 28
may choose to discard the expired IA and use the addresses in the may choose to discard the expired IA and use the addresses in the
other IAs other IAs
18.1.5. Creation and Transmission of Information-request messages 18.1.5. Creation and Transmission of Information-request messages
The client uses an Information-request message to obtain The client uses an Information-request message to obtain
configuration information without having addresses assigned to it. configuration information without having addresses assigned to it.
The client sets the "msg-type" field to INFORMATION-REQUEST. The The client sets the "msg-type" field to INFORMATION-REQUEST. The
client generates a transaction ID and inserts this value in the client generates a transaction ID and inserts this value in the
"transaction-ID" field. "transaction-id" field.
The client SHOULD include a Client Identifier option to identify The client SHOULD include a Client Identifier option to identify
itself to the server. If the client does not include a Client itself to the server. If the client does not include a Client
Identifier option, the server will not be able to return any Identifier option, the server will not be able to return any
client-specific options to the client, or the server may choose not client-specific options to the client, or the server may choose not
to respond to the message at all. to respond to the message at all.
The client MAY request specific options from the server by including The client MUST include an Option Request option (see section 22.7)
an Option Request option (see section 22.7) as a hint about the to indicate the options the client is interested in receiving. The
options the client is interested in receiving. If the client client MAY include options with data values as hints to the server
requires a consistent prioritization of the options it receives, it about parameter values the client would like to have returned.
includes an Option Request option indicating the options it needs
(see section 18.2.5). The client MAY include options with data
values as hints to the server about parameter values the client would
like to have returned.
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT INF_TIMEOUT IRT INF_TIMEOUT
MRT INF_MAX_RT MRT INF_MAX_RT
MRC 0 MRC 0
MRD 0 MRD 0
18.1.6. Receipt of Reply message in response to a Request, Confirm, 18.1.6. Creation and transmission of Release messages
Renew, Rebind or Information-request message
Upon the receipt of a valid Reply message in response to a Request,
Confirm, Renew, Rebind or Information-request message, the client
extracts the configuration information contained in the Reply. The
client MAY choose to report any status code or message from the
status code option in the Reply message.
The client SHOULD perform duplicate address detection [18] on each
of the addresses in any IAs it receives in the Reply message before
using that address for traffic. If any of the addresses are found
to be in use on the link, the client sends a Decline message to the
server as described in section 18.1.9.
The client records the T1 and T2 times for each IA in the Reply
message. The client records any addresses included with IAs in
the Reply message. The client updates the preferred and valid
lifetimes for the addresses in the IA from the lifetime information
in the IA option. The client leaves any addresses that the client
has associated with the IA that are not included in the IA option
unchanged.
If the Reply was received in response to a Request, Renew or Rebind
message, the client must update the information in any IA option
contained in the Reply message. The client adds any new addresses
from the IA option to the IA, updates lifetimes for existing
addresses in the IA from the IA option and discards any addresses
with a lifetime of zero in the IA option.
Management of the specific configuration information is detailed in
the definition of each option, in section 22.
When the client receives a NotOnLink status in an IA from the server
in response to a Confirm message, the client can assume it needs to
send a Request to the server to obtain appropriate addresses for the
IA. If the client receives any Reply messages that do not indicate
a NotOnLink status, the client can use the addresses in the IA and
ignore any messages that do indicate a NotOnLink status.
When the client receives a NoBinding 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 with the server.
When the client receives a NoBinding 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 with the server or try another server.
When the client receives an AddrUnavail 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 with the server or try another server.
18.1.7. Creation and transmission of Release messages
To release one or more addresses, a client sends a Release message to To release one or more addresses, a client sends a Release message to
the server. the server.
The client sets the "msg-type" field to RELEASE. The client generates The client sets the "msg-type" field to RELEASE. The client generates
a transaction ID and places this value in the "transaction-ID" field. a transaction ID and places this value in the "transaction-id" field.
The client places the identifier of the server that allocated the The client places the identifier of the server that allocated the
address(es) in a Server Identifier option. address(es) in a Server Identifier option.
The client MUST include a Client Identifier option to identify itself The client MUST include a Client Identifier option to identify itself
to the server. The client includes options containing the IAs for to the server. The client includes options containing the IAs for
the addresses it is releasing in the "options" field. The addresses the addresses it is releasing in the "options" field. The addresses
to be released MUST be included in the IAs. Any addresses for the to be released MUST be included in the IAs. Any addresses for the
IAs the client wishes to continue to use should not be in added to IAs the client wishes to continue to use MUST NOT be in added to the
the IAs. IAs.
The client MUST NOT use any of the addresses if is releasing as The client MUST NOT use any of the addresses it is releasing as
the source address in the Release message or in any subsequently the source address in the Release message or in any subsequently
transmitted message. transmitted message.
If the client has a source address of sufficient scope that can be Because Release messages may be lost, the client should retransmit
used by the server as a return address and the client has received the Release if no Reply is received. However, there are scenarios
a Server Unicast option (section 22.13) from the server, the client where the client may not wish to wait for the normal retransmission
SHOULD unicast the Release message to the server. timeout before giving up (e.g., on power down). Implementations
SHOULD retransmit one or more times, but MAY choose to terminate the
DISCUSSION: retransmission procedure early.
Use of multicast on a link and relay agents enables the
inclusion of relay agent options in all messages sent by
the client. The server MUST NOT enable the use of unicast
for a client when relay agent options are required for that
client.
The client SHOULD choose to guarantee the delivery of the Release
message using the retransmission strategy in section 14. An example
of a situation in which a client would not guarantee delivery would
be when the client is powering down or restarting because of some
error condition.
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT REL_TIMEOUT IRT REL_TIMEOUT
MRT 0 MRT 0
MRC REL_MAX_MRC MRC REL_MAX_MRC
MRD 0 MRD 0
The client MUST abandon the attempt to release addresses if the
Release message exchange fails.
The client MUST stop using all of the addresses being released as The client MUST stop using all of the addresses being released as
soon as the client begins the Release message exchange process. If soon as the client begins the Release message exchange process. If
addresses are released but the Reply from a DHCP server is lost, addresses are released but the Reply from a DHCP server is lost,
the client will retransmit the Release message, and the server may the client will retransmit the Release message, and the server may
respond with a Reply indicating a status of NoBinding. Therefore, respond with a Reply indicating a status of NoBinding. Therefore,
the client does not treat a Reply message with a status of NoBinding the client does not treat a Reply message with a status of NoBinding
in a Release message exchange as if it indicates an error. in a Release message exchange as if it indicates an error.
Note that if the client fails to release the addresses, the addresses Note that if the client fails to release the addresses, the addresses
assigned to the IA will be reclaimed by the server when the lifetime assigned to the IA will be reclaimed by the server when the valid
of the address expires. lifetime of the address expires.
18.1.8. Receipt of Reply message in response to a Release message
Upon receipt of a valid Reply message, the client can consider the 18.1.7. Creation and transmission of Decline messages
Release event successful.
18.1.9. Creation and transmission of Decline messages If a client detects that one or more addresses assigned to it by a
server are already in use by another node, the client sends a Decline
message to the server to inform it that the address is suspect.
The client sets the "msg-type" field to DECLINE. The client generates The client sets the "msg-type" field to DECLINE. The client generates
a transaction ID and places this value in the "transaction-ID" field. a transaction ID and places this value in the "transaction-id" field.
The client places the identifier of the server that allocated the The client places the identifier of the server that allocated the
address(es) in a Server Identifier option. address(es) in a Server Identifier option.
The client MUST include a Client Identifier option to identify itself The client MUST include a Client Identifier option to identify itself
to the server. The client includes options containing the IAs for to the server. The client includes options containing the IAs for
the addresses it is declining in the "options" field. The addresses the addresses it is declining in the "options" field. The addresses
to be declined MUST be included in the IAs. Any addresses for the to be declined MUST be included in the IAs. Any addresses for the
IAs the client wishes to continue to use should not be in added to IAs the client wishes to continue to use should not be in added to
the IAs. the IAs.
The client MUST NOT use any of the addresses it is declining as The client MUST NOT use any of the addresses it is declining as
the source address in the Decline message or in any subsequently the source address in the Decline message or in any subsequently
transmitted message. transmitted message.
If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received
a Server Unicast option (section 22.13) from the server, the client
SHOULD unicast the Decline message to the server.
DISCUSSION:
Use of multicast on a link and relay agents enables the
inclusion of relay agent options in all messages sent by
the client. The server MUST NOT enable the use of unicast
for a client when relay agent options are required for that
client.
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT DEC_TIMEOUT IRT DEC_TIMEOUT
MRT DEC_MAX_RT MRT DEC_MAX_RT
MRC DEC_MAX_RC MRC DEC_MAX_RC
MRD 0 MRD 0
The client MUST abandon the attempt to decline addresses if the
Decline message exchange fails.
If addresses are released but the Reply from a DHCP server is lost, If addresses are released but the Reply from a DHCP server is lost,
the client will retransmit the Decline message, and the server may the client will retransmit the Decline message, and the server may
respond with a Reply indicating a status of NoBinding. Therefore, respond with a Reply indicating a status of NoBinding. Therefore,
the client does not treat a Reply message with a status of NoBinding the client does not treat a Reply message with a status of NoBinding
in a Decline message exchange as if it indicates an error. in a Decline message exchange as if it indicates an error.
18.1.10. Receipt of Reply message in response to a Decline message 18.1.8. Receipt of Reply messages
Upon receipt of a valid Reply message, the client can consider the Upon the receipt of a valid Reply message in response to a Request,
Decline event successful. Confirm, Renew, Rebind or Information-request message, the client
extracts the configuration information contained in the Reply. The
client MAY choose to report any status code or message from the
status code option in the Reply message.
The client SHOULD perform duplicate address detection [20] on each
of the addresses in any IAs it receives in the Reply message before
using that address for traffic. If any of the addresses are found
to be in use on the link, the client sends a Decline message to the
server as described in section 18.1.7.
The client records the T1 and T2 times for each IA in the Reply
message. The client records any addresses included with IAs in the
Reply message. The client updates the preferred and valid lifetimes
for the addresses in the IA from the lifetime information in the
IA option, and discards any addresses with valid lifetime set to 0
in the IA option. The client leaves any addresses that the client
has associated with the IA that are not included in the IA option
unchanged.
If the Reply was received in response to a Request, Renew or Rebind
message, the client must update the information it has recorded about
IAs from the IA options contained in the Reply message:
- Add any new addresses in the IA option to the IA as recorded by
the client
- Update lifetimes for any addresses in the IA option that the
client already has recorded in the IA
- Discard any addresses from the IA as recorded by the client that
have a lifetime of 0 in the IA Address option
Management of the specific configuration information is detailed in
the definition of each option, in section 22.
When the client receives a Reply message with a Status Code option
with value UseMulticast, the client records the receipt of the
message and sends subsequent messages to the server through the
interface on which the message was received using multicast. The
client resends the original message using multicast.
When the client receives a NotOnLink status from the server in
response to a Confirm message, the client performs DHCP server
solicitation as described in section 17 and client-initiated
configuration as described in section 18. If the client receives any
Reply messages that do not indicate a NotOnLink status, the client
can use the addresses in the IA and ignore any messages that do
indicate a NotOnLink status.
When the client receives a status code with value NoBinding in an IA
from the server in response to a Renew message or a Rebind message,
the client sends a Request to reestablish an IA with the server.
When the client receives a valid Reply message in response to a
Release message, the client considers the Release event completed,
regardless of the Status Code option(s) returned by the server.
When the client receives a valid Reply message in response to a
Decline message, the client considers the Decline event completed,
regardless of the Status Code option(s) returned by the server.
18.2. Server Behavior 18.2. 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 with configuration of interest to an implementation specific manner with configuration of interest to
clients. clients.
In most instances, the server will send a Reply in response to a
client message. This Reply message MUST always contain the Server
Identifier option containing the server's DUID and the Client
Identifier option from the client message if one was present.
18.2.1. Receipt of Request messages 18.2.1. Receipt of Request messages
When the server receives a Request message via unicast from a When the server receives a Request message via unicast from a
client to which the server has not sent a unicast option, the server client to which the server has not sent a unicast option, the server
discards the Request message and responds with a Reply message discards the Request message and responds with a Reply message
containing a status code option with value UseMulticast and no other containing a Status Code option with value UseMulticast, a Server
options. Identifier option containing the server's DUID, the Client Identifier
option from the client message and no other options.
When the server receives a Request the client is requesting the When the server receives a valid Request message, the server creates
configuration of IAs by the server. The server creates the bindings the bindings for that client according to the server's policy and
for that client according to the server's policy and configuration configuration information and records the IAs and other information
information and records the IAs and other information about the requested by the client.
client.
The server constructs a Reply message by setting the "msg-type" field The server constructs a Reply message by setting the "msg-type" field
to REPLY, copying the transaction ID from the Request message into to REPLY, copying the transaction ID from the Request message into
the transaction-ID field. the transaction-id field.
The server MUST include a Server Identifier option containing the The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Request server's DUID and the Client Identifier option from the Request
message in the Reply message. message in the Reply message.
If the server finds that the prefix on one or more IP addresses in If the server finds that the prefix on one or more IP addresses in
any IA in the message from the client is not a valid prefix for the any IA in the message from the client is not appropriate to the link
link to which the client is connected, the server MUST return the IA to which the client is connected, the server MUST return the IA to
to the client with the status field set to NotOnLink. the client with a Status Code option with value NotOnLink.
If the server cannot assign any addresses to any of the IAs in the If the server cannot assign any addresses to any of the IAs in the
message from the client, the server MUST include the IAs in the Reply message from the client, the server MUST include the IAs in the Reply
message with the status field set to AddrUnavail and no addresses in message with Status Code option set to NoAddrsAvail and no addresses
the IA. in the IA.
For any IAs to which the server can assign addresses, the server For any IAs to which the server can assign addresses, the server
includes the IA with addresses and other configuration parameters and includes the IA with addresses and other configuration parameters and
records the IA as a new client binding. records the IA as a new client binding.
If the server will use a reconfigure nonce value for security of If the server will use a reconfigure nonce value for security of
Reconfigure messages, the server generates a new nonce value for the Reconfigure messages, the server generates a new nonce value for the
client, records the value and includes it in a Reconfigure Nonce client, records the value and includes it in a Reconfigure Nonce
option (see section 22.21) in the Reply message. option (see section 22.20) in the Reply message.
The server includes other options containing configuration The server includes other options containing configuration
information to be returned to the client. The server SHOULD limit information to be returned to the client. The server SHOULD limit
the options returned to the client so that the DHCP message header the options returned to the client so that the DHCP message header
and options do not cause fragmentation. If the client has included and options do not cause fragmentation. If the client has included
an Option Request option in the Solicit message, the server uses that an Option Request option in the Solicit message, the server includes
option as a hint about the options the client has a preference for options in the Advertise message containing configuration parameters
receiving from the server. for all of the options identified in the Option Request option that
the server has been configured to return to the client. The server
MAY return additional options to the client if it has been configured
to do so.
18.2.2. Receipt of Confirm messages 18.2.2. Receipt of Confirm messages
When the server receives a Confirm message, the client is requesting When the server receives a Confirm message, the server determines
confirmation that the IP addresses it will use is valid and if the addresses in the Confirm message are appropriate to the
requesting the most current configuration information for the client. link to which the client is attached. The server ignores the T1
The server compares the addresses in the IA Address options in the and T2 fields in the IA options and the preferred-lifetime and
Confirm message from the client with the addresses in the binding for valid-lifetime fields in the IA Address options.
the client.
If the server finds that the addresses in the Confirm message do not
match what is in the binding for that client or the addresses in
the Confirm message are not appropriate for the link from which the
client sent the Confirm message, the server sends a Reply message
containing a Status Code option with the value ConfNoMatch.
If the server finds that the addresses in the Confirm message match If all of the addresses in the Confirm message pass this test, the
the addresses in the binding for that client, and the configuration server returns a status of Success. If any of the addresses do not
information is still valid, the server sends a Reply message pass this test, the server returns a status of NotOnLink.
containing a Status Code option with the value Success.
If the server cannot determine if the information in the Confirm If the server does not find any addresses that are not appropriate to
message is valid or invalid, the server MUST NOT send a reply to the the link to which the client is connected, but cannot determine if
client. For example, if the server does not have a binding for the some of the addresses are appropriate to the link or not appropriate
client, but the configuration information in the Confirm message to the link, the server MUST NOT send a reply to the client. For
appears valid, the server does not reply. example, if the server does not have information about prefixes on
the link to which the client is connected, the server does not reply.
The server constructs a Reply message by setting the "msg-type" field The server constructs a Reply message by setting the "msg-type" field
to REPLY, copying the transaction ID from the Confirm message into to REPLY, copying the transaction ID from the Confirm message into
the transaction-ID field. the transaction-id field.
The server MUST include a Server Identifier option containing the The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Confirm server's DUID and the Client Identifier option from the Confirm
message in the Reply message. message in the Reply message. The server includes a Status Code
option indicating the status of the Confirm message.
The server includes IA options for each of the IA options in the
Confirm message. The server chooses values for T1, T2 and lifetimes
for each of the addresses in the IAs according to the server's
configured policies. The values for T1, T2 and the lifetimes sent by
the client are the client's preferences for those values. The server
also includes options for any other configuration information to be
sent to the client.
The server includes other options containing configuration
information to be returned to the client. The server SHOULD limit
the options returned to the client so that the DHCP message header
and options do not cause fragmentation. If the client has included
an Option Request option in the Renew message, the server uses that
option as a hint about the options the client has a preference for
receiving from the server.
The Reply message from the server MUST include a Status Code option.
18.2.3. Receipt of Renew messages 18.2.3. Receipt of Renew messages
When the server receives a Renew message via unicast from a client to When the server receives a Renew message via unicast from a client to
which the server has not sent a unicast option, the server discards which the server has not sent a unicast option, the server discards
the Renew message and responds with a Reply message containing a the Renew message and responds with a Reply message containing a
status code option with value UseMulticast and no other options. Status Code option with value UseMulticast, a Server Identifier
option containing the server's DUID, the Client Identifier option
from the client message and no other options.
When the server receives a Renew and IA option from a client it When the server receives a Renew message that contains an IA option
locates the client's binding and verifies that the information in the from a client, it locates the client's binding and verifies that the
IA from the client matches the information stored for that client. information in the IA from the client matches the information stored
for that client.
If the server cannot find a client entry for the IA the server If the server cannot find a client entry for the IA the server
returns the IA containing no addresses with status set to NoBinding returns the IA containing no addresses with a Status Code option set
in the Renew message. to NoBinding in the Reply message.
If the server finds that any of the addresses are no longer valid If the server finds that any of the addresses are not appropriate
for the client, the server returns the address to the client with to the link to which the client is attached, the server returns the
lifetimes of 0. address to the client with lifetimes of 0.
If the server finds the addresses in the IA for the client then the If the server finds the addresses in the IA for the client then the
server sends back the IA to the client with new lifetimes and T1/T2 server sends back the IA to the client with new lifetimes and T1/T2
times, and includes a Status Code option with value Success. The times, and includes a Status Code option with value Success. The
server may choose to change the list of addresses and the lifetimes server may choose to change the list of addresses and the lifetimes
of addresses in IAs that are returned to the client. of addresses in IAs that are returned to the client.
The server constructs a Reply message by setting the "msg-type" field The server constructs a Reply message by setting the "msg-type" field
to REPLY, copying the transaction ID from the Renew message into the to REPLY, copying the transaction ID from the Renew message into the
transaction-ID field. transaction-id field.
The server MUST include a Server Identifier option containing the The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Renew message server's DUID and the Client Identifier option from the Renew message
in the Reply message. in the Reply message.
18.2.4. Receipt of Rebind messages 18.2.4. Receipt of Rebind messages
When the server receives a Rebind and IA option from a client it When the server receives a Rebind message that contains an IA option
locates the client's binding and verifies that the information in the from a client, it locates the client's binding and verifies that the
IA from the client matches the information stored for that client. information in the IA from the client matches the information stored
for that client.
If the server cannot find a client entry for the IA the server If the server cannot find a client entry for the IA the server
returns the IA containing no addresses with status set to NoBinding returns the IA containing no addresses with a Status Code option set
in the Rebind message. to NoBinding in the Reply message.
If the server finds that the any of the addresses are no longer valid If the server finds that the any of the addresses are no longer
for the client, the server returns the address to the client with appropriate to the link to which the client is attache, the server
lifetimes of 0. returns the address to the client with lifetimes of 0.
If the server finds the addresses in the IA for the client then the 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 lifetimes and server SHOULD send back the IA to the client with new lifetimes and
T1/T2 times. T1/T2 times.
The server constructs a Reply message by setting the "msg-type" field The server constructs a Reply message by setting the "msg-type" field
to REPLY, copying the transaction ID from the Rebind message into the to REPLY, copying the transaction ID from the Rebind message into the
transaction-ID field. transaction-id field.
The server MUST include a Server Identifier option containing the The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Rebind server's DUID and the Client Identifier option from the Rebind
message in the Reply message. message in the Reply message.
The server includes other options containing configuration The server includes other options containing configuration
information to be returned to the client. The server SHOULD limit information to be returned to the client. The server SHOULD limit
the options returned to the client so that the DHCP message header the options returned to the client so that the DHCP message header
and options do not cause fragmentation. If the client has included and options do not cause fragmentation. If the client has included
an Option Request option in the Rebind message, the server uses that an Option Request option in the Solicit message, the server includes
option as a hint about the options the client has a preference for options in the Advertise message containing configuration parameters
receiving from the server. for all of the options identified in the Option Request option that
the server has been configured to return to the client . The server
MAY return additional options to the client if it has been configured
to do so.
18.2.5. Receipt of Information-request messages 18.2.5. Receipt of Information-request messages
When the server receives an Information-request message, the When the server receives an Information-request message, the
client is requesting configuration information that does not client is requesting configuration information that does not
include the assignment of any addresses. The server determines all include the assignment of any addresses. The server determines all
configuration parameters appropriate to the client, based on the configuration parameters appropriate to the client, based on the
server configuration policies known to the server. server configuration policies known to the server.
If the Information-request message specifies an IA option or an IA_TA
option, the server responds by sending a Reply message containing
a Server Identifier option, a Client Identifier option if one was
included in the Information-request message and a Status Code option
with status UnSpecFail.
The server constructs a Reply message by setting the "msg-type" field The server constructs a Reply message by setting the "msg-type" field
to REPLY, copying the transaction ID from the Information-request to REPLY, copying the transaction ID from the Information-request
message into the transaction-ID field. message into the transaction-id field.
The server MUST include a Server Identifier option containing the The server MUST include a Server Identifier option containing the
server's DUID in the Reply message. If the client included a Client server's DUID in the Reply message. If the client included a Client
Identification option in the Information-request message, the server Identification option in the Information-request message, the server
copies that option to the Reply message. copies that option to the Reply message.
The server includes options containing configuration information The server includes options containing configuration information
to be returned to the client. The server SHOULD limit the options to be returned to the client. The server SHOULD limit the options
returned to the client so that the DHCP message header and options returned to the client so that the DHCP message header and options
do not cause fragmentation. If the client has included an Option do not cause fragmentation. If the client has included an Option
Request option in the Information-request message, the server uses Request option in the Solicit message, the server includes options in
that option as a hint about the options the client has a preference the Advertise message containing configuration parameters for all of
for receiving from the server. the options identified in the Option Request option that the server
has been configured to return to the client . The server MAY return
additional options to the client if it has been configured to do so.
If the Information-request message received from the client did If the Information-request message received from the client did
not include a Client Identifier option, the server SHOULD respond not include a Client Identifier option, the server SHOULD respond
with a Reply message containing any configuration parameters with a Reply message containing any configuration parameters
that are not determined by the client's identity. If the server that are not determined by the client's identity. If the server
chooses not to respond, the client may continue to retransmit the chooses not to respond, the client may continue to retransmit the
Information-request message indefinitely. Information-request message indefinitely.
18.2.6. Receipt of Release messages 18.2.6. Receipt of Release messages
When the server receives a Release message via unicast from a When the server receives a Release message via unicast from a
client to which the server has not sent a unicast option, the server client to which the server has not sent a unicast option, the server
discards the Release message and responds with a Reply message discards the Release message and responds with a Reply message
containing a status code option with value UseMulticast and no other containing a Status Code option with value UseMulticast, a Server
options. Identifier option containing the server's DUID, the Client Identifier
option from the client message and no other options.
Upon the receipt of a valid Release message, the server examines 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 message are in a binding for the client and the addresses in
the IAs have been assigned by the server to those IAs, the server the IAs have been assigned by the server to those IAs, the server
deletes the addresses from the IAs and makes the addresses available deletes the addresses from the IAs and makes the addresses available
for assignment to other clients. The server ignores addresses not for assignment to other clients. The server ignores addresses not
assigned to the IA (though it may choose to log an error if it finds assigned to the IA, and it may make a notification if it finds such
such an address). an address.
After all the addresses have been processed, the server generates a After all the addresses have been processed, the server generates a
Reply message and includes a Status Code option with value Success, Reply message and includes a Status Code option with value Success,
a Server Identifier option with the server's DUID and a Client a Server Identifier option with the server's DUID and a Client
Identifier option with the client's DUID. For each IA in the Release Identifier option with the client's DUID. For each IA in the Release
message for which the server has no binding information, the server message for which the server has no binding information, the server
adds an IA option using the IAID from the Release message and adds an IA option using the IAID from the Release message and
includes a Status Code option with the value NoBinding in the IA includes a Status Code option with the value NoBinding in the IA
option. No other options are included in the IA option. option. No other options are included in the IA option.
A server may choose to retain a record of assigned addresses and IAs A server may choose to retain a record of assigned addresses and IAs
after the lifetimes on the addresses have expired to allow the server after the lifetimes on the addresses have expired to allow the server
to reassign the previously assigned addresses to a client. to reassign the previously assigned addresses to a client.
18.2.7. Receipt of Decline messages 18.2.7. Receipt of Decline messages
When the server receives a Decline message via unicast from a When the server receives a Decline message via unicast from a
client to which the server has not sent a unicast option, the server client to which the server has not sent a unicast option, the server
discards the Decline message and responds with a Reply message discards the Decline message and responds with a Reply message
containing a status code option with value UseMulticast and no other containing a Status Code option with value UseMulticast, a Server
options. Identifier option containing the server's DUID, the Client Identifier
option from the client message and no other options.
Upon the receipt of a valid Decline message, the server examines the Upon the receipt of a valid Decline 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. The server SHOULD mark the addresses the addresses from the IAs. The server SHOULD mark the addresses
declined by the client so that those addresses are not assigned to declined by the client so that those addresses are not assigned to
other clients, and MAY choose to make a notification that addresses other clients, and MAY choose to make a notification that addresses
were declined. The server ignores addresses not assigned to the IA were declined. The server ignores addresses not assigned to the IA
(though it may choose to log an error if it finds such an address). (though it may choose to log an error if it finds such an address).
After all the address have been processed, the server generates a After all the address have been processed, the server generates a
Reply message and includes a Status Code option with value Success, Reply message and includes a Status Code option with value Success,
a Server Identifier option with the server's DUID and a Client a Server Identifier option with the server's DUID and a Client
Identifier option with the client's DUID. For each IA in the Release Identifier option with the client's DUID. For each IA in the Decline
message for which the server has no binding information, the server message for which the server has no binding information, the server
adds an IA option using the IAID from the Release message and adds an IA option using the IAID from the Release message and
includes a Status Code option with the value NoBinding in the IA includes a Status Code option with the value NoBinding in the IA
option. No other options are included in the IA option. option. No other options are included in the IA option.
18.2.8. Transmission of Reply messages 18.2.8. Transmission of Reply messages
If the original message was received directly by the server, the If the original message was received directly by the server, the
server unicasts the Reply message directly to the client using the server unicasts the Reply message directly to the client using the
address in the source address field from the IP datagram in which the address in the source address field from the IP datagram in which the
skipping to change at page 46, line 15 skipping to change at page 45, line 46
software. software.
19.1. Server Behavior 19.1. Server Behavior
A server sends a Reconfigure message to cause a client to initiate A server sends a Reconfigure message to cause a client to initiate
immediately a Renew/Reply or Information-request/Reply message immediately a Renew/Reply or Information-request/Reply message
exchange with the server. exchange with the server.
19.1.1. Creation and transmission of Reconfigure messages 19.1.1. Creation and transmission of Reconfigure messages
The server sets the "msg-type" field to RECONFIGURE. The server sets The server sets the "msg-type" field to RECONFIGURE. The server
the transaction-id field to 0. The server places its identifier in a sets the transaction-id field to 0. The server includes a Server
Server Identifier option. Identifier option containing its DUID and a Client Identifier option
containing the client's DUID in the Reconfigure message.
The server MAY include an Option Request option to inform the client The server MAY include an Option Request option to inform the client
of what information has been changed or new information that has been of what information has been changed or new information that has been
added. In particular, the server specifies the IA option in the added. In particular, the server specifies the IA option in the
Option Request option if the server wants the client to obtain new Option Request option if the server wants the client to obtain new
address information. address information.
Because of the risk of denial of service attacks against DHCP Because of the risk of denial of service attacks against DHCP
clients, the use of a security mechanism is mandated in Reconfigure clients, the use of a security mechanism is mandated in Reconfigure
messages.The server MUST use one of the following two security messages.The server MUST use one of the following two security
mechanisms: mechanisms:
- The server includes a Reconfigure Nonce option containing the - The server includes a Reconfigure Nonce option containing the
reconfiugre nonce value currently assigned to the client reconfigure nonce value currently assigned to the client
- The server includes an authentication option in the Reconfigure - The server includes an authentication option in the Reconfigure
message message
The server MUST include a Reconfigure Message option (defined in The server MUST include a Reconfigure Message option (defined in
section 22.20) to select whether the client responds with a Renew section 22.19) to select whether the client responds with a Renew
message or an Information-Request message. message or an Information-Request message.
The server MUST NOT include any other options in the Reconfigure The server MUST NOT include any other options in the Reconfigure
except as specifically allowed in the definition of individual except as specifically allowed in the definition of individual
options. options.
A server sends each Reconfigure message to a single DHCP client, A server sends each Reconfigure message to a single DHCP client,
using an IPv6 unicast address of sufficient scope belonging to the using an IPv6 unicast address of sufficient scope belonging to the
DHCP client. The server may obtain the address of the client through DHCP client. The server may obtain the address of the client through
the information that the server has about clients that have been in the information that the server has about clients that have been in
skipping to change at page 47, line 15 skipping to change at page 46, line 48
reconfiguration message exchanges are still in progress. reconfiguration message exchanges are still in progress.
The Reconfigure message causes the client to initiate a Renew/Reply The Reconfigure message causes the client to initiate a Renew/Reply
or Information-request/Reply message exchange with the server. The or Information-request/Reply message exchange with the server. The
server interprets the receipt of a Renew or Information-request server interprets the receipt of a Renew or Information-request
message (whichever was specified in the original Reconfigure message) message (whichever was specified in the original Reconfigure message)
from the client as satisfying the Reconfigure message request. from the client as satisfying the Reconfigure message request.
19.1.2. Time out and retransmission of Reconfigure messages 19.1.2. Time out and retransmission of Reconfigure messages
If the server does not receive a Renew or Information-request message If the server does not receive a Renew or Information-request
from the client in REC_TIMEOUT milliseconds, the server retransmits message from the client in REC_TIMEOUT milliseconds, the server
the Reconfigure message, doubles the RECREP_TIMEOUT value and retransmits the Reconfigure message, doubles the REC_TIMEOUT value
waits again. The server continues this process until REC_MAX_R and waits again. The server continues this process until REC_MAX_RC
unsuccessful attempts have been made, at which point the server unsuccessful attempts have been made, at which point the server
SHOULD abort the reconfigure process for that client. SHOULD abort the reconfigure process for that client.
Default and initial values for REC_TIMEOUT and REC_MAX_RT are Default and initial values for REC_TIMEOUT and REC_MAX_RC are
documented in section 5.5. documented in section 5.5.
19.1.3. Receipt of Renew messages 19.2. Receipt of Renew messages
The server generates and sends Reply message(s) to the client as The server generates and sends a Reply message to the client as
described in sections 18.2.3 and 18.2.8, including options for described in sections 18.2.3 and 18.2.8, including options for
configuration parameters. configuration parameters.
The server MAY choose to send a Reply with the IAs and other The server MAY include options containing the IAs and new values for
parameters to be reconfigured, even if those IAs and parameters were other configuration parameters in the Reply message, even if those
not requested in the Renew message from the client. IAs and parameters were not requested in the Renew message from the
client.
19.2. Receipt of Information-request messages 19.3. Receipt of Information-request messages
The server generates and sends Reply message(s) to the client as The server generates and sends a Reply message to the client as
described in sections 18.2.5 and 18.2.8, including options for described in sections 18.2.5 and 18.2.8, including options for
configuration parameters. configuration parameters.
The server MAY choose to send a Reply with the other parameters to The server MAY include options containing new values for other
be reconfigured, even if those parameters were not specified in the configuration parameters in the Reply message, even if those
Information-request message from the client. parameters were not requested in the Information-request message from
the client.
19.3. Client Behavior 19.4. Client Behavior
A client MUST accept Reconfigure messages sent to UDP port 546 on A client MUST accept Reconfigure messages sent to UDP port 546 on
interfaces for which it has acquired configuration information interfaces for which it has acquired configuration information
through DHCP. These messages may be sent at any time. Since the through DHCP. These messages may be sent at any time. Since the
results of a reconfiguration event may affect application layer results of a reconfiguration event may affect application layer
programs, the client SHOULD log these events, and MAY notify these programs, the client SHOULD log these events, and MAY notify these
programs of the change through an implementation-specific interface. programs of the change through an implementation-specific interface.
19.3.1. Receipt of Reconfigure messages 19.4.1. Receipt of Reconfigure messages
Upon receipt of a valid Reconfigure message, the client initiates a Upon receipt of a valid Reconfigure message, the client initiates a
transaction with the server by sending a Reply or Information-request transaction with the server by sending a Renew or Information-request
message. While the transaction is in progress, the client silently message. The client ignores the transaction-id field in the received
discards any Reconfigure messages it receives. Reconfigure message. While the transaction is in progress, the
client silently discards any Reconfigure messages it receives.
The client responds with either a Renew message or an The client responds with either a Renew message or an
Information-request message as indicated by the Reconfigure Information-request message as indicated by the Reconfigure
Message option (as defined in section 22.20). Message option (as defined in section 22.19).
DISCUSSION: DISCUSSION:
The Reconfigure message acts as a trigger that signals the The Reconfigure message acts as a trigger that signals the
client to complete a successful message exchange. Once client to complete a successful message exchange. Once
the client has received a Reconfigure, the client proceeds the client has received a Reconfigure, the client proceeds
with the message exchange (retransmitting the Renew or with the message exchange (retransmitting the Renew or
Information-request message if necessary); the client Information-request message if necessary); the client
ignores any additional Reconfigure messages (regardless ignores any additional Reconfigure messages until the
of the transaction ID in the Reconfigure message) until exchange is complete. Subsequent Reconfigure messages cause
the exchange is complete. Subsequent Reconfigure messages the client to initiate a new exchange.
(again independent of the transaction ID) cause the client
to initiate a new exchange.
How does this mechanism work in the face of duplicated or How does this mechanism work in the face of duplicated or
retransmitted Reconfigure messages? Duplicate messages retransmitted Reconfigure messages? Duplicate messages
will be ignored because the client will begin the exchange will be ignored because the client will begin the exchange
after the receipt of the first Reconfigure. Retransmitted after the receipt of the first Reconfigure. Retransmitted
messages will either trigger the exchange (if the first messages will either trigger the exchange (if the first
Reconfigure was not received by the client) or will be Reconfigure was not received by the client) or will be
ignored. The server can discontinue retransmission of ignored. The server can discontinue retransmission of
Reconfigure messages to the client once the server receives Reconfigure messages to the client once the server receives
the Renew or Information-request message from the client. the Renew or Information-request message from the client.
It might be possible for a duplicate or retransmitted It might be possible for a duplicate or retransmitted
Reconfigure to be sufficiently delayed (and delivered out of Reconfigure to be sufficiently delayed (and delivered out of
order) to arrive at the client after the exchange (initiated order) to arrive at the client after the exchange (initiated
by the original Reconfigure) has been completed. In this by the original Reconfigure) has been completed. In this
case, the client would initiate a redundant exchange. The case, the client would initiate a redundant exchange. The
likelihood of delayed and out of order delivery is small likelihood of delayed and out of order delivery is small
enough to be ignored. The consequence of the redundant enough to be ignored. The consequence of the redundant
exchange is inefficiency rather than incorrect operation. exchange is inefficiency rather than incorrect operation.
19.3.2. Creation and transmission of Renew messages 19.4.2. Creation and transmission of Renew messages
When responding to a Reconfigure, the client creates and sends When responding to a Reconfigure, the client creates and sends
the Renew message in exactly the same manner as outlined in the Renew message in exactly the same manner as outlined in
section 18.1.3, with the exception: if the server included on Option section 18.1.3, with the exception: if the Reconfigure message
Request option specifying the IA option, the client MUST include IA contains an Option Request option that includes the IA option code,
options containing the addresses the client currently has assigned to the client MUST include IA options containing the addresses the
ALL IAs for the interface through which the Reconfigure message was client currently has assigned to ALL IAs for the interface through
received. which the Reconfigure message was received.
19.3.3. Creation and transmission of Information-request messages 19.4.3. Creation and transmission of Information-request messages
When responding to a Reconfigure, the client creates and sends the When responding to a Reconfigure, the client creates and sends the
Information-request message in exactly the same manner as outlined in Information-request message in exactly the same manner as outlined in
section 18.1.5, with the exception that the client includes a Server section 18.1.5, with the exception that the client includes a Server
Identifier option with the identifier from the Reconfigure message to Identifier option with the identifier from the Reconfigure message to
which the client is responding. which the client is responding.
19.3.4. Time out and retransmission of Renew or Information-request 19.4.4. Time out and retransmission of Renew or Information-request
messages messages
The client uses the same variables and retransmission algorithm as The client uses the same variables and retransmission algorithm as
it does with Renew or Information-request messages generated as part it does with Renew or Information-request messages generated as part
of a client-initiated configuration exchange. See sections 18.1.3 of a client-initiated configuration exchange. See sections 18.1.3
and 18.1.5 for details. and 18.1.5 for details. If the client does not receive a response
from the server by the end of the retransmission process, the client
ignores and discards the Reconfigure message.
19.3.5. Receipt of Reply messages 19.4.5. 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 processes the
contents of the "options" field, and sets (or resets) configuration options and sets (or resets) configuration parameters appropriately.
parameters appropriately. The client records and updates the The client records and updates the lifetimes for any addresses
lifetimes for any addresses specified in IAs in the Reply message. specified in IAs in the Reply message.
20. Relay Agent Behavior 20. Relay Agent Behavior
For this discussion, the relay agent MAY be configured to use a The relay agent MAY be configured to use a list of destination
list of server destination addresses, which MAY include unicast addresses, which MAY include unicast addresses, the All_DHCP_Servers
addresses, the All_DHCP_Servers multicast address, or other multicast multicast address, or other addresses selected by the network
addresses selected by the network administrator. If the relay agent administrator. If the relay agent has not been explicitly
has not been explicitly configured, it MUST use the All_DHCP_Servers configured, it MUST use the All_DHCP_Servers multicast address as the
multicast address as the default. default.
20.1. Relaying of client messages 20.1. Forwarding a client message or a Relay-forward message
When a relay agent receives a valid client message, it constructs A relay agent forwards both messages from clients and Relay-forward
a Relay-forward message. The relay agent places a global or messages from other relay agents. When a relay agent receives a
site-scoped address with a prefix assigned to the link on which the valid message to be forwarded, it constructs a new Relay-forward
client should be assigned an address in the link-address field. This message. The relay agent copies the source address from the
address will be used by the server to determine the link from which header of the IP datagram in which the message was received to the
the client should be assigned an address and other configuration peer-address field of the Relay-forward message. The relay agent
information. copies the received DHCP message (excluding any IP or UDP headers)
into a Relay Message option in the new message. The relay agent adds
to the Relay-forward message any other options it is configured to
include.
20.1.1. Forwarding a message from a client
If the relay agent received the message to be forwarded from a
client, the relay agent places a global or site-scoped address with a
prefix assigned to the link on which the client should be assigned an
address in the link-address field. This address will be used by the
server to determine the link from which the client should be assigned
an address and other configuration information. The hop-count in the
Relay-forward message is set to 0.
If the relay agent cannot use the address in the link-address field If the relay agent cannot use the address in the link-address field
to identify the interface through which the response to the client to identify the interface through which the response to the client
will be forwarded, the relay agent MUST include an Interface-id will be forwarded, the relay agent MUST include an Interface-id
option (see section 22.19) in the Relay-forward message. The server option (see section 22.18) in the Relay-forward message. The server
will include the Interface-id option in its Relay-reply message. will include the Interface-id option in its Relay-reply message.
The relay agent fills in the link-address field as described in the The relay agent fills in the link-address field as described in the
previous paragraph regardless of whether the relay agent includes an previous paragraph regardless of whether the relay agent includes an
Interface-id option in the Relay-forward message. Interface-id option in the Relay-forward message.
The relay agent copies the source address from the IP datagram 20.1.2. Forwarding a message from a relay agent
in which the message was received from the client into the
client-address field in the Relay-forward message.
The relay agent constructs a Client Message option (see If the message received by the relay agent is a Relay-forward
section 22.10) that contains the entire DHCP message (excluding message and the hop-count in the message is greater than or equal to
the IP and UDP headers) from the client in the data field of HOP_COUNT_LIMIT, the relay agent discards the received message.
the option. The relay agent places the Client Message option
along with any "relay agent-specific" options in the options
field of the Relay-forward message. The relay agent sends the
Relay-forward message to all the servers in the list of server
destination addresses with which it has been configured or to the
All_DHCP_Servers address if it has not been explicitly configured
with server destination addresses.
20.2. Relaying of server messages The relay agent sets the link-address field to 0 and sets the
hop-count field to the value of the hop-count field in the received
message incremented by 1.
The relay agent processes any other options included in the The relay agent copies the source address from the IP datagram in
Relay-reply message as appropriate to those options. The relay which the message was received from the client into the peer-address
agents then discards those options. field in the Relay-forward message.
If the Relay-reply message includes a Interface-id option, the relay 20.2. Forwarding a Relay-reply message
agent forwards the message from the server to the client on the link
identified by the Interface-id option. Otherwise, the relay agent
forwards the message on the link identified by the link-address
field.
In either case, the relay agent extracts the server message from the The relay agent processes any options included in the Relay-reply
Server Message option (see section 22.11) and forwards the message to message in addition to the Relay Message option and then discards
the address in the client-address field in the Relay-reply message. those options.
The relay agent extracts the message from the Relay Message option
and forwards it to the address contained in the peer-address field of
the Relay-reply message.
If the Relay-reply message includes an Interface-id option, the
relay agent forwards the message from the server to the client on
the link identified by the Interface-id option. Otherwise, if the
link-address field is not set to zero, the relay agent forwards the
message on the link identified by the link-address field.
If the Relay-reply message does not include an Interface-id option
and the link-address field is zero, the address in the peer-address
field must be a global address or a site-local address (and the
device on which the relay agent is running belongs to only one
site). If the address in the peer-address field does not meet this
condition, the relay agent discards the Relay-reply message and
SHOULD communicate an error condition.
20.3. Construction of Relay-reply messages
A server uses a Relay-reply message to return a response to a client
if the original message from the client was forwarded to the server
in a Relay-forward message. The response to the client MUST be
forwarded through the same relay agents as the original client
message. The server causes this to happen by creating a Relay-reply
message that includes a Relay Message option containing the message
for the next relay agent in the return path to the client. The
contained Relay-reply message contains another Relay Message option
to be sent to the next relay agent, and so on. The server must
record the contents of the peer-address fields in the received
message so it can construct the appropriate Relay-reply message
carrying the response from the server.
For example, if client C sent a message that was forwarded by relay
agent A to relay agent B and then to the server, the server would the
following Relay-Reply message to relay agent B:
msg-type: RELAY-REPLY
hop-count: 0
link-address: 0
peer-address: A
Relay Message option, containing:
msg-type: RELAY-REPLY
hop-count: 0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: <response from server>
21. Authentication of DHCP messages 21. Authentication of DHCP messages
Some network administrators may wish to provide authentication of Some network administrators may wish to provide authentication of
the source and contents of DHCP messages. For example, clients may the source and contents of DHCP messages. For example, clients may
be subject to denial of service attacks through the use of bogus be subject to denial of service attacks through the use of bogus
DHCP servers, or may simply be misconfigured due to unintentionally DHCP servers, or may simply be misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish to instantiated DHCP servers. Network administrators may wish to
constrain the allocation of addresses to authorized hosts to avoid constrain the allocation of addresses to authorized hosts to avoid
denial of service attacks in "hostile" environments where the network denial of service attacks in "hostile" environments where the network
medium is not physically secured, such as wireless networks or medium is not physically secured, such as wireless networks or
college residence halls. college residence halls.
The DHCP authentication mechanism is based on the design of The DHCP authentication mechanism is based on the design of
authentication for DHCPv4 [5]. authentication for DHCPv4 [6].
21.1. DHCP threat model 21.1. DHCP threat model
The threat to DHCP is inherently an insider threat (assuming a The threat to DHCP is inherently an insider threat (assuming a
properly configured network where DHCPv6 ports are blocked on the properly configured network where DHCPv6 ports are blocked on the
perimeter gateways of the enterprise). Regardless of the gateway perimeter gateways of the enterprise). Regardless of the gateway
configuration, however, the potential attacks by insiders and configuration, however, the potential attacks by insiders and
outsiders are the same. outsiders are the same.
The attack specific to a DHCP client is the possibility of the The attack specific to a DHCP client is the possibility of the
skipping to change at page 51, line 30 skipping to change at page 52, line 24
accidentally configured DHCP servers that answer DHCP client requests accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters. with unintentionally incorrect configuration parameters.
The threat specific to a DHCP server is an invalid client The threat specific to a DHCP server is an invalid client
masquerading as a valid client. The motivation for this may be for masquerading as a valid client. The motivation for this may be for
"theft of service", or to circumvent auditing for any number of "theft of service", or to circumvent auditing for any number of
nefarious purposes. nefarious purposes.
The threat common to both the client and the server is the resource The threat common to both the client and the server is the resource
"denial of service" (DoS) attack. These attacks typically involve "denial of service" (DoS) attack. These attacks typically involve
the exhaustion of valid addresses, or the exhaustion of CPU or the exhaustion of available addresses, or the exhaustion of CPU
network bandwidth, and are present anytime there is a shared or network bandwidth, and are present anytime there is a shared
resource. resource.
This threat model does not consider the privacy of the contents This threat model does not consider the privacy of the contents
of DHCP messages to be important. DHCP is not used to exchange of DHCP messages to be important. DHCP is not used to exchange
authentication or configuration information that must be kept secret authentication or configuration information that must be kept secret
from other networks nodes. from other networks nodes.
21.2. Security of messages sent between servers and relay agents 21.2. Security of messages sent between servers and relay agents
Relay agents and servers that choose to exchange messages securely Relay agents and servers that choose to exchange messages securely
use the IPsec mechanisms for IPv6 [8]. The way in which IPsec use the IPsec mechanisms for IPv6 [10]. Relay agents and servers
is employed by relay agents and servers is not specified in this MUST support manual configuration and installation of static keys.
document. If a client message is forwarded through multiple relay agents, each
of the relay agents must have established independent, pairwise trust
relationships. That is, if messages from client C will be forwarded
by relay agent A to relay agent B and then to the server, relay
agents A and B must be configured to use IPSec for the messages they
exchange, and relay agent B and the server must be configured to use
IPSec for the messages they exchange.
21.3. Summary of DHCP authentication 21.3. Summary of DHCP authentication
Authentication of DHCP messages is accomplished through the use of Authentication of DHCP messages is accomplished through the use of
the Authentication option (see section 22.12). The authentication the Authentication option (see section 22.11). The authentication
information carried in the Authentication option can be used to information carried in the Authentication option can be used to
reliably identify the source of a DHCP message and to confirm that reliably identify the source of a DHCP message and to confirm that
the contents of the DHCP message have not been tampered with. the contents of the DHCP message have not been tampered with.
The Authentication option provides a framework for multiple The Authentication option provides a framework for multiple
authentication protocols. One such protocol is defined here. authentication protocols. One such protocol is defined here.
Other protocols defined in the future will be specified in separate Other protocols defined in the future will be specified in separate
documents. documents.
The protocol field in the Authentication option identifies the The protocol field in the Authentication option identifies the
specific protocol used to generate the authentication information specific protocol used to generate the authentication information
carried in the option. The algorithm field identifies a specific carried in the option. The algorithm field identifies a specific
algorithm within the authentication protocol; for example, the algorithm within the authentication protocol; for example, the
algorithm field specifies the hash algorithm used to generate the algorithm field specifies the hash algorithm used to generate the
message authentication code (MAC) in the authentication option. The message authentication code (MAC) in the authentication option. The
replay detection method (RDM) field specifies the type of replay replay detection method (RDM) field specifies the type of replay
skipping to change at page 52, line 25 skipping to change at page 53, line 27
detection used in the replay detection field. detection used in the replay detection field.
21.4. Replay detection 21.4. Replay detection
The Replay Detection Method (RDM) field determines the type of replay The Replay Detection Method (RDM) field determines the type of replay
detection used in the Replay Detection field. detection used in the Replay Detection field.
If the RDM field contains 0x00, the replay detection field MUST If the RDM field contains 0x00, the replay detection field MUST
be set to the value of a monotonically increasing counter. Using be set to the value of a monotonically increasing counter. Using
a counter value such as the current time of day (for example, an a counter value such as the current time of day (for example, an
NTP-format timestamp [10]) can reduce the danger of replay attacks. NTP-format timestamp [12]) can reduce the danger of replay attacks.
This method MUST be supported by all protocols. This method MUST be supported by all protocols.
21.5. Delayed authentication protocol 21.5. Delayed authentication protocol
If the protocol field is 1, the message is using the "delayed If the protocol field is 1, the message is using the "delayed
authentication" mechanism. In delayed authentication, the client authentication" mechanism. In delayed authentication, the client
requests authentication in its Solicit message and the server replies requests authentication in its Solicit message and the server replies
with an Advertise message that includes authentication information. with an Advertise message that includes authentication information.
This authentication information contains a nonce value generated by This authentication information contains a nonce value generated by
the source as a message authentication code (MAC) to provide message the source as a message authentication code (MAC) to provide message
authentication and entity authentication. authentication and entity authentication.
The use of a particular technique based on the HMAC protocol [9] The use of a particular technique based on the HMAC protocol [11]
using the MD5 hash [17] is defined here. using the MD5 hash [19] is defined here.
21.5.1. Management issues in the delayed authentication protocol
The "delayed authentication" protocol does not attempt to address
situations where a client may roam from one administrative domain
to another, i.e. interdomain roaming. This protocol is focused on
solving the intradomain problem where the out-of-band exchange of a
shared key is feasible.
21.5.2. Use of the Authentication option in the delayed authentication 21.5.1. Use of the Authentication option in the delayed authentication
protocol protocol
In a Solicit message, the Authentication option carries the Protocol, In a Solicit message, the Authentication option carries the Protocol,
Algorithm and fields, but no Replay detection or Authentication Algorithm and fields, but no Replay detection or Authentication
information. information.
In an Advertise, Request, Renew, Rebind, Confirm, Decline, Release In an Advertise, Request, Renew, Rebind, Confirm, Decline, Release
or Information-request message, the Authentication option carries or Information-request message, the Authentication option carries
the Protocol, Algorithm, RDM and Replay detection fields and the Protocol, Algorithm, RDM and Replay detection fields and
Authentication information. Authentication information.
skipping to change at page 53, line 46 skipping to change at page 54, line 34
Replay Detection - as defined by the RDM field Replay Detection - as defined by the RDM field
K - a key (secret value) shared K - a key (secret value) shared
between the source and between the source and
destination of the message; destination of the message;
each key has a unique each key has a unique
identifier (key ID) identifier (key ID)
key ID - the unique identifier for the key value key ID - the unique identifier for the key value
used to generate the MAC for this message used to generate the MAC for this message
HMAC-MD5 - the MAC generating function. HMAC-MD5 - the MAC generating function.
The sender computes the MAC using the HMAC generation algorithm [9] The sender computes the MAC using the HMAC generation algorithm [11]
and the MD5 hash function [17]. The entire DHCP message (setting and the MD5 hash function [19]. The entire DHCP message (setting
the MAC field to zero), including the DHCP message header and the the MAC field of the authentication option to zero), including the
options field, is used as input to the HMAC-MD5 computation function. DHCP message header and the options field, is used as input to the
The 'key ID' field MUST be set to the identifier of the key used to HMAC-MD5 computation function. The 'key ID' field MUST be set to the
generate the MAC. identifier of the key used to generate the MAC.
DISCUSSION: DISCUSSION:
Algorithm 1 specifies the use of HMAC-MD5. Use of a Algorithm 1 specifies the use of HMAC-MD5. Use of a
different technique, such as HMAC-SHA, will be specified as different technique, such as HMAC-SHA, will be specified as
a separate protocol. a separate protocol.
Delayed authentication requires a shared secret key for each Delayed authentication requires a shared secret key for each
client on each DHCP server with which that client may wish client on each DHCP server with which that client may wish
to use the DHCP protocol. Each key has a unique identifier to use the DHCP protocol. Each key has a unique identifier
that can be used by a receiver to determine which key was that can be used by a receiver to determine which key was
used to generate the MAC in the DHCP message. Therefore, used to generate the MAC in the DHCP message. Therefore,
delayed authentication may not scale well in an architecture delayed authentication may not scale well in an architecture
in which a DHCP client connects to multiple administrative in which a DHCP client connects to multiple administrative
domains. domains.
21.5.3. Message validation 21.5.2. Message validation
Any DHCP message that includes more than one authentication option
MUST be discarded.
To validate an incoming message, the receiver first checks that To validate an incoming message, the receiver first checks that
the value in the replay detection field is acceptable according to the value in the replay detection field is acceptable according to
the replay detection method specified by the RDM field. Next, the the replay detection method specified by the RDM field. Next, the
receiver computes the MAC as described in [9]. The entire DHCP receiver computes the MAC as described in [11]. The entire DHCP
message (except the MAC field of the authentication option itself), message (setting the MAC field of the authentication option to 0),
is used as input to the HMAC-MD5 computation function. If the MAC is used as input to the HMAC-MD5 computation function. If the MAC
computed by the receiver does not match the MAC contained in the computed by the receiver does not match the MAC contained in the
authentication option, the receiver MUST discard the DHCP message. authentication option, the receiver MUST discard the DHCP message.
21.5.4. Key utilization 21.5.3. Key utilization
Each DHCP client has a key, K. The server uses the client's DUID to Each DHCP client has a key, K. The server uses the client's DUID to
identify the client's key. The client uses its key to encode any identify the client's key. The client uses its key to encode any
messages it sends to the server and to authenticate and verify any messages it sends to the server and to authenticate and verify any
messages it receives from the server. The client's key is initially messages it receives from the server. The client's key is initially
distributed to the client through some out-of-band mechanism, and distributed to the client through some out-of-band mechanism, and
is stored locally on the client for use in all authenticated DHCP is stored locally on the client for use in all authenticated DHCP
messages. Once the client has been given its key, it uses that key messages. Once the client has been given its key, it uses that key
for all transactions even if the client's configuration changes; for for all transactions even if the client's configuration changes; for
example, if the client is assigned a new network address. example, if the client is assigned a new network address.
Each DHCP server knows, or be able to obtain in a secure manner, Each DHCP server stores or is able to obtain in a secure manner the
the keys for all authorized clients. If all clients use the same keys for all authorized clients. To authenticate the identity of
key, clients can perform both entity and message authentication for individual clients, each client must be configured with a unique key
all messages received from servers. However, the sharing of keys and a key ID for that key.
is strongly discouraged as it allows for unauthorized clients to
masquerade as authorized clients by obtaining a copy of the shared
key and allows for trivial spoofing of an authenticated DHCP server.
To authenticate the identity of individual clients, each client must
be configured with a unique key and a key ID for that key.
21.5.5. Client considerations for delayed authentication protocol 21.5.4. Client considerations for delayed authentication protocol
21.5.5.1. Sending Solicit messages 21.5.4.1. Sending Solicit messages
When the client sends a Solicit message and wishes to use When the client sends a Solicit message and wishes to use
authentication, it includes an Authentication option with the desired authentication, it includes an Authentication option with the desired
protocol, algorithm and RDM as described in section 21.5. The client protocol, algorithm and RDM as described in section 21.5. The client
does not include any replay detection or authentication information does not include any replay detection or authentication information
in the Authentication option. in the Authentication option.
21.5.5.2. Receiving Advertise messages 21.5.4.2. Receiving Advertise messages
The client validates any Advertise messages containing an The client validates any Advertise messages containing an
Authentication option specifying the delayed authentication protocol Authentication option specifying the delayed authentication protocol
using the validation test described in section 21.5.3. using the validation test described in section 21.5.2.
Client behavior if no Advertise messages include authentication Client behavior if no Advertise messages include authentication
information or pass the validation test is controlled by local policy information or pass the validation test is controlled by local policy
on the client. According to client policy, the client MAY choose to on the client. According to client policy, the client MAY choose to
respond to a Advertise message that has not been authenticated. respond to a Advertise message that has not been authenticated.
The decision to set local policy to accept unauthenticated messages The decision to set local policy to accept unauthenticated messages
should be made with care. Accepting an unauthenticated Advertise should be made with care. Accepting an unauthenticated Advertise
message can make the client vulnerable to spoofing and other message can make the client vulnerable to spoofing and other
attacks. If local users are not explicitly informed that the client attacks. If local users are not explicitly informed that the client
skipping to change at page 55, line 45 skipping to change at page 56, line 26
A client MUST be configurable to discard unauthenticated messages, A client MUST be configurable to discard unauthenticated messages,
and SHOULD be configured by default to discard unauthenticated and SHOULD be configured by default to discard unauthenticated
messages if the client has been configured with an authentication messages if the client has been configured with an authentication
key or other authentication information. A client MAY choose to key or other authentication information. A client MAY choose to
differentiate between Advertise messages with no authentication differentiate between Advertise messages with no authentication
information and Advertise messages that do not pass the validation information and Advertise messages that do not pass the validation
test; for example, a client might accept the former and discard the test; for example, a client might accept the former and discard the
latter. If a client does accept an unauthenticated message, the latter. If a client does accept an unauthenticated message, the
client SHOULD inform any local users and SHOULD log the event. client SHOULD inform any local users and SHOULD log the event.
21.5.5.3. Sending Request, Confirm, Renew, Rebind, Decline or Release 21.5.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release
messages messages
If the client authenticated the Advertise message through which the If the client authenticated the Advertise message through which the
client selected the server, the client MUST generate authentication client selected the server, the client MUST generate authentication
information for subsequent Request, Confirm, Renew, Rebind or Release information for subsequent Request, Confirm, Renew, Rebind or Release
messages sent to the server as described in section 21.5. When the messages sent to the server as described in section 21.5. When the
client sends a subsequent message, it MUST use the same key used by client sends a subsequent message, it MUST use the same key used by
the server to generate the authentication information. the server to generate the authentication information.
21.5.5.4. Sending Information-request messages 21.5.4.4. Sending Information-request messages
If the server has selected a key for the client in a previous message If the server has selected a key for the client in a previous message
exchange (see section 21.5.6.1, the client MUST use the same key exchange (see section 21.5.5.1), the client MUST use the same key
to generate the authentication information. If the client has not to generate the authentication information. If the client has not
previously been given a key with the server, the client MUST use previously been given a key with the server, the client MUST use
a key that has been selected for the client through some external a key that has been selected for the client through some external
mechanism. mechanism.
21.5.5.5. Receiving Reply messages 21.5.4.5. Receiving Reply messages
If the client authenticated the Advertise it accepted, the client If the client authenticated the Advertise it accepted, the client
MUST validate the associated Reply message from the server. The MUST validate the associated Reply message from the server. The
client MUST discard the Reply if the message fails to pass validation client MUST discard the Reply if the message fails to pass validation
and MAY log the validation failure. If the Reply fails to pass and MAY log the validation failure. If the Reply fails to pass
validation, the client MUST restart the DHCP configuration process by validation, the client MUST restart the DHCP configuration process by
sending a Solicit message. sending a Solicit message.
If the client accepted an Advertise message that did not include If the client accepted an Advertise message that did not include
authentication information or did not pass the validation test, the authentication information or did not pass the validation test, the
client MAY accept an unauthenticated Reply message from the server. client MAY accept an unauthenticated Reply message from the server.
21.5.5.6. Receiving Reconfigure messages 21.5.4.6. Receiving Reconfigure messages
The client MUST discard the Reconfigure if the message fails to pass The client MUST discard the Reconfigure if the message fails to pass
validation and MAY log the validation failure. validation and MAY log the validation failure.
21.5.6. Server considerations for delayed authentication protocol 21.5.5. Server considerations for delayed authentication protocol
21.5.6.1. Receiving Solicit messages and Sending Advertise messages 21.5.5.1. Receiving Solicit messages and Sending Advertise messages
The server selects a key for the client and includes authentication The server selects a key for the client and includes authentication
information in the Advertise message returned to the client as information in the Advertise message returned to the client as
specified in section 21.5. The server MUST record the identifier of specified in section 21.5. The server MUST record the identifier of
the key selected for the client and use that same key for validating the key selected for the client and use that same key for validating
subsequent messages with the client. subsequent messages with the client.
21.5.6.2. Receiving Request, Confirm, Renew, Rebind or Release messages 21.5.5.2. Receiving Request, Confirm, Renew, Rebind or Release messages
and Sending Reply messages and Sending Reply messages
The server uses the key identified in the message and validates the The server uses the key identified in the message and validates the
message as specified in section 21.5.3. If the message fails to pass message as specified in section 21.5.2. If the message fails to pass
validation or the server does not know the key identified by the 'key validation or the server does not know the key identified by the 'key
ID' field, the server MUST discard the message and MAY choose to log ID' field, the server MUST discard the message and MAY choose to log
the validation failure. the validation failure.
If the message passes the validation procedure, the server responds If the message passes the validation procedure, the server responds
to the specific message as described in section 18.2. The server to the specific message as described in section 18.2. The server
MUST include authentication information generated using the key MUST include authentication information generated using the key
identified in the received message as specified in section 21.5. identified in the received message as specified in section 21.5.
21.5.6.3. Sending Reconfigure messages 21.5.5.3. Sending Reconfigure messages
The server MUST include an Authentication option in a Reconfigure The server MUST include an Authentication option in a Reconfigure
message, generated as specified in section 21.5 using the key the message, generated as specified in section 21.5 using the key the
server initially selected for the client to which the Reconfigure server initially selected for the client to which the Reconfigure
message is to be sent. message is to be sent.
If the server has not previously selected a key for the client, the If the server has not previously selected a key for the client, the
server MUST use a key that has been selected for the client through server MUST use a key that has been selected for the client through
some external mechanism. some external mechanism.
skipping to change at page 57, line 37 skipping to change at page 58, line 19
separate documents. separate documents.
Unless otherwise noted, each option may appear only in the options Unless otherwise noted, each option may appear only in the options
area of a DHCP message and may appear only once. If an option does area of a DHCP message and may appear only once. If an option does
appear multiple times, each instance is considered separate and the appear multiple times, each instance is considered separate and the
data areas of the options MUST NOT be concatenated or otherwise data areas of the options MUST NOT be concatenated or otherwise
combined. combined.
22.1. Format of DHCP options 22.1. Format of DHCP options
The format of DHCP options 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data | | option-data |
| (option-len octets) | | (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code An unsigned integer identifying the specific option option-code An unsigned integer identifying the specific option
skipping to change at page 58, line 15 skipping to change at page 58, line 46
option-data The data for the option; the format of this data option-data The data for the option; the format of this data
depends on the definition of the option. depends on the definition of the option.
DHCPv6 options are scoped by using encapsulation. Some options apply DHCPv6 options are scoped by using encapsulation. Some options apply
generally to the client, some are specific to an IA, and some are generally to the client, some are specific to an IA, and some are
specific to the addresses within an IA. These latter two cases are specific to the addresses within an IA. These latter two cases are
discussed in sections 22.4 and 22.6. discussed in sections 22.4 and 22.6.
22.2. Client Identifier option 22.2. Client Identifier option
The Client Identifier option is used to carry a DUID identifying The Client Identifier option is used to carry a DUID identifying a
a client between a client and a server. The format of the Client client between a client and a server.
Identifier option is:
The format of the Client Identifier 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENTID | option-len | | OPTION_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. DUID . . DUID .
. (variable length) . . (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENTID (1) option-code OPTION_CLIENTID (1)
option-len Length of DUID in octets option-len Length of DUID in octets
DUID The DUID for the client DUID The DUID for the client
22.3. Server Identifier option 22.3. Server Identifier option
The Server Identifier option is used to carry a DUID identifying The Server Identifier option is used to carry a DUID identifying a
a server between a client and a server. The format of the Server server between a client and a server.
Identifier option is:
The format of the Server Identifier 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVERID | option-len | | OPTION_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. DUID . . DUID .
. (variable length) . . (variable length) .
. . . .
skipping to change at page 59, line 20 skipping to change at page 60, line 12
A server MUST process any message it receives that contains a Server A server MUST process any message it receives that contains a Server
Identifier option with a DUID that matches the server's DUID. Identifier option with a DUID that matches the server's DUID.
22.4. Identity Association option 22.4. Identity Association option
The Identity Association option (IA option) is used to carry an The Identity Association option (IA option) is used to carry an
identity association, the parameters associated with the IA and the identity association, the parameters associated with the IA and the
addresses associated with the IA. addresses associated with the IA.
Addresses appearing in an IA option are not temporary addresses (see Addresses appearing in an IA option are not temporary addresses (see
section 22.5). section 22.5). 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA | option-len | | OPTION_IA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) | | IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 | | T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 63, line 4 skipping to change at page 63, line 49
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime | | preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime | | valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IAaddr-options . . IAaddr-options .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_IADDR (5)
option-len 24 + length of IAaddr-options field option-code OPTION_IAADDR (5)
option-len 24 + length of IAaddr-options field
IPv6 address An IPv6 address IPv6 address An IPv6 address
preferred-lifetime The preferred lifetime for the IPv6 address in preferred-lifetime The preferred lifetime for the IPv6 address in
the option, expressed in units of seconds the option, expressed in units of seconds
valid-lifetime The valid lifetime for the IPv6 address in the valid-lifetime The valid lifetime for the IPv6 address in the
option, expressed in units of seconds option, expressed in units of seconds
IAaddr-options Options associated with this address IAaddr-options Options associated with this address
skipping to change at page 63, line 36 skipping to change at page 64, line 32
An IA Address option may appear only in an IA option or an IA_TA An IA Address option may appear only in an IA option or an IA_TA
option. More than one IA Address Options can appear in an IA option option. More than one IA Address Options can appear in an IA option
or an IA_TA option. or an IA_TA option.
The status of any operations involving this IA Address is indicated The status of any operations involving this IA Address is indicated
in a Status Code option in the IAaddr-options field. in a Status Code option in the IAaddr-options field.
22.7. Option Request option 22.7. Option Request option
The Option Request option is used to identify a list of options in a The Option Request option is used to identify a list of options in
message between a client and a server. a message between a client and a server. The format of the Option
Request option is:
The format of the Option Request 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ORO | option-len | | OPTION_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 | | requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 64, line 20 skipping to change at page 65, line 14
A client MAY include an Option Request option in a Solicit, Request, A client MAY include an Option Request option in a Solicit, Request,
Renew, Rebind, Confirm or Information-request message to inform Renew, Rebind, Confirm or Information-request message to inform
the server about options the client wants the server to send to the server about options the client wants the server to send to
the client. A server MAY include an Option Request option in a the client. A server MAY include an Option Request option in a
Reconfigure option to indicate which options the client should Reconfigure option to indicate which options the client should
request from the server. request from the server.
22.8. Preference option 22.8. Preference option
The Preference option is sent by a server to a client to affect the
selection of a server by the client. The format of the Preference
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFERENCE | option-len | | OPTION_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value | | pref-value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
option-code OPTION_PREFERENCE (7) option-code OPTION_PREFERENCE (7)
option-len 1. option-len 1
pref-value The preference value for the server in this message. pref-value The preference value for the server in this message.
A server MAY include a Preference option in an Advertise message to A server MAY include a Preference option in an Advertise message to
control the selection of a server by the client. See section 17.1.3 control the selection of a server by the client. See section 17.1.3
for the use of the Preference option by the client and the for the use of the Preference option by the client and the
interpretation of Preference option data value. interpretation of Preference option data value.
22.9. Elapsed Time 22.9. Elapsed Time 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_ELAPSED_TIME | option-len | | OPTION_ELAPSED_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| elapsed-time | | elapsed-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ELAPSED_TIME (8) option-code OPTION_ELAPSED_TIME (8)
option-len 2. option-len 2.
elapsed-time The amount of time since the client began its elapsed-time The amount of time since the client began its
current DHCP transaction. This time is expressed in current DHCP transaction. This time is expressed in
hundredths of a second (10^-2 seconds). hundredths of a second (10^-2 seconds).
A client MUST include an Elapsed Time option in messages to indicate A client MUST include an Elapsed Time option in messages to indicate
how long the client has been trying to complete a DHCP transaction. how long the client has been trying to complete a DHCP message
Servers and Relay Agents use the data value in this option as input exchange. The elapsed time is measured from the time at which the
to policy controlling how a server responds to a client message. client sent the first message in the message exchange, and the
For example, the elapsed time option allows a secondary DHCP server elapsed-time field is set to 0 in the first message in the message
to respond to a request when a primary server hasn't answered in a exchange. Servers and Relay Agents use the data value in this option
reasonable time. as input to policy controlling how a server responds to a client
message. For example, the elapsed time option allows a secondary
22.10. Client message option DHCP server to respond to a request when a primary server hasn't
answered in a reasonable time.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENT_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCP-client-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_MSG (9)
option-len Length of DHCP client message.
DHCP-client-message The message received from the client; 22.10. Relay Message option
forwarded verbatim to the server.
A relay agent forwards a message from a client to a server as the The Relay Message option carries a DHCP message in a Relay-forward or
contents of a Client Message option in a Relay-forward message. Relay-reply message.
22.11. Server message option The format of the Relay Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVER_MSG | option-len | | OPTION_RELAY_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. DHCP-server-message . . DHCP-relay-message .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SERVER_MSG (10)
option-len Length of DHCP server message. option-code OPTION_RELAY_MSG (9)
DHCP-server-message The message received from the server; option-len Length of DHCP-relay-message
forwarded verbatim to the client.
A server sends a DHCP message to be forwarded to a client by a relay DHCP-relay-message In a Relay-forward message, the received
agent as the contents of a Server Message option in a Relay-reply message, forwarded verbatim to the next relay agent
message. or server; in a Relay-reply message, the message to
be copied and forwarded to the relay agent or client
whose address is in the peer-address field of the
Relay-reply message
22.12. Authentication option 22.11. Authentication option
The Authentication option carries authentication information to The Authentication option carries authentication information to
authenticate the identity and contents of DHCP messages. The use of authenticate the identity and contents of DHCP messages. The use of
the Authentication option is described in section 21. the Authentication option is described in section 21.
The format of the Authentication option is: The format of the Authentication 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 67, line 4 skipping to change at page 67, line 39
this authentication option this authentication option
algorithm The algorithm used in the algorithm The algorithm used in the
authentication protocol authentication protocol
RDM The replay detection method used in RDM The replay detection method used in
this authentication option this authentication option
Replay detection The replay detection information for Replay detection The replay detection information for
the RDM the RDM
Authentication information The authentication information, Authentication information The authentication information,
as specified by the protocol and as specified by the protocol and
algorithm used in this authentication algorithm used in this authentication
option option
22.13. Server unicast option 22.12. Server unicast option
The server sends this option to a client to indicate to the client The server sends this option to a client to indicate to the client
that it is allowed to unicast messages to the server. The server that it is allowed to unicast messages to the server.
specifies the IPv6 address to which the client is to send unicast
messages in the server-address field. When a client receives this
option, where permissible and appropriate, the client sends messages
directly to the server using the IPv6 address specified in the
server-address field of the option.
Details about when the client may send messages to the server using The format of the Server Unicast option is:
unicast are in section 18.
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_UNICAST | option-len | | OPTION_UNICAST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| server-address | | server-address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_UNICAST (12) option-code OPTION_UNICAST (12)
option-len 16 option-len 16
server-address The IP address to which the client should send server-address The IP address to which the client should send
messages delivered using unicast messages delivered using unicast
22.14. Status Code Option The server specifies the IPv6 address to which the client is to send
unicast messages in the server-address field. When a client receives
this option, where permissible and appropriate, the client sends
messages directly to the server using the IPv6 address specified in
the server-address field of the option.
Details about when the client may send messages to the server using
unicast are in section 18.
22.13. Status Code Option
This option returns a status indication related to the DHCP message This option returns a status indication related to the DHCP message
or option in which it appears. or option in which it appears. The format of the Status Code 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_STATUS_CODE | option-len | | OPTION_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | | | status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. . . .
. status-message . . status-message .
skipping to change at page 68, line 18 skipping to change at page 69, line 4
| OPTION_STATUS_CODE | option-len | | OPTION_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | | | status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. . . .
. status-message . . status-message .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_STATUS_CODE (13) option-code OPTION_STATUS_CODE (13)
option-len 2 + length of status-message option-len 2 + length of status-message
status-code The numeric code for the status encoded in status-code The numeric code for the status encoded in
this option. The status codes are defined in this option. The status codes are defined in
section 24.4. section 24.4.
status-message A UTF-8 encoded text string, which MUST NOT status-message A UTF-8 encoded text string suitable for
be null-terminated. display to an end user, which MUST NOT be
null-terminated.
A Status Code option may appear in a DHCP message option, or in the
options area of another option. If the Status Code option does not
appear in a message in which the option could appear, the status of
the message is assumed to be Success.
22.15. Rapid Commit option A Status Code option may appear in the options field of a DHCP
message and/or in the options field of another option. If the Status
Code option does not appear in a message in which the option could
appear, the status of the message is assumed to be Success.
A client MAY include this option in a Solicit message if the client 22.14. Rapid Commit option
is prepared to perform the Solicit-Reply message exchange described
in section 17.1.1.
A server MUST include this option in a Reply message sent in response The Rapid Commit option is used to signal the use of the two message
to a Solicit message when completing the Solicit-Reply message exchange for address assignment. The format of the Rapid Commit
exchange. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RAPID_COMMIT | 0 | | OPTION_RAPID_COMMIT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RAPID_COMMIT (14) option-code OPTION_RAPID_COMMIT (14)
option-len 0 option-len 0
A client MAY include this option in a Solicit message if the client
is prepared to perform the Solicit-Reply message exchange described
in section 17.1.1.
A server MUST include this option in a Reply message sent in response
to a Solicit message when completing the Solicit-Reply message
exchange.
DISCUSSION: DISCUSSION:
Each server that responds with a Reply to a Solicit that Each server that responds with a Reply to a Solicit that
includes a Rapid Commit option will commit the assigned includes a Rapid Commit option will commit the assigned
addresses in the Reply message to the client, and will not addresses in the Reply message to the client, and will not
receive any confirmation that the client has received the receive any confirmation that the client has received the
Reply message. Therefore, if more than one server responds Reply message. Therefore, if more than one server responds
to a Solicit that includes a Rapid Commit option, some to a Solicit that includes a Rapid Commit option, some
servers will commit addresses that are not actually used by servers will commit addresses that are not actually used by
the client. the client.
The problem of unused addresses can be minimized, for The problem of unused addresses can be minimized, for
example, by designing the DHCP service so that only one example, by designing the DHCP service so that only one
server responds to the Solicit or by using relatively short server responds to the Solicit or by using relatively short
lifetimes for assigned addresses. lifetimes for assigned addresses.
22.16. User Class Option 22.15. User Class option
This option is used by a client to identify the type or category of The User Class option is used by a client to identify the type or
user or applications it represents. The information contained in the category of user or applications it represents.
data area of this option is contained in one or more opaque fields
that represent the user class or classes of which the client is a The format of the User Class option is:
member. A server selects configuration information for the client
based on the classes identified in this option. For example, the
User Class option can be used to configure all clients of people
in the accounting department with a different printer than clients
of people in the marketing department. The user class information
carried in this option MUST be configurable on the client.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_USER_CLASS | option-len | | OPTION_USER_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. user-class-data . . user-class-data .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_USER_CLASS (15) option-code OPTION_USER_CLASS (15)
option-len Length of user class data field option-len Length of user class data field
user-class-data The user classes carried by the client. user-class-data The user classes carried by the client.
The information contained in the data area of this option is
contained in one or more opaque fields that represent the user
class or classes of which the client is a member. A server selects
configuration information for the client based on the classes
identified in this option. For example, the User Class option can be
used to configure all clients of people in the accounting department
with a different printer than clients of people in the marketing
department. The user class information carried in this option MUST
be configurable on the client.
The data area of the user class option MUST contain one or more The data area of the user class option MUST contain one or more
instances of user class data. Each instance of the user class data instances of user class data. Each instance of the user class data
is formatted as follows: is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-data | | user-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The user-class-len is two octets long and specifies the length of the The user-class-len is two octets long and specifies the length of the
opaque user class data in network byte order. opaque user class data in network byte order.
A server interprets the classes identified in this option according A server interprets the classes identified in this option according
to its configuration to select the appropriate configuration to its configuration to select the appropriate configuration
information for the client. A server may use only those user information for the client. A server may use only those user
classes that it is configured to interpret in selecting configuration classes that it is configured to interpret in selecting configuration
information for a client and ignore any other user classes. In information for a client and ignore any other user classes. In
response to a message containing a User Class option, a server response to a message containing a User Class option, a server
includes a User Class option containing those classes that were includes a User Class option containing those classes that were
skipping to change at page 70, line 17 skipping to change at page 71, line 12
A server interprets the classes identified in this option according A server interprets the classes identified in this option according
to its configuration to select the appropriate configuration to its configuration to select the appropriate configuration
information for the client. A server may use only those user information for the client. A server may use only those user
classes that it is configured to interpret in selecting configuration classes that it is configured to interpret in selecting configuration
information for a client and ignore any other user classes. In information for a client and ignore any other user classes. In
response to a message containing a User Class option, a server response to a message containing a User Class option, a server
includes a User Class option containing those classes that were includes a User Class option containing those classes that were
successfully interpreted by the server, so that the client can be successfully interpreted by the server, so that the client can be
informed of the classes interpreted by the server. informed of the classes interpreted by the server.
22.17. Vendor Class Option 22.16. Vendor Class Option
This option is used by a client to identify the vendor that This option is used by a client to identify the vendor that
manufactured the hardware on which the client is running. The manufactured the hardware on which the client is running. The
information contained in the data area of this option is contained information contained in the data area of this option is contained
in one or more opaque fields that identify details of the hardware in one or more opaque fields that identify details of the hardware
configuration. configuration. The format of the Vendor Class option is:
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_VENDOR_CLASS | option-len | | OPTION_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number | | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. vendor-class-data . . vendor-class-data .
. . . . . . . . . .
skipping to change at page 71, line 10 skipping to change at page 72, line 4
each of which describes some characteristic of the client's hardware each of which describes some characteristic of the client's hardware
configuration. Examples of vendor-class-data instances might include configuration. Examples of vendor-class-data instances might include
the version of the operating system the client is running or the the version of the operating system the client is running or the
amount of memory installed on the client. amount of memory installed on the client.
Each instance of the vendor-class-data is formatted as follows: Each instance of the vendor-class-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data | | vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The vendor-class-len is two octets long and specifies the length of The vendor-class-len is two octets long and specifies the length of
the opaque vendor class data in network byte order. the opaque vendor class data in network byte order.
22.18. Vendor-specific Information option 22.17. Vendor-specific Information option
This option is used by clients and servers to exchange This option is used by clients and servers to exchange
vendor-specific information. The definition of this information is vendor-specific information. The format of this option
vendor specific. The vendor is indicated in the enterprise-number is:
field. Clients that do not receive desired vendor-specific
information SHOULD make an attempt to operate without it, although
they may do so (and announce they are doing so) in a degraded mode.
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_VENDOR_OPTS | option-len | | OPTION_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number | | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. option-data . . option-data .
. . . .
skipping to change at page 71, line 45 skipping to change at page 72, line 35
option-len 4 + length of option-data field option-len 4 + length of option-data field
enterprise-number The vendor's registered Enterprise Number as enterprise-number The vendor's registered Enterprise Number as
registered with IANA. registered with IANA.
option-data An opaque object of option-len octets, option-data An opaque object of option-len octets,
interpreted by vendor-specific code on the interpreted by vendor-specific code on the
clients and servers clients and servers
The definition of the information carried in this option is vendor
specific. The vendor is indicated in the enterprise-number field.
Use of vendor-specific information allows enhanced operation,
utilizing additional features in a vendor's DHCP implementation.
A DHCP client that does not receive requested vendor-specific
information will still configure the host device's IPv6 stack to be
functional.
The encapsulated vendor-specific options field MUST be encoded as a The encapsulated vendor-specific options field MUST be encoded as a
sequence of code/length/value fields of identical format to the DHCP sequence of code/length/value fields of identical format to the DHCP
options field. The option codes are defined by the vendor identified options field. The option codes are defined by the vendor identified
in the enterprise-number field and are not managed by IANA. in the enterprise-number field and are not managed by IANA.
Each of the encapsulated options is formatted as follows. Each of the encapsulated options is formatted as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| opt-code | option-len | | opt-code | option-len |
skipping to change at page 72, line 31 skipping to change at page 73, line 31
option-data The data area for the encapsulated option option-data The data area for the encapsulated option
Multiple instances of the Vendor-specific Information option may Multiple instances of the Vendor-specific Information option may
appear in a DHCP message. Each instance of the option is interpreted appear in a DHCP message. Each instance of the option is interpreted
according to the option codes defined by the vendor identified by the according to the option codes defined by the vendor identified by the
Enterprise Number in that option. A DHCP message MUST NOT contain Enterprise Number in that option. A DHCP message MUST NOT contain
more than one Vendor-specific Information option with the same more than one Vendor-specific Information option with the same
Enterprise Number. Enterprise Number.
22.19. Interface-Id Option 22.18. Interface-Id Option
The relay agent MAY send the Interface-id option to identify the The relay agent MAY send the Interface-id option to identify the
interface on which the client message was received. If a relay agent interface on which the client message was received. If a relay agent
receives a Relay-reply message with an Interface-id option, the receives a Relay-reply message with an Interface-id option, the
relay agent forwards the message to the client through the interface relay agent forwards the message to the client through the interface
identified by the option. identified by the option.
The format of the Interface ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INTERFACE_ID | option-len | | OPTION_INTERFACE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. interface-id . . interface-id .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 73, line 15 skipping to change at page 74, line 15
by the relay agent to identify one of the by the relay agent to identify one of the
relay agent's interfaces relay agent's interfaces
The server MUST copy the Interface-Id option from the Relay-Forward The server MUST copy the Interface-Id option from the Relay-Forward
message into the Relay-Reply message the server sends to the relay message into the Relay-Reply message the server sends to the relay
agent in response to the Relay-Forward message. This option MUST NOT agent in response to the Relay-Forward message. This option MUST NOT
appear in any message except a Relay-Forward or Relay-Reply message. appear in any message except a Relay-Forward or Relay-Reply message.
Servers MAY use the Interface-ID for parameter assignment policies. Servers MAY use the Interface-ID for parameter assignment policies.
The Interface-ID SHOULD be considered an opaque value, with policies The Interface-ID SHOULD be considered an opaque value, with policies
based on exact string match only; that is, the Interface-ID SHOULD based on exact match only; that is, the Interface-ID SHOULD NOT be
NOT be internally parsed by the server. The Interface-ID value for internally parsed by the server. The Interface-ID value for an
an interface SHOULD be stable and remain unchanged, for example, interface SHOULD be stable and remain unchanged, for example, after
after the relay agent is restarted; if the Interface-ID changes, a the relay agent is restarted; if the Interface-ID changes, a server
server will not be able to use it reliably in parameter assignment will not be able to use it reliably in parameter assignment policies.
policies.
22.20. Reconfigure Message option 22.19. Reconfigure Message option
A server includes a Reconfigure Message option in a Reconfigure A server includes a Reconfigure Message option in a Reconfigure
message to indicate to the client whether the client responds with a message to indicate to the client whether the client responds with a
Renew message or an Information-request message. Renew message or an Information-request message. The format of this
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_MSG | option-len | | OPTION_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | | msg-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_MSG (19) option-code OPTION_RECONF_MSG (19)
option-len 1 option-len 1
msg-type 1 for Renew message, 2 for msg-type 5 for Renew message, 11 for
Information-request message Information-request message
22.21. Reconfigure Nonce option The Reconfigure Message option can only appear in a Reconfigure
message.
22.20. Reconfigure Nonce option
If a server uses a reconfigure nonce to provide security for If a server uses a reconfigure nonce to provide security for
Reconfigure messages, the server maintains a nonce value for each Reconfigure messages, the server maintains a nonce value for each
client. It initially informs the client of the nonce value and then client. It initially informs the client of the nonce value and then
includes the nonce value in any Reconfigure message sent to the includes the nonce value in any Reconfigure message sent to the
client. client.
The following figure gives the format of the Reconfigure Nonce The following figure gives the format of the Reconfigure Nonce
option: option:
skipping to change at page 74, line 18 skipping to change at page 75, line 21
| OPTION_RECONF_NONCE | option-len | | OPTION_RECONF_NONCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reconfigure-nonce | | reconfigure-nonce |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_NONCE (20) option-code OPTION_RECONF_NONCE (20)
option-len 8 option-len 8
reconfigure-nonce reconfigure nonce value sent to the client reconfigure-nonce reconfigure nonce value sent to the client;
the nonce MUST be a cryptographically strong
random number that cannot easily be guessed
or predicted.
The Reconfigure Nonce option MUST NOT appear in any DHCP message The Reconfigure Nonce option MUST NOT appear in any DHCP message
other than Reply or Reconfigure. other than Reply or Reconfigure.
23. Security Considerations 23. Security Considerations
Section 21 describes a threat model and an option that provides an Section 21 describes the DHCP threat model. The primary threat
authentication framework to defend against that threat model. to a DHCP client is the incorrect configuration of the client
through a DHCP exchange with a malicious DHCP server. The incorrect
configuration may present a denial of service attack by causing
communication with a service to fail, or a masquerade attack by
causing the client to communicate with a malicious server instead of
a valid server for some service such as DNS or NTP.
A DHCP server may be subject to a theft of service attack by a
malicious client representing itself as a valid client, or a denial
of service attack in which a malicious client exhausts the supply of
available addresses or consumes all of the computation resources or
network bandwidth available to the DHCP server.
A DHCP client may also be subject to attack through the receipt
of a Reconfigure message from a malicious server that causes the
client to obtain incorrect configuration information from that
server. Note that although a client sends its response (Renew or
Information-request message) through a relay agent and, therefore,
that response will only be received by servers to which DHCP messages
are forwarded, a malicious server could send a Reconfigure message to
a client, followed (after an appropriate delay) by a Reply message
that would be accepted by the client. Thus, a malicious server that
is not on the network path between the client and the server may
still be able to mount a Reconfigure attack on a client. The use of
transaction IDs that are cryptographically sound and cannot easily be
predicted will also reduce the probability that such an attack will
be successful.
DHCP authentication provides for authentication of the identity of
DHCP clients and servers, and for the integrity of messages delivered
between DHCP clients and servers. DHCP authentication does not
provide any privacy for the contents of DHCP messages.
The "delayed authentication" protocol described in section 21.5
uses a secret key that is shared between a client and a server and
does not attempt to address situations where a client may roam from
one administrative domain to another, i.e. interdomain roaming.
The use of shared keys may not scale well and does not provide for
repudiation of compromised keys. This protocol is focused on solving
the intradomain problem where the out-of-band exchange of a shared
key is feasible.
The Reconfigure Nonce option (see section 22.20) provides a way
for a client to confirm the identity of the server from which it
has received a Reconfigure message. The Reconfigure Nonce option
protects the client from attack by a malicious server that is not on
the network path from the server to the client; a malicious server
between the server and the client can read the nonce value sent
from the server to the client and spoof the server's identity in a
Reconfigure message.
Communication between a server and a relay agent can be secured
through the use of IPSec. The use of manual configuration and
installation of static keys are acceptable in this instance because
the relay agent and server will belong to the same administrative
domain and the relay agent will require other specific configuration
(for example, configuration of the DHCP server address) as well as
the IPSec configuration.
24. IANA Considerations 24. IANA Considerations
This document defines several new name spaces associated with DHCPv6 This document defines several new name spaces associated with DHCPv6
and DHCPv6 options: and DHCPv6 options:
- Multicast addresses
- Message types - Message types
- Option codes
- Status codes - Status codes
- DUID - DUID
- Authentication - Option codes
* Protocol
* Algorithm
* RDM
IANA is requested to manage a registry of values for each of these IANA is requested to manage a registry of values for each of these
name spaces, which are described in the remainder of this section. name spaces, which are described in the remainder of this section.
These name spaces are all to be managed separately from the name These name spaces are all to be managed separately from the name
spaces defined for DHCPv4 [4, 1]. spaces defined for DHCPv4 [5, 1].
New values in each of these name spaces except for DHCP option codes New multicast addresses, message types, status codes and DUID types
should be approved by the process of IETF consensus [12]. New DHCP are assigned via Standards Action [14].
option codes should be approved through expert review by a designated
expert [12]. New DHCP option codes are tentatively assigned after the
specification for the associated option, published as an Internet
Draft, has received expert review by a designated expert [14].
The final assignment of DHCP option codes is through Standards
Action [14].
This document also references three name spaces in section 21 that
are associated with the Authentication Option (section 22.11). These
name spaces are defined by the authentication mechanism for DHCPv4 in
RFC3118 [6].
The authentication name spaces currently registered by IANA will
apply to both DHCPv6 and DHCPv4. In the future, specifications that
define new Protocol, Algorithm and RDM mechanisms will explicitly
define whether the new mechanisms are used with DHCPv4, DHCPv6 or
both.
24.1. Multicast addresses 24.1. Multicast addresses
Section 5.1 defines the following multicast addresses, which have Section 5.1 defines the following multicast addresses, which have
been assigned by IANA for use by DHCPv6: been assigned by IANA for use by DHCPv6:
All_DHCP_Relay_Agents_and_Servers address: FF02::1:2 All_DHCP_Relay_Agents_and_Servers address: FF02::1:2
All_DHCP_Servers address: FF05::1:3 All_DHCP_Servers address: FF05::1:3
skipping to change at page 76, line 19 skipping to change at page 78, line 30
codes. codes.
OPTION_CLIENTID 1 OPTION_CLIENTID 1
OPTION_SERVERID 2 OPTION_SERVERID 2
OPTION_IA 3 OPTION_IA 3
OPTION_IA_TMP 4 OPTION_IA_TMP 4
OPTION_IADDR 5 OPTION_IAADDR 5
OPTION_ORO 6 OPTION_ORO 6
OPTION_PREFERENCE 7 OPTION_PREFERENCE 7
OPTION_ELAPSED_TIME 8 OPTION_ELAPSED_TIME 8
OPTION_CLIENT_MSG 9 OPTION_CLIENT_MSG 9
OPTION_SERVER_MSG 10 OPTION_SERVER_MSG 10
skipping to change at page 77, line 14 skipping to change at page 79, line 25
Name Code Description Name Code Description
---------- ---- ----------- ---------- ---- -----------
Success 0 Success Success 0 Success
UnspecFail 1 Failure, reason unspecified; this UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client status code is sent by either a client
or a server to indicate a failure or a server to indicate a failure
not explicitly specified in this not explicitly specified in this
document document
AuthFailed 2 Authentication failed or nonexistent AuthFailed 2 Authentication failed or nonexistent
AddrUnavail 3 Addresses unavailable AddrUnavail 3 Address unavailable
NoBinding 4 Client record (binding) unavailable NoAddrsAvail 4 Server has no addresses available to assign to
ConfNoMatch 5 Client record Confirm doesn't match IA the IA(s)
NotOnLink 6 One or more prefixes of the addresses NoBinding 5 Client record (binding) unavailable
in the IA is not valid for the link ConfNoMatch 6 Client record Confirm doesn't match IA
from which the client message was received NotOnLink 7 The prefix for the address is not appropriate to
UseMulticast 7 Sent by a server to a client to force the the link to which the client is attached
UseMulticast 8 Sent by a server to a client to force the
client to send messages to the server client to send messages to the server
using the All_DHCP_Relay_Agents_and_Servers using the All_DHCP_Relay_Agents_and_Servers
address address
24.5. DUID 24.5. DUID
IANA is requested to record the following DUID types (as defined in IANA is requested to record the following DUID types (as defined in
section 9.1). IANA is requested to manage definition of additional section 9.1). IANA is requested to manage definition of additional
DUID types in the future. DUID types in the future.
Link-layer address plus time 1 DUID-LLT 1
VUID-EN 2
Link-layer address 3
24.6. Authentication option
Section 21 references three name spaces associated with the DUID-EN 2
Authentication Option (section 22.12), which are defined in the
authentication mechanism for DHCPv4 [5].
The authentication name spaces currently registered by IANA will DUID-LL 3
apply to both DHCPv6 and DHCPv4. In the future, specifications that
define new Protocol, Algorithm and RDM mechanisms will explicitly
define whether the new mechanisms are used with DHCPv4, DHCPv6 or
both.
25. Acknowledgments 25. Acknowledgments
Thanks to the DHC Working Group and the members of the IETF for Thanks to the DHC Working Group and the members of the IETF for
their time and input into the specification. In particular, thanks their time and input into the specification. In particular, thanks
also for the consistent input, ideas, and review by (in alphabetical also for the consistent input, ideas, and review by (in alphabetical
order) Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, Vijayabhaskar, order) Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, A. K.
Brian Carpenter, Matt Crawford, Francis Dupont, Tony Lindstrom, Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont, Tony
Josh Littlefield, Gerald Maguire, Jack McCann, Thomas Narten, Erik Lindstrom, Josh Littlefield, Gerald Maguire, Jack McCann, Thomas
Nordmark, Yakov Rekhter, Mark Stapp, Matt Thomas, Sue Thomson, and Narten, Erik Nordmark, Yakov Rekhter, Mark Stapp, Matt Thomas, Sue
Phil Wells. Thomson, Tatuya Jinmei and Phil Wells.
Thanks to Steve Deering and Bob Hinden, who have consistently Thanks to Steve Deering and Bob Hinden, who have consistently
taken the time to discuss the more complex parts of the IPv6 taken the time to discuss the more complex parts of the IPv6
specifications. specifications.
And, thanks to Steve Deering for pointing out at IETF 51 in London And, thanks to Steve Deering for pointing out at IETF 51 in London
that the DHCPv6 specification has the highest revision number of any that the DHCPv6 specification has the highest revision number of any
Internet Draft. Internet Draft.
26. Changes in draft-ietf-dhc-dhcpv6-25.txt 26. Changes in draft-ietf-dhc-dhcpv6-25.txt
skipping to change at page 79, line 38 skipping to change at page 81, line 38
- Removed replay detection information field from Solicit message - Removed replay detection information field from Solicit message
to avoid potential DOS attack. to avoid potential DOS attack.
- Clarified capabilities and constraints on relay agent forwarding. - Clarified capabilities and constraints on relay agent forwarding.
- Edited definition of vendor class data to clarify that instances - Edited definition of vendor class data to clarify that instances
of vendor-class-data are individual characteristics of the of vendor-class-data are individual characteristics of the
client. client.
- Added text in section 21.5.4 to specify that client key is - Added text in section 21.5.3 to specify that client key is
identified by client DUID. identified by client DUID.
- Removed "Year 2000 Considerations" section; hope we don't need a - Removed "Year 2000 Considerations" section; hope we don't need a
"Year 3000 Consideration" section. "Year 3000 Consideration" section.
- Authentication mechanism now shares Protocol, Algorithm and RDM - Authentication mechanism now shares Protocol, Algorithm and RDM
name spaces with DHCPv4. name spaces with DHCPv4.
- Added text to specify return of NoBinding if server cannot - Added text to specify return of NoBinding if server cannot
find binding for IA in Decline; added text allowing client to find binding for IA in Decline; added text allowing client to
disregard NoBinding in Reply to Decline. disregard NoBinding in Reply to Decline.
- Clarify that Solicit, Confirm and Rebind are invalid if Server - Clarified that Solicit, Confirm and Rebind are invalid if Server
Identifier option is included. Identifier option is included.
- Edited text about Option Request option to clarify that the - Edited text about Option Request option to clarify that the
option is a hint from the client to the server about options the option is a hint from the client to the server about options the
client has a preference to receive; includes recommendation that client has a preference to receive; includes recommendation that
client send Option Request option if it has options it requires. client send Option Request option if it has options it requires.
- Added nonce value for security of Reconfigure messages. - Added nonce value for security of Reconfigure messages.
27. Changes in draft-ietf-dhc-dhcpv6-26.txt
- Clarified section 18.1.1 to allow Request message to be sent at
any time.
- Fixed Reconfigure Message option so that msg-type field is one
octet and uses the DHCP message code to indicate which message
the client sends back to the server.
- Added text anticipating description of how to emulate multicast
in specific "IPv6 over X" documents.
- Reconfigure message now requires Client Identifier option with
receiving client's DUID.
- Added text to allow a relay agent to forward a message from a
client to another relay agent as well as to a server. Added text
in authentication section specifying use of IPSec between relay
agents and servers for message security.
- Fixed definition of "binding" to allow a binding with no IAs to
be indexed by just <DUID>.
- Clarified text in section 17.2.2 to explain that AddrUnavail is
returned only if the Solicit message from the client included one
or more IA options.
- Edited text about Option Request option to clarify that the
client is required to include the option and to identify all
options the client has a preference to receive; also clarified
that a server may include additional options if the server is
configured to do so.
- Added text explaining why DHCPv6 and DHCPv4 are not integrated in
this document.
- Changed use of Confirm so that server simply checks whether
addresses are appropriate to link to which client is attached.
- Expanded Security Considerations section to give more detail on
threat model and limitations to authentication.
- Client now restarts with server solicitation when server returns
NotOnLink to Confirm message.
- Modified several retransmission parameters (in section 5.5) for
consistency and anticipated operation.
- Defined "appropriate to the link" and changed "valid on the link"
to "appropriate to the link" throughout for clarity
- Added text requiring transaction IDs to be not predictable and
described potential attack in security considerations
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, March 1997. RFC 2132. Extensions, March 1997. RFC 2132.
[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, March 1997. RFC 2119. Levels, March 1997. RFC 2119.
[3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [3] M. Crawford. Transmission of IPv6 Packets over Ethernet
Networks, December 1998. RFC 2464.
[4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification, December 1998. RFC 2460. Specification, December 1998. RFC 2460.
[4] R. Droms. Dynamic Host Configuration Protocol, March 1997. RFC [5] R. Droms. Dynamic Host Configuration Protocol, March 1997. RFC
2131. 2131.
[5] R. Droms, Editor, W. Arbaugh, and Editor. Authentication for [6] R. Droms, Editor, W. Arbaugh, and Editor. Authentication for
DHCP Messages, June 2001. RFC 3118. DHCP Messages, June 2001. RFC 3118.
[6] R. Hinden and S. Deering. IP Version 6 Addressing Architecture, [7] R. (ed.) Droms. DNS Configuration options for DHCPv6. Internet
Draft, Internet Engineering Task Force, April 2002. Work in
progress.
[8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture,
July 1998. RFC 2373. July 1998. RFC 2373.
[7] IANA. Private Enterprise Numbers. [9] IANA. Private Enterprise Numbers.
http://www.iana.org/assignments/enterprise-numbers. http://www.iana.org/assignments/enterprise-numbers.
[8] S. Kent and R. Atkinson. Security Architecture for the Internet [10] S. Kent and R. Atkinson. Security Architecture for the Internet
Protocol, November 1998. RFC 2401. Protocol, November 1998. RFC 2401.
[9] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing [11] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
for Message Authentication, February 1997. RFC 2104. for Message Authentication, February 1997. RFC 2104.
[10] David L. Mills. Network Time Protocol (Version 3) [12] David L. Mills. Network Time Protocol (Version 3)
Specification, Implementation, March 1992. RFC 1305. Specification, Implementation, March 1992. RFC 1305.
[11] P.V. Mockapetris. Domain names - implementation and [13] P.V. Mockapetris. Domain names - implementation and
specification, November 1987. RFC 1035. specification, November 1987. RFC 1035.
[12] T. Narten and H. Alvestrand. Guidelines for Writing an IANA [14] T. Narten and H. Alvestrand. Guidelines for Writing an IANA
Considerations Section in RFCs, October 1998. RFC 2434. Considerations Section in RFCs, October 1998. RFC 2434.
[13] T. Narten and R. Draves. Privacy Extensions for Stateless [15] T. Narten and R. Draves. Privacy Extensions for Stateless
Address Autoconfiguration in IPv6, January 2001. RFC 3041. Address Autoconfiguration in IPv6, January 2001. RFC 3041.
[14] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for [16] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6), December 1998. RFC 2461. IP Version 6 (IPv6), December 1998. RFC 2461.
[15] D.C. Plummer. Ethernet Address Resolution Protocol: Or [17] 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, November 1982. RFC 826. for transmission on Ethernet hardware, November 1982. RFC 826.
[16] J. Postel. User Datagram Protocol, August 1980. RFC 768. [18] J. Postel. User Datagram Protocol, August 1980. RFC 768.
[17] R. Rivest. The MD5 Message-Digest Algorithm, April 1992. RFC [19] R. Rivest. The MD5 Message-Digest Algorithm, April 1992. RFC
1321. 1321.
[18] S. Thomson and T. Narten. IPv6 Stateless Address [20] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration, December 1998. RFC 2462. Autoconfiguration, December 1998. RFC 2462.
[19] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic [21] A. K. Vijayabhaskar. Time Configuration Options for DHCPv6.
Internet Draft, Internet Engineering Task Force, May 2002. Work
in progress.
[22] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic
Updates in the Domain Name System (DNS UPDATE), April 1997. RFC Updates in the Domain Name System (DNS UPDATE), April 1997. RFC
2136. 2136.
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
300 Apollo Drive 300 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-4733 Phone: (978) 244-4733
E-mail: rdroms@cisco.com E-mail: rdroms@cisco.com
Authors' Addresses Authors' Addresses
Questions about this memo can be directed to: Questions about this document can be directed to:
Jim Bound Jim Bound
Hewlett Packard Corporation Hewlett Packard Corporation
ZK3-3/W20 ZK3-3/W20
110 Spit Brook Road 110 Spit Brook Road
Nashua, NH 03062-2698 Nashua, NH 03062-2698
USA USA
Voice: +1 603 884 0062 Voice: +1 603 884 0062
E-mail: Jim.Bound@hp.com E-mail: Jim.Bound@hp.com
Mike Carney Bernie Volz
Sun Microsystems, Inc Ericsson
Mail Stop: UMPK17-202 959 Concord St
901 San Antonio Road Framingham, MA 01701
Palo Alto, CA 94303-4900
USA USA
Voice: +1-650-786-4171 Voice: +1-508-875-3162
E-mail: mwc@eng.sun.com E-mail: bernie.volz@ericsson.com
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
USA
E-mail: Ted.Lemon@nominum.com
Charles E. Perkins Charles E. Perkins
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Voice: +1-650 625-2986 Voice: +1-650 625-2986
E-mail: charliep@iprg.nokia.com E-mail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
Ted Lemon Mike Carney
Nominum, Inc. Sun Microsystems, Inc
950 Charter Street Mail Stop: UMPK17-202
Redwood City, CA 94043 901 San Antonio Road
E-mail: Ted.Lemon@nominum.com Palo Alto, CA 94303-4900
Bernie Volz
Ericsson
959 Concord St
Framingham, MA 01701
Voice: +1-508-875-3162
Fax: +1-508-875-3018
E-mail: bernie.volz@ericsson.com
Ralph Droms
Cisco Systems
300 Apollo Drive
Chelmsford, MA 01824
USA USA
Voice: +1 978 479 4733 Voice: +1-650-786-4171
E-mail: rdroms@cisco.com E-mail: mwc@eng.sun.com
A. Appearance of Options in Message Types A. Appearance of Options in Message Types
The following table indicates with a "*" the options are allowed in The following table indicates with a "*" the options are allowed in
each DHCP message type: each DHCP message type:
Client Server IA/ Option Pref Time Client Server Client Server IA/ Option Pref Time Client Server
ID ID IA_TA Request Msg. Msg. ID ID IA_TA Request Msg. Msg.
Solicit * * * * Solicit * * * *
Advert. * * * * * Advert. * * * * *
skipping to change at page 83, line 29 skipping to change at page 86, line 29
Release * * * * * Release * * * * *
Reply * * * * * Reply * * * * *
Reconf. * * * Reconf. * * *
Inform. * (see no