Network Working Group R. Droms, Ed.
Request for Comments: 3315 Cisco
Category: Standards Track J. Bound
Hewlett Packard
B. Volz
Ericsson
T. Lemon
Nominum
C. Perkins
Nokia Research Center
M. Carney
Sun Microsystems
July 2003
Network Working Group R. Droms, Ed.
Request for Comments: 3315 Cisco
Category: Standards Track J. Bound
Hewlett Packard
B. Volz
Ericsson
T. Lemon
Nominum
C. Perkins
Nokia Research Center
M. Carney
Sun Microsystems
July 2003
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IPv6的动态主机配置协议（DHCPv6）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters.
IPv6动态主机配置协议（DHCP）使DHCP服务器能够将配置参数（如IPv6网络地址）传递给IPv6节点。它提供了自动分配可重复使用的网络地址的能力和额外的配置灵活性。该协议是“IPv6无状态地址自动配置”（RFC 2462）的有状态对应协议，可单独使用或与后者同时使用以获取配置参数。
Table of Contents
目录
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5
1.1. Protocols and Addressing . . . . . . . . . . . . . . . 6
1.2. Client-server Exchanges Involving Two Messages . . . . 6
1.3. Client-server Exchanges Involving Four Messages. . . . 7
2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Background. . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . 9
4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . 10
5. DHCP Constants. . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 13
5.2. UDP Ports. . . . . . . . . . . . . . . . . . . . . . . 13
5.3. DHCP Message Types . . . . . . . . . . . . . . . . . . 13
5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 15
5.5. Transmission and Retransmission Parameters . . . . . . 16
5.6 Representation of time values and "Infinity" as a time
value. . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Client/Server Message Formats . . . . . . . . . . . . . . . . 16
7. Relay Agent/Server Message Formats. . . . . . . . . . . . . . 17
7.1. Relay-forward Message. . . . . . . . . . . . . . . . . 18
7.2. Relay-reply Message. . . . . . . . . . . . . . . . . . 19
8. Representation and Use of Domain Names. . . . . . . . . . . . 19
9. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 19
9.1. DUID Contents. . . . . . . . . . . . . . . . . . . . . 20
9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]. 20
9.3. DUID Assigned by Vendor Based on Enterprise Number
[DUID-EN]. . . . . . . . . . . . . . . . . . . . . . . 22
9.4. DUID Based on Link-layer Address [DUID-LL] . . . . . . 22
10. Identity Association. . . . . . . . . . . . . . . . . . . . . 23
11. Selecting Addresses for Assignment to an IA . . . . . . . . . 24
12. Management of Temporary Addresses . . . . . . . . . . . . . . 25
13. Transmission of Messages by a Client. . . . . . . . . . . . . 25
14. Reliability of Client Initiated Message Exchanges . . . . . . 26
15. Message Validation. . . . . . . . . . . . . . . . . . . . . . 27
15.1. Use of Transaction IDs . . . . . . . . . . . . . . . . 28
15.2. Solicit Message. . . . . . . . . . . . . . . . . . . . 28
15.3. Advertise Message. . . . . . . . . . . . . . . . . . . 28
15.4. Request Message. . . . . . . . . . . . . . . . . . . . 29
15.5. Confirm Message. . . . . . . . . . . . . . . . . . . . 29
15.6. Renew Message. . . . . . . . . . . . . . . . . . . . . 29
15.7. Rebind Message . . . . . . . . . . . . . . . . . . . . 29
15.8. Decline Messages . . . . . . . . . . . . . . . . . . . 30
15.9. Release Message. . . . . . . . . . . . . . . . . . . . 30
15.10. Reply Message. . . . . . . . . . . . . . . . . . . . . 30
15.11. Reconfigure Message. . . . . . . . . . . . . . . . . . 31
15.12. Information-request Message. . . . . . . . . . . . . . 31
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5
1.1. Protocols and Addressing . . . . . . . . . . . . . . . 6
1.2. Client-server Exchanges Involving Two Messages . . . . 6
1.3. Client-server Exchanges Involving Four Messages. . . . 7
2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Background. . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . 9
4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . 10
5. DHCP Constants. . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 13
5.2. UDP Ports. . . . . . . . . . . . . . . . . . . . . . . 13
5.3. DHCP Message Types . . . . . . . . . . . . . . . . . . 13
5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 15
5.5. Transmission and Retransmission Parameters . . . . . . 16
5.6 Representation of time values and "Infinity" as a time
value. . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Client/Server Message Formats . . . . . . . . . . . . . . . . 16
7. Relay Agent/Server Message Formats. . . . . . . . . . . . . . 17
7.1. Relay-forward Message. . . . . . . . . . . . . . . . . 18
7.2. Relay-reply Message. . . . . . . . . . . . . . . . . . 19
8. Representation and Use of Domain Names. . . . . . . . . . . . 19
9. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 19
9.1. DUID Contents. . . . . . . . . . . . . . . . . . . . . 20
9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]. 20
9.3. DUID Assigned by Vendor Based on Enterprise Number
[DUID-EN]. . . . . . . . . . . . . . . . . . . . . . . 22
9.4. DUID Based on Link-layer Address [DUID-LL] . . . . . . 22
10. Identity Association. . . . . . . . . . . . . . . . . . . . . 23
11. Selecting Addresses for Assignment to an IA . . . . . . . . . 24
12. Management of Temporary Addresses . . . . . . . . . . . . . . 25
13. Transmission of Messages by a Client. . . . . . . . . . . . . 25
14. Reliability of Client Initiated Message Exchanges . . . . . . 26
15. Message Validation. . . . . . . . . . . . . . . . . . . . . . 27
15.1. Use of Transaction IDs . . . . . . . . . . . . . . . . 28
15.2. Solicit Message. . . . . . . . . . . . . . . . . . . . 28
15.3. Advertise Message. . . . . . . . . . . . . . . . . . . 28
15.4. Request Message. . . . . . . . . . . . . . . . . . . . 29
15.5. Confirm Message. . . . . . . . . . . . . . . . . . . . 29
15.6. Renew Message. . . . . . . . . . . . . . . . . . . . . 29
15.7. Rebind Message . . . . . . . . . . . . . . . . . . . . 29
15.8. Decline Messages . . . . . . . . . . . . . . . . . . . 30
15.9. Release Message. . . . . . . . . . . . . . . . . . . . 30
15.10. Reply Message. . . . . . . . . . . . . . . . . . . . . 30
15.11. Reconfigure Message. . . . . . . . . . . . . . . . . . 31
15.12. Information-request Message. . . . . . . . . . . . . . 31
15.13. Relay-forward Message. . . . . . . . . . . . . . . . . 31
15.14. Relay-reply Message. . . . . . . . . . . . . . . . . . 31
16. Client Source Address and Interface Selection . . . . . . . . 32
17. DHCP Server Solicitation. . . . . . . . . . . . . . . . . . . 32
17.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 32
17.1.1. Creation of Solicit Messages . . . . . . . . . 32
17.1.2. Transmission of Solicit Messages . . . . . . . 33
17.1.3. Receipt of Advertise Messages. . . . . . . . . 35
17.1.4. Receipt of Reply Message . . . . . . . . . . . 35
17.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 36
17.2.1. Receipt of Solicit Messages . . . . . . . . . 36
17.2.2. Creation and Transmission of Advertise Messages 36
17.2.3. Creation and Transmission of Reply Messages. . 38
18. DHCP Client-Initiated Configuration Exchange. . . . . . . . . 38
18.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 39
18.1.1. Creation and Transmission of Request Messages. 39
18.1.2. Creation and Transmission of Confirm Messages. 40
18.1.3. Creation and Transmission of Renew Messages. . 41
18.1.4. Creation and Transmission of Rebind Messages . 43
18.1.5. Creation and Transmission of Information-
request Messages . . .. . . . . . . . . . . . 44
18.1.6. Creation and Transmission of Release Messages. 44
18.1.7. Creation and Transmission of Decline Messages. 46
18.1.8. Receipt of Reply Messages. . . . . . . . . . . 46
18.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 48
18.2.1. Receipt of Request Messages. . . . . . . . . . 49
18.2.2. Receipt of Confirm Messages. . . . . . . . . . 50
18.2.3. Receipt of Renew Messages. . . . . . . . . . . 51
18.2.4. Receipt of Rebind Messages . . . . . . . . . . 51
18.2.5. Receipt of Information-request Messages. . . . 52
18.2.6. Receipt of Release Messages. . . . . . . . . . 53
18.2.7. Receipt of Decline Messages. . . . . . . . . . 53
18.2.8. Transmission of Reply Messages . . . . . . . . 54
19. DHCP Server-Initiated Configuration Exchange. . . . . . . . . 54
19.1. Server Behavior. . . . . . . . . . . . . . . . . . . . 55
19.1.1. Creation and Transmission of Reconfigure
Messages . . . . . . . . . . . . . . . . . . . 55
19.1.2. Time Out and Retransmission of Reconfigure
Messages . . . . . . . . . . . . . . . . . . . 56
19.2. Receipt of Renew Messages. . . . . . . . . . . . . . . 56
19.3. Receipt of Information-request Messages. . . . . . . . 56
19.4. Client Behavior. . . . . . . . . . . . . . . . . . . . 57
19.4.1. Receipt of Reconfigure Messages. . . . . . . . 57
19.4.2. Creation and Transmission of Renew Messages. . 58
19.4.3. Creation and Transmission of Information-
request Messages . . . . . . . . . . . . . . . 58
19.4.4. Time Out and Retransmission of Renew or
Information-request Messages . . . . . . . . . 58
15.13. Relay-forward Message. . . . . . . . . . . . . . . . . 31
15.14. Relay-reply Message. . . . . . . . . . . . . . . . . . 31
16. Client Source Address and Interface Selection . . . . . . . . 32
17. DHCP Server Solicitation. . . . . . . . . . . . . . . . . . . 32
17.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 32
17.1.1. Creation of Solicit Messages . . . . . . . . . 32
17.1.2. Transmission of Solicit Messages . . . . . . . 33
17.1.3. Receipt of Advertise Messages. . . . . . . . . 35
17.1.4. Receipt of Reply Message . . . . . . . . . . . 35
17.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 36
17.2.1. Receipt of Solicit Messages . . . . . . . . . 36
17.2.2. Creation and Transmission of Advertise Messages 36
17.2.3. Creation and Transmission of Reply Messages. . 38
18. DHCP Client-Initiated Configuration Exchange. . . . . . . . . 38
18.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 39
18.1.1. Creation and Transmission of Request Messages. 39
18.1.2. Creation and Transmission of Confirm Messages. 40
18.1.3. Creation and Transmission of Renew Messages. . 41
18.1.4. Creation and Transmission of Rebind Messages . 43
18.1.5. Creation and Transmission of Information-
request Messages . . .. . . . . . . . . . . . 44
18.1.6. Creation and Transmission of Release Messages. 44
18.1.7. Creation and Transmission of Decline Messages. 46
18.1.8. Receipt of Reply Messages. . . . . . . . . . . 46
18.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 48
18.2.1. Receipt of Request Messages. . . . . . . . . . 49
18.2.2. Receipt of Confirm Messages. . . . . . . . . . 50
18.2.3. Receipt of Renew Messages. . . . . . . . . . . 51
18.2.4. Receipt of Rebind Messages . . . . . . . . . . 51
18.2.5. Receipt of Information-request Messages. . . . 52
18.2.6. Receipt of Release Messages. . . . . . . . . . 53
18.2.7. Receipt of Decline Messages. . . . . . . . . . 53
18.2.8. Transmission of Reply Messages . . . . . . . . 54
19. DHCP Server-Initiated Configuration Exchange. . . . . . . . . 54
19.1. Server Behavior. . . . . . . . . . . . . . . . . . . . 55
19.1.1. Creation and Transmission of Reconfigure
Messages . . . . . . . . . . . . . . . . . . . 55
19.1.2. Time Out and Retransmission of Reconfigure
Messages . . . . . . . . . . . . . . . . . . . 56
19.2. Receipt of Renew Messages. . . . . . . . . . . . . . . 56
19.3. Receipt of Information-request Messages. . . . . . . . 56
19.4. Client Behavior. . . . . . . . . . . . . . . . . . . . 57
19.4.1. Receipt of Reconfigure Messages. . . . . . . . 57
19.4.2. Creation and Transmission of Renew Messages. . 58
19.4.3. Creation and Transmission of Information-
request Messages . . . . . . . . . . . . . . . 58
19.4.4. Time Out and Retransmission of Renew or
Information-request Messages . . . . . . . . . 58
19.4.5. Receipt of Reply Messages. . . . . . . . . . . 58
20. Relay Agent Behavior. . . . . . . . . . . . . . . . . . . . . 58
20.1. Relaying a Client Message or a Relay-forward Message . 59
20.1.1. Relaying a Message from a Client . . . . . . . 59
20.1.2. Relaying a Message from a Relay Agent. . . . . 59
20.2. Relaying a Relay-reply Message . . . . . . . . . . . . 60
20.3. Construction of Relay-reply Messages . . . . . . . . . 60
21. Authentication of DHCP Messages . . . . . . . . . . . . . . . 61
21.1. Security of Messages Sent Between Servers and Relay
Agents . . . . . . . . . . . . . . . . . . . . . . . 61
21.2. Summary of DHCP Authentication . . . . . . . . . . . . 63
21.3. Replay Detection . . . . . . . . . . . . . . . . . . . 63
21.4. Delayed Authentication Protocol. . . . . . . . . . . . 63
21.4.1. Use of the Authentication Option in the Delayed
Authentication Protocol. . . . . . . . . . . . 64
21.4.2. Message Validation . . . . . . . . . . . . . . 65
21.4.3. Key Utilization . . . . . . . . . . . . . . . 65
21.4.4. Client Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . . 66
21.4.5. Server Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . . 67
21.5. Reconfigure Key Authentication Protocol. . . . . . . . 68
21.5.1. Use of the Authentication Option in the
Reconfigure Key Authentication Protocol. . . . 69
21.5.2. Server considerations for Reconfigure Key
protocol . . . . . . . . . . . . . . . . . . . 69
21.5.3. Client considerations for Reconfigure Key
protocol . . . . . . . . . . . . . . . . . . . 70
22. DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . . 70
22.1. Format of DHCP Options . . . . . . . . . . . . . . . . 71
22.2. Client Identifier Option . . . . . . . . . . . . . . . 71
22.3. Server Identifier Option . . . . . . . . . . . . . . . 72
22.4. Identity Association for Non-temporary Addresses Option 72
22.5. Identity Association for Temporary Addresses Option. . 75
22.6. IA Address Option. . . . . . . . . . . . . . . . . . . 76
22.7. Option Request Option. . . . . . . . . . . . . . . . . 78
22.8. Preference Option. . . . . . . . . . . . . . . . . . . 79
22.9. Elapsed Time Option. . . . . . . . . . . . . . . . . . 79
22.10. Relay Message Option . . . . . . . . . . . . . . . . . 80
22.11. Authentication Option. . . . . . . . . . . . . . . . . 81
22.12. Server Unicast Option. . . . . . . . . . . . . . . . . 82
22.13. Status Code Option . . . . . . . . . . . . . . . . . . 82
22.14. Rapid Commit Option. . . . . . . . . . . . . . . . . . 83
22.15. User Class Option. . . . . . . . . . . . . . . . . . . 84
22.16. Vendor Class Option. . . . . . . . . . . . . . . . . . 85
22.17. Vendor-specific Information Option . . . . . . . . . . 86
22.18. Interface-Id Option. . . . . . . . . . . . . . . . . . 87
22.19. Reconfigure Message Option . . . . . . . . . . . . . . 88
19.4.5. Receipt of Reply Messages. . . . . . . . . . . 58
20. Relay Agent Behavior. . . . . . . . . . . . . . . . . . . . . 58
20.1. Relaying a Client Message or a Relay-forward Message . 59
20.1.1. Relaying a Message from a Client . . . . . . . 59
20.1.2. Relaying a Message from a Relay Agent. . . . . 59
20.2. Relaying a Relay-reply Message . . . . . . . . . . . . 60
20.3. Construction of Relay-reply Messages . . . . . . . . . 60
21. Authentication of DHCP Messages . . . . . . . . . . . . . . . 61
21.1. Security of Messages Sent Between Servers and Relay
Agents . . . . . . . . . . . . . . . . . . . . . . . 61
21.2. Summary of DHCP Authentication . . . . . . . . . . . . 63
21.3. Replay Detection . . . . . . . . . . . . . . . . . . . 63
21.4. Delayed Authentication Protocol. . . . . . . . . . . . 63
21.4.1. Use of the Authentication Option in the Delayed
Authentication Protocol. . . . . . . . . . . . 64
21.4.2. Message Validation . . . . . . . . . . . . . . 65
21.4.3. Key Utilization . . . . . . . . . . . . . . . 65
21.4.4. Client Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . . 66
21.4.5. Server Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . . 67
21.5. Reconfigure Key Authentication Protocol. . . . . . . . 68
21.5.1. Use of the Authentication Option in the
Reconfigure Key Authentication Protocol. . . . 69
21.5.2. Server considerations for Reconfigure Key
protocol . . . . . . . . . . . . . . . . . . . 69
21.5.3. Client considerations for Reconfigure Key
protocol . . . . . . . . . . . . . . . . . . . 70
22. DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . . 70
22.1. Format of DHCP Options . . . . . . . . . . . . . . . . 71
22.2. Client Identifier Option . . . . . . . . . . . . . . . 71
22.3. Server Identifier Option . . . . . . . . . . . . . . . 72
22.4. Identity Association for Non-temporary Addresses Option 72
22.5. Identity Association for Temporary Addresses Option. . 75
22.6. IA Address Option. . . . . . . . . . . . . . . . . . . 76
22.7. Option Request Option. . . . . . . . . . . . . . . . . 78
22.8. Preference Option. . . . . . . . . . . . . . . . . . . 79
22.9. Elapsed Time Option. . . . . . . . . . . . . . . . . . 79
22.10. Relay Message Option . . . . . . . . . . . . . . . . . 80
22.11. Authentication Option. . . . . . . . . . . . . . . . . 81
22.12. Server Unicast Option. . . . . . . . . . . . . . . . . 82
22.13. Status Code Option . . . . . . . . . . . . . . . . . . 82
22.14. Rapid Commit Option. . . . . . . . . . . . . . . . . . 83
22.15. User Class Option. . . . . . . . . . . . . . . . . . . 84
22.16. Vendor Class Option. . . . . . . . . . . . . . . . . . 85
22.17. Vendor-specific Information Option . . . . . . . . . . 86
22.18. Interface-Id Option. . . . . . . . . . . . . . . . . . 87
22.19. Reconfigure Message Option . . . . . . . . . . . . . . 88
22.20. Reconfigure Accept Option. . . . . . . . . . . . . . . 89
23. Security Considerations . . . . . . . . . . . . . . . . . . . 89
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
24.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 92
24.2. DHCP Message Types . . . . . . . . . . . . . . . . . . 93
24.3. DHCP Options . . . . . . . . . . . . . . . . . . . . . 94
24.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 95
24.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . 95
25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95
26. References. . . . . . . . . . . . . . . . . . . . . . . . . . 96
26.1. Normative References . . . . . . . . . . . . . . . . . 96
26.2. Informative References . . . . . . . . . . . . . . . . 97
A. Appearance of Options in Message Types . . . . . . . . . . . . 98
B. Appearance of Options in the Options Field of DHCP Options . . 99
Chair's Address . . . . . . . . . . . . . . . . . . . . . . . . . 99
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 100
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 101
22.20. Reconfigure Accept Option. . . . . . . . . . . . . . . 89
23. Security Considerations . . . . . . . . . . . . . . . . . . . 89
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
24.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 92
24.2. DHCP Message Types . . . . . . . . . . . . . . . . . . 93
24.3. DHCP Options . . . . . . . . . . . . . . . . . . . . . 94
24.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 95
24.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . 95
25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95
26. References. . . . . . . . . . . . . . . . . . . . . . . . . . 96
26.1. Normative References . . . . . . . . . . . . . . . . . 96
26.2. Informative References . . . . . . . . . . . . . . . . 97
A. Appearance of Options in Message Types . . . . . . . . . . . . 98
B. Appearance of Options in the Options Field of DHCP Options . . 99
Chair's Address . . . . . . . . . . . . . . . . . . . . . . . . . 99
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 100
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 101
This document describes DHCP for IPv6 (DHCP), a client/server protocol that provides managed configuration of devices.
本文档介绍DHCP for IPv6（DHCP），这是一种提供设备托管配置的客户端/服务器协议。
DHCP can provide a device with addresses assigned by a DHCP server and other configuration information, which are carried in options. DHCP can be extended through the definition of new options to carry configuration information not specified in this document.
DHCP可以为设备提供由DHCP服务器分配的地址和其他配置信息，这些信息在选项中提供。DHCP可以通过定义新选项来扩展，以携带本文档中未指定的配置信息。
DHCP is the "stateful address autoconfiguration protocol" and the "stateful autoconfiguration protocol" referred to in "IPv6 Stateless Address Autoconfiguration" [17].
DHCP是“有状态地址自动配置协议”和“IPv6无状态地址自动配置”中提到的“有状态自动配置协议”[17]。
The operational models and relevant configuration information for DHCPv4 [18][19] 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.
DHCPv4[18][19]和DHCPv6的操作模型和相关配置信息完全不同，因此本文档中不包括两种服务之间的集成。如果有足够的兴趣和需求，可以在扩展DHCPv6以承载IPv4地址和配置信息的文档中指定集成。
The remainder of this introduction summarizes DHCP, explaining the message exchange mechanisms and example message flows. The message flows in sections 1.2 and 1.3 are intended as illustrations of DHCP operation rather than an exhaustive list of all possible client-server interactions. Sections 17, 18, and 19 explain client and server operation in detail.
本简介的其余部分总结了DHCP，解释了消息交换机制和示例消息流。第1.2节和第1.3节中的消息流旨在说明DHCP操作，而不是所有可能的客户机-服务器交互的详尽列表。第17、18和19节详细解释了客户机和服务器的操作。
Clients and servers exchange DHCP messages using UDP [15]. The client uses a link-local address or addresses determined through other mechanisms for transmitting and receiving DHCP messages.
客户端和服务器使用UDP交换DHCP消息[15]。客户端使用链路本地地址或通过其他机制确定的地址来发送和接收DHCP消息。
DHCP servers receive messages from clients using a reserved, link-scoped multicast address. A DHCP client transmits most messages to this reserved multicast address, so that the client need not be configured with the address or addresses of DHCP servers.
DHCP服务器使用保留的、链接范围的多播地址从客户端接收消息。DHCP客户端将大多数消息传输到此保留的多播地址，因此客户端无需配置DHCP服务器的一个或多个地址。
To allow a DHCP client to send a message to a DHCP server that is not attached to the same link, a DHCP relay agent on the client's link will relay messages between the client and server. The operation of the relay agent is transparent to the client and the discussion of message exchanges in the remainder of this section will omit the description of message relaying by relay agents.
要允许DHCP客户端向未连接到同一链路的DHCP服务器发送消息，客户端链路上的DHCP中继代理将在客户端和服务器之间中继消息。中继代理的操作对客户端是透明的，本节剩余部分中对消息交换的讨论将省略对中继代理的消息中继的描述。
Once the client has determined the address of a server, it may under some circumstances send messages directly to the server using unicast.
一旦客户机确定了服务器的地址，在某些情况下，它可能会使用单播直接向服务器发送消息。
When a DHCP client does not need to have a DHCP server assign it IP addresses, the client can obtain configuration information such as a list of available DNS servers [20] or NTP servers [21] through a single message and reply exchanged with a DHCP server. To obtain configuration information the client first sends an Information-Request message to the All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond with a Reply message containing the configuration information for the client.
当DHCP客户端不需要DHCP服务器为其分配IP地址时，客户端可以通过单个消息和与DHCP服务器交换的应答来获取配置信息，例如可用DNS服务器[20]或NTP服务器[21]的列表。要获取配置信息，客户端首先向所有\u DHCP\u中继\u代理\u和\u服务器多播地址发送信息请求消息。服务器通过包含客户端配置信息的回复消息进行响应。
This message exchange assumes that the client requires only configuration information and does not require the assignment of any IPv6 addresses.
此消息交换假定客户端只需要配置信息，而不需要分配任何IPv6地址。
When a server has IPv6 addresses and other configuration information committed to a client, the client and server may be able to complete the exchange using only two messages, instead of four messages as described in the next section. In this case, the client sends a Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting the assignment of addresses and other configuration information. This message includes an indication that the client is willing to accept an immediate Reply message from the server. The server that is willing to commit the assignment of addresses to the client
当服务器具有提交给客户端的IPv6地址和其他配置信息时，客户端和服务器可能仅使用两条消息即可完成交换，而不是下一节所述的四条消息。在这种情况下，客户端向所有的DHCP中继代理和服务器发送请求消息，请求分配地址和其他配置信息。此消息包括客户端愿意接受来自服务器的即时回复消息的指示。愿意向客户端提交地址分配的服务器
immediately responds with a Reply message. The configuration information and the addresses in the Reply message are then immediately available for use by the client.
立即回复信息。然后，回复消息中的配置信息和地址立即可供客户端使用。
Each address assigned to the client has associated preferred and valid lifetimes specified by the server. To request an extension of the lifetimes assigned to an address, the client sends a Renew message to the server. The server sends a Reply message to the client with the new lifetimes, allowing the client to continue to use the address without interruption.
分配给客户机的每个地址都有服务器指定的相关首选和有效生存期。要请求延长分配给地址的生命周期，客户端将向服务器发送续订消息。服务器向客户机发送一条具有新生存期的回复消息，允许客户机继续使用该地址而不会中断。
To request the assignment of one or more IPv6 addresses, a client first locates a DHCP server and then requests the assignment of addresses and other configuration information from the server. The client sends a Solicit message to the All_DHCP_Relay_Agents_and_Servers address to find available DHCP servers. Any server that can meet the client's requirements responds with an Advertise message. The client then chooses one of the servers and sends a Request message to the server asking for confirmed assignment of addresses and other configuration information. The server responds with a Reply message that contains the confirmed addresses and configuration.
要请求分配一个或多个IPv6地址，客户端首先查找DHCP服务器，然后从服务器请求分配地址和其他配置信息。客户端向所有DHCP中继代理和服务器地址发送请求消息，以查找可用的DHCP服务器。任何能够满足客户机要求的服务器都会以播发消息进行响应。然后，客户机选择其中一台服务器，并向服务器发送请求消息，请求确认地址分配和其他配置信息。服务器用一条回复消息进行响应，该消息包含已确认的地址和配置。
As described in the previous section, the client sends a Renew message to the server to extend the lifetimes associated with its addresses, allowing the client to continue to use those addresses without interruption.
如前一节所述，客户机向服务器发送续订消息以延长与其地址相关联的生存期，从而允许客户机继续使用这些地址而不中断。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [1].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[1]中的说明进行解释。
This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document.
本文档还使用内部概念变量来描述协议行为和实现必须允许系统管理员更改的外部变量。提供特定变量名称、其值如何更改以及其设置如何影响协议行为，以演示协议行为。只要实现的外部行为与本文档中描述的一致，则不要求实现的外部行为与本文中描述的完全相同。
The IPv6 Specification provides the base architecture and design of IPv6. Related work in IPv6 that would best serve an implementor to study includes the IPv6 Specification [3], the IPv6 Addressing Architecture [5], IPv6 Stateless Address Autoconfiguration [17], IPv6 Neighbor Discovery Processing [13], and Dynamic Updates to DNS [22]. These specifications enable DHCP to build upon the IPv6 work to provide both robust stateful autoconfiguration and autoregistration of DNS Host Names.
IPv6规范提供了IPv6的基本架构和设计。IPv6中最有助于实施者研究的相关工作包括IPv6规范[3]、IPv6寻址体系结构[5]、IPv6无状态地址自动配置[17]、IPv6邻居发现处理[13]和DNS的动态更新[22]。这些规范使DHCP能够在IPv6工作的基础上构建，以提供健壮的有状态自动配置和DNS主机名的自动注册。
The IPv6 Addressing Architecture specification [5] defines the address scope that can be used in an IPv6 implementation, and the various configuration architecture guidelines for network designers of the IPv6 address space. Two advantages of IPv6 are that support for multicast is required and nodes can create link-local addresses during initialization. The availability of these features means that a client can use its link-local address and a well-known multicast address to discover and communicate with DHCP servers or relay agents on its link.
IPv6寻址体系结构规范[5]定义了可在IPv6实现中使用的地址范围，以及IPv6地址空间网络设计者的各种配置体系结构指南。IPv6的两个优点是需要对多播的支持，并且节点可以在初始化期间创建链路本地地址。这些功能的可用性意味着客户端可以使用其链路本地地址和众所周知的多播地址来发现其链路上的DHCP服务器或中继代理并与之通信。
IPv6 Stateless Address Autoconfiguration [17] specifies procedures by which a node may autoconfigure addresses based on router advertisements [13], and the use of a valid lifetime to support renumbering of addresses on the Internet. In addition, the protocol interaction by which a node begins stateless or stateful autoconfiguration is specified. DHCP is one vehicle to perform stateful autoconfiguration. Compatibility with stateless address autoconfiguration is a design requirement of DHCP.
IPv6无状态地址自动配置[17]指定了节点可以根据路由器广告[13]自动配置地址的过程，以及使用有效的生存期来支持Internet上地址的重新编号。此外，还指定了节点开始无状态或有状态自动配置的协议交互。DHCP是执行有状态自动配置的一种工具。与无状态地址自动配置的兼容性是DHCP的设计要求。
IPv6 Neighbor Discovery [13] is the node discovery protocol in IPv6 which replaces and enhances functions of ARP [14]. To understand IPv6 and stateless address autoconfiguration, it is strongly recommended that implementors understand IPv6 Neighbor Discovery.
IPv6邻居发现[13]是IPv6中的节点发现协议，它取代并增强了ARP的功能[14]。要了解IPv6和无状态地址自动配置，强烈建议实施者了解IPv6邻居发现。
Dynamic Updates to DNS [22] is a specification that supports the dynamic update of DNS records for both IPv4 and IPv6. DHCP can use the dynamic updates to DNS to integrate addresses and name space to not only support autoconfiguration, but also autoregistration in IPv6.
DNS动态更新[22]是一种规范，支持IPv4和IPv6 DNS记录的动态更新。DHCP可以使用DNS的动态更新来集成地址和名称空间，不仅支持自动配置，还支持IPv6中的自动注册。
This sections defines terminology specific to IPv6 and DHCP used in this document.
本节定义了本文档中使用的特定于IPv6和DHCP的术语。
IPv6 terminology relevant to this specification from the IPv6 Protocol [3], IPv6 Addressing Architecture [5], and IPv6 Stateless Address Autoconfiguration [17] is included below.
IPv6协议[3]、IPv6寻址体系结构[5]和IPv6无状态地址自动配置[17]中与本规范相关的IPv6术语如下所示。
address An IP layer identifier for an interface or a set of interfaces.
地址一个接口或一组接口的IP层标识符。
host Any node that is not a router.
托管不是路由器的任何节点。
IP Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6 are used only in contexts where it is necessary to avoid ambiguity.
IP Internet协议版本6（IPv6）。术语IPv4和IPv6仅在需要避免歧义的上下文中使用。
interface A node's attachment to a link.
将节点的附件连接到链接。
link A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernet (simple or bridged); Token Ring; PPP links, X.25, Frame Relay, or ATM networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself.
链路节点可在链路层（即IP下的一层）上进行通信的通信设施或介质。例如以太网（简单或桥接）；令牌环；PPP链路、X.25、帧中继或ATM网络；互联网（或更高）层的“隧道”，如IPv4或IPv6本身上的隧道。
link-layer identifier A link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet or Token Ring network interfaces, and E.164 addresses for ISDN links.
链路层标识符接口的链路层标识符。示例包括以太网或令牌环网接口的IEEE 802地址，以及ISDN链路的E.164地址。
link-local address An IPv6 address having a link-only scope, indicated by having the prefix (FE80::/10), that can be used to reach neighboring nodes attached to the same link. Every interface has a link-local address.
链路本地地址具有仅链路作用域的IPv6地址，由前缀（FE80:：/10）表示，可用于到达连接到同一链路的相邻节点。每个接口都有一个链接本地地址。
multicast address An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address.
多播地址一组接口（通常属于不同节点）的标识符。发送到多播地址的数据包被发送到该地址标识的所有接口。
neighbor A node attached to the same link.
邻居连接到同一链路的节点。
node A device that implements IP.
节点实现IP的设备。
packet An IP header plus payload.
一个IP报头加上有效负载的数据包。
prefix The initial bits of an address, or a set of IP addresses that share the same initial bits.
前缀地址的初始位，或共享相同初始位的一组IP地址。
prefix length The number of bits in a prefix.
前缀长度前缀中的位数。
router A node that forwards IP packets not explicitly addressed to itself.
路由器转发未显式寻址到自身的IP数据包的节点。
unicast address An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address.
单播地址单个接口的标识符。发送到单播地址的数据包被发送到由该地址标识的接口。
Terminology specific to DHCP can be found below.
DHCP专用术语见下文。
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.
适用于链路当地址与DHCP服务器对网络拓扑、前缀分配和地址分配策略的了解一致时，地址为“适用于链路”。
binding A binding (or, client binding) is a group of server data records containing the information the server has about the addresses in an IA or configuration information explicitly assigned to the client. Configuration information that has been returned to a client through a policy - for example, the information returned to all clients on the same link - does not require a binding. A binding containing information about 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>.
绑定绑定（或客户端绑定）是一组服务器数据记录，其中包含服务器关于IA中地址的信息或显式分配给客户端的配置信息。通过策略返回给客户端的配置信息（例如，返回给同一链接上所有客户端的信息）不需要绑定。包含IA信息的绑定由元组<DUID，IA type，IAID>索引（其中IA type是IA中的地址类型；例如，临时地址）。包含客户端配置信息的绑定由<DUID>索引。
configuration parameter An element of the configuration information set on the server and delivered to the client using DHCP. Such parameters may be used to carry information to be used by a node to configure its network subsystem and enable communication on a link or internetwork, for example.
配置参数服务器上设置的配置信息的元素，并使用DHCP传递给客户端。例如，这些参数可用于携带节点用于配置其网络子系统和启用链路或互联网上的通信的信息。
DHCP Dynamic Host Configuration Protocol for IPv6. The terms DHCPv4 and DHCPv6 are used only in contexts where it is necessary to avoid ambiguity.
IPv6的DHCP动态主机配置协议。术语DHCPv4和DHCPv6仅在需要避免歧义的上下文中使用。
DHCP client (or client) A node that initiates requests on a link to obtain configuration parameters from one or more DHCP servers.
DHCP客户端（或客户端）在链路上发起请求以从一个或多个DHCP服务器获取配置参数的节点。
DHCP domain A set of links managed by DHCP and operated by a single administrative entity.
DHCP域由DHCP管理并由单个管理实体操作的一组链接。
DHCP realm A name used to identify the DHCP administrative domain from which a DHCP authentication key was selected.
DHCP域用于标识从中选择DHCP身份验证密钥的DHCP管理域的名称。
DHCP relay agent (or relay agent) A node that acts as an intermediary to deliver DHCP messages between clients and servers, and is on the same link as the client.
DHCP中继代理（或中继代理）作为中介在客户端和服务器之间传递DHCP消息的节点，与客户端位于同一链路上。
DHCP server (or server) A node that responds to requests from clients, and may or may not be on the same link as the client(s).
DHCP服务器（或服务器）响应客户端请求的节点，可能与客户端位于同一链路上，也可能与客户端不在同一链路上。
DUID A DHCP Unique IDentifier for a DHCP participant; each DHCP client and server has exactly one DUID. See section 9 for details of the ways in which a DUID may be constructed.
DUID DHCP参与者的DHCP唯一标识符；每个DHCP客户端和服务器只有一个DUID。有关DUID构造方式的详细信息，请参见第9节。
Identity association (IA) A collection of addresses assigned to a client. Each IA has an associated IAID. A client may have more than one IA assigned to it; for example, one for each of its interfaces.
身份关联（IA）分配给客户端的地址集合。每个IA都有一个关联的IAID。一个客户可能有多个IA分配给它；例如，每个接口对应一个。
Each IA holds one type of address; for example, an identity association for temporary addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses"). Throughout this document, "IA" is used to refer to an identity association without identifying the type of addresses in the IA.
每个IA持有一种类型的地址；例如，临时地址的标识关联（IA_TA）持有临时地址（请参阅“临时地址的标识关联”）。在本文档中，“IA”用于指身份关联，而不标识IA中的地址类型。
Identity association identifier (IAID) An identifier for an IA, chosen by the client. Each IA has an IAID, which is chosen to be unique among all IAIDs for IAs belonging to that client.
标识关联标识符（IAID）：由客户端选择的IA标识符。每个IA都有一个IAID，该IAID在属于该客户机的IAs的所有IAID中是唯一的。
Identity association for non-temporary addresses (IA_NA) An IA that carries assigned addresses that are not temporary addresses (see "identity association for temporary addresses")
非临时地址标识关联（IA_NA）承载非临时地址的分配地址的IA（参见“临时地址标识关联”）
Identity association for temporary addresses (IA_TA) An IA that carries temporary addresses (see RFC 3041 [12]).
临时地址标识关联（IA_TA）承载临时地址的IA（参见RFC 3041[12]）。
message A unit of data carried as the payload of a UDP datagram, exchanged among DHCP servers, relay agents and clients.
消息作为UDP数据报的有效载荷携带的数据单元，在DHCP服务器、中继代理和客户端之间交换。
Reconfigure key A key supplied to a client by a server used to provide security for Reconfigure messages.
重新配置密钥服务器提供给客户端的密钥，用于为重新配置消息提供安全性。
relaying A DHCP relay agent relays DHCP messages between DHCP participants.
中继DHCP中继代理在DHCP参与者之间中继DHCP消息。
transaction ID An opaque value used to match responses with replies initiated either by a client or server.
事务ID一个不透明的值，用于将响应与客户端或服务器启动的响应进行匹配。
This section describes various program and networking constants used by DHCP.
本节介绍DHCP使用的各种程序和网络常量。
DHCP makes use of the following multicast addresses:
DHCP使用以下多播地址：
All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped multicast address used by a client to communicate with neighboring (i.e., on-link) relay agents and servers. All servers and relay agents are members of this multicast group.
所有_DHCP_中继_代理_和_服务器（FF02:：1:2）客户端用于与相邻（即链路上）中继代理和服务器通信的链路范围的多播地址。所有服务器和中继代理都是此多播组的成员。
All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used by a relay agent to communicate with servers, either because the relay agent wants to send messages to all servers or because it does not know the unicast addresses of the servers. Note that in order for a relay agent to use this address, it must have an address of sufficient scope to be reachable by the servers. All servers within the site are members of this multicast group.
All_DHCP_Servers（FF05:：1:3）中继代理用于与服务器通信的站点范围的多播地址，这可能是因为中继代理希望向所有服务器发送消息，也可能是因为它不知道服务器的单播地址。请注意，为了使中继代理使用此地址，它必须具有足够范围的地址，以便服务器可以访问。站点中的所有服务器都是此多播组的成员。
Clients listen for DHCP messages on UDP port 546. Servers and relay agents listen for DHCP messages on UDP port 547.
客户端在UDP端口546上侦听DHCP消息。服务器和中继代理在UDP端口547上侦听DHCP消息。
DHCP defines the following message types. More detail on these message types can be found in sections 6 and 7. Message types not listed here are reserved for future use. The numeric encoding for each message type is shown in parentheses.
DHCP定义了以下消息类型。有关这些消息类型的更多详细信息，请参见第6节和第7节。此处未列出的消息类型保留供将来使用。括号中显示了每种消息类型的数字编码。
SOLICIT (1) A client sends a Solicit message to locate servers.
请求（1）客户端发送请求消息以定位服务器。
ADVERTISE (2) A server sends an Advertise message to indicate that it is available for DHCP service, in response to a Solicit message received from a client.
播发（2）服务器发送播发消息以指示它可用于DHCP服务，以响应从客户端接收的请求消息。
REQUEST (3) A client sends a Request message to request configuration parameters, including IP addresses, from a specific server.
请求（3）客户端从特定服务器向请求配置参数（包括IP地址）发送请求消息。
CONFIRM (4) A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected.
确认（4）客户端向任何可用的服务器发送确认消息，以确定分配给它的地址是否仍然适用于客户端所连接的链接。
RENEW (5) A client sends a Renew message to the server that originally provided the client's addresses and configuration parameters to extend the lifetimes on the addresses assigned to the client and to update other configuration parameters.
续订（5）客户端向最初提供客户端地址和配置参数的服务器发送续订消息，以延长分配给客户端的地址的生存期并更新其他配置参数。
REBIND (6) A client sends a Rebind message to any available server to extend the lifetimes on the addresses assigned to the client and to update other configuration parameters; this message is sent after a client receives no response to a Renew message.
重新绑定（6）客户机向任何可用服务器发送重新绑定消息，以延长分配给客户机的地址的生存期，并更新其他配置参数；此消息在客户端未收到对续订消息的响应后发送。
REPLY (7) 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.
回复（7）服务器发送包含分配地址和配置参数的回复消息，以响应从客户端接收的请求、请求、续订和重新绑定消息。服务器发送包含配置参数的回复消息以响应信息请求消息。服务器发送回复消息以响应确认消息，确认或拒绝分配给客户机的地址适合于客户机所连接的链接。服务器发送回复消息以确认已收到释放或拒绝消息。
RELEASE (8) A client sends a Release message to the server that assigned addresses to the client to indicate that the client will no longer use one or more of the assigned addresses.
释放（8）客户端向服务器发送一条释放消息，向该服务器分配地址，以指示该客户端将不再使用一个或多个分配的地址。
DECLINE (9) A client sends a Decline message to a server to indicate that the client has determined that one or more addresses assigned by the server are already in use on the link to which the client is connected.
拒绝（9）客户端向服务器发送拒绝消息，以指示客户端已确定服务器分配的一个或多个地址已在客户端所连接的链路上使用。
RECONFIGURE (10) A server sends a Reconfigure message to a client to inform the client that the server has new or updated configuration parameters, and that the client is to initiate a Renew/Reply or Information-request/Reply transaction with the server in order to receive the updated information.
重新配置（10）服务器向客户端发送重新配置消息，以通知客户端服务器具有新的或更新的配置参数，并且客户端将与服务器发起续订/回复或信息请求/回复事务，以便接收更新的信息。
INFORMATION-REQUEST (11) A client sends an Information-request message to a server to request configuration parameters without the assignment of any IP addresses to the client.
信息请求（11）客户端向服务器发送信息请求消息以请求配置参数，而无需向客户端分配任何IP地址。
RELAY-FORW (12) A relay agent sends a Relay-forward message to relay messages to servers, either directly or through another relay agent. The received message, either a client message or a Relay-forward message from another relay agent, is encapsulated in an option in the Relay-forward message.
中继转发（12）中继代理直接或通过另一个中继代理向服务器发送中继转发消息。接收到的消息（客户端消息或来自另一个中继代理的中继转发消息）封装在中继转发消息中的选项中。
RELAY-REPL (13) A server sends a Relay-reply message to a relay agent containing a message that the relay agent delivers to a client. The Relay-reply message may be relayed by other relay agents for delivery to the destination relay agent.
中继回复（13）服务器向中继代理发送中继回复消息，其中包含中继代理向客户端发送的消息。中继应答消息可以由其他中继代理中继以传送到目的地中继代理。
The server encapsulates the client message as an option in the Relay-reply message, which the relay agent extracts and relays to the client.
服务器将客户机消息封装为中继回复消息中的一个选项，中继代理提取该消息并将其中继到客户机。
DHCPv6 uses status codes to communicate the success or failure of operations requested in messages from clients and servers, and to provide additional information about the specific cause of the failure of a message. The specific status codes are defined in section 24.4.
DHCPv6使用状态代码传达来自客户端和服务器的消息中请求的操作的成功或失败，并提供有关消息失败的特定原因的附加信息。具体状态代码在第24.4节中定义。
This section presents a table of values used to describe the message transmission behavior of clients and servers.
本节提供了一个用于描述客户端和服务器的消息传输行为的值表。
Parameter Default Description
-------------------------------------
SOL_MAX_DELAY 1 sec Max delay of first Solicit
SOL_TIMEOUT 1 sec Initial Solicit timeout
SOL_MAX_RT 120 secs Max Solicit timeout value
REQ_TIMEOUT 1 sec Initial Request timeout
REQ_MAX_RT 30 secs Max Request timeout value
REQ_MAX_RC 10 Max Request retry attempts
CNF_MAX_DELAY 1 sec Max delay of first Confirm
CNF_TIMEOUT 1 sec Initial Confirm timeout
CNF_MAX_RT 4 secs Max Confirm timeout
CNF_MAX_RD 10 secs Max Confirm duration
REN_TIMEOUT 10 secs Initial Renew timeout
REN_MAX_RT 600 secs Max Renew timeout value
REB_TIMEOUT 10 secs Initial Rebind timeout
REB_MAX_RT 600 secs Max Rebind timeout value
INF_MAX_DELAY 1 sec Max delay of first Information-request
INF_TIMEOUT 1 sec Initial Information-request timeout
INF_MAX_RT 120 secs Max Information-request timeout value
REL_TIMEOUT 1 sec Initial Release timeout
REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 1 sec Initial Decline timeout
DEC_MAX_RC 5 Max Decline attempts
REC_TIMEOUT 2 secs Initial Reconfigure timeout
REC_MAX_RC 8 Max Reconfigure attempts
HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward message
Parameter Default Description
-------------------------------------
SOL_MAX_DELAY 1 sec Max delay of first Solicit
SOL_TIMEOUT 1 sec Initial Solicit timeout
SOL_MAX_RT 120 secs Max Solicit timeout value
REQ_TIMEOUT 1 sec Initial Request timeout
REQ_MAX_RT 30 secs Max Request timeout value
REQ_MAX_RC 10 Max Request retry attempts
CNF_MAX_DELAY 1 sec Max delay of first Confirm
CNF_TIMEOUT 1 sec Initial Confirm timeout
CNF_MAX_RT 4 secs Max Confirm timeout
CNF_MAX_RD 10 secs Max Confirm duration
REN_TIMEOUT 10 secs Initial Renew timeout
REN_MAX_RT 600 secs Max Renew timeout value
REB_TIMEOUT 10 secs Initial Rebind timeout
REB_MAX_RT 600 secs Max Rebind timeout value
INF_MAX_DELAY 1 sec Max delay of first Information-request
INF_TIMEOUT 1 sec Initial Information-request timeout
INF_MAX_RT 120 secs Max Information-request timeout value
REL_TIMEOUT 1 sec Initial Release timeout
REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 1 sec Initial Decline timeout
DEC_MAX_RC 5 Max Decline attempts
REC_TIMEOUT 2 secs Initial Reconfigure timeout
REC_MAX_RC 8 Max Reconfigure attempts
HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward message
All time values for lifetimes, T1 and T2 are unsigned integers. The value 0xffffffff is taken to mean "infinity" when used as a lifetime (as in RFC2461 [17]) or a value for T1 or T2.
生命周期T1和T2的所有时间值都是无符号整数。当用作生存期（如RFC2461[17]中所述）或T1或T2的值时，值0xFFFFFF表示“无穷大”。
All DHCP messages sent between clients and servers share an identical fixed format header and a variable format area for options.
客户端和服务器之间发送的所有DHCP消息共享相同的固定格式标头和用于选项的可变格式区域。
All values in the message header and in options are in network byte order.
消息头和选项中的所有值均按网络字节顺序排列。
Options are stored serially in the options field, with no padding between the options. Options are byte-aligned but are not aligned in any other way such as on 2 or 4 byte boundaries.
选项串行存储在选项字段中，选项之间没有填充。选项是字节对齐的，但不以任何其他方式对齐，例如在2或4字节边界上。
The following diagram illustrates the format of DHCP messages sent between clients and servers:
下图说明了在客户端和服务器之间发送的DHCP消息的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type Identifies the DHCP message type; the available message types are listed in section 5.3.
msg type标识DHCP消息类型；第5.3节列出了可用的消息类型。
transaction-id The transaction ID for this message exchange.
事务id此消息交换的事务id。
options Options carried in this message; options are described in section 22.
此消息中包含的选项；选项在第22节中描述。
Relay agents exchange messages with servers to relay messages between clients and servers that are not connected to the same link.
中继代理与服务器交换消息，以在未连接到同一链路的客户端和服务器之间中继消息。
All values in the message header and in options are in network byte order.
消息头和选项中的所有值均按网络字节顺序排列。
Options are stored serially in the options field, with no padding between the options. Options are byte-aligned but are not aligned in any other way such as on 2 or 4 byte boundaries.
选项串行存储在选项字段中，选项之间没有填充。选项是字节对齐的，但不以任何其他方式对齐，例如在2或4字节边界上。
There are two relay agent messages, which share the following format:
有两条中继代理消息，它们共享以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | hop-count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| peer-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. options (variable number and length) .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | hop-count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| peer-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. options (variable number and length) .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following sections describe the use of the Relay Agent message header.
以下各节介绍中继代理消息头的使用。
The following table defines the use of message fields in a Relay-forward message.
下表定义了中继转发消息中消息字段的使用。
msg-type RELAY-FORW
msg型继电器-FORW
hop-count Number of relay agents that have relayed this message.
跃点计数已中继此消息的中继代理数。
link-address A global or site-local address that will be used by the server to identify the link on which the client is located.
链接地址服务器将使用的全局或站点本地地址来标识客户端所在的链接。
peer-address The address of the client or relay agent from which the message to be relayed was received.
对等地址从中接收要中继的消息的客户端或中继代理的地址。
options MUST include a "Relay Message option" (see section 22.10); MAY include other options added by the relay agent.
选项必须包括“中继消息选项”（见第22.10节）；可能包括中继代理添加的其他选项。
The following table defines the use of message fields in a Relay-reply message.
下表定义了中继回复消息中消息字段的使用。
msg-type RELAY-REPL
msg型继电器-REPL
hop-count Copied from the Relay-forward message
从中继转发消息复制的跃点计数
link-address Copied from the Relay-forward message
从中继转发消息复制的链接地址
peer-address Copied from the Relay-forward message
从中继转发消息复制的对等地址
options MUST include a "Relay Message option"; see section 22.10; MAY include other options
选项必须包括“中继消息选项”；见第22.10节；可能包括其他选项
So that domain names may be encoded uniformly, a domain name or a list of domain names is encoded using the technique described in section 3.1 of RFC 1035 [10]. A domain name, or list of domain names, in DHCP MUST NOT be stored in compressed form, as described in section 4.1.4 of RFC 1035.
为了对域名进行统一编码，使用RFC 1035[10]第3.1节中描述的技术对域名或域名列表进行编码。DHCP中的域名或域名列表不得以压缩形式存储，如RFC 1035第4.1.4节所述。
Each DHCP client and server has a DUID. DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. DHCP clients use DUIDs to identify a server in messages where a server needs to be identified. See sections 22.2 and 22.3 for the representation of a DUID in a DHCP message.
每个DHCP客户端和服务器都有一个DUID。DHCP服务器使用DUID识别用于选择配置参数和IAs与客户端关联的客户端。DHCP客户端使用DUID在需要标识服务器的消息中标识服务器。有关DHCP消息中DUID的表示，请参见第22.2节和第22.3节。
Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs. Clients and servers MUST NOT restrict DUIDs to the types defined in this document, as additional DUID types may be defined in the future.
客户端和服务器必须将DUID视为不透明值，并且必须仅比较DUID是否相等。客户端和服务器不得以任何其他方式解释DUID。客户端和服务器不得将DUID限制为本文档中定义的类型，因为将来可能会定义其他DUID类型。
The DUID is carried in an option because it may be variable length and because it is not required in all DHCP messages. The DUID is designed to be unique across all DHCP clients and servers, and stable for any specific client or server - that is, the DUID used by a client or server SHOULD NOT change over time if at all possible; for example, a device's DUID should not change as a result of a change in the device's network hardware.
DUID包含在选项中，因为它可能是可变长度的，并且并非所有DHCP消息都需要它。DUID设计为在所有DHCP客户端和服务器上都是唯一的，并且对于任何特定的客户端或服务器都是稳定的，也就是说，如果可能的话，客户端或服务器使用的DUID不应随时间而改变；例如，设备的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 of globally-unique identifier that is easy to generate for any given device can differ quite widely. Also, some devices may not contain any persistent storage. Retaining a generated DUID in such a device is not possible, so the DUID scheme must accommodate such devices.
拥有多种类型的DUID的动机是DUID必须是全局唯一的，并且必须易于生成。对于任何给定的设备，易于生成的全局唯一标识符的种类可能相差很大。此外，某些设备可能不包含任何持久性存储。在这样的设备中保留生成的DUID是不可能的，因此DUID方案必须适应这样的设备。
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 actual identifier. A DUID can be no more than 128 octets long (not including the type code). The following types are currently defined:
DUID由以网络字节顺序表示的两个八位字节类型的代码组成，后跟组成实际标识符的可变八位字节数。DUID的长度不能超过128个八位字节（不包括类型代码）。目前定义了以下类型：
1 Link-layer address plus time 2 Vendor-assigned unique ID based on Enterprise Number 3 Link-layer address
1链路层地址加上时间2供应商根据企业编号3链路层地址分配的唯一ID
Formats for the variable field of the DUID for each of the above types are shown below.
上述每种类型的DUID变量字段格式如下所示。
This type of DUID consists of a two octet type field containing the value 1, a two octet hardware type code, four octets containing a time value, followed by link-layer address of any one network interface that is connected to the DHCP device at the time that the DUID is generated. The time value is the time that the DUID is generated represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by the IANA as described in RFC 826 [14]. 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 RFC 2464 [2].
这种类型的DUID包括一个包含值1的双八位字节类型字段、一个双八位字节硬件类型代码、四个包含时间值的八位字节，然后是生成DUID时连接到DHCP设备的任何一个网络接口的链路层地址。时间值是从2000年1月1日午夜（UTC）开始生成DUID的时间，以秒为单位，模数为2^32。硬件类型必须是由IANA分配的有效硬件类型，如RFC 826[14]所述。时间和硬件类型都以网络字节顺序存储。链路层地址以规范形式存储，如RFC 2464[2]所述。
The following diagram illustrates the format of a DUID-LLT:
下图说明了DUID-LLT的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The choice of network interface can be completely arbitrary, as long as that interface provides a globally unique link-layer address for the link type, and the same DUID-LLT SHOULD be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID-LLT.
网络接口的选择可以是完全任意的，只要该接口为链路类型提供全局唯一的链路层地址，并且在配置连接到设备的所有网络接口时应使用相同的DUID-LLT，而不管使用哪个接口的链路层地址生成DUID-LLT。
Clients and servers using this type of DUID MUST store the DUID-LLT in stable storage, and MUST continue to use this DUID-LLT even if the network interface used to generate the DUID-LLT is removed. Clients and servers that do not have any stable storage MUST NOT use this type of DUID.
使用此类型DUID的客户端和服务器必须将DUID-LLT存储在稳定的存储中，并且即使删除了用于生成DUID-LLT的网络接口，也必须继续使用此DUID-LLT。没有任何稳定存储的客户端和服务器不得使用此类DUID。
Clients and servers that use this DUID SHOULD attempt to configure the time prior to generating the DUID, if that is possible, and MUST use some sort of time source (for example, a real-time clock) in 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 unlikely that two identical DUID-LLTs will be generated if the network interface is removed from the client and another client then uses the same network interface to generate a DUID-LLT. A collision between two DUID-LLTs is very unlikely even if the clocks have not been configured prior to generating the DUID.
如果可能，使用此DUID的客户端和服务器应尝试在生成DUID之前配置时间，并且在生成DUID时必须使用某种时间源（例如，实时时钟），即使在生成DUID之前无法配置该时间源。如果从客户端移除网络接口，并且另一个客户端使用相同的网络接口生成DUID-LLT，则使用时间源不太可能生成两个相同的DUID LLT。即使在生成DUID之前未配置时钟，两个DUID LLT之间的冲突也不太可能发生。
This method of DUID generation is recommended for all general purpose computing devices such as desktop computers and laptop computers, and also for devices such as printers, routers, and so on, that contain some form of writable non-volatile storage.
这种DUID生成方法推荐用于所有通用计算设备，如台式计算机和笔记本电脑，以及包含某种形式的可写非易失性存储的设备，如打印机、路由器等。
Despite our best efforts, it is possible that this algorithm for generating a DUID could result in a client identifier collision. 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.
尽管我们尽了最大努力，但这种生成DUID的算法可能会导致客户端标识符冲突。使用此机制生成DUID-LLT的DHCP客户端必须提供一个管理接口，用新生成的DUID-LLT替换现有的DUID。
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 [6] followed by a unique identifier assigned by the vendor. The following diagram summarizes the structure of a DUID-EN:
此形式的DUID由供应商分配给设备。它由IANA维护的供应商注册私营企业编号[6]和供应商分配的唯一标识符组成。下图总结了DUID-EN的结构：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The source of the identifier is left up to the vendor defining it, but each identifier part of each DUID-EN MUST be unique to the device that is using it, and MUST be assigned to the device at the time it is manufactured and stored in some form of non-volatile storage. The generated DUID SHOULD be recorded in non-erasable storage. The enterprise-number is the vendor's registered Private Enterprise Number as maintained by IANA [6]. The enterprise-number is stored as an unsigned 32 bit number.
标识符的来源由定义它的供应商决定，但每个DUID-EN的每个标识符部分必须对使用它的设备是唯一的，并且必须在设备制造时分配给设备，并以某种形式存储在非易失性存储器中。生成的DUID应记录在不可擦除存储器中。企业编号是供应商注册的私营企业编号，由IANA维护[6]。企业编号存储为无符号32位数字。
An example DUID of this type might look like this:
此类型的示例DUID可能如下所示：
+---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 0 | 0 | 9| 12|192|
+---+---+---+---+---+---+---+---+
|132|221| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 0 | 0 | 9| 12|192|
+---+---+---+---+---+---+---+---+
|132|221| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+
This example includes the two-octet type of 2, the Enterprise Number (9), followed by eight octets of identifier data (0x0CC084D303000912).
此示例包括两个八位字节类型2，即企业编号（9），后跟八个八位字节的标识符数据（0x0CC084D303000912）。
This type of DUID consists of two octets containing the DUID type 3, a two octet network hardware type code, followed by the link-layer address of any one network interface that is permanently connected to the client or server device. For example, a host that has a network interface implemented in a chip that is unlikely to be removed and
这种类型的DUID由两个八位字节组成，其中包含DUID类型3、两个八位字节的网络硬件类型代码，后跟永久连接到客户端或服务器设备的任何一个网络接口的链路层地址。例如，在芯片中实现网络接口的主机不太可能被移除和移除
used elsewhere could use a DUID-LL. The hardware type MUST be a valid hardware type assigned by the IANA, as described in RFC 826 [14]. The hardware type is stored in network byte order. The link-layer address is stored in canonical form, as described in RFC 2464 [2]. The following diagram illustrates the format of a DUID-LL:
如果在别处使用，可以使用DUID-LL。硬件类型必须是IANA分配的有效硬件类型，如RFC 826[14]所述。硬件类型以网络字节顺序存储。链路层地址以规范形式存储，如RFC 2464[2]所述。下图说明了DUID-LL的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The choice of network interface can be completely arbitrary, as long as that interface provides a unique link-layer address and is permanently attached to the device on which the DUID-LL is being generated. The same DUID-LL SHOULD be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID.
网络接口的选择可以是完全任意的，只要该接口提供唯一的链路层地址并永久连接到正在生成DUID-LL的设备。在配置连接到设备的所有网络接口时，应使用相同的DUID-LL，无论使用哪个接口的链路层地址生成DUID。
DUID-LL is recommended for devices that have a permanently-connected network interface with a link-layer address, and do not have nonvolatile, writable stable storage. DUID-LL MUST NOT be used by DHCP clients or servers that cannot tell whether or not a network interface is permanently attached to the device on which the DHCP client is running.
DUID-LL建议用于具有永久连接的网络接口和链路层地址，并且没有非易失性、可写稳定存储器的设备。无法判断网络接口是否永久连接到运行DHCP客户端的设备的DHCP客户端或服务器不得使用DUID-LL。
An "identity-association" (IA) is a construct through which a server and a client can identify, group, and manage a set of related IPv6 addresses. Each IA consists of an IAID and associated configuration information.
“身份关联”（IA）是一种结构，通过它，服务器和客户端可以识别、分组和管理一组相关的IPv6地址。每个IA由一个IAID和相关的配置信息组成。
A client must associate at least one distinct IA with each of its network interfaces for which it is to request the assignment of IPv6 addresses from a DHCP server. The client uses the IAs assigned to an interface to obtain configuration information from a server for that interface. Each IA must be associated with exactly one interface.
客户端必须将至少一个不同的IA与其每个网络接口相关联，以便从DHCP服务器请求分配IPv6地址。客户端使用分配给接口的IAs从服务器获取该接口的配置信息。每个IA必须仅与一个接口关联。
The IAID uniquely identifies the IA and must be chosen to be unique among the IAIDs on the client. The IAID is chosen by the client. For any given use of an IA by the client, the IAID for that IA MUST be consistent across restarts of the DHCP client. The client may maintain consistency either by storing the IAID in non-volatile
IAID唯一地标识IA，并且必须选择为在客户端上的IAID中唯一。IAID由客户端选择。对于客户端对IA的任何给定使用，该IA的IAID必须在DHCP客户端重新启动时保持一致。客户端可以通过将IAID存储在非易失性存储中来保持一致性
storage or by using an algorithm that will consistently produce the same IAID as long as the configuration of the client has not changed. There may be no way for a client to maintain consistency of the IAIDs if it does not have non-volatile storage and the client's hardware configuration changes.
存储或使用算法，只要客户端的配置没有更改，该算法将始终生成相同的IAID。如果客户端没有非易失性存储，并且客户端的硬件配置发生更改，则客户端可能无法保持IAID的一致性。
The configuration information in an IA consists of one or more IPv6 addresses along with the times T1 and T2 for the IA. See section 22.4 for the representation of an IA in a DHCP message.
IA中的配置信息包括一个或多个IPv6地址以及IA的时间T1和T2。有关DHCP消息中IA的表示，请参见第22.4节。
Each address in an IA has a preferred lifetime and a valid lifetime, as defined in RFC 2462 [17]. The lifetimes are transmitted from the DHCP server to the client in the IA option. The lifetimes apply to the use of IPv6 addresses, as described in section 5.5.4 of RFC 2462.
IA中的每个地址都有一个首选生存期和一个有效生存期，如RFC 2462[17]中所定义。生命周期在IA选项中从DHCP服务器传输到客户端。生命周期适用于IPv6地址的使用，如RFC 2462第5.5.4节所述。
A server selects addresses to be assigned to an IA according to the address assignment policies determined by the server administrator and the specific information the server determines about the client from some combination of the following sources:
服务器根据服务器管理员确定的地址分配策略以及服务器从以下来源的某些组合中确定的有关客户端的特定信息，选择要分配给IA的地址：
- The link to which the client is attached. The server determines the link as follows:
- 客户端连接到的链接。服务器按如下方式确定链接：
* If the server receives the message directly from the client and the source address in the IP datagram in which the message was received is a link-local address, then the client is on the same link to which the interface over which the message was received is attached.
* 如果服务器直接从客户机接收消息，并且接收消息的IP数据报中的源地址是链路本地地址，则客户机位于连接接收消息的接口的同一链路上。
* If the server receives the message from a forwarding relay agent, then the client is on the same link as the one to which the interface, identified by the link-address field in the message from the relay agent, is attached.
* 如果服务器从转发中继代理接收到消息，则客户端位于与接口连接的链路相同的链路上，该接口由来自中继代理的消息中的链路地址字段标识。
* If the server receives the message directly from the client and the source address in the IP datagram in which the message was received is not a link-local address, then the client is on the link identified by the source address in the IP datagram (note that this situation can occur only if the server has enabled the use of unicast message delivery by the client and the client has sent a message for which unicast delivery is allowed).
* 如果服务器直接从客户端接收消息，并且接收消息的IP数据报中的源地址不是链路本地地址，则客户端位于由IP数据报中的源地址标识的链路上（请注意，只有当服务器已启用客户端使用单播消息传递，并且客户端已发送允许单播传递的消息时，才会发生这种情况）。
- The DUID supplied by the client.
- 客户端提供的DUID。
- Other information in options supplied by the client.
- 客户提供的选项中的其他信息。
- Other information in options supplied by the relay agent.
- 中继代理提供的选项中的其他信息。
Any address assigned by a server that is based on an EUI-64 identifier MUST include an interface identifier with the "u" (universal/local) and "g" (individual/group) bits of the interface identifier set appropriately, as indicated in section 2.5.1 of RFC 2373 [5].
如RFC 2373[5]第2.5.1节所示，由基于EUI-64标识符的服务器分配的任何地址必须包括接口标识符，接口标识符的“u”（通用/本地）和“g”（单个/组）位设置适当。
A server MUST NOT assign an address that is otherwise reserved for some other purpose. For example, a server MUST NOT assign reserved anycast addresses, as defined in RFC 2526, from any subnet.
服务器不得分配为其他目的保留的地址。例如，服务器不得从任何子网分配RFC 2526中定义的保留选播地址。
A client may request the assignment of temporary addresses (see RFC 3041 [12] for the definition of temporary addresses). DHCPv6 handling of address assignment is no different for temporary addresses. DHCPv6 says nothing about details of temporary addresses like lifetimes, how clients use temporary addresses, rules for generating successive temporary addresses, etc.
客户可以请求分配临时地址（有关临时地址的定义，请参见RFC 3041[12]）。对于临时地址，DHCPv6对地址分配的处理没有什么不同。DHCPv6没有提到临时地址的详细信息，如生存期、客户端如何使用临时地址、生成连续临时地址的规则等。
Clients ask for temporary addresses and servers assign them. Temporary addresses are carried in the Identity Association for Temporary Addresses (IA_TA) option (see section 22.5). Each IA_TA option contains at most one temporary address for each of the prefixes on the link to which the client is attached.
客户端请求临时地址，服务器分配它们。临时地址包含在临时地址标识关联（IA_TA）选项中（见第22.5节）。每个IA_TA选项最多包含一个临时地址，用于连接客户端的链接上的每个前缀。
The IAID number space for the IA_TA option IAID number space is separate from the IA_NA option IAID number space.
IA_TA选项IAID编号空间的IAID编号空间与IA_NA选项IAID编号空间分开。
The server MAY update the DNS for a temporary address, as described in section 4 of RFC 3041.
服务器可以更新临时地址的DNS，如RFC 3041第4节所述。
Unless otherwise specified in this document, or in a document that 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.
除非本文档或描述如何通过特定类型的链路（对于不支持多播的链路类型）承载IPv6的文档中另有规定，否则客户端会将DHCP消息发送到所有\u DHCP\u中继\u代理\u和\u服务器。
A client uses multicast to reach all servers or an individual server. An individual server is indicated by specifying that server's DUID in 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.
客户端使用多播访问所有服务器或单个服务器。通过在客户端消息中的服务器标识符选项（参见第22.3节）中指定服务器的DUID来指示单个服务器（所有服务器将接收此消息，但只有指示的服务器将响应）。所有服务器均表示不提供此选项。
A client may send some messages directly to a server using unicast, as described in section 22.12.
如第22.12节所述，客户端可以使用单播直接向服务器发送一些消息。
DHCP clients are responsible for reliable delivery of messages in the client-initiated message exchanges described in sections 17 and 18. If a DHCP client fails to receive an expected response from a server, the client must retransmit its message. This section describes the retransmission strategy to be used by clients in client-initiated message exchanges.
DHCP客户端负责在第17节和第18节所述的客户端发起的消息交换中可靠地传递消息。如果DHCP客户端无法从服务器接收到预期的响应，则该客户端必须重新传输其消息。本节描述客户端在客户端发起的消息交换中使用的重传策略。
Note that the procedure described in this section is slightly modified when used with the Solicit message. The modified procedure is described in section 17.1.2.
请注意，当与请求消息一起使用时，本节中描述的过程略有修改。第17.1.2节描述了修改后的程序。
The client begins the message exchange by transmitting a message to the server. The message exchange terminates when either the client successfully receives the appropriate response or responses from a server or servers, or when the message exchange is considered to have failed according to the retransmission mechanism described below.
客户端通过向服务器发送消息来开始消息交换。当客户机成功地从一个或多个服务器接收到一个或多个适当的响应时，或者当根据下面描述的重传机制认为消息交换失败时，消息交换终止。
The client retransmission behavior is controlled and described by the following variables:
客户端重传行为由以下变量控制和描述：
RT Retransmission timeout
RT重传超时
IRT Initial retransmission time
初始重传时间
MRC Maximum retransmission count
最大重传计数
MRT Maximum retransmission time
最大重传时间
MRD Maximum retransmission duration
最大重传持续时间
RAND Randomization factor
兰德随机化因子
With each message transmission or retransmission, the client sets RT according to the rules given below. If RT expires before the message exchange terminates, the client recomputes RT and retransmits the message.
在每次消息传输或重传时，客户机根据下面给出的规则设置RT。如果RT在消息交换终止之前过期，客户端将重新计算RT并重新传输消息。
Each of the computations of a new RT include a randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.1 and +0.1. The randomization factor is included to minimize synchronization of messages transmitted by DHCP clients.
新RT的每次计算都包括一个随机化因子（RAND），它是一个均匀分布在-0.1和+0.1之间的随机数。随机化因子用于最小化DHCP客户端传输的消息的同步。
The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of random numbers from each invocation of the DHCP client.
选择一个随机数的算法不需要在密码上可靠。该算法应该从DHCP客户端的每次调用中产生不同的随机数序列。
RT for the first message transmission is based on IRT:
第一次消息传输的RT基于IRT：
RT = IRT + RAND*IRT
RT = IRT + RAND*IRT
RT for each subsequent message transmission is based on the previous value of RT:
每个后续消息传输的RT基于之前的RT值：
RT = 2*RTprev + RAND*RTprev
RT = 2*RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT (disregarding the randomization added by the use of RAND). If MRT has a value of 0, there is no upper limit on the value of RT. Otherwise:
MRT指定RT值的上限（忽略使用RAND增加的随机化）。如果MRT的值为0，则RT的值没有上限。否则：
if (RT > MRT)
RT = MRT + RAND*MRT
if (RT > MRT)
RT = MRT + RAND*MRT
MRC specifies an upper bound on the number of times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times.
MRC指定客户端可以重新传输消息的次数上限。除非MRC为零，否则一旦客户机传输消息MRC次，消息交换就会失败。
MRD specifies an upper bound on the length of time a client may retransmit a message. Unless MRD is zero, the message exchange fails once MRD seconds have elapsed since the client first transmitted the message.
MRD指定客户端可以重新传输消息的时间长度上限。除非MRD为零，否则自客户端首次传输消息以来，一旦MRD秒过去，消息交换就会失败。
If both MRC and MRD are non-zero, the message exchange fails whenever either of the conditions specified in the previous two paragraphs are met.
如果MRC和MRD均为非零，则只要满足前两段中指定的任一条件，消息交换就会失败。
If both MRC and MRD are zero, the client continues to transmit the message until it receives a response.
如果MRC和MRD都为零，则客户端将继续传输消息，直到收到响应为止。
Clients and servers SHOULD discard any messages that contain options that are not allowed to appear in the received message. For example, an IA option is not allowed to appear in an Information-request message. Clients and servers MAY choose to extract information from such a message if the information is of use to the recipient.
客户端和服务器应丢弃包含不允许在接收到的消息中出现的选项的任何消息。例如，信息请求消息中不允许出现IA选项。如果信息对收件人有用，客户端和服务器可以选择从此类邮件中提取信息。
A server MUST discard any Solicit, Confirm, Rebind or Information-request messages it receives with a unicast destination address.
服务器必须丢弃其接收的带有单播目标地址的任何请求、确认、重新绑定或信息请求消息。
Message validation based on DHCP authentication is discussed in section 21.4.2.
第21.4.2节讨论了基于DHCP身份验证的消息验证。
If a server receives a message that contains options it should not contain (such as an Information-request message with an IA option), is missing options that it should contain, or is otherwise not valid, it MAY send a Reply (or Advertise as appropriate) with a Server Identifier option, a Client Identifier option if one was included in the message and a Status Code option with status UnSpecFail.
如果服务器收到的消息包含其不应包含的选项（例如，带有IA选项的信息请求消息）、缺少其应包含的选项或其他无效选项，则可能会发送带有服务器标识符选项的回复（或根据需要播发），一个客户端标识符选项（如果消息中包含一个）和一个状态代码选项（状态为UnSpecFail）。
The "transaction-id" field holds a value used by clients and servers to synchronize server responses to client messages. A client SHOULD generate a random number that cannot easily be guessed or predicted to use as the transaction ID for each new message it sends. 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.
“事务id”字段保存客户端和服务器用于同步服务器对客户端消息的响应的值。客户机应该生成一个随机数，该随机数不容易猜测或预测，可以用作它发送的每个新消息的事务ID。请注意，如果客户端生成易于预测的事务标识符，则它可能更容易受到来自非路径入侵者的某些类型的攻击。在重新传输消息时，客户端必须保持事务ID不变。
Clients MUST discard any received Solicit messages.
客户端必须丢弃任何收到的请求消息。
Servers MUST discard any Solicit messages that do not include a Client Identifier option or that do include a Server Identifier option.
服务器必须丢弃任何不包含客户端标识符选项或包含服务器标识符选项的请求消息。
Clients MUST discard any received Advertise messages that meet any of the following conditions:
客户端必须丢弃满足以下任何条件的任何接收到的播发消息：
- the message does not include a Server Identifier option.
- 该消息不包括服务器标识符选项。
- the message does not include a Client Identifier option.
- 该消息不包括客户端标识符选项。
- the contents of the Client Identifier option does not match the client's DUID.
- 客户端标识符选项的内容与客户端的DUID不匹配。
- the "transaction-id" field value does not match the value the client used in its Solicit message.
- “事务id”字段值与客户端在其请求消息中使用的值不匹配。
Servers and relay agents MUST discard any received Advertise messages.
服务器和中继代理必须丢弃任何接收到的播发消息。
Clients MUST discard any received Request messages.
客户端必须丢弃任何接收到的请求消息。
Servers MUST discard any received Request message that meet any of the following conditions:
服务器必须丢弃满足以下任何条件的任何接收到的请求消息：
- the message does not include a Server Identifier option.
- 该消息不包括服务器标识符选项。
- the contents of the Server Identifier option do not match the server's DUID.
- 服务器标识符选项的内容与服务器的DUID不匹配。
- the message does not include a Client Identifier option.
- 该消息不包括客户端标识符选项。
Clients MUST discard any received Confirm messages.
客户端必须丢弃任何收到的确认消息。
Servers MUST discard any received Confirm messages that do not include a Client Identifier option or that do include a Server Identifier option.
服务器必须丢弃任何接收到的不包含客户端标识符选项或包含服务器标识符选项的确认消息。
Clients MUST discard any received Renew messages.
客户端必须丢弃任何接收到的续订消息。
Servers MUST discard any received Renew message that meets any of the following conditions:
服务器必须丢弃满足以下任何条件的任何接收到的续订消息：
- the message does not include a Server Identifier option.
- 该消息不包括服务器标识符选项。
- the contents of the Server Identifier option does not match the server's identifier.
- 服务器标识符选项的内容与服务器的标识符不匹配。
- the message does not include a Client Identifier option.
- 该消息不包括客户端标识符选项。
Clients MUST discard any received Rebind messages.
客户端必须丢弃任何接收到的重新绑定消息。
Servers MUST discard any received Rebind messages that do not include a Client Identifier option or that do include a Server Identifier option.
服务器必须丢弃任何接收到的不包含客户端标识符选项或包含服务器标识符选项的重新绑定消息。
Clients MUST discard any received Decline messages.
客户端必须丢弃任何接收到的拒绝消息。
Servers MUST discard any received Decline message that meets any of the following conditions:
服务器必须丢弃满足以下任何条件的任何接收到的拒绝消息：
- the message does not include a Server Identifier option.
- 该消息不包括服务器标识符选项。
- the contents of the Server Identifier option does not match the server's identifier.
- 服务器标识符选项的内容与服务器的标识符不匹配。
- the message does not include a Client Identifier option.
- 该消息不包括客户端标识符选项。
Clients MUST discard any received Release messages.
客户端必须丢弃任何接收到的发布消息。
Servers MUST discard any received Release message that meets any of the following conditions:
服务器必须丢弃满足以下任何条件的任何接收到的发布消息：
- the message does not include a Server Identifier option.
- 该消息不包括服务器标识符选项。
- the contents of the Server Identifier option does not match the server's identifier.
- 服务器标识符选项的内容与服务器的标识符不匹配。
- the message does not include a Client Identifier option.
- 该消息不包括客户端标识符选项。
Clients MUST discard any received Reply message that meets any of the following conditions:
客户端必须丢弃任何满足以下任何条件的接收回复消息：
- the message does not include a Server Identifier option.
- 该消息不包括服务器标识符选项。
- the "transaction-id" field in the message does not match the value used in the original message.
- 消息中的“事务id”字段与原始消息中使用的值不匹配。
If the client included a Client Identifier option in the original message, the Reply message MUST include a Client Identifier option and the contents of the Client Identifier option MUST match the 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.
如果客户端在原始消息中包含客户端标识符选项，则回复消息必须包含客户端标识符选项，并且客户端标识符选项的内容必须与客户端的DUID匹配；或者，如果客户端未在原始消息中包含客户端标识符选项，则回复消息不得包含客户端标识符选项。
Servers and relay agents MUST discard any received Reply messages.
服务器和中继代理必须丢弃任何收到的回复消息。
Servers and relay agents MUST discard any received Reconfigure messages.
服务器和中继代理必须丢弃任何接收到的重新配置消息。
Clients MUST discard any Reconfigure messages that meets any of the following conditions:
客户端必须丢弃满足以下任何条件的任何重新配置消息：
- the message was not unicast to the client.
- 消息未单播到客户端。
- the message does not include a Server Identifier option.
- 该消息不包括服务器标识符选项。
- the message does not include a Client Identifier option that contains the client's DUID.
- 消息不包括包含客户端DUID的客户端标识符选项。
- the message does not contain a Reconfigure Message option and the msg-type must be a valid value.
- 消息不包含重新配置消息选项，消息类型必须为有效值。
- the message includes any IA options and the msg-type in the Reconfigure Message option is INFORMATION-REQUEST.
- 该消息包含任何IA选项，且重新配置消息选项中的消息类型为INFORMATION-REQUEST。
- the message does not include DHCP authentication:
- 该消息不包括DHCP身份验证：
* the message does not contain an authentication option.
* 消息不包含身份验证选项。
* the message does not pass the authentication validation performed by the client.
* 消息未通过客户端执行的身份验证。
Clients MUST discard any received Information-request messages.
客户端必须丢弃任何接收到的信息请求消息。
Servers MUST discard any received Information-request message that meets any of the following conditions:
服务器必须丢弃满足以下任何条件的任何接收到的信息请求消息：
- The message includes a Server Identifier option and the DUID in the option does not match the server's DUID.
- 该消息包含服务器标识符选项，该选项中的DUID与服务器的DUID不匹配。
- The message includes an IA option.
- 该消息包含一个IA选项。
Clients MUST discard any received Relay-forward messages.
客户端必须丢弃任何接收到的中继转发消息。
Clients and servers MUST discard any received Relay-reply messages.
客户端和服务器必须丢弃任何接收到的中继回复消息。
When a client sends a DHCP message to the All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message through the interface for which configuration information is being requested. However, the client MAY send the message through another interface attached to the same link, if and only if the client is certain the two interfaces are attached to the same link. The client MUST use a link-local address assigned to the interface for which it is requesting configuration information as the source address in the header of the IP datagram.
当客户端将DHCP消息发送到所有\u DHCP\u中继\u代理\u和\u服务器地址时，它应通过请求配置信息的接口发送消息。然而，当且仅当客户端确定两个接口连接到同一链路时，客户端可以通过连接到同一链路的另一个接口发送消息。客户端必须使用分配给其请求配置信息的接口的链路本地地址作为IP数据报报头中的源地址。
When a client sends a DHCP message directly to a server using unicast (after receiving the Server Unicast option from that server), the source address in the header of the IP datagram MUST be an address assigned to the interface for which the client is interested in obtaining configuration and which is suitable for use by the server in responding to the client.
当客户端使用单播直接向服务器发送DHCP消息时（从该服务器接收到服务器单播选项后），IP数据报报头中的源地址必须是分配给接口的地址，客户机有兴趣获取该接口的配置，并且该地址适合服务器在响应客户机时使用。
This section describes how a client locates servers that will assign addresses to IAs belonging to the client.
本节描述客户机如何定位将为属于客户机的IAs分配地址的服务器。
The client is responsible for creating IAs and requesting that a server assign IPv6 addresses to the IA. The client first creates an IA and assigns it an IAID. The client then transmits a Solicit message containing an IA option describing the IA. Servers that can assign addresses to the IA respond to the client with an Advertise message. The client then initiates a configuration exchange as described in section 18.
客户端负责创建IA，并请求服务器为IA分配IPv6地址。客户端首先创建一个IA并为其分配一个IAID。然后，客户端发送一条请求消息，其中包含描述IA的IA选项。可以为IA分配地址的服务器会向客户端发送播发消息。然后，客户机启动第18节所述的配置交换。
If the client will accept a Reply message with committed address assignments and other resources in response to the Solicit message, the client includes a Rapid Commit option (see section 22.14) in the Solicit message.
如果客户端将接受带有提交地址分配和其他资源的回复消息以响应请求消息，则客户端将在请求消息中包括快速提交选项（参见第22.14节）。
A client uses the Solicit message to discover DHCP servers configured to assign addresses or return other configuration parameters on the link to which the client is attached.
客户端使用请求消息来发现配置为在客户端所连接的链接上分配地址或返回其他配置参数的DHCP服务器。
The client sets the "msg-type" field to SOLICIT. The client generates a transaction ID and inserts this value in the "transaction-id" field.
客户端将“msg type”字段设置为请求。客户端生成一个事务ID并将该值插入“事务ID”字段。
The client MUST include a Client Identifier option to identify itself to the server. The client includes IA options for any IAs to which it wants the server to assign addresses. The client MAY include addresses in the IAs as a hint to the server about addresses for which the client has a preference. The client MUST NOT include any other options in the Solicit message, except as specifically allowed in the definition of individual options.
客户机必须包含一个客户机标识符选项，以便向服务器标识自己。客户机包括其希望服务器向其分配地址的任何IAs的IA选项。客户机可以在IAs中包含地址，作为向服务器提示客户机优先选择的地址的提示。客户不得在征求信息中包含任何其他选项，除非个别选项定义中明确允许。
The client uses IA_NA options to request the assignment of non-temporary addresses and uses IA_TA options to request the assignment of temporary addresses. Either IA_NA or IA_TA options, or a combination of both, can be included in DHCP messages.
客户端使用IA_NA选项请求分配非临时地址，并使用IA_TA选项请求分配临时地址。DHCP消息中可以包含IA_NA或IA_TA选项，或两者的组合。
The client SHOULD include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY additionally include instances of those options that are identified in the Option Request option, with data values as hints to the server about parameter values the client would like to have returned.
客户应包括一个选项请求选项（见第22.7节），以表明客户有兴趣接收的选项。客户机还可以包括在选项请求选项中标识的那些选项的实例，并将数据值作为关于客户机希望返回的参数值的提示发送给服务器。
The client includes a Reconfigure Accept option (see section 22.20) if the client is willing to accept Reconfigure messages from the server.
如果客户机愿意接受来自服务器的重新配置消息，则客户机包括重新配置接受选项（参见第22.20节）。
The first Solicit message from the client on the interface MUST be delayed by a random amount of time between 0 and SOL_MAX_DELAY. In the case of a Solicit message transmitted when DHCP is initiated by IPv6 Neighbor Discovery, the delay gives the amount of time to wait after IPv6 Neighbor Discovery causes the client to invoke the stateful address autoconfiguration protocol (see section 5.5.3 of RFC 2462). This random delay desynchronizes clients which start at the same time (for example, after a power outage).
来自接口上客户端的第一条请求消息必须延迟0到SOL_MAX_DELAY之间的随机时间量。在IPv6邻居发现启动DHCP时发送请求消息的情况下，延迟提供了IPv6邻居发现导致客户端调用有状态地址自动配置协议后的等待时间（请参阅RFC 2462第5.5.3节）。这种随机延迟会使同时启动的客户端（例如，断电后）失去同步。
The client transmits the message according to section 14, using the following parameters:
客户端使用以下参数根据第14节传输消息：
IRT SOL_TIMEOUT
IRT SOL_超时
MRT SOL_MAX_RT
捷运Solu\u MAX\u RT
MRC 0
MRC 0
MRD 0
MRD 0
If the client has included a Rapid Commit option in its Solicit message, the client terminates the waiting process as soon as a Reply message with a Rapid Commit option is received.
如果客户端在其请求消息中包含快速提交选项，则客户端在收到带有快速提交选项的回复消息后立即终止等待过程。
If the client is waiting for an Advertise message, the mechanism in section 14 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before the first RT has elapsed. Rather, the client collects Advertise messages until the first RT has elapsed. Also, the first RT MUST be selected to be strictly greater than IRT by choosing RAND to be strictly greater than 0.
如果客户端正在等待播发消息，则将第14部分中的机制修改如下，以用于请求消息的传输。在第一次RT结束之前，消息交换不会因收到播发而终止。相反，客户端收集播发消息，直到第一个RT结束。此外，通过选择RAND严格大于0，必须选择第一个RT严格大于IRT。
A client MUST collect Advertise messages for the first RT seconds, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 22.8). Any Advertise that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message that includes a Preference option with a preference value of 255, the client immediately begins a client-initiated message exchange (as described in section 18) by sending a Request message to the server from which the Advertise message was received. If the client receives an Advertise message that does not include a Preference option with a preference value of 255, the client continues to wait until the first RT elapses. If the first RT elapses and the client has received an Advertise message, the client SHOULD continue with a client-initiated message exchange by sending a Request message.
客户端必须在第一个RT秒收集播发消息，除非它接收到首选项值为255的播发消息。首选项值包含在首选项选项中（第22.8节）。任何不包含首选项选项的播发都被视为首选项值为0。如果客户端接收到包含首选项选项（首选项值为255）的播发消息，则客户端通过向接收播发消息的服务器发送请求消息，立即开始客户端发起的消息交换（如第18节所述）。如果客户端接收到不包含首选项值为255的首选项选项的播发消息，则客户端将继续等待，直到第一个RT过期。如果第一个RT已过，并且客户端已收到播发消息，则客户端应通过发送请求消息继续进行客户端启动的消息交换。
If the client does not receive any Advertise messages before the first RT has elapsed, it begins the retransmission mechanism described in section 14. The client terminates the retransmission process as soon as it receives any Advertise message, and the client acts on the received Advertise message without waiting for any additional Advertise messages.
如果客户机在第一个RT过去之前没有接收到任何播发消息，则它开始第14节中描述的重传机制。客户端在接收到任何播发消息后立即终止重传过程，并且客户端在不等待任何附加播发消息的情况下对接收到的播发消息进行操作。
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 0, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it SHOULD restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link.
DHCP客户端应将MRC和MRD选择为0。如果配置DHCP客户端时将MRC或MRD设置为0以外的值，则在消息交换失败时，它必须停止尝试配置接口。DHCP客户端停止尝试配置接口后，应在某些外部事件（如用户输入、系统重新启动或客户端连接到新链接）后重新启动重新配置过程。
The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user.
客户端必须忽略任何包含包含值NOADRSAVAIL的状态代码选项的播发消息，但客户端可能会向用户显示关联的状态消息除外。
Upon receipt of one or more valid Advertise messages, the client selects one or more Advertise messages based upon the following criteria.
在收到一个或多个有效的播发消息后，客户端根据以下条件选择一个或多个播发消息。
- Those Advertise messages with the highest server preference value are preferred over all other Advertise messages.
- 具有最高服务器首选项值的播发消息优先于所有其他播发消息。
- Within a group of Advertise messages with the same server preference value, a client MAY select those servers whose Advertise messages advertise information of interest to the client. For example, the client may choose a server that returned an advertisement with configuration options of interest to the client.
- 在具有相同服务器首选项值的一组播发消息中，客户机可以选择那些其播发消息播发客户机感兴趣的信息的服务器。例如，客户机可以选择返回具有客户机感兴趣的配置选项的广告的服务器。
- The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs.
- 如果服务器具有一组更好的公布参数，例如在IAs中公布的可用地址，则客户端可以选择一个不太首选的服务器。
Once a client has selected Advertise message(s), the client will typically store information about each server, such as server preference value, addresses advertised, when the advertisement was received, and so on.
一旦客户机选择了播发消息，客户机通常将存储关于每个服务器的信息，例如服务器首选项值、播发地址、接收播发的时间等。
If the client needs to select an alternate server in the case that a chosen server does not respond, the client chooses the next server according to the criteria given above.
如果客户机需要在所选服务器未响应的情况下选择备用服务器，则客户机将根据上述标准选择下一台服务器。
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 response. The client discards any Reply messages it receives that do not include a Rapid Commit option. If the client receives 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.
如果客户机在请求消息中包含快速提交选项，则它将期望收到一条应答消息，该消息在应答中包含快速提交选项。客户端将丢弃它收到的任何不包含快速提交选项的回复消息。如果客户端接收到包含快速提交选项的有效回复消息，它将按照第18.1.8节所述处理该消息。如果客户机未收到此类回复消息且收到有效的播发消息，则客户机将按照第17.1.3节所述处理播发消息。
If the client subsequently receives a valid Reply message that includes a Rapid Commit option, it either:
如果客户端随后收到包含快速提交选项的有效回复消息，则会：
processes the Reply message as described in section 18.1.8, and discards any Reply messages received in response to the Request message, or
按照第18.1.8节所述处理回复消息，并丢弃响应请求消息而收到的任何回复消息，或
processes any Reply messages received in response to the Request message and discards the Reply message that includes the Rapid Commit option.
处理响应请求消息而收到的任何回复消息，并丢弃包含快速提交选项的回复消息。
A server sends an Advertise message in response to valid Solicit messages it receives to announce the availability of the server to the client.
服务器发送播发消息以响应其接收到的有效请求消息，从而向客户端宣布服务器的可用性。
The server determines the information about the client and its location as described in section 11 and checks its administrative policy about responding to the client. If the server is not permitted to respond to the client, the server discards the Solicit message. For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client indicates with a Reconfigure Accept option in the Solicit message that it will not accept a Reconfigure message, the servers discard the Solicit message.
如第11节所述，服务器确定有关客户端及其位置的信息，并检查其有关响应客户端的管理策略。如果不允许服务器响应客户端，服务器将丢弃请求消息。例如，如果服务器的管理策略是，它可能只响应愿意接受重新配置消息的客户端，则如果客户端在请求消息中使用重新配置接受选项指示它将不接受重新配置消息，则服务器将丢弃请求消息。
If the client has included a Rapid Commit option in the Solicit message and the server has been configured to respond with committed address assignments and other resources, the server responds to the Solicit with a Reply message as described in section 17.2.3. Otherwise, the server ignores the Rapid Commit option and processes the remainder of the message as if no Rapid Commit option were present.
如果客户端已在请求消息中包含快速提交选项，并且服务器已配置为使用提交的地址分配和其他资源进行响应，则服务器将使用第17.2.3节中所述的回复消息响应请求。否则，服务器将忽略快速提交选项并处理消息的其余部分，就像不存在快速提交选项一样。
The server sets the "msg-type" field to ADVERTISE and copies the contents of the transaction-id field from the Solicit message received from the client to the Advertise message. The server includes its server identifier in a Server Identifier option and copies the Client Identifier from the Solicit message into the Advertise message.
服务器将“msg type”字段设置为播发，并将事务id字段的内容从从客户端接收的请求消息复制到播发消息。服务器在服务器标识符选项中包含其服务器标识符，并将客户机标识符从请求消息复制到播发消息中。
The server MAY add a Preference option to carry the preference value for the Advertise message. The server implementation SHOULD allow the setting of a server preference value by the administrator. The server preference value MUST default to zero unless otherwise configured by the server administrator.
服务器可以添加一个首选项选项来携带广告消息的首选项值。服务器实现应允许管理员设置服务器首选项值。服务器首选项值必须默认为零，除非服务器管理员另有配置。
The server includes a Reconfigure Accept option if the server wants to require that the client accept Reconfigure messages.
如果服务器希望要求客户端接受重新配置消息，则服务器包含重新配置接受选项。
The server includes options the server will return to the client in a subsequent Reply message. The information in these options may 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 must be aware of the recommendations on packet sizes and the use of fragmentation in section 5 of RFC 2460.
服务器包含服务器将在后续回复消息中返回给客户端的选项。如果客户机接收到多个播发消息，则客户机可以在选择服务器时使用这些选项中的信息。如果客户端已在请求消息中包含选项请求选项，则服务器将在播发消息中包含选项，其中包含服务器已配置为返回客户端的选项请求选项中标识的所有选项的配置参数。如果已将服务器配置为向客户端返回其他选项，则服务器可能会向客户端返回这些选项。服务器必须了解RFC 2460第5节中关于数据包大小和碎片使用的建议。
If the Solicit message from the client included one or more IA options, the server MUST include IA options in the Advertise message containing any addresses that would be assigned to IAs contained in the Solicit message from the client. If the client has included addresses in the IAs in the Solicit message, the server uses those addresses as hints about the addresses the client would like to receive.
如果来自客户端的请求消息包含一个或多个IA选项，则服务器必须在包含将分配给来自客户端的请求消息中包含的IAs的任何地址的播发消息中包含IA选项。如果客户端在请求消息中的IAs中包含了地址，服务器将使用这些地址作为有关客户端希望接收的地址的提示。
If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID.
如果服务器在来自客户端的后续请求中不会将任何地址分配给任何IAs，则服务器必须向客户端发送一条播发消息，该消息仅包括一个带有代码NOADRSAVAIL的状态代码选项和一条针对用户的状态消息，一个带有服务器DUID的服务器标识符选项，以及一个带有客户端DUID的客户端标识符选项。
If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the address in the source address field from the IP datagram in which the Solicit message was received. The Advertise message MUST be unicast on the link from which the Solicit message was received.
如果服务器直接接收到请求消息，则服务器使用接收到请求消息的IP数据报的源地址字段中的地址，将播发消息直接单播到客户端。播发消息必须在接收请求消息的链接上单播。
If the Solicit message was received in a Relay-forward message, the server constructs a Relay-reply message with the Advertise message in the payload of a "relay-message" option. If the Relay-forward messages included an Interface-id option, the server copies that option to the Relay-reply message. The server unicasts the Relay-reply message directly to the relay agent using the address in
如果在中继转发消息中接收到请求消息，则服务器将在“中继消息”选项的有效负载中使用播发消息构造中继回复消息。如果中继转发消息包含接口id选项，则服务器会将该选项复制到中继回复消息。服务器使用中的地址将中继回复消息直接单播到中继代理
the source address field from the IP datagram in which the Relay-forward message was received.
IP数据报中接收中继转发消息的源地址字段。
The server MUST commit the assignment of any addresses or other configuration information message before sending a Reply message to a client in response to a Solicit message.
在向客户端发送回复消息以响应请求消息之前，服务器必须提交任何地址或其他配置信息消息的分配。
DISCUSSION:
讨论：
When using the Solicit-Reply message exchange, the server commits the assignment of any addresses before sending the Reply message. The client can assume it has been assigned the addresses in the Reply message and does not need to send a Request message for those addresses.
使用请求回复邮件交换时，服务器在发送回复邮件之前提交任何地址的分配。客户机可以假定已在回复消息中为其分配了地址，而不需要为这些地址发送请求消息。
Typically, servers that are configured to use the Solicit-Reply message exchange will be deployed so that only one server will respond to a Solicit message. If more than one server responds, the client will only use the addresses from one of the servers, while the addresses from the other servers will be committed to the client but not used by the client.
通常，将部署配置为使用请求-答复消息交换的服务器，以便只有一台服务器响应请求消息。如果有多个服务器响应，客户端将只使用其中一个服务器的地址，而其他服务器的地址将提交给客户端，但客户端不使用。
The server includes a Rapid Commit option in the Reply message to indicate that the Reply is in response to a Solicit message.
服务器在回复消息中包含一个快速提交选项，以指示回复是对请求消息的响应。
The server includes a Reconfigure Accept option if the server wants to require that the client accept Reconfigure messages.
如果服务器希望要求客户端接受重新配置消息，则服务器包含重新配置接受选项。
The server produces the Reply message as though it had received a Request message, as described in section 18.2.1. The server transmits the Reply message as described in section 18.2.8.
如第18.2.1节所述，服务器产生回复消息，就好像它收到了请求消息一样。服务器按照第18.2.8节所述发送回复消息。
A client initiates a message exchange with a server or servers to acquire or update configuration information of interest. The client may initiate the configuration exchange as part of the operating system configuration process, when requested to do so by the application layer, when required by Stateless Address Autoconfiguration or as required to extend the lifetime of an address (Renew and Rebind messages).
客户端启动与一个或多个服务器的消息交换，以获取或更新感兴趣的配置信息。当应用层请求进行配置交换时，当无状态地址自动配置需要时，或当需要延长地址的生存期（续订和重新绑定消息）时，客户端可以作为操作系统配置过程的一部分启动配置交换。
A client uses Request, Renew, Rebind, Release and Decline messages during the normal life cycle of addresses. It uses Confirm to validate addresses when it may have moved to a new link. It uses Information-Request messages when it needs configuration information but no addresses.
客户端在地址的正常生命周期内使用请求、续订、重新绑定、释放和拒绝消息。当它可能已移动到新链接时，它使用确认来验证地址。当它需要配置信息但不需要地址时，它使用信息请求消息。
If the client has a source address of sufficient scope that can be used by the server 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.
如果客户端具有足够范围的源地址，服务器可以将其用作返回地址，并且客户端已从服务器接收到服务器单播选项（第22.12节），则客户端应向服务器单播任何请求、续订、释放和拒绝消息。
DISCUSSION:
讨论：
Use of unicast may avoid delays due to the relaying of messages by relay agents, as well as avoid overhead and duplicate responses by servers due to the 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.
使用单播可以避免由于中继代理转发消息而导致的延迟，以及避免由于将客户端消息传递到多个服务器而导致服务器的开销和重复响应。要求客户端通过中继代理中继所有DHCP消息可以在客户端发送的所有消息中包含中继代理选项。只有在不使用中继代理选项时，服务器才应启用单播。
The client uses a Request message to populate IAs with addresses and obtain other configuration information. The client includes one or more IA options in the Request message. The server then returns addresses and other information about the IAs to the client in IA options in a Reply message.
客户端使用请求消息用地址填充IAs并获取其他配置信息。客户端在请求消息中包含一个或多个IA选项。然后，服务器将地址和有关IAs的其他信息以回复消息的形式返回到IA选项中的客户端。
The client generates a transaction ID and inserts this value in the "transaction-id" field.
客户端生成一个事务ID并将该值插入“事务ID”字段。
The client places the identifier of the destination server in a Server Identifier option.
客户端将目标服务器的标识符放置在服务器标识符选项中。
The client MUST include a Client Identifier option to identify itself to the server. The client adds any other appropriate options, including one or more IA options (if the client is requesting that the server assign it some network addresses).
客户机必须包含一个客户机标识符选项，以便向服务器标识自己。客户端添加任何其他适当的选项，包括一个或多个IA选项（如果客户端请求服务器为其分配一些网络地址）。
The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.
客户必须包括一个选项请求选项（见第22.7节），以表明客户有兴趣接收的选项。客户机可能包括带有数据值的选项，作为向服务器提示客户机希望返回的参数值。
The client includes a Reconfigure Accept option (see section 22.20) indicating whether or not the client is willing to accept Reconfigure messages from the server.
客户机包括一个重新配置接受选项（参见第22.20节），指示客户机是否愿意接受来自服务器的重新配置消息。
The client transmits the message according to section 14, using the following parameters:
客户端使用以下参数根据第14节传输消息：
IRT REQ_TIMEOUT
请求超时
MRT REQ_MAX_RT
捷运需求最大值
MRC REQ_MAX_RC
MRC要求最大值
MRD 0
MRD 0
If the message exchange fails, the client takes an action based on the client's local policy. Examples of actions the client might take include:
如果消息交换失败，客户端将根据客户端的本地策略采取操作。客户可能采取的行动示例包括：
- Select another server from a list of servers known to the client; for example, servers that responded with an Advertise message.
- 从客户端已知的服务器列表中选择另一台服务器；例如，以播发消息响应的服务器。
- Initiate the server discovery process described in section 17.
- 启动第17节中描述的服务器发现过程。
- Terminate the configuration process and report failure.
- 终止配置过程并报告故障。
Whenever a client may have moved to a new link, the prefixes from the addresses assigned to the interfaces on that link may no longer be appropriate for the link to which the client is attached. Examples of times when a client may have moved to a new link include:
每当客户端移动到新链接时，分配给该链接上接口的地址的前缀可能不再适用于客户端所连接的链接。客户机可能已移动到新链接的时间示例包括：
o The client reboots.
o 客户端重新启动。
o The client is physically connected to a wired connection.
o 客户端物理连接到有线连接。
o The client returns from sleep mode.
o 客户端从睡眠模式返回。
o The client using a wireless technology changes access points.
o 使用无线技术的客户端更改访问点。
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 assigned to the interface that may have moved to a new link, along with the addresses associated with those IAs, in its
在客户端可能已移动到新链接的任何情况下，客户端必须启动确认/回复消息交换。客户机包括分配给接口的、可能已移动到新链接的任何IAs，以及与这些IAs关联的地址
Confirm message. Any responding servers will indicate whether those addresses are appropriate for the link to which the client is attached with the status in the Reply message it returns to the client.
确认消息。任何响应服务器都将指示这些地址是否适用于客户端所连接的链接，并在其返回给客户端的回复消息中显示状态。
The client sets the "msg-type" field to CONFIRM. The client generates a transaction ID and inserts this value in the "transaction-id" field.
客户端将“msg type”字段设置为确认。客户端生成一个事务ID并将该值插入“事务ID”字段。
The client MUST include a Client Identifier option to identify itself to the server. The client includes IA options for all of the IAs assigned to the interface for which the Confirm message is being sent. The IA options include all of the addresses the client currently has associated with those IAs. The client SHOULD set the T1 and T2 fields in any IA_NA options, and the preferred-lifetime and valid-lifetime fields in the IA Address options to 0, as the server will ignore these fields.
客户机必须包含一个客户机标识符选项，以便向服务器标识自己。客户端包括分配给发送确认消息的接口的所有IA的IA选项。IA选项包括客户端当前与这些IAs关联的所有地址。客户端应将任何IA_NA选项中的T1和T2字段以及IA Address选项中的首选生存期和有效生存期字段设置为0，因为服务器将忽略这些字段。
The first Confirm message from the client on the interface MUST be delayed by a random amount of time between 0 and CNF_MAX_DELAY. The client transmits the message according to section 14, using the following parameters:
来自接口上客户端的第一条确认消息必须延迟0到CNF_MAX_DELAY之间的随机时间量。客户端使用以下参数根据第14节传输消息：
IRT CNF_TIMEOUT
IRT CNF_超时
MRT CNF_MAX_RT
捷运CNF_MAX_RT
MRC 0
MRC 0
MRD CNF_MAX_RD
MRD CNF_MAX_路
If the client receives no responses before the message transmission process terminates, as described in section 14, the client SHOULD continue to use any IP addresses, using the last known lifetimes for those addresses, and SHOULD continue to use any other previously obtained configuration parameters.
如第14节所述，如果客户机在消息传输过程终止前未收到任何响应，则客户机应继续使用任何IP地址，使用这些地址的最后一个已知生存期，并应继续使用先前获得的任何其他配置参数。
To extend the valid and preferred lifetimes for the addresses associated with an IA, the client sends a Renew message to 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 administrative configuration of the server. The server may also add
为了延长与IA关联的地址的有效和首选生存期，客户机向服务器发送续订消息，客户机从服务器获取IA中的地址，其中包含IA的IA选项。客户端在IA选项中包含IA地址选项，用于与IA关联的地址。服务器根据服务器的管理配置确定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 zero.
国际机场管理局的新地址。服务器可以通过将这些地址的首选和有效生存期设置为零，从IA中删除这些地址。
The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 and T2 parameters assigned to an IA.
服务器通过分配给IA的T1和T2参数控制客户端与服务器联系以延长分配地址的生存期的时间。
At time T1 for an IA, the client initiates a Renew/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Renew message.
在IA的时间T1，客户端启动续订/应答消息交换，以延长IA中任何地址的生存期。客户端包括一个IA选项，该选项在其续订消息中包含当前分配给IA的所有地址。
If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind message, respectively, at the client's discretion.
如果服务器（对于IA_-NA）将T1或T2设置为0，或者没有T1或T2时间（对于IA_-TA），则客户机可自行决定分别发送续订或重新绑定消息。
The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-id" field.
客户端将“消息类型”字段设置为续订。客户端生成一个事务ID并将该值插入“事务ID”字段。
The client places the identifier of the destination server in a Server Identifier option.
客户端将目标服务器的标识符放置在服务器标识符选项中。
The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options. The client MUST include the list of addresses the client currently has associated with the IAs in the Renew message.
客户机必须包含一个客户机标识符选项，以便向服务器标识自己。客户端添加任何适当的选项，包括一个或多个IA选项。客户端必须在续订消息中包含客户端当前与IAs关联的地址列表。
The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.
客户必须包括一个选项请求选项（见第22.7节），以表明客户有兴趣接收的选项。客户机可能包括带有数据值的选项，作为向服务器提示客户机希望返回的参数值。
The client transmits the message according to section 14, using the following parameters:
客户端使用以下参数根据第14节传输消息：
IRT REN_TIMEOUT
IRT RENU超时
MRT REN_MAX_RT
捷运站
MRC 0
MRC 0
MRD Remaining time until T2
MRD到T2的剩余时间
The message exchange is terminated when time T2 is reached (see section 18.1.4), at which time the client begins a Rebind message exchange.
当到达时间T2（见第18.1.4节）时，消息交换终止，此时客户端开始重新绑定消息交换。
At time T2 for an IA (which will only be reached if the server to which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange with any available server. The client includes an IA option with all addresses currently assigned to the IA in its Rebind message.
对于IA，在时间T2（仅当在时间T1向其发送续订消息的服务器未响应时才会到达），客户端启动与任何可用服务器的重新绑定/回复消息交换。客户机包括一个IA选项，该选项在其重新绑定消息中包含当前分配给IA的所有地址。
The client sets the "msg-type" field to REBIND. The client generates a transaction ID and inserts this value in the "transaction-id" field.
客户端将“msg type”字段设置为重新绑定。客户端生成一个事务ID并将该值插入“事务ID”字段。
The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options. The client MUST include the list of addresses the client currently has associated with the IAs in the Rebind message.
客户机必须包含一个客户机标识符选项，以便向服务器标识自己。客户端添加任何适当的选项，包括一个或多个IA选项。客户端必须在重新绑定消息中包含客户端当前与IAs关联的地址列表。
The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.
客户必须包括一个选项请求选项（见第22.7节），以表明客户有兴趣接收的选项。客户机可能包括带有数据值的选项，作为向服务器提示客户机希望返回的参数值。
The client transmits the message according to section 14, using the following parameters:
客户端使用以下参数根据第14节传输消息：
IRT REB_TIMEOUT
IRT REB_超时
MRT REB_MAX_RT
捷运快线快线
MRC 0
MRC 0
MRD Remaining time until valid lifetimes of all addresses have expired
MRD在所有地址的有效生存期到期之前的剩余时间
The message exchange is terminated when the valid lifetimes of all the addresses assigned to the IA expire (see section 10), at which time the client has several alternative actions to choose from; for example:
当分配给IA的所有地址的有效生存期到期（见第10节）时，消息交换终止，此时客户端可以选择多个备选操作；例如：
- The client may choose to use a Solicit message to locate a new DHCP server and send a Request for the expired IA to the new server.
- 客户端可以选择使用请求消息来定位新的DHCP服务器，并向新服务器发送过期IA的请求。
- The client may have other addresses in other IAs, so the client may choose to discard the expired IA and use the addresses in the other IAs.
- 客户机可能在其他IAs中有其他地址，因此客户机可以选择放弃过期的IA并使用其他IAs中的地址。
The client uses an Information-request message to obtain configuration information without having addresses assigned to it.
客户端使用信息请求消息来获取配置信息，而无需为其分配地址。
The client sets the "msg-type" field to INFORMATION-REQUEST. The client generates a transaction ID and inserts this value in the "transaction-id" field.
客户端将“msg type”字段设置为INFORMATION-REQUEST。客户端生成一个事务ID并将该值插入“事务ID”字段。
The client SHOULD include a Client Identifier option to identify itself to the server. If the client does not include a Client Identifier option, the server will not be able to return any client-specific options to the client, or the server may choose not to respond to the message at all. The client MUST include a Client Identifier option if the Information-Request message will be authenticated.
客户机应该包括一个客户机标识符选项，以便向服务器标识自己。如果客户端不包括客户端标识符选项，服务器将无法向客户端返回任何特定于客户端的选项，或者服务器可能选择根本不响应消息。如果要对信息请求消息进行身份验证，则客户端必须包含客户端标识符选项。
The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.
客户必须包括一个选项请求选项（见第22.7节），以表明客户有兴趣接收的选项。客户机可能包括带有数据值的选项，作为向服务器提示客户机希望返回的参数值。
The first Information-request message from the client on the interface MUST be delayed by a random amount of time between 0 and INF_MAX_DELAY. The client transmits the message according to section 14, using the following parameters:
来自接口上客户端的第一条信息请求消息必须延迟0到INF_MAX_DELAY之间的随机时间量。客户端使用以下参数根据第14节传输消息：
IRT INF_TIMEOUT
IRT INF\u超时
MRT INF_MAX_RT
MRT INF\u MAX\u RT
MRC 0
MRC 0
MRD 0
MRD 0
To release one or more addresses, a client sends a Release message to the server.
要释放一个或多个地址，客户端将向服务器发送一条释放消息。
The client sets the "msg-type" field to RELEASE. The client generates a transaction ID and places this value in the "transaction-id" field.
客户端将“msg type”字段设置为RELEASE。客户端生成一个事务ID，并将该值放在“事务ID”字段中。
The client places the identifier of the server that allocated the address(es) in a Server Identifier option.
客户端将分配地址的服务器的标识符放置在服务器标识符选项中。
The client MUST include a Client Identifier option to identify itself to the server. The client includes options containing the IAs for the addresses it is releasing in the "options" field. The addresses to be released MUST be included in the IAs. Any addresses for the IAs the client wishes to continue to use MUST NOT be added to the IAs.
客户机必须包含一个客户机标识符选项，以便向服务器标识自己。客户机在“选项”字段中包含包含其正在发布的地址的IAs的选项。要发布的地址必须包含在IAs中。客户希望继续使用的IAs地址不得添加到IAs中。
The client MUST NOT use any of the addresses it is releasing as the source address in the Release message or in any subsequently transmitted message.
客户端不得将其正在发布的任何地址用作发布消息或任何后续传输消息中的源地址。
Because Release messages may be lost, the client should retransmit the Release if no Reply is received. However, there are scenarios where the client may not wish to wait for the normal retransmission timeout before giving up (e.g., on power down). Implementations SHOULD retransmit one or more times, but MAY choose to terminate the retransmission procedure early.
因为发布消息可能会丢失，所以如果没有收到回复，客户端应该重新传输发布。但是，在某些情况下，客户端可能不希望在放弃之前等待正常的重新传输超时（例如，断电）。实现应该重传一次或多次，但可以选择提前终止重传过程。
The client transmits the message according to section 14, using the following parameters:
客户端使用以下参数根据第14节传输消息：
IRT REL_TIMEOUT
IRT REL_超时
MRT 0
地铁0
MRC REL_MAX_RC
MRC REL_MAX_RC
MRD 0
MRD 0
The client MUST stop using all of the addresses being released as soon as the client begins the Release message exchange process. If addresses are released but the Reply from a DHCP server is lost, the client will retransmit the Release message, and the server may respond with a Reply indicating a status of NoBinding. Therefore, the client does not treat a Reply message with a status of NoBinding in a Release message exchange as if it indicates an error.
一旦客户端开始释放消息交换过程，客户端必须停止使用所有被释放的地址。如果释放了地址，但DHCP服务器的回复丢失，则客户端将重新传输释放消息，服务器可能会用指示NoBinding状态的回复进行响应。因此，客户端不会将发布消息交换中状态为NoBinding的回复消息视为指示错误。
Note that if the client fails to release the addresses, each address assigned to the IA will be reclaimed by the server when the valid lifetime of that address expires.
请注意，如果客户端未能释放地址，则分配给IA的每个地址将在该地址的有效生存期到期时由服务器回收。
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 a transaction ID and places this value in the "transaction-id" field.
客户端将“消息类型”字段设置为拒绝。客户端生成一个事务ID，并将该值放在“事务ID”字段中。
The client places the identifier of the server that allocated the address(es) in a Server Identifier option.
客户端将分配地址的服务器的标识符放置在服务器标识符选项中。
The client MUST include a Client Identifier option to identify itself to the server. The client includes options containing the IAs for the addresses it is declining in the "options" field. The addresses 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 the IAs.
客户机必须包含一个客户机标识符选项，以便向服务器标识自己。客户机在“选项”字段中包含包含其拒绝的地址的IAs的选项。要拒绝的地址必须包含在IAs中。客户希望继续使用的IAs地址不应添加到IAs中。
The client MUST NOT use any of the addresses it is declining as the source address in the Decline message or in any subsequently transmitted message.
客户端不得将其拒绝的任何地址用作拒绝消息或任何后续传输消息中的源地址。
The client transmits the message according to section 14, using the following parameters:
客户端使用以下参数根据第14节传输消息：
IRT DEC_TIMEOUT
IRT DEC_超时
MRT 0
地铁0
MRC DEC_MAX_RC
MRC DEC_MAX_RC
MRD 0
MRD 0
If addresses are declined but the Reply from a DHCP server is lost, the client will retransmit the Decline message, and the server may respond with a Reply indicating a status of NoBinding. Therefore, the client does not treat a Reply message with a status of NoBinding in a Decline message exchange as if it indicates an error.
如果地址被拒绝，但来自DHCP服务器的回复丢失，客户端将重新传输拒绝消息，服务器可能会用指示NoBinding状态的回复进行响应。因此，在拒绝消息交换中，客户端不会将状态为NoBinding的回复消息视为指示错误。
Upon the receipt of a valid Reply message in response to a Solicit (with a Rapid Commit option), Request, Confirm, Renew, Rebind or Information-request message, the client extracts the configuration
在收到响应请求（具有快速提交选项）、请求、确认、续订、重新绑定或信息请求消息的有效回复消息后，客户端提取配置
information contained in the Reply. The client MAY choose to report any status code or message from the status code option in the Reply message.
答复中所载的资料。客户端可以从回复消息中的状态代码选项中选择报告任何状态代码或消息。
The client SHOULD perform duplicate address detection [17] 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.
在使用该地址进行通信之前，客户端应在其在回复消息中收到的任何IAs中的每个地址上执行重复地址检测[17]。如果发现任何地址在链路上使用，客户端将向服务器发送拒绝消息，如第18.1.7节所述。
If the Reply was received in response to a Solicit (with a Rapid Commit option), Request, Renew or Rebind message, the client updates the information it has recorded about IAs from the IA options contained in the Reply message:
如果收到回复是对请求（具有快速提交选项）、请求、续订或重新绑定消息的响应，则客户机会根据回复消息中包含的IA选项更新其记录的有关IAs的信息：
- Record T1 and T2 times.
- 记录T1和T2次。
- Add any new addresses in the IA option to the IA as recorded by the client.
- 将IA选项中的任何新地址添加到客户端记录的IA中。
- Update lifetimes for any addresses in the IA option that the client already has recorded in the IA.
- 更新IA选项中客户端已在IA中记录的任何地址的生存期。
- Discard any addresses from the IA, as recorded by the client, that have a valid lifetime of 0 in the IA Address option.
- 丢弃客户端记录的IA地址中IA地址选项中有效生存期为0的所有地址。
- Leave unchanged any information about addresses the client has recorded in the IA but that were not included in the IA from the server.
- 保留有关客户端已记录在IA中但未包含在服务器IA中的地址的任何信息不变。
Management of the specific configuration information is detailed in the definition of each option in section 22.
具体配置信息的管理详见第22节中每个选项的定义。
If the client receives a Reply message with a Status Code containing UnspecFail, the server is indicating that it was unable to process the message due to an unspecified failure condition. If the client retransmits the original message to the same server to retry the desired operation, the client MUST limit the rate at which it retransmits the message and limit the duration of the time during which it retransmits the message.
如果客户端接收到状态代码包含UnspecFail的回复消息，则服务器表示由于未指定的故障条件，它无法处理该消息。如果客户端将原始消息重新传输到同一服务器以重试所需操作，则客户端必须限制其重新传输消息的速率，并限制其重新传输消息的持续时间。
When the client receives a Reply message with a Status Code option with the 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.
当客户端接收到一条带有状态代码选项且值为UseMulticast的回复消息时，客户端会记录消息的接收情况，并通过使用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 indicate a NotOnLink status.
当客户机收到来自服务器的NotOnLink状态以响应确认消息时，客户机执行DHCP服务器请求（如第17节所述）和客户机启动的配置（如第18节所述）。如果客户端收到任何不指示NotOnLink状态的回复消息，则客户端可以使用IA中的地址并忽略任何指示NotOnLink状态的消息。
When the client receives a NotOnLink status from the server in response to a Request, the client can either re-issue the Request without specifying any addresses or restart the DHCP server discovery process (see section 17).
当客户端从服务器接收到响应请求的NotOnLink状态时，客户端可以在不指定任何地址的情况下重新发出请求，也可以重新启动DHCP服务器发现过程（请参阅第17节）。
The client examines the status code in each IA individually. If the status code is NoAddrsAvail, the client has received no usable addresses in the IA and may choose to try obtaining addresses for the IA from another server. The client uses addresses and other information from any IAs that do not contain a Status Code option with the NoAddrsAvail code. If the client receives no addresses in any of the IAs, it may either try another server (perhaps restarting the DHCP server discovery process) or use the Information-request message to obtain other configuration information only.
客户机单独检查每个IA中的状态代码。如果状态代码为NoAddrsAvail，则客户端在IA中未收到可用地址，可能会选择尝试从其他服务器获取IA的地址。客户端使用来自任何不包含NOADRSAVAIL代码的状态代码选项的IAs的地址和其他信息。如果客户端在任何IAs中都没有收到地址，它可能会尝试另一台服务器（可能会重新启动DHCP服务器发现过程），或者使用信息请求消息仅获取其他配置信息。
When the client receives a Reply message in response to a Renew or Rebind message, the client examines each IA independently. For each IA in the original Renew or Rebind message, the client:
当客户端收到响应续订或重新绑定消息的回复消息时，客户端将独立检查每个IA。对于原始续订或重新绑定消息中的每个IA，客户端：
- sends a Request message if the IA contained a Status Code option with the NoBinding status (and does not send any additional Renew/Rebind messages)
- 如果IA包含状态代码选项且状态为NoBinding（未发送任何其他续订/重新绑定消息），则发送请求消息
- sends a Renew/Rebind if the IA is not in the Reply message
- 如果IA不在回复消息中，则发送续订/重新绑定
- otherwise accepts the information in the IA
- 否则接受IA中的信息
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.
当客户端收到响应拒绝消息的有效回复消息时，无论服务器返回的状态代码选项如何，客户端都会认为拒绝事件已完成。
For this discussion, the Server is assumed to have been configured in an implementation specific manner with configuration of interest to 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.
在大多数情况下，服务器将发送回复以响应客户端消息。此回复消息必须始终包含包含服务器DUID的服务器标识符选项和客户端消息中的客户端标识符选项（如果存在）。
In most Reply messages, the server includes options containing configuration information for the client. The server must be aware of the recommendations on packet sizes and the use of fragmentation in section 5 of RFC 2460. If the client included an Option Request option in its message, the server includes options in the Reply 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.
在大多数回复消息中，服务器包含包含客户端配置信息的选项。服务器必须了解RFC 2460第5节中关于数据包大小和碎片使用的建议。如果客户端在其消息中包含选项请求选项，则服务器会在回复消息中包含选项，其中包含服务器已配置为返回客户端的选项请求选项中标识的所有选项的配置参数。如果已将服务器配置为向客户端返回其他选项，则服务器可能会向客户端返回这些选项。
When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options.
当服务器通过单播从未向其发送单播选项的客户端接收到请求消息时，服务器将丢弃该请求消息，并使用包含值为UseMotcast的状态代码选项（包含服务器DUID的服务器标识符选项）的回复消息进行响应，客户端消息中的客户端标识符选项，不包含其他选项。
When the server receives a valid Request message, the server creates the bindings for that client according to the server's policy and configuration information and records the IAs and other information requested by the client.
当服务器收到有效的请求消息时，服务器将根据服务器的策略和配置信息为该客户端创建绑定，并记录客户端请求的IAs和其他信息。
The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Request message into the transaction-id field.
服务器通过将“msg type”字段设置为Reply，并将事务ID从请求消息复制到事务ID字段中，来构造一条回复消息。
The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Request message in the Reply message.
服务器必须在回复消息中包含包含服务器DUID的服务器标识符选项和来自请求消息的客户端标识符选项。
If the server finds that the prefix on one or more IP addresses in any IA in the message from the client is not appropriate for the link to which the client is connected, the server MUST return the IA to the client with a Status Code option with the value NotOnLink.
如果服务器发现来自客户端的消息中任何IA中的一个或多个IP地址上的前缀不适用于客户端连接到的链接，则服务器必须使用值为NotOnLink的状态代码选项将IA返回给客户端。
If the server cannot assign any addresses to an IA in the message from the client, the server MUST include the IA in the Reply message with no addresses in the IA and a Status Code option in the IA containing status code NoAddrsAvail.
如果服务器无法在来自客户端的消息中为IA分配任何地址，则服务器必须在回复消息中包含IA，而IA中没有地址，并且在IA中包含状态代码NOADRSAVAIL的状态代码选项。
For any IAs to which the server can assign addresses, the server includes the IA with addresses and other configuration parameters, and records the IA as a new client binding.
对于服务器可以向其分配地址的任何IAs，服务器将IA包括在地址和其他配置参数中，并将IA记录为新的客户端绑定。
The server includes a Reconfigure Accept option if the server wants to require that the client accept Reconfigure messages.
如果服务器希望要求客户端接受重新配置消息，则服务器包含重新配置接受选项。
The server includes other options containing configuration information to be returned to the client as described in section 18.2.
如第18.2节所述，服务器包括包含要返回给客户端的配置信息的其他选项。
If the server finds that the client has included an IA in the Request message for which the server already has a binding that associates the IA with the client, the client has resent a Request message for which it did not receive a Reply message. The server either resends a previously cached Reply message or sends a new Reply message.
如果服务器发现客户机已在请求消息中包含IA，并且服务器已为该IA与客户机关联的绑定，则客户机已重新发送未收到回复消息的请求消息。服务器重新发送以前缓存的回复消息或发送新的回复消息。
When the server receives a Confirm message, the server determines whether the addresses in the Confirm message are appropriate for the link to which the client is attached. If all of the addresses in the Confirm message pass this test, the server returns a status of Success. If any of the addresses do not pass this test, the server returns a status of NotOnLink. If the server is unable to perform this test (for example, the server does not have information about prefixes on the link to which the client is connected), or there were no addresses in any of the IAs sent by the client, the server MUST NOT send a reply to the client.
当服务器收到确认消息时，服务器将确定确认消息中的地址是否适合客户端所连接的链接。如果确认消息中的所有地址都通过了此测试，服务器将返回成功状态。如果任何地址未通过此测试，服务器将返回NotOnLink状态。如果服务器无法执行此测试（例如，服务器没有有关客户端连接到的链接上的前缀的信息），或者客户端发送的任何IAs中没有地址，则服务器不得向客户端发送回复。
The server ignores the T1 and T2 fields in the IA options and the preferred-lifetime and valid-lifetime fields in the IA Address options.
服务器忽略IA选项中的T1和T2字段以及IA地址选项中的首选生存期和有效生存期字段。
The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Confirm message into the transaction-id field.
服务器通过将“msg type”字段设置为Reply，并将事务ID从确认消息复制到事务ID字段中，来构造一条回复消息。
The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Confirm message in the Reply message. The server includes a Status Code option indicating the status of the Confirm message.
服务器必须包括一个包含服务器DUID的服务器标识符选项和回复消息中确认消息中的客户端标识符选项。服务器包括一个状态代码选项，指示确认消息的状态。
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 the Renew message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options.
当服务器通过单播从未向其发送单播选项的客户端接收到续订消息时，服务器将丢弃续订消息，并使用包含值为UseMotcast的状态代码选项（包含服务器DUID的服务器标识符选项）的回复消息进行响应，客户端消息中的客户端标识符选项，不包含其他选项。
When the server receives a Renew message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client.
当服务器从客户端接收到包含IA选项的续订消息时，它将定位客户端的绑定，并验证来自客户端的IA中的信息是否与为该客户端存储的信息匹配。
If the server cannot find a client entry for the IA the server returns the IA containing no addresses with a Status Code option set to NoBinding in the Reply message.
如果服务器找不到IA的客户机条目，服务器将返回不包含地址的IA，并在回复消息中将状态代码选项设置为NoBinding。
If the server finds that any of the addresses are not appropriate for the link to which the client is attached, the server returns the address to the client with lifetimes of 0.
如果服务器发现任何地址不适合客户端连接到的链接，则服务器会将该地址返回给客户端，其生存期为0。
If the server finds the addresses in the IA for the client then the server sends back the IA to the client with new lifetimes and T1/T2 times. The server may choose to change the list of addresses and the lifetimes of addresses in IAs that are returned to the client.
如果服务器在IA中找到客户机的地址，则服务器将IA发送回客户机，并提供新的生存期和T1/T2时间。服务器可以选择更改IAs中返回给客户端的地址列表和地址的生存期。
The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Renew message into the transaction-id field.
服务器通过将“msg type”字段设置为Reply，并将事务ID从续订消息复制到事务ID字段中，来构造一条回复消息。
The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Renew message in the Reply message.
服务器必须在回复消息中包含包含服务器DUID的服务器标识符选项和续订消息中的客户端标识符选项。
The server includes other options containing configuration information to be returned to the client as described in section 18.2.
如第18.2节所述，服务器包括包含要返回给客户端的配置信息的其他选项。
When the server receives a Rebind message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client.
当服务器从客户端接收到包含IA选项的重新绑定消息时，它将定位客户端的绑定，并验证来自客户端的IA中的信息是否与为该客户端存储的信息匹配。
If the server cannot find a client entry for the IA and the server determines that the addresses in the IA are not appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server MAY send a Reply message to the client containing the client's IA, with the lifetimes for the addresses in the IA set to zero. This Reply constitutes an explicit notification to the client that the addresses in the IA are no longer valid. In this situation, if the server does not send a Reply message it silently discards the Rebind message.
如果服务器找不到IA的客户端条目，并且服务器根据服务器的显式配置信息确定IA中的地址不适合客户端接口连接到的链接，则服务器可以向客户端发送包含客户端IA的回复消息，IA中地址的生存期设置为零。此回复构成对客户端的明确通知，即IA中的地址不再有效。在这种情况下，如果服务器不发送回复消息，它会自动丢弃重新绑定消息。
If the server finds that any of the addresses are no longer appropriate for the link to which the client is attached, the server returns the address to the client with lifetimes of 0.
如果服务器发现任何地址不再适用于客户端连接到的链接，则服务器将地址返回给客户端，其生存期为0。
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 T1/T2 times.
如果服务器在IA中找到客户机的地址，则服务器应将IA发送回客户机，并提供新的生存期和T1/T2时间。
The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Rebind message into the transaction-id field.
服务器通过将“msg type”字段设置为Reply，并将事务ID从重新绑定消息复制到事务ID字段中，来构造一条回复消息。
The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Rebind message in the Reply message.
服务器必须包括一个包含服务器DUID的服务器标识符选项和回复消息中重新绑定消息的客户端标识符选项。
The server includes other options containing configuration information to be returned to the client as described in section 18.2.
如第18.2节所述，服务器包括包含要返回给客户端的配置信息的其他选项。
When the server receives an Information-request message, the client is requesting configuration information that does not include the assignment of any addresses. The server determines all configuration parameters appropriate to the client, based on the server configuration policies known to the server.
当服务器收到信息请求消息时，客户端请求的配置信息不包括任何地址的分配。服务器根据服务器已知的服务器配置策略确定适合客户端的所有配置参数。
The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Information-request message into the transaction-id field.
服务器通过将“msg type”字段设置为Reply，并将事务ID从信息请求消息复制到事务ID字段中，来构造一条回复消息。
The server MUST include a Server Identifier option containing the server's DUID in the Reply message. If the client included a Client Identification option in the Information-request message, the server copies that option to the Reply message.
服务器必须在回复消息中包含包含服务器DUID的服务器标识符选项。如果客户机在信息请求消息中包含客户机标识选项，则服务器会将该选项复制到回复消息中。
The server includes options containing configuration information to be returned to the client as described in section 18.2.
如第18.2节所述，服务器包括包含要返回给客户端的配置信息的选项。
If the Information-request message received from the client did not include a Client Identifier option, the server SHOULD respond with a Reply message containing any configuration parameters that are not determined by the client's identity. If the server chooses not to respond, the client may continue to retransmit the Information-request message indefinitely.
如果从客户端接收到的信息请求消息不包括客户端标识符选项，则服务器应使用包含未由客户端标识确定的任何配置参数的回复消息进行响应。如果服务器选择不响应，客户端可能会继续无限期地重新传输信息请求消息。
When the server receives a Release message via unicast from a client to which the server has not sent a unicast option, the server discards the Release message and responds with a Reply message containing a Status Code option with value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options.
当服务器通过单播从未向其发送单播选项的客户端接收到释放消息时，服务器将丢弃该释放消息，并使用包含值为UseMulticast的状态代码选项（包含服务器DUID的服务器标识符选项）的回复消息进行响应，客户端消息中的客户端标识符选项，不包含其他选项。
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 message are in a binding for the client, and the addresses in the IAs have been assigned by the server to those IAs, the server deletes the addresses from the IAs and makes the addresses available for assignment to other clients. The server ignores addresses not assigned to the IA, although it may choose to log an error.
在收到有效的发布消息后，服务器将检查IAs和IAs中的地址的有效性。如果消息中的IAs处于客户端的绑定中，并且服务器已将IAs中的地址分配给这些IAs，则服务器将从IAs中删除地址，并使这些地址可分配给其他客户端。服务器会忽略未分配给IA的地址，尽管它可能会选择记录错误。
After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. For each IA in the Release message for which the server has no binding information, the server adds an IA option using the IAID from the Release message, and includes a Status Code option with the value NoBinding in the IA option. No other options are included in the IA option.
处理完所有地址后，服务器将生成一条回复消息，并包括一个值为Success的状态代码选项、一个带有服务器DUID的服务器标识符选项和一个带有客户端DUID的客户端标识符选项。对于服务器没有绑定信息的发布消息中的每个IA，服务器使用发布消息中的IAID添加一个IA选项，并在IA选项中包含一个值为NoBinding的状态代码选项。IA选项中不包括其他选项。
A server may choose to retain a record of assigned addresses and IAs after the lifetimes on the addresses have expired to allow the server to reassign the previously assigned addresses to a client.
服务器可以选择在地址的生存期到期后保留已分配地址和IAs的记录，以允许服务器将以前分配的地址重新分配给客户端。
When the server receives a Decline message via unicast from a client to which the server has not sent a unicast option, the server discards the Decline message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options.
当服务器通过单播从未向其发送单播选项的客户端接收到拒绝消息时，服务器将丢弃该拒绝消息，并使用包含值为UseMulticast的状态代码选项（包含服务器DUID的服务器标识符选项）的回复消息进行响应，客户端消息中的客户端标识符选项，不包含其他选项。
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 message are in a binding for the client, and the addresses in the IAs have been assigned by the server to those IAs, the server deletes the addresses from the IAs. The server ignores addresses not assigned to the IA (though it may choose to log an error if it finds such an address).
在收到有效的拒绝消息后，服务器将检查IAs和IAs中的地址的有效性。如果消息中的IAs位于客户端的绑定中，并且服务器已将IAs中的地址分配给这些IAs，则服务器将从IAs中删除这些地址。服务器会忽略未分配给IA的地址（尽管如果找到此类地址，它可能会选择记录错误）。
The client has found any addresses in the Decline messages to be already in use on its link. Therefore, the server SHOULD mark the addresses declined by the client so that those addresses are not assigned to other clients, and MAY choose to make a notification that addresses were declined. Local policy on the server determines when the addresses identified in a Decline message may be made available for assignment.
客户端发现拒绝消息中的任何地址已在其链接上使用。因此，服务器应该标记客户端拒绝的地址，以便这些地址不会分配给其他客户端，并且可以选择发出地址被拒绝的通知。服务器上的本地策略确定拒绝消息中标识的地址何时可用于分配。
After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with the value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. For each IA in the Decline message for which the server has no binding information, the server adds an IA option using the IAID from the Release message and includes a Status Code option with the value NoBinding in the IA option. No other options are included in the IA option.
处理完所有地址后，服务器将生成一条回复消息，并包括一个值为Success的状态代码选项、一个值为服务器DUID的服务器标识符选项和一个值为客户端DUID的客户端标识符选项。对于服务器没有绑定信息的拒绝消息中的每个IA，服务器使用发布消息中的IAID添加IA选项，并在IA选项中包含值为NoBinding的状态代码选项。IA选项中不包括其他选项。
If the original message was received directly by the server, 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 original message was received. The Reply message MUST be unicast through the interface on which the original message was received.
如果原始消息是由服务器直接接收的，则服务器使用接收原始消息的IP数据报中的源地址字段中的地址，将应答消息直接单播到客户端。回复消息必须通过接收原始消息的接口单播。
If the original message was received in a Relay-forward message, the server constructs a Relay-reply message with the Reply message in the payload of a Relay Message option (see section 22.10). If the Relay-forward messages included an Interface-id option, the server copies that option to the Relay-reply message. The server unicasts the Relay-reply message directly to the relay agent using the address in the source address field from the IP datagram in which the Relay-forward message was received.
如果在中继转发消息中接收到原始消息，则服务器将在中继消息选项的有效负载中构造一条中继回复消息（请参阅第22.10节）。如果中继转发消息包含接口id选项，则服务器会将该选项复制到中继回复消息。服务器使用从接收中继转发消息的IP数据报的源地址字段中的地址，将中继回复消息直接单播到中继代理。
A server initiates a configuration exchange to cause DHCP clients to obtain new addresses and other configuration information. For example, an administrator may use a server-initiated configuration exchange when links in the DHCP domain are to be renumbered. Other
服务器启动配置交换，以使DHCP客户端获得新地址和其他配置信息。例如，当DHCP域中的链接要重新编号时，管理员可以使用服务器启动的配置交换。另外
examples include changes in the location of directory servers, addition of new services such as printing, and availability of new software.
示例包括目录服务器位置的更改、添加新服务（如打印）以及新软件的可用性。
A server sends a Reconfigure message to cause a client to initiate immediately a Renew/Reply or Information-request/Reply message exchange with the server.
服务器发送重新配置消息，使客户端立即启动与服务器的续订/回复或信息请求/回复消息交换。
The server sets the "msg-type" field to RECONFIGURE. The server sets the transaction-id field to 0. The server includes a Server Identifier option containing its DUID and a Client Identifier option containing the client's DUID in the Reconfigure message.
服务器将“msg type”字段设置为重新配置。服务器将事务id字段设置为0。服务器在重新配置消息中包括一个包含其DUID的服务器标识符选项和一个包含客户端DUID的客户端标识符选项。
The server MAY include an Option Request option to inform the client of what information has been changed or new information that has been added. In particular, the server specifies the IA option in the Option Request option if the server wants the client to obtain new address information. If the server identifies the IA option in the Option Request option, the server MUST include an IA option that contains no other sub-options to identify each IA that is to be reconfigured on the client.
服务器可以包括一个选项请求选项，用于通知客户端已更改的信息或已添加的新信息。特别是，如果服务器希望客户端获取新地址信息，则服务器在选项请求选项中指定IA选项。如果服务器在选项请求选项中标识IA选项，则服务器必须包含一个IA选项，该选项不包含其他子选项，以标识要在客户端上重新配置的每个IA。
Because of the risk of denial of service attacks against DHCP clients, the use of a security mechanism is mandated in Reconfigure messages. The server MUST use DHCP authentication in the Reconfigure message.
由于存在针对DHCP客户端的拒绝服务攻击风险，因此在重新配置消息时必须使用安全机制。服务器必须在重新配置消息中使用DHCP身份验证。
The server MUST include a Reconfigure Message option (defined in section 22.19) to select whether the client responds with a Renew message or an Information-Request message.
服务器必须包括一个重新配置消息选项（在第22.19节中定义），以选择客户端是使用续订消息还是信息请求消息进行响应。
The server MUST NOT include any other options in the Reconfigure except as specifically allowed in the definition of individual options.
服务器不得在重新配置中包含任何其他选项，除非在单个选项的定义中明确允许。
A server sends each Reconfigure message to a single DHCP client, using an IPv6 unicast address of sufficient scope belonging to the DHCP client. If the server does not have an address to which it can send the Reconfigure message directly to the client, the server uses a Relay-reply message (as described in section 20.3) to send the Reconfigure message to a relay agent that will relay the message to the client. The server may obtain the address of the client (and the
服务器使用属于DHCP客户端的足够范围的IPv6单播地址将每个重新配置消息发送到单个DHCP客户端。如果服务器没有地址可将重新配置消息直接发送至客户端，则服务器使用中继回复消息（如第20.3节所述）将重新配置消息发送至中继代理，中继代理将消息中继至客户端。服务器可以获取客户机的地址（以及
appropriate relay agent, if required) through the information the server has about clients that have been in contact with the server, or through some external agent.
适当的中继代理（如果需要），通过服务器拥有的有关已与服务器联系的客户端的信息，或通过某些外部代理。
To reconfigure more than one client, the server unicasts a separate message to each client. The server may initiate the reconfiguration of multiple clients concurrently; for example, a server may send a Reconfigure message to additional clients while previous reconfiguration message exchanges are still in progress.
要重新配置多个客户端，服务器将向每个客户端单播一条单独的消息。服务器可同时启动多个客户端的重新配置；例如，当先前的重新配置消息交换仍在进行中时，服务器可能会向其他客户端发送重新配置消息。
The Reconfigure message causes the client to initiate a Renew/Reply or Information-request/Reply message exchange with the server. The server interprets the receipt of a Renew or Information-request message (whichever was specified in the original Reconfigure message) from the client as satisfying the Reconfigure message request.
重新配置消息导致客户端启动与服务器的续订/回复或信息请求/回复消息交换。服务器将从客户端接收到续订或信息请求消息（以原始重新配置消息中指定的为准）解释为满足重新配置消息请求。
If the server does not receive a Renew or Information-request message from the client in REC_TIMEOUT milliseconds, the server retransmits the Reconfigure message, doubles the REC_TIMEOUT value and waits again. The server continues this process until REC_MAX_RC unsuccessful attempts have been made, at which point the server SHOULD abort the reconfigure process for that client.
如果服务器在REC_超时毫秒内未收到来自客户端的续订或信息请求消息，服务器将重新传输重新配置消息，将REC_超时值加倍，然后再次等待。服务器将继续此过程，直到尝试REC_MAX_RC失败，此时服务器应中止该客户端的重新配置过程。
Default and initial values for REC_TIMEOUT and REC_MAX_RC are documented in section 5.5.
REC_TIMEOUT和REC_MAX_RC的默认值和初始值记录在第5.5节中。
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 configuration parameters.
服务器按照第18.2.3节和第18.2.8节所述生成回复消息并发送给客户端，包括配置参数选项。
The server MAY include options containing the IAs and new values for other configuration parameters in the Reply message, even if those IAs and parameters were not requested in the Renew message from the client.
服务器可能会在回复消息中包含包含IAs和其他配置参数的新值的选项，即使这些IAs和参数没有在来自客户端的续订消息中请求。
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 configuration parameters.
服务器按照第18.2.5节和第18.2.8节所述生成回复消息并发送给客户端，包括配置参数选项。
The server MAY include options containing new values for other configuration parameters in the Reply message, even if those parameters were not requested in the Information-request message from the client.
服务器可以在回复消息中包括包含其他配置参数的新值的选项，即使这些参数没有在来自客户端的信息请求消息中被请求。
A client receives Reconfigure messages sent to the UDP port 546 on interfaces for which it has acquired configuration information through DHCP. These messages may be sent at any time. Since the results of a reconfiguration event may affect application layer programs, the client SHOULD log these events, and MAY notify these programs of the change through an implementation-specific interface.
客户端在其通过DHCP获取配置信息的接口上接收发送到UDP端口546的重新配置消息。这些信息可以随时发送。由于重新配置事件的结果可能会影响应用层程序，因此客户端应记录这些事件，并可通过特定于实现的接口将更改通知这些程序。
Upon receipt of a valid Reconfigure message, the client responds with either a Renew message or an Information-request message as indicated by the Reconfigure Message option (as defined in section 22.19). The client ignores the transaction-id field in the received Reconfigure message. While the transaction is in progress, the client silently discards any Reconfigure messages it receives.
在收到有效的重新配置消息后，客户机将按照重新配置消息选项（定义见第22.19节）的指示，以更新消息或信息请求消息进行响应。客户端忽略收到的重新配置消息中的事务id字段。当事务正在进行时，客户端会自动丢弃它接收到的任何重新配置消息。
DISCUSSION:
讨论：
The Reconfigure message acts as a trigger that signals the client to complete a successful message exchange. Once the client has received a Reconfigure, the client proceeds with the message exchange (retransmitting the Renew or Information-request message if necessary); the client ignores any additional Reconfigure messages until the exchange is complete. Subsequent Reconfigure messages cause the client to initiate a new exchange.
重新配置消息充当一个触发器，向客户机发送信号以完成成功的消息交换。一旦客户端收到重新配置，客户端将继续进行消息交换（如有必要，重新传输续订或信息请求消息）；在交换完成之前，客户端将忽略任何其他重新配置消息。随后的重新配置消息会导致客户端启动新的交换。
How does this mechanism work in the face of duplicated or retransmitted Reconfigure messages? Duplicate messages will be ignored because the client will begin the exchange after the receipt of the first Reconfigure. Retransmitted messages will either trigger the exchange (if the first Reconfigure was not received by the client) or will be ignored. The server can discontinue retransmission of Reconfigure messages to the client once the server receives the Renew or Information-request message from the client.
面对重复或重新传输的重新配置消息，此机制如何工作？重复的消息将被忽略，因为客户端将在收到第一次重新配置后开始交换。重新传输的消息将触发交换（如果客户端未收到第一次重新配置），或者将被忽略。一旦服务器从客户端接收到续订或信息请求消息，服务器就可以停止向客户端重新传输重新配置消息。
It might be possible for a duplicate or retransmitted Reconfigure to be sufficiently delayed (and delivered out of order) to arrive at the client after the exchange (initiated by the original Reconfigure) has been completed. In this case, the client would initiate a redundant exchange. The likelihood of delayed and out
在交换（由原始重新配置启动）完成后，可能会对重复或重新传输的重新配置进行足够的延迟（并无序交付），以到达客户端。在这种情况下，客户端将启动冗余交换。延迟和退出的可能性
of order delivery is small enough to be ignored. The consequence of the redundant exchange is inefficiency rather than incorrect operation.
订单交付数量小到可以忽略不计。冗余交换的结果是效率低下，而不是操作不正确。
When responding to a Reconfigure, the client creates and sends the Renew message in exactly the same manner as outlined in section 18.1.3, with the exception that the client copies the Option Request option and any IA options from the Reconfigure message into the Renew message.
当响应重新配置时，客户机以与第18.1.3节所述完全相同的方式创建和发送续订消息，但客户机将选项请求选项和任何IA选项从重新配置消息复制到续订消息中的情况除外。
When responding to a Reconfigure, the client creates and sends the Information-request message in exactly the same manner as outlined in section 18.1.5, with the exception that the client includes a Server Identifier option with the identifier from the Reconfigure message to which the client is responding.
响应重新配置时，客户机以与第18.1.5节所述完全相同的方式创建和发送信息请求消息，但客户机包含服务器标识符选项，该标识符来自客户机响应的重新配置消息。
19.4.4. Time Out and Retransmission of Renew or Information-request Messages
19.4.4. 续订或信息请求消息超时和重新传输
The client uses the same variables and retransmission algorithm as it does with Renew or Information-request messages generated as part of a client-initiated configuration exchange. See sections 18.1.3 and 18.1.5 for details. If the client does not receive a response from the server by the end of the retransmission process, the client ignores and discards the Reconfigure message.
客户端使用的变量和重传算法与在客户端启动的配置交换中生成的续订或信息请求消息相同。详见第18.1.3节和第18.1.5节。如果客户端在重新传输过程结束时未收到来自服务器的响应，则客户端将忽略并丢弃重新配置消息。
Upon the receipt of a valid Reply message, the client processes the options and sets (or resets) configuration parameters appropriately. The client records and updates the lifetimes for any addresses specified in IAs in the Reply message.
在收到有效的回复消息后，客户端将处理选项并适当地设置（或重置）配置参数。客户端记录并更新回复消息中IAs中指定的任何地址的生存期。
The relay agent MAY be configured to use a list of destination addresses, which MAY include unicast addresses, the All_DHCP_Servers multicast address, or other addresses selected by the network administrator. If the relay agent has not been explicitly configured, it MUST use the All_DHCP_Servers multicast address as the default.
中继代理可被配置为使用目的地地址的列表，其可包括单播地址、所有DHCP服务器多播地址或网络管理员选择的其他地址。如果中继代理尚未明确配置，则它必须使用All_DHCP_Servers多播地址作为默认地址。
If the relay agent relays messages to the All_DHCP_Servers multicast address or other multicast addresses, it sets the Hop Limit field to 32.
如果中继代理将消息中继到All_DHCP_服务器多播地址或其他多播地址，则会将跃点限制字段设置为32。
A relay agent relays both messages from clients and Relay-forward messages from other relay agents. When a relay agent receives a valid message to be relayed, it constructs a new Relay-forward message. The relay agent copies the source address from the header of the IP datagram in which the message was received to the peer-address field of the Relay-forward message. The relay agent 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.
中继代理既中继来自客户端的消息，也中继转发来自其他中继代理的消息。当中继代理接收到要中继的有效消息时，它将构造一个新的中继转发消息。中继代理将源地址从接收消息的IP数据报报头复制到中继转发消息的对等地址字段。中继代理将接收到的DHCP消息（不包括任何IP或UDP头）复制到新消息中的中继消息选项中。中继代理将其配置为包括的任何其他选项添加到中继转发消息中。
If the relay agent received the message to be relayed 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.
如果中继代理从客户机接收到要中继的消息，则中继代理会在“链接地址”字段中放置一个全局或站点范围的地址，并将前缀分配给客户机应在其上分配地址的链接。服务器将使用此地址来确定应该从中为客户端分配地址和其他配置信息的链接。中继转发消息中的跃点计数设置为0。
If the relay agent cannot use the address in the link-address field to identify the interface through which the response to the client will be relayed, the relay agent MUST include an Interface-id option (see section 22.18) in the Relay-forward message. The server will include the Interface-id option in its Relay-reply message. The relay agent fills in the link-address field as described in the previous paragraph regardless of whether the relay agent includes an Interface-id option in the Relay-forward message.
如果中继代理无法使用链路地址字段中的地址来标识将通过哪个接口中继对客户端的响应，则中继代理必须在中继转发消息中包含一个接口id选项（见第22.18节）。服务器将在其中继回复消息中包含接口id选项。无论中继代理是否在中继转发消息中包含接口id选项，中继代理都会按照上一段中所述填写链路地址字段。
If the message received by the relay agent is a Relay-forward message and the hop-count in the message is greater than or equal to HOP_COUNT_LIMIT, the relay agent discards the received message.
如果中继代理接收到的消息是中继转发消息，且消息中的跃点计数大于或等于跃点计数限制，则中继代理将丢弃接收到的消息。
The relay agent copies the source address from the IP datagram in which the message was received from the client into the peer-address field in the Relay-forward message and sets the hop-count field to the value of the hop-count field in the received message incremented by 1.
中继代理将从客户端接收消息的IP数据报中的源地址复制到中继转发消息中的对等地址字段中，并将跃点计数字段设置为接收消息中跃点计数字段的值加1。
If the source address from the IP datagram header of the received message is a global or site-local address (and the device on which the relay agent is running belongs to only one site), the relay agent sets the link-address field to 0; otherwise the relay agent sets the link-address field to a global or site-local address assigned to the interface on which the message was received, or includes an Interface-ID option to identify the interface on which the message was received.
如果来自所接收消息的IP数据报报头的源地址是全局或站点本地地址（并且中继代理运行的设备仅属于一个站点），则中继代理将链路地址字段设置为0；否则，中继代理将链路地址字段设置为分配给接收消息的接口的全局或站点本地地址，或包括接口ID选项，以标识接收消息的接口。
The relay agent processes any options included in the Relay-reply message in addition to the Relay Message option, and then discards those options.
中继代理程序除处理中继消息选项外，还处理中继回复消息中包含的任何选项，然后丢弃这些选项。
The relay agent extracts the message from the Relay Message option and relays 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 relays 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 relays the message on the link identified by the link-address field.
如果中继回复消息包含接口id选项，则中继代理将消息从服务器中继到由接口id选项标识的链路上的客户端。否则，如果链路地址字段未设置为零，中继代理将在链路地址字段标识的链路上中继消息。
A server uses a Relay-reply message to return a response to a client if the original message from the client was relayed to the server in a Relay-forward message or to send a Reconfigure message to a client if the server does not have an address it can use to send the message directly to the client.
如果来自客户端的原始消息在中继转发消息中中继到服务器，则服务器使用中继回复消息向客户端返回响应；如果服务器没有可用于将消息直接发送到客户端的地址，则服务器使用中继回复消息向客户端发送重新配置消息。
A response to the client MUST be relayed 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 relayed by relay agent A to relay agent B and then to the server, the server would send the following Relay-Reply message to relay agent B:
例如，如果客户端C发送了一条由中继代理a中继到中继代理B然后再到服务器的消息，则服务器将向中继代理B发送以下中继回复消息：
msg-type: RELAY-REPLY
hop-count: 1
link-address: 0
peer-address: A
Relay Message option, containing:
msg-type: RELAY-REPLY
hop-count: 0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: <response from server>
msg-type: RELAY-REPLY
hop-count: 1
link-address: 0
peer-address: A
Relay Message option, containing:
msg-type: RELAY-REPLY
hop-count: 0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: <response from server>
When sending a Reconfigure message to a client through a relay agent, the server creates a Relay-reply message that includes a Relay Message option containing the Reconfigure message for the next relay agent in the return path to the client. The server sets the peer-address field in the Relay-reply message header to the address of the client, and sets the link-address field as required by the relay agent to relay the Reconfigure message to the client. The server obtains the addresses of the client and the relay agent through prior interaction with the client or through some external mechanism.
当通过中继代理向客户端发送重新配置消息时，服务器将创建一条中继回复消息，该消息包含一个中继消息选项，该选项包含客户端返回路径中下一个中继代理的重新配置消息。服务器将中继回复消息头中的对等地址字段设置为客户端的地址，并根据中继代理的要求设置链接地址字段，以将重新配置消息中继到客户端。服务器通过事先与客户机交互或通过某种外部机制获得客户机和中继代理的地址。
Some network administrators may wish to provide authentication of the source and contents of DHCP messages. For example, clients may be subject to denial of service attacks through the use of bogus DHCP servers, or may simply be misconfigured due to unintentionally instantiated DHCP servers. Network administrators may wish to constrain the allocation of addresses to authorized hosts to avoid denial of service attacks in "hostile" environments where the network medium is not physically secured, such as wireless networks or college residence halls.
一些网络管理员可能希望提供DHCP消息源和内容的身份验证。例如，客户端可能会通过使用伪造的DHCP服务器受到拒绝服务攻击，或者可能只是由于无意中实例化了DHCP服务器而配置错误。网络管理员可能希望限制向授权主机分配地址，以避免在网络介质物理上不安全的“敌对”环境中（如无线网络或大学宿舍）发生拒绝服务攻击。
The DHCP authentication mechanism is based on the design of authentication for DHCPv4 [4].
DHCP身份验证机制基于DHCPv4的身份验证设计[4]。
Relay agents and servers that exchange messages securely use the IPsec mechanisms for IPv6 [7]. If a client message is relayed 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 relayed by relay agent A to relay
安全地交换消息的中继代理和服务器使用IPv6的IPsec机制[7]。如果客户端消息通过多个中继代理进行中继，则每个中继代理必须建立独立的成对信任关系。也就是说，如果来自客户端C的消息将由中继代理A中继到中继
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.
代理B然后到服务器，中继代理A和B必须配置为对其交换的消息使用IPSec，中继代理B和服务器必须配置为对其交换的消息使用IPSec。
Relay agents and servers that support secure relay agent to server or relay agent to relay agent communication use IPsec under the following conditions:
支持安全中继代理到服务器或中继代理到中继代理通信的中继代理和服务器在以下条件下使用IPsec：
Selectors Relay agents are manually configured with the addresses of the relay agent or server to which DHCP messages are to be forwarded. Each relay agent and server that will be using IPsec for securing DHCP messages must also be configured with a list of the relay agents to which messages will be returned. The selectors for the relay agents and servers will be the pairs of addresses defining relay agents and servers that exchange DHCP messages on the DHCPv6 UDP ports 546 and 547.
选择器中继代理手动配置有要转发DHCP消息的中继代理或服务器的地址。每个将使用IPsec保护DHCP消息的中继代理和服务器还必须配置一个消息将返回到的中继代理列表。中继代理和服务器的选择器将是定义中继代理和服务器的地址对，中继代理和服务器在DHCPv6 UDP端口546和547上交换DHCP消息。
Mode Relay agents and servers use transport mode and ESP. The information in DHCP messages is not generally considered confidential, so encryption need not be used (i.e., NULL encryption can be used).
模式中继代理和服务器使用传输模式，尤其是DHCP消息中的信息通常不被视为机密信息，因此不需要使用加密（即可以使用空加密）。
Key management Because the relay agents and servers are used within an organization, public key schemes are not necessary. Because the relay agents and servers must be manually configured, manually configured key management may suffice, but does not provide defense against replayed messages. Accordingly, IKE with preshared secrets SHOULD be supported. IKE with public keys MAY be supported.
密钥管理由于中继代理和服务器在组织内使用，因此不需要公钥方案。由于中继代理和服务器必须手动配置，因此手动配置的密钥管理可能就足够了，但不能防止重播消息。因此，应该支持具有预共享秘密的IKE。可能支持带有公钥的IKE。
Security policy DHCP messages between relay agents and servers should only be accepted from DHCP peers as identified in the local configuration.
中继代理和服务器之间的安全策略DHCP消息只能从本地配置中标识的DHCP对等方接受。
Authentication Shared keys, indexed to the source IP address of the received DHCP message, are adequate in this application.
根据接收到的DHCP消息的源IP地址编制索引的身份验证共享密钥在此应用程序中已足够。
Availability Appropriate IPsec implementations are likely to be available for servers and for relay agents in more featureful devices used in enterprise and
适用于可用性的IPsec实现可能适用于企业和应用程序中使用的功能更强大的设备中的服务器和中继代理
core ISP networks. IPsec is less likely to be available for relay agents in low end devices primarily used in the home or small office markets.
核心ISP网络。IPsec不太可能用于主要用于家庭或小型办公室市场的低端设备中的中继代理。
Authentication of DHCP messages is accomplished through the use of the Authentication option (see section 22.11). The authentication information carried in the Authentication option can be used to reliably identify the source of a DHCP message and to confirm that the contents of the DHCP message have not been tampered with.
DHCP消息的身份验证通过使用身份验证选项来完成（见第22.11节）。身份验证选项中携带的身份验证信息可用于可靠地识别DHCP消息的源，并确认DHCP消息的内容未被篡改。
The Authentication option provides a framework for multiple authentication protocols. Two such protocols are defined here. Other protocols defined in the future will be specified in separate documents.
身份验证选项为多个身份验证协议提供了一个框架。这里定义了两个这样的协议。将来定义的其他协议将在单独的文件中指定。
Any DHCP message MUST NOT include more than one Authentication option.
任何DHCP消息不得包含多个身份验证选项。
The protocol field in the Authentication option identifies the specific protocol used to generate the authentication information carried in the option. The algorithm field identifies a specific algorithm within the authentication protocol; for example, the algorithm field specifies the hash algorithm used to generate the message authentication code (MAC) in the authentication option. The replay detection method (RDM) field specifies the type of replay detection used in the replay detection field.
身份验证选项中的协议字段标识用于生成选项中包含的身份验证信息的特定协议。算法字段标识认证协议内的特定算法；例如，算法字段指定用于在身份验证选项中生成消息身份验证码（MAC）的哈希算法。重播检测方法（RDM）字段指定重播检测字段中使用的重播检测类型。
The Replay Detection Method (RDM) field determines the type of replay detection used in the Replay Detection field.
重播检测方法（RDM）字段确定重播检测字段中使用的重播检测类型。
If the RDM field contains 0x00, the replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value, such as the current time of day (for example, an NTP-format timestamp [9]), can reduce the danger of replay attacks. This method MUST be supported by all protocols.
如果RDM字段包含0x00，则重播检测字段必须设置为单调递增计数器的值。使用计数器值，例如一天中的当前时间（例如，NTP格式的时间戳[9]），可以减少重播攻击的危险。所有协议都必须支持此方法。
If the protocol field is 2, the message is using the "delayed authentication" mechanism. In delayed authentication, the client requests authentication in its Solicit message, and the server replies with an Advertise message that includes authentication
如果协议字段为2，则消息使用“延迟身份验证”机制。在延迟身份验证中，客户端在其请求消息中请求身份验证，服务器用包含身份验证的播发消息进行回复
information. This authentication information contains a nonce value generated by the source as a message authentication code (MAC) to provide message authentication and entity authentication.
信息此身份验证信息包含由源生成的作为消息身份验证码（MAC）的nonce值，以提供消息身份验证和实体身份验证。
The use of a particular technique based on the HMAC protocol [8] using the MD5 hash [16] is defined here.
这里定义了使用MD5散列[16]的基于HMAC协议[8]的特定技术的使用。
21.4.1. Use of the Authentication Option in the Delayed Authentication Protocol
21.4.1. 在延迟身份验证协议中使用身份验证选项
In a Solicit message, the client fills in the protocol, algorithm and RDM fields in the Authentication option with the client's preferences. The client sets the replay detection field to zero and omits the authentication information field. The client sets the option-len field to 11.
在请求消息中，客户机使用客户机的首选项填写身份验证选项中的协议、算法和RDM字段。客户端将replay检测字段设置为零，并忽略身份验证信息字段。客户端将选项len字段设置为11。
In all other messages, the protocol and algorithm fields identify the method used to construct the contents of the authentication information field. The RDM field identifies the method used to construct the contents of the replay detection field.
在所有其他消息中，协议和算法字段标识用于构造身份验证信息字段内容的方法。RDM字段标识用于构造replay检测字段内容的方法。
The format of the Authentication information is:
身份验证信息的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP realm |
| (variable length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-MD5 |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP realm |
| (variable length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-MD5 |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCP realm The DHCP realm that identifies the key used to generate the HMAC-MD5 value.
DHCP领域标识用于生成HMAC-MD5值的密钥的DHCP领域。
key ID The key identifier that identified the key used to generate the HMAC-MD5 value.
密钥ID标识用于生成HMAC-MD5值的密钥的密钥标识符。
HMAC-MD5 The message authentication code generated by applying MD5 to the DHCP message using the key identified by the DHCP realm, client DUID, and key ID.
HMAC-MD5通过使用DHCP域、客户端DUID和密钥ID标识的密钥将MD5应用于DHCP消息而生成的消息身份验证代码。
The sender computes the MAC using the HMAC generation algorithm [8] and the MD5 hash function [16]. The entire DHCP message (setting the MAC field of the authentication option to zero), including the DHCP message header and the options field, is used as input to the HMAC-MD5 computation function.
发送方使用HMAC生成算法[8]和MD5哈希函数[16]计算MAC。整个DHCP消息（将身份验证选项的MAC字段设置为零），包括DHCP消息头和选项字段，用作HMAC-MD5计算函数的输入。
DISCUSSION:
讨论：
Algorithm 1 specifies the use of HMAC-MD5. Use of a different technique, such as HMAC-SHA, will be specified as a separate protocol.
算法1指定HMAC-MD5的使用。使用不同的技术，如HMAC-SHA，将被指定为单独的协议。
The DHCP realm used to identify authentication keys is chosen to be unique among administrative domains. Use of the DHCP realm allows DHCP administrators to avoid conflict in the use of key identifiers, and allows a host using DHCP to use authenticated DHCP while roaming among DHCP administrative domains.
用于标识身份验证密钥的DHCP域在管理域中是唯一的。DHCP域的使用允许DHCP管理员避免密钥标识符的使用冲突，并允许使用DHCP的主机在DHCP管理域之间漫游时使用经过身份验证的DHCP。
Any DHCP message that includes more than one authentication option MUST be discarded.
必须丢弃包含多个身份验证选项的任何DHCP消息。
To validate an incoming message, the receiver first checks that the value in the replay detection field is acceptable according to the replay detection method specified by the RDM field. Next, the receiver computes the MAC as described in [8]. The entire DHCP message (setting the MAC field of the authentication option to 0) 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 authentication option, the receiver MUST discard the DHCP message.
为了验证传入消息，接收器首先根据RDM字段指定的重播检测方法检查重播检测字段中的值是否可接受。接下来，接收机按照[8]中所述计算MAC。整个DHCP消息（将身份验证选项的MAC字段设置为0）用作HMAC-MD5计算函数的输入。如果接收方计算的MAC与身份验证选项中包含的MAC不匹配，则接收方必须丢弃DHCP消息。
Each DHCP client has a set of keys. Each key is identified by <DHCP realm, client DUID, key id>. Each key also has a lifetime. The key may not be used past the end of its lifetime. The client's keys are initially distributed to the client through some out-of-band mechanism. The lifetime for each key is distributed with the key. Mechanisms for key distribution and lifetime specification are beyond the scope of this document.
每个DHCP客户端都有一组密钥。每个密钥由<DHCP领域、客户端DUID、密钥id>标识。每把钥匙也有一个生命周期。密钥在其生命周期结束后不能使用。客户端的密钥最初通过一些带外机制分发给客户端。每个密钥的生存期随密钥一起分配。密钥分发机制和生命周期规范超出了本文档的范围。
The client and server use one of the client's keys to authenticate DHCP messages during a session (until the next Solicit message sent by the client).
客户端和服务器使用客户端的一个密钥在会话期间对DHCP消息进行身份验证（直到客户端发送下一条请求消息）。
The client announces its intention to use DHCP authentication by including an Authentication option in its Solicit message. The server selects a key for the client based on the client's DUID. The client and server use that key to authenticate all DHCP messages exchanged during the session.
客户端通过在其请求消息中包含身份验证选项来宣布其使用DHCP身份验证的意图。服务器根据客户端的DUID为客户端选择密钥。客户端和服务器使用该密钥对会话期间交换的所有DHCP消息进行身份验证。
When the client sends a Solicit message and wishes to use authentication, it includes an Authentication option with the desired protocol, algorithm and RDM as described in section 21.4. The client does not include any replay detection or authentication information in the Authentication option.
当客户端发送请求消息并希望使用身份验证时，它包括一个具有第21.4节所述的所需协议、算法和RDM的身份验证选项。客户端在“身份验证”选项中不包含任何重播检测或身份验证信息。
The client validates any Advertise messages containing an Authentication option specifying the delayed authentication protocol using the validation test described in section 21.4.2.
客户机使用第21.4.2节所述的验证测试，验证包含指定延迟验证协议的验证选项的任何播发消息。
Client behavior, if no Advertise messages include authentication information or pass the validation test, is controlled by local policy on the client. According to client policy, the client MAY choose to respond to an Advertise message that has not been authenticated.
如果没有包含身份验证信息或通过验证测试的播发消息，则客户端行为由客户端上的本地策略控制。根据客户端策略，客户端可以选择响应未经身份验证的播发消息。
The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated Advertise message can make the client vulnerable to spoofing and other attacks. If local users are not explicitly informed that the client has accepted an unauthenticated Advertise message, the users may incorrectly assume that the client has received an authenticated address and is not subject to DHCP attacks through unauthenticated messages.
应谨慎决定是否设置本地策略以接受未经验证的邮件。接受未经验证的播发消息会使客户端容易受到欺骗和其他攻击。如果未明确告知本地用户客户端已接受未经身份验证的播发消息，则用户可能会错误地认为客户端已收到经过身份验证的地址，并且未通过未经身份验证的消息受到DHCP攻击。
A client MUST be configurable to discard unauthenticated messages, and SHOULD be configured by default to discard unauthenticated messages if the client has been configured with an authentication key or other authentication information. A client MAY choose to differentiate between Advertise messages with no authentication information and Advertise messages that do not pass the validation test; for example, a client might accept the former and discard the latter. If a client does accept an unauthenticated message, the client SHOULD inform any local users and SHOULD log the event.
客户端必须可配置为丢弃未经身份验证的消息，如果客户端已配置身份验证密钥或其他身份验证信息，则默认情况下应配置为丢弃未经身份验证的消息。客户端可以选择区分没有身份验证信息的播发消息和未通过验证测试的播发消息；例如，客户机可能接受前者而放弃后者。如果客户端确实接受未经验证的消息，则客户端应通知任何本地用户并记录事件。
21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release Messages
21.4.4.3. 发送请求、确认、续订、重新绑定、拒绝或发布消息
If the client authenticated the Advertise message through which the client selected the server, the client MUST generate authentication information for subsequent Request, Confirm, Renew, Rebind or Release messages sent to the server, as described in section 21.4. When the client sends a subsequent message, it MUST use the same key used by the server to generate the authentication information.
如果客户机验证了客户机选择服务器时所通过的播发消息，则客户机必须为发送到服务器的后续请求、确认、续订、重新绑定或释放消息生成验证信息，如第21.4节所述。当客户端发送后续消息时，它必须使用服务器用于生成身份验证信息的相同密钥。
If the server has selected a key for the client in a previous message exchange (see section 21.4.5.1), the client MUST use the same key to generate the authentication information throughout the session.
如果服务器在以前的消息交换中为客户端选择了密钥（请参阅第21.4.5.1节），则客户端必须在整个会话中使用相同的密钥生成身份验证信息。
If the client authenticated the Advertise it accepted, the client MUST validate the associated Reply message from the server. The client MUST discard the Reply if the message fails to pass the validation test and MAY log the validation failure. If the Reply fails to pass the validation test, the client MUST restart the DHCP configuration process by sending a Solicit message.
如果客户机对其接受的播发进行了身份验证，则客户机必须验证来自服务器的相关回复消息。如果消息未能通过验证测试，客户端必须放弃回复，并且可能会记录验证失败。如果回复未能通过验证测试，则客户端必须通过发送请求消息重新启动DHCP配置过程。
If the client accepted an Advertise message that did not include authentication information or did not pass the validation test, the client MAY accept an unauthenticated Reply message from the server.
如果客户端接受了不包含身份验证信息或未通过验证测试的播发消息，则客户端可能会接受来自服务器的未经验证的回复消息。
The client MUST discard the Reconfigure if the message fails to pass the validation test and MAY log the validation failure.
如果消息未能通过验证测试，客户端必须放弃重新配置，并且可能会记录验证失败。
After receiving a Solicit message that contains an Authentication option, the server selects a key for the client, based on the client's DUID and key selection policies with which the server has been configured. The server identifies the selected key in the Advertise message and uses the key to validate subsequent messages between the client and the server.
在接收到包含身份验证选项的请求消息后，服务器将根据客户端的DUID和配置服务器的密钥选择策略为客户端选择密钥。服务器在播发消息中标识所选密钥，并使用该密钥验证客户端和服务器之间的后续消息。
The server selects a key for the client and includes authentication information in the Advertise message returned to the client as specified in section 21.4. The server MUST record the identifier of the key selected for the client and use that same key for validating subsequent messages with the client.
服务器为客户端选择一个密钥，并按照第21.4节的规定在返回给客户端的播发消息中包含身份验证信息。服务器必须记录为客户端选择的密钥的标识符，并使用该密钥验证客户端的后续消息。
21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages and Sending Reply Messages
21.4.5.2. 接收请求、确认、续订、重新绑定或发布消息以及发送回复消息
The server uses the key identified in the message and validates the message as specified in section 21.4.2. If the message fails to pass the validation test 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 the validation failure.
服务器使用消息中标识的密钥，并按照第21.4.2节的规定验证消息。如果消息未能通过验证测试，或者服务器不知道“密钥ID”字段标识的密钥，则服务器必须放弃该消息，并可以选择记录验证失败。
If the message passes the validation test, the server responds to the specific message as described in section 18.2. The server MUST include authentication information generated using the key identified in the received message, as specified in section 21.4.
如果消息通过验证测试，服务器将按照第18.2节所述响应特定消息。按照第21.4节的规定，服务器必须包括使用接收到的消息中标识的密钥生成的身份验证信息。
The Reconfigure key authentication protocol provides protection against misconfiguration of a client caused by a Reconfigure message sent by a malicious DHCP server. In this protocol, a DHCP server sends a Reconfigure Key to the client in the initial exchange of DHCP messages. The client records the Reconfigure Key for use in authenticating subsequent Reconfigure messages from that server. The server then includes an HMAC computed from the Reconfigure Key in subsequent Reconfigure messages.
重新配置密钥身份验证协议可防止恶意DHCP服务器发送的重新配置消息导致客户端配置错误。在此协议中，DHCP服务器在DHCP消息的初始交换中向客户端发送重新配置密钥。客户端记录重新配置密钥，用于验证来自该服务器的后续重新配置消息。然后，服务器在随后的重新配置消息中包含根据重新配置密钥计算的HMAC。
Both the Reconfigure Key sent from the server to the client and the HMAC in subsequent Reconfigure messages are carried as the Authentication information in an Authentication option. The format of the Authentication information is defined in the following section.
从服务器发送到客户端的重新配置密钥和后续重新配置消息中的HMAC都作为身份验证选项中的身份验证信息携带。认证信息的格式在下一节中定义。
The Reconfigure Key protocol is used (initiated by the server) only if the client and server are not using any other authentication protocol and the client and server have negotiated to use Reconfigure messages.
仅当客户端和服务器未使用任何其他身份验证协议且客户端和服务器已协商使用重新配置消息时，才使用重新配置密钥协议（由服务器启动）。
21.5.1. Use of the Authentication Option in the Reconfigure Key Authentication Protocol
21.5.1. 在重新配置密钥身份验证协议中使用身份验证选项
The following fields are set in an Authentication option for the Reconfigure Key Authentication Protocol:
在重新配置密钥身份验证协议的身份验证选项中设置了以下字段：
protocol 3
议定书3
algorithm 1
算法1
RDM 0
RDM0
The format of the Authentication information for the Reconfigure Key Authentication Protocol is:
重新配置密钥身份验证协议的身份验证信息格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value (128 bits) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value (128 bits) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type of data in Value field carried in this option:
此选项中携带的值字段中的数据类型：
1 Reconfigure Key value (used in Reply message).
1重新配置键值（用于回复消息）。
2 HMAC-MD5 digest of the message (used in Reconfigure message).
2条消息的HMAC-MD5摘要（用于重新配置消息）。
Value Data as defined by field.
由字段定义的值数据。
The server selects a Reconfigure Key for a client during the Request/Reply, Solicit/Reply or Information-request/Reply message exchange. The server records the Reconfigure Key and transmits that key to the client in an Authentication option in the Reply message.
服务器在请求/答复、请求/答复或信息请求/答复消息交换期间为客户端选择重新配置密钥。服务器记录重新配置密钥，并在回复消息中的身份验证选项中将该密钥传输给客户端。
The Reconfigure Key is 128 bits long, and MUST be a cryptographically strong random or pseudo-random number that cannot easily be predicted.
重新配置密钥的长度为128位，必须是无法轻易预测的加密强随机数或伪随机数。
To provide authentication for a Reconfigure message, the server selects a replay detection value according to the RDM selected by the server, and computes an HMAC-MD5 of the Reconfigure message using the Reconfigure Key for the client. The server computes the HMAC-MD5 over the entire DHCP Reconfigure message, including the Authentication option; the HMAC-MD5 field in the Authentication option is set to zero for the HMAC-MD5 computation. The server includes the HMAC-MD5 in the authentication information field in an Authentication option included in the Reconfigure message sent to the client.
为了为重新配置消息提供身份验证，服务器根据服务器选择的RDM选择重播检测值，并使用客户端的重新配置密钥计算重新配置消息的HMAC-MD5。服务器通过整个DHCP重新配置消息（包括身份验证选项）计算HMAC-MD5；对于HMAC-MD5计算，身份验证选项中的HMAC-MD5字段设置为零。服务器在发送给客户端的重新配置消息中包含的身份验证选项的身份验证信息字段中包含HMAC-MD5。
The client will receive a Reconfigure Key from the server in the initial Reply message from the server. The client records the Reconfigure Key for use in authenticating subsequent Reconfigure messages.
客户端将在来自服务器的初始回复消息中从服务器接收重新配置密钥。客户端记录重新配置密钥以用于验证后续重新配置消息。
To authenticate a Reconfigure message, the client computes an HMAC-MD5 over the DHCP Reconfigure message, using the Reconfigure Key received from the server. If this computed HMAC-MD5 matches the value in the Authentication option, the client accepts the Reconfigure message.
为了验证重新配置消息，客户端使用从服务器接收的重新配置密钥，通过DHCP重新配置消息计算HMAC-MD5。如果计算出的HMAC-MD5与身份验证选项中的值匹配，则客户端接受重新配置消息。
Options are used to carry additional information and parameters in DHCP messages. Every option shares a common base format, as described in section 22.1. All values in options are represented in network byte order.
选项用于在DHCP消息中携带附加信息和参数。如第22.1节所述，每个期权共享一个共同的基本格式。选项中的所有值都以网络字节顺序表示。
This document describes the DHCP options defined as part of the base DHCP specification. Other options may be defined in the future in separate documents.
本文档描述了作为基本DHCP规范一部分定义的DHCP选项。其他选项可能在将来的单独文件中定义。
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 appear multiple times, each instance is considered separate and the data areas of the options MUST NOT be concatenated or otherwise combined.
除非另有说明，否则每个选项只能出现在DHCP消息的选项区域中，并且只能出现一次。如果某个选项出现多次，则每个实例都被视为单独的，并且这些选项的数据区域不得连接或以其他方式组合。
The format of DHCP options is:
DHCP选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code An unsigned integer identifying the specific option type carried in this option.
选项代码标识此选项中包含的特定选项类型的无符号整数。
option-len An unsigned integer giving the length of the option-data field in this option in octets.
option len一个无符号整数，给出此选项中选项数据字段的长度（以八位字节为单位）。
option-data The data for the option; the format of this data depends on the definition of the option.
期权数据-期权的数据；此数据的格式取决于选项的定义。
DHCPv6 options are scoped by using encapsulation. Some options apply 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 discussed in sections 22.4 and 22.6.
DHCPv6选项的范围是通过使用封装来确定的。有些选项通常适用于客户端，有些特定于IA，有些特定于IA中的地址。第22.4节和第22.6节讨论了后两种情况。
The Client Identifier option is used to carry a DUID (see section 9) identifying a client between a client and a server. The format of the Client Identifier option is:
客户机标识符选项用于在客户机和服务器之间携带识别客户机的DUID（参见第9节）。客户端标识符选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENTID (1).
选项代码选项\客户端ID（1）。
option-len Length of DUID in octets.
选项len DUID的长度（以八位字节为单位）。
DUID The DUID for the client.
DUID客户端的DUID。
The Server Identifier option is used to carry a DUID (see section 9) identifying a server between a client and a server. The format of the Server Identifier option is:
服务器标识符选项用于携带一个DUID（参见第9节），用于在客户端和服务器之间标识服务器。服务器标识符选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SERVERID (2).
选项代码选项\服务器ID（2）。
option-len Length of DUID in octets.
选项len DUID的长度（以八位字节为单位）。
DUID The DUID for the server.
DUID服务器的DUID。
The Identity Association for Non-temporary Addresses option (IA_NA option) is used to carry an IA_NA, the parameters associated with the IA_NA, and the non-temporary addresses associated with the IA_NA.
非临时地址的标识关联选项（IA_NA选项）用于携带IA_NA、与IA_NA关联的参数以及与IA_NA关联的非临时地址。
Addresses appearing in an IA_NA option are not temporary addresses (see section 22.5).
IA_NA选项中出现的地址不是临时地址（见第22.5节）。
The format of the IA_NA option is:
IA_NA选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_NA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_NA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_NA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_NA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_IA_NA (3).
选项代码选项IA_NA（3）。
option-len 12 + length of IA_NA-options field.
选项长度12+IA_NA选项字段的长度。
IAID The unique identifier for this IA_NA; the IAID must be unique among the identifiers for all of this client's IA_NAs. The number space for IA_NA IAIDs is separate from the number space for IA_TA IAIDs.
IAID此IA_NA的唯一标识符；IAID在该客户端的所有IA_NAs的标识符中必须是唯一的。IA_NA IAID的数字空间与IA_TA IAID的数字空间是分开的。
T1 The time at which the client contacts the server from which the addresses in the IA_NA were obtained to extend the lifetimes of the addresses assigned to the IA_NA; T1 is a time duration relative to the current time expressed in units of seconds.
T1客户端与服务器联系的时间，从该服务器获取IA_NA中的地址，以延长分配给IA_NA的地址的生存期；T1是相对于当前时间的持续时间，以秒为单位表示。
T2 The time at which the client contacts any available server to extend the lifetimes of the addresses assigned to the IA_NA; T2 is a time duration relative to the current time expressed in units of seconds.
T2客户端联系任何可用服务器以延长分配给IA_NA的地址的生存期的时间；T2是相对于当前时间的持续时间，以秒为单位表示。
IA_NA-options Options associated with this IA_NA.
IA_NA—与此IA_NA关联的选项。
The IA_NA-options field encapsulates those options that are specific to this IA_NA. For example, all of the IA Address Options carrying the addresses associated with this IA_NA are in the IA_NA-options field.
IA_NA-options字段封装了特定于此IA_NA的选项。例如，包含与此IA_NA关联的地址的所有IA地址选项都位于IA_NA-Options字段中。
An IA_NA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_NA options.
IA_NA选项只能出现在DHCP消息的选项区域中。DHCP消息可能包含多个IA_NA选项。
The status of any operations involving this IA_NA is indicated in a Status Code option in the IA_NA-options field.
涉及此IA-NA的任何操作的状态在IA-NA-options字段中的状态代码选项中指示。
Note that an IA_NA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_NA have expired, the IA_NA can be considered as having expired. T1 and T2 are included to give servers explicit control over when a client recontacts the server about a specific IA_NA.
请注意，IA_NA本身没有明确的“寿命”或“租赁期限”。当IA_NA中所有地址的有效生存期已过期时，可以认为IA_NA已过期。T1和T2是为了让服务器明确控制客户端何时就特定IA_NA重新与服务器联系。
In a message sent by a client to a server, values in the T1 and T2 fields indicate the client's preference for those parameters. The client sets T1 and T2 to 0 if it has no preference for those values. In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters, unless those values in those fields are 0. The values in the T1 and T2 fields are the number of seconds until T1 and T2.
在客户端发送给服务器的消息中，T1和T2字段中的值表示客户端对这些参数的偏好。如果客户机对这些值没有偏好，则将T1和T2设置为0。在服务器发送给客户机的消息中，客户机必须使用T1和T2字段中的值作为T1和T2参数，除非这些字段中的值为0。T1和T2字段中的值是T1和T2之前的秒数。
The server selects the T1 and T2 times to allow the client to extend the lifetimes of any addresses in the IA_NA before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the addresses in the IA that the server is willing to extend, respectively. If the "shortest" preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values are also 0xffffffff. If the time at which the addresses in an IA_NA are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0.
服务器选择T1和T2时间，以允许客户端在生命周期到期之前延长IA_NA中任何地址的生命周期，即使服务器在短时间内不可用。T1和T2的建议值分别是服务器愿意延长的IA中地址的最短首选生存期的.5倍和.8倍。如果“最短”首选寿命为0xFFFFFF（“无穷大”），则建议的T1和T2值也为0xFFFFFF。如果更新IA_NA中地址的时间由客户端决定，则服务器将T1和T2设置为0。
If a server receives an IA_NA with T1 greater than T2, and both T1 and T2 are greater than 0, the server ignores the invalid values of T1 and T2 and processes the IA_NA as though the client had set T1 and T2 to 0.
如果服务器接收到T1大于T2的IA_NA，并且T1和T2都大于0，则服务器将忽略T1和T2的无效值，并处理IA_NA，就像客户端已将T1和T2设置为0一样。
If a client receives an IA_NA with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_NA option and processes the remainder of the message as though the server had not included the invalid IA_NA option.
如果客户端接收到T1大于T2的IA_NA，并且T1和T2都大于0，则客户端将丢弃IA_NA选项，并处理消息的其余部分，就像服务器未包含无效IA_NA选项一样。
Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). A client will never attempt to extend the lifetimes of any addresses in an IA with T1 set to 0xffffffff. A client will never attempt to use a Rebind message to locate a different server to extend the lifetimes of any addresses in an IA with T2 set to 0xffffffff.
在将T1或T2设置为0xffffffff（“无穷大”）时应小心。在T1设置为0xFFFFFF的IA中，客户端永远不会尝试延长任何地址的生存期。在T2设置为0xFFFFFF的IA中，客户端永远不会尝试使用重新绑定消息来定位不同的服务器，以延长任何地址的生存期。
The Identity Association for the Temporary Addresses (IA_TA) option is used to carry an IA_TA, the parameters associated with the IA_TA and the addresses associated with the IA_TA. All of the addresses in this option are used by the client as temporary addresses, as defined in RFC 3041 [12]. The format of the IA_TA option is:
临时地址（IA_TA）选项的标识关联用于携带IA_TA、与IA_TA关联的参数以及与IA_TA关联的地址。如RFC 3041[12]中所定义，此选项中的所有地址都被客户端用作临时地址。IA_TA选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_TA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_TA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_TA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_TA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_IA_TA (4).
选项代码选项IA_TA（4）。
option-len 4 + length of IA_TA-options field.
选项len 4+IA_TA-options字段的长度。
IAID The unique identifier for this IA_TA; the IAID must be unique among the identifiers for all of this client's IA_TAs. The number space for IA_TA IAIDs is separate from the number space for IA_NA IAIDs.
IAID此IA_TA的唯一标识符；IAID在该客户端的所有IA_TA的标识符中必须是唯一的。IA_TA IAID的数字空间与IA_NA IAID的数字空间是分开的。
IA_TA-options Options associated with this IA_TA.
IA_TA—与此IA_TA关联的选项。
The IA_TA-Options field encapsulates those options that are specific to this IA_TA. For example, all of the IA Address Options carrying the addresses associated with this IA_TA are in the IA_TA-options field.
IA_TA-Options字段封装了特定于此IA_TA的选项。例如，包含与此IA_TA关联的地址的所有IA地址选项都位于IA_TA-Options字段中。
Each IA_TA carries one "set" of temporary addresses; that is, at most one address from each prefix assigned to the link to which the client is attached.
每个IA_TA都有一套临时地址；也就是说，每个前缀中最多有一个地址分配给客户端所连接的链接。
An IA_TA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_TA options.
IA_TA选项只能出现在DHCP消息的选项区域中。DHCP消息可能包含多个IA_TA选项。
The status of any operations involving this IA_TA is indicated in a Status Code option in the IA_TA-options field.
涉及此IA_TA的任何操作的状态在IA_TA-options字段中的状态代码选项中指示。
Note that an IA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_TA have expired, the IA can be considered as having expired.
请注意，IA本身没有明确的“寿命”或“租赁期限”。当IA_TA中所有地址的有效生存期已过期时，IA可视为已过期。
An IA_TA option does not include values for T1 and T2. A client MAY request that the lifetimes on temporary addresses be extended by including the addresses in a IA_TA option sent in a Renew or Rebind message to a server. For example, a client would request an extension on the lifetime of a temporary address to allow an application to continue to use an established TCP connection.
IA_TA选项不包括T1和T2的值。客户端可以通过将地址包括在以续订或重新绑定消息发送到服务器的IA_TA选项中，请求延长临时地址的生存期。例如，客户机将请求延长临时地址的生存期，以允许应用程序继续使用已建立的TCP连接。
The client obtains new temporary addresses by sending an IA_TA option with a new IAID to a server. Requesting new temporary addresses from the server is the equivalent of generating new temporary addresses as described in RFC 3041. The server will generate new temporary addresses and return them to the client. The client should request new temporary addresses before the lifetimes on the previously assigned addresses expire.
客户端通过向服务器发送带有新IAID的IA_TA选项来获得新的临时地址。从服务器请求新的临时地址相当于生成RFC 3041中所述的新临时地址。服务器将生成新的临时地址并将其返回给客户端。客户端应在先前分配的地址的生存期到期之前请求新的临时地址。
A server MUST return the same set of temporary address for the same IA_TA (as identified by the IAID) as long as those addresses are still valid. After the lifetimes of the addresses in an IA_TA have expired, the IAID may be reused to identify a new IA_TA with new temporary addresses.
服务器必须为相同的IA_TA返回相同的临时地址集（由IAID标识），只要这些地址仍然有效。在IA_-TA中的地址的生存期到期后，可以重用IAID以用新的临时地址标识新的IA_-TA。
This option MAY appear in a Confirm message if the lifetimes on the temporary addresses in the associated IA have not expired.
如果相关IA中的临时地址的生存期尚未到期，则此选项可能出现在确认消息中。
The IA Address option is used to specify IPv6 addresses associated with an IA_NA or an IA_TA. The IA Address option must be encapsulated in the Options field of an IA_NA or IA_TA option. The Options field encapsulates those options that are specific to this address.
IA Address选项用于指定与IA_NA或IA_TA关联的IPv6地址。IA地址选项必须封装在IA_NA或IA_TA选项的选项字段中。选项字段封装了特定于此地址的选项。
The format of the IA Address option is:
IA地址选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IAADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IAaddr-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IAADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IAaddr-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_IAADDR (5).
选项代码选项_IAADDR（5）。
option-len 24 + length of IAaddr-options field.
选项长度24+IAaddr选项字段的长度。
IPv6 address An IPv6 address.
IPv6地址IPv6地址。
preferred-lifetime The preferred lifetime for the IPv6 address in the option, expressed in units of seconds.
首选生存期选项中IPv6地址的首选生存期，以秒为单位。
valid-lifetime The valid lifetime for the IPv6 address in the option, expressed in units of seconds.
有效生存期选项中IPv6地址的有效生存期，以秒为单位。
IAaddr-options Options associated with this address.
与此地址关联的IAaddr选项。
In a message sent by a client to a server, values in the preferred and valid lifetime fields indicate the client's preference for those parameters. The client may send 0 if it has no preference for the preferred and valid lifetimes. In a message sent by a server to a client, the client MUST use the values in the preferred and valid lifetime fields for the preferred and valid lifetimes. The values in the preferred and valid lifetimes are the number of seconds remaining in each lifetime.
在客户端发送给服务器的消息中，首选和有效生存期字段中的值表示客户端对这些参数的首选。如果客户端没有首选和有效的生存期，则可以发送0。在服务器发送给客户端的消息中，客户端必须使用首选和有效生存期字段中的值作为首选和有效生存期。首选和有效生存期中的值是每个生存期中剩余的秒数。
A client discards any addresses for which the preferred lifetime is greater than the valid lifetime. A server ignores the lifetimes set by the client if the preferred lifetime is greater than the valid lifetime and ignores the values for T1 and T2 set by the client if those values are greater than the preferred lifetime.
客户端丢弃首选生存期大于有效生存期的任何地址。如果首选生存期大于有效生存期，服务器将忽略客户端设置的生存期；如果T1和T2的值大于首选生存期，服务器将忽略客户端设置的这些值。
Care should be taken in setting the valid lifetime of an address to 0xffffffff ("infinity"), which amounts to a permanent assignment of an address to a client.
在将地址的有效生存期设置为0xffffffff（“无穷大”）时应小心，这相当于将地址永久分配给客户端。
An IA Address option may appear only in an IA_NA option or an IA_TA option. More than one IA Address Option can appear in an IA_NA option or an IA_TA option.
IA地址选项只能出现在IA_NA选项或IA_TA选项中。IA_NA选项或IA_TA选项中可以出现多个IA Address选项。
The status of any operations involving this IA Address is indicated in a Status Code option in the IAaddr-options field.
涉及此IA地址的任何操作的状态在IAaddr options字段的status Code选项中指示。
The Option Request option is used to identify a list of options in a message between a client and a server. The format of the Option Request option is:
Option Request选项用于标识客户端和服务器之间消息中的选项列表。选项请求选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ORO (6).
选项代码选项_ORO（6）。
option-len 2 * number of requested options.
选项len 2*请求的选项数。
requested-option-code-n The option code for an option requested by the client.
requested-option-code-n客户端请求的选项的选项代码。
A client MAY include an Option Request option in a Solicit, Request, Renew, Rebind, Confirm or Information-request message to inform the server about options the client wants the server to send to the client. A server MAY include an Option Request option in a Reconfigure option to indicate which options the client should request from the server.
客户端可以在请求、请求、续订、重新绑定、确认或信息请求消息中包括选项请求选项，以通知服务器客户端希望服务器发送给客户端的选项。服务器可以在重新配置选项中包含选项请求选项，以指示客户端应该从服务器请求哪些选项。
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 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value |
+-+-+-+-+-+-+-+-+
option-code OPTION_PREFERENCE (7).
选项代码选项_首选项（7）。
option-len 1.
选项1。
pref-value The preference value for the server in this message.
pref value此消息中服务器的首选项值。
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 for the use of the Preference option by the client and the interpretation of Preference option data value.
服务器可以在播发消息中包括首选项选项，以控制客户端对服务器的选择。关于客户对优先选择权的使用和优先选择权数据值的解释，请参见第17.1.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ELAPSED_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| elapsed-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ELAPSED_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| elapsed-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ELAPSED_TIME (8).
选项代码选项已用时间（8）。
option-len 2.
选项2。
elapsed-time The amount of time since the client began its current DHCP transaction. This time is expressed in hundredths of a second (10^-2 seconds).
已用时间自客户端开始其当前DHCP事务以来的时间量。此时间以百分之一秒（10^-2秒）表示。
A client MUST include an Elapsed Time option in messages to indicate how long the client has been trying to complete a DHCP message exchange. The elapsed time is measured from the time at which the client sent the first message in the message exchange, and the
客户端必须在消息中包含已用时间选项，以指示客户端尝试完成DHCP消息交换的时间。已用时间从客户端在消息交换中发送第一条消息的时间和
elapsed-time field is set to 0 in the first message in the message exchange. Servers and Relay Agents use the data value in this option as input to policy controlling how a server responds to a client message. For example, the elapsed time option allows a secondary DHCP server to respond to a request when a primary server has not answered in a reasonable time. The elapsed time value is an unsigned, 16 bit integer. The client uses the value 0xffff to represent any elapsed time values greater than the largest time value that can be represented in the Elapsed Time option.
在消息交换的第一条消息中，已用时间字段设置为0。服务器和中继代理使用此选项中的数据值作为策略的输入，以控制服务器如何响应客户端消息。例如，当主服务器在合理的时间内没有响应请求时，“已用时间”选项允许辅助DHCP服务器响应请求。已用时间值是一个无符号的16位整数。客户机使用值0xffff表示任何大于可在“已用时间”选项中表示的最大时间值的已用时间值。
The Relay Message option carries a DHCP message in a Relay-forward or Relay-reply message.
中继消息选项在中继转发或中继回复消息中携带DHCP消息。
The format of the Relay Message option is:
中继消息选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RELAY_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCP-relay-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RELAY_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCP-relay-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RELAY_MSG (9)
选项代码选项继电器消息（9）
option-len Length of DHCP-relay-message
选项len DHCP中继消息的长度
DHCP-relay-message In a Relay-forward message, the received message, relayed verbatim to the next relay agent or server; in a Relay-reply message, the message to be copied and relayed to the relay agent or client whose address is in the peer-address field of the Relay-reply message
DHCP中继消息在中继转发消息中，接收到的消息逐字中继到下一个中继代理或服务器；在中继回复消息中，要复制并中继到中继代理或客户端的消息，其地址位于中继回复消息的对等地址字段中
The Authentication option carries authentication information to authenticate the identity and contents of DHCP messages. The use of the Authentication option is described in section 21. The format of the Authentication option is:
身份验证选项携带身份验证信息，以验证DHCP消息的身份和内容。第21节描述了认证选项的使用。身份验证选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | algorithm | RDM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| replay detection (64 bits) +-+-+-+-+-+-+-+-+
| | auth-info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. authentication information .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | algorithm | RDM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| replay detection (64 bits) +-+-+-+-+-+-+-+-+
| | auth-info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. authentication information .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_AUTH (11)
选项代码选项认证（11）
option-len 11 + length of authentication information field
选项len 11+身份验证信息字段的长度
protocol The authentication protocol used in this authentication option
协议此身份验证选项中使用的身份验证协议
algorithm The algorithm used in the authentication protocol
算法身份验证协议中使用的算法
RDM The replay detection method used in this authentication option
RDM此身份验证选项中使用的重播检测方法
Replay detection The replay detection information for the RDM
重播检测RDM的重播检测信息
authentication information The authentication information, as specified by the protocol and algorithm used in this authentication option
身份验证信息此身份验证选项中使用的协议和算法指定的身份验证信息
The server sends this option to a client to indicate to the client that it is allowed to unicast messages to the server. The format of the Server Unicast option is:
服务器将此选项发送到客户端，以向客户端指示允许将消息单播到服务器。服务器单播选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_UNICAST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_UNICAST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_UNICAST (12).
选项代码选项_单播（12）。
option-len 16.
选项16。
server-address The IP address to which the client should send messages delivered using unicast.
服务器地址客户端应向其发送使用单播传送的消息的IP地址。
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.
服务器在“服务器地址”字段中指定客户端要向其发送单播消息的IPv6地址。当客户端收到此选项时（在允许和适当的情况下），客户端将使用该选项的“服务器地址”字段中指定的IPv6地址直接向服务器发送消息。
When the server sends a Unicast option to the client, some messages from the client will not be relayed by Relay Agents, and will not include Relay Agent options from the Relay Agents. Therefore, a server should only send a Unicast option to a client when Relay Agents are not sending Relay Agent options. A DHCP server rejects any messages sent inappropriately using unicast to ensure that messages are relayed by Relay Agents when Relay Agent options are in use.
当服务器向客户端发送单播选项时，来自客户端的某些消息将不会由中继代理转发，并且不会包括来自中继代理的中继代理选项。因此，当中继代理不发送中继代理选项时，服务器只应向客户端发送单播选项。DHCP服务器拒绝使用单播不当发送的任何消息，以确保在使用中继代理选项时由中继代理中继消息。
Details about when the client may send messages to the server using unicast are in section 18.
有关客户端何时可以使用单播向服务器发送消息的详细信息，请参见第18节。
This option returns a status indication related to the DHCP message or option in which it appears. The format of the Status Code option is:
此选项返回与DHCP消息或其出现的选项相关的状态指示。状态代码选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. status-message .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. status-message .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_STATUS_CODE (13).
选项代码选项状态代码（13）。
option-len 2 + length of status-message.
选项len 2+状态消息的长度。
status-code The numeric code for the status encoded in this option. The status codes are defined in section 24.4.
状态代码此选项中编码的状态的数字代码。第24.4节定义了状态代码。
status-message A UTF-8 encoded text string suitable for display to an end user, which MUST NOT be null-terminated.
状态消息适用于向最终用户显示的UTF-8编码文本字符串，不得以null结尾。
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.
状态代码选项可能出现在DHCP消息的选项字段和/或另一选项的选项字段中。如果状态代码选项未出现在可能出现该选项的消息中，则假定该消息的状态为成功。
The Rapid Commit option is used to signal the use of the two message exchange for address assignment. The format of the Rapid Commit option is:
快速提交选项用于发出使用两条消息交换进行地址分配的信号。快速提交选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RAPID_COMMIT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_RAPID_COMMIT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RAPID_COMMIT (14).
选项代码选项快速提交（14）。
option-len 0.
选项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.
如果客户准备执行第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:
讨论：
Each server that responds with a Reply to a Solicit that includes a Rapid Commit option will commit the assigned addresses in the Reply message to the client, and will not receive any confirmation that the client has received the Reply message. Therefore, if more than one server responds to a Solicit that includes a Rapid Commit option, some servers will commit addresses that are not actually used by the client.
对于包含快速提交选项的请求，每台服务器都会在回复消息中将分配的地址提交给客户端，并且不会收到客户端已收到回复消息的任何确认。因此，如果多个服务器响应包含快速提交选项的请求，则某些服务器将提交客户端实际未使用的地址。
The problem of unused addresses can be minimized, for example, by designing the DHCP service so that only one server responds to the Solicit or by using relatively short lifetimes for assigned addresses.
未使用地址的问题可以最小化，例如，通过设计DHCP服务，使只有一台服务器响应请求，或者通过对分配的地址使用相对较短的生存期。
The User Class option is used by a client to identify the type or category of user or applications it represents.
用户类选项由客户端用来标识它所代表的用户或应用程序的类型或类别。
The format of the User 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_USER_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. user-class-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. user-class-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_USER_CLASS (15).
选项代码选项用户类（15）。
option-len Length of user class data field.
选项len用户类数据字段的长度。
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 instances of user class data. Each instance of the user class data 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 opaque user class data in network byte order.
用户类len有两个八位字节长，以网络字节顺序指定不透明用户类数据的长度。
A server interprets the classes identified in this option according to its configuration to select the appropriate configuration information for the client. A server may use only those user classes that it is configured to interpret in selecting configuration information for a client and ignore any other user classes. In response to a message containing a User Class option, a server includes a User Class option containing those classes that were successfully interpreted by the server, so that the client can be informed of the classes interpreted by the server.
服务器根据其配置解释此选项中标识的类，以便为客户端选择适当的配置信息。在为客户机选择配置信息时，服务器只能使用其配置为解释的那些用户类，而忽略任何其他用户类。作为对包含用户类选项的消息的响应，服务器包括一个用户类选项，该选项包含服务器已成功解释的那些类，以便可以将服务器解释的类通知客户端。
This option is used by a client to identify the vendor that manufactured the hardware on which the client is running. The information contained in the data area of this option is contained in one or more opaque fields that identify details of the hardware 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_VENDOR_CLASS (16).
选项代码选项\供应商\类别（16）。
option-len 4 + length of vendor class data field.
选项len 4+供应商类别数据字段的长度。
enterprise-number The vendor's registered Enterprise Number as registered with IANA [6].
企业编号供应商在IANA注册的注册企业编号[6]。
vendor-class-data The hardware configuration of the host on which the client is running.
供应商类数据运行客户端的主机的硬件配置。
The vendor-class-data is composed of a series of separate items, each of which describes some characteristic of the client's hardware configuration. Examples of vendor-class-data instances might include the version of the operating system the client is running or the amount of memory installed on the client.
供应商类数据由一系列单独的项组成，每个项描述客户机硬件配置的一些特征。供应商类数据实例的示例可能包括客户端正在运行的操作系统版本或客户端上安装的内存量。
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 opaque vendor class data in network byte order.
供应商类len有两个八位字节长，并以网络字节顺序指定不透明供应商类数据的长度。
This option is used by clients and servers to exchange vendor-specific information.
客户端和服务器使用此选项交换特定于供应商的信息。
The format of the Vendor-specific Information 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_VENDOR_OPTS (17)
选项代码选项\供应商\选项（17）
option-len 4 + length of option-data field
选项长度4+选项数据字段的长度
enterprise-number The vendor's registered Enterprise Number as registered with IANA [6].
企业编号供应商在IANA注册的注册企业编号[6]。
option-data An opaque object of option-len octets, interpreted by vendor-specific code on the clients and servers
option data option len八位字节的不透明对象，由客户机和服务器上的供应商特定代码解释
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.
此选项中包含的信息的定义是特定于供应商的。供应商在“企业编号”字段中指明。使用特定于供应商的信息可以增强操作，利用供应商DHCP实现中的附加功能。未接收请求的供应商特定信息的DHCP客户端仍将配置主机设备的IPv6堆栈以使其正常工作。
The encapsulated vendor-specific options field MUST be encoded as a sequence of code/length/value fields of identical format to the DHCP options field. The option codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA. Each of the encapsulated options is formatted as follows:
封装的特定于供应商的选项字段必须编码为与DHCP选项字段格式相同的代码/长度/值字段序列。选项代码由企业编号字段中标识的供应商定义，不由IANA管理。每个封装选项的格式如下所示：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| opt-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| opt-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt-code The code for the encapsulated option.
opt code封装选项的代码。
option-len An unsigned integer giving the length of the option-data field in this encapsulated option in octets.
option len一个无符号整数，给出此封装选项中选项数据字段的长度（以八位字节为单位）。
option-data The data area for the encapsulated option.
选项数据封装选项的数据区域。
Multiple instances of the Vendor-specific Information option may appear in a DHCP message. Each instance of the option is interpreted according to the option codes defined by the vendor identified by the Enterprise Number in that option.
DHCP消息中可能会出现供应商特定信息选项的多个实例。该选项的每个实例都根据该选项中由企业编号标识的供应商定义的选项代码进行解释。
The relay agent MAY send the Interface-id option to identify the interface on which the client message was received. If a relay agent receives a Relay-reply message with an Interface-id option, the relay agent relays the message to the client through the interface identified by the option.
中继代理可以发送接口id选项，以标识接收客户端消息的接口。如果中继代理接收到带有接口id选项的中继回复消息，则中继代理将通过该选项标识的接口将消息中继到客户端。
The format of the Interface ID option is:
接口ID选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INTERFACE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. interface-id .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INTERFACE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. interface-id .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_INTERFACE_ID (18).
选项代码选项接口ID（18）。
option-len Length of interface-id field.
选项len接口id字段的长度。
interface-id An opaque value of arbitrary length generated by the relay agent to identify one of the relay agent's interfaces.
接口id中继代理生成的任意长度的不透明值，用于标识中继代理的一个接口。
The server MUST copy the Interface-Id option from the Relay-Forward message into the Relay-Reply message the server sends to the relay agent in response to the Relay-Forward message. This option MUST NOT appear in any message except a Relay-Forward or Relay-Reply message.
服务器必须将接口Id选项从中继转发消息复制到服务器发送给中继代理以响应中继转发消息的中继回复消息中。除中继转发或中继回复消息外，此选项不得出现在任何消息中。
Servers MAY use the Interface-ID for parameter assignment policies. The Interface-ID SHOULD be considered an opaque value, with policies based on exact match only; that is, the Interface-ID SHOULD NOT be internally parsed by the server. The Interface-ID value for an interface SHOULD be stable and remain unchanged, for example, after the relay agent is restarted; if the Interface-ID changes, a server will not be able to use it reliably in parameter assignment policies.
服务器可以将接口ID用于参数分配策略。接口ID应被视为不透明值，策略仅基于精确匹配；也就是说，服务器不应在内部解析接口ID。接口的接口ID值应稳定且保持不变，例如，在中继代理重新启动后；如果接口ID更改，服务器将无法在参数分配策略中可靠地使用它。
A server includes a Reconfigure Message option in a Reconfigure message to indicate to the client whether the client responds with a Renew message or an Information-request message. The format of this option is:
服务器在重新配置消息中包括重新配置消息选项，以向客户端指示客户端是使用续订消息还是信息请求消息进行响应。此选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |
+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_MSG (19).
选项代码选项识别信息（19）。
option-len 1.
选项1。
msg-type 5 for Renew message, 11 for Information-request message.
消息类型5表示续订消息，11表示信息请求消息。
The Reconfigure Message option can only appear in a Reconfigure message.
重新配置消息选项只能出现在重新配置消息中。
A client uses the Reconfigure Accept option to announce to the server whether the client is willing to accept Reconfigure messages, and a server uses this option to tell the client whether or not to accept Reconfigure messages. The default behavior, in the absence of this option, means unwillingness to accept Reconfigure messages, or instruction not to accept Reconfigure messages, for the client and server messages, respectively. The following figure gives the format of the Reconfigure Accept option:
客户端使用重新配置接受选项向服务器宣布客户端是否愿意接受重新配置消息，服务器使用此选项告知客户端是否接受重新配置消息。在没有此选项的情况下，默认行为意味着不愿意分别接受客户机和服务器消息的重新配置消息，或不接受重新配置消息的指令。下图给出了重新配置接受选项的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_ACCEPT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_ACCEPT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_ACCEPT (20).
选项代码选项重新确认接受（20）。
option-len 0.
选项len 0。
The threat to DHCP is inherently an insider threat (assuming a properly configured network where DHCPv6 ports are blocked on the perimeter gateways of the enterprise). Regardless of the gateway configuration, however, the potential attacks by insiders and outsiders are the same.
对DHCP的威胁本质上是一种内部威胁（假设在正确配置的网络中，DHCPv6端口在企业的外围网关上被阻塞）。但是，无论网关配置如何，内部人员和外部人员的潜在攻击都是相同的。
Use of manually configured preshared keys for IPsec between relay agents and servers does not defend against replayed DHCP messages. Replayed messages can represent a DOS attack through exhaustion of processing resources, but not through mis-configuration or exhaustion of other resources such as assignable addresses.
在中继代理和服务器之间为IPsec使用手动配置的预共享密钥不会防止重播DHCP消息。重放的消息可以通过耗尽处理资源而表示DOS攻击，但不能通过错误配置或耗尽其他资源（如可分配地址）。
One attack specific to a DHCP client is the establishment of a malicious server with the intent of providing incorrect configuration information to the client. The motivation for doing so may be to
针对DHCP客户端的一种攻击是建立恶意服务器，目的是向客户端提供不正确的配置信息。这样做的动机可能是
mount a "man in the middle" attack that causes the client to communicate with a malicious server instead of a valid server for some service such as DNS or NTP. The malicious server may also mount a denial of service attack through misconfiguration of the client that causes all network communication from the client to fail.
装载“中间人”攻击，该攻击会导致客户端与恶意服务器通信，而不是与某些服务（如DNS或NTP）的有效服务器通信。恶意服务器还可能通过错误配置客户端而发起拒绝服务攻击，从而导致来自客户端的所有网络通信失败。
There is another threat to DHCP clients from mistakenly or accidentally configured DHCP servers that answer DHCP client requests with unintentionally incorrect configuration parameters.
错误或意外配置的DHCP服务器会对DHCP客户端造成另一种威胁，这些服务器会使用不正确的配置参数响应DHCP客户端请求。
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 relayed, 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客户端还可能通过从恶意服务器接收重新配置消息而受到攻击，该消息会导致客户端从该服务器获取不正确的配置信息。请注意，尽管客户端通过中继代理发送其响应（续订或信息请求消息），因此该响应将仅由DHCP消息中继到的服务器接收，但恶意服务器可能会向客户端发送重新配置消息，然后（经过适当的延迟）通过客户端接受的回复消息。因此，不在客户端和服务器之间的网络路径上的恶意服务器可能仍然能够在客户端上装载重新配置攻击。使用加密可靠且不易预测的事务ID也将降低此类攻击成功的概率。
The threat specific to a DHCP server is an invalid client masquerading as a valid client. The motivation for this may be for theft of service, or to circumvent auditing for any number of nefarious purposes.
DHCP服务器特有的威胁是伪装为有效客户端的无效客户端。这样做的动机可能是为了窃取服务，或为了任何邪恶目的规避审计。
The threat common to both the client and the server is the resource "denial of service" (DoS) attack. These attacks typically involve the exhaustion of available addresses, or the exhaustion of CPU or network bandwidth, and are present anytime there is a shared resource.
客户端和服务器共同面临的威胁是资源“拒绝服务”（DoS）攻击。这些攻击通常涉及可用地址耗尽，或CPU或网络带宽耗尽，并且在存在共享资源时随时存在。
In the case where relay agents add additional options to Relay Forward messages, the messages exchanged between relay agents and servers may be used to mount a "man in the middle" or denial of service attack.
在中继代理添加额外选项以中继转发消息的情况下，中继代理和服务器之间交换的消息可用于发起“中间人”攻击或拒绝服务攻击。
This threat model does not consider the privacy of the contents of DHCP messages to be important. DHCP is not used to exchange authentication or configuration information that must be kept secret from other networks nodes.
这种威胁模型不考虑DHCP消息内容的隐私是重要的。DHCP不用于交换必须对其他网络节点保密的身份验证或配置信息。
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.
DHCP身份验证提供DHCP客户端和服务器的身份验证，以及DHCP客户端和服务器之间传递的消息的完整性。DHCP身份验证不为DHCP消息的内容提供任何隐私。
The Delayed Authentication protocol described in section 21.4 uses a secret key that is shared between a client and a server. The use of a "DHCP realm" in the shared key allows identification of administrative domains so that a client can select the appropriate key or keys when roaming between administrative domains. However, the Delayed Authentication protocol does not define any mechanism for sharing of keys, so a client may require separate keys for each administrative domain it encounters. 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.
第21.4节中描述的延迟认证协议使用客户机和服务器之间共享的密钥。在共享密钥中使用“DHCP域”可以识别管理域，以便客户端在管理域之间漫游时可以选择适当的密钥。但是，延迟身份验证协议没有定义任何共享密钥的机制，因此客户端可能需要为其遇到的每个管理域使用单独的密钥。共享密钥的使用可能无法很好地扩展，并且不能拒绝泄露的密钥。该协议主要解决共享密钥带外交换可行的域内问题。
Because of the opportunity for attack through the Reconfigure message, a DHCP client MUST discard any Reconfigure message that does not include authentication or that does not pass the validation process for the authentication protocol.
由于存在通过重新配置消息进行攻击的机会，DHCP客户端必须丢弃任何不包含身份验证或未通过身份验证协议验证过程的重新配置消息。
The Reconfigure Key protocol described in section 21.5 provides protection against the use of a Reconfigure message by a malicious DHCP server to mount a denial of service or man-in-the-middle attack on a client. This protocol can be compromised by an attacker that can intercept the initial message in which the DHCP server sends the key to the client.
第21.5节中描述的重新配置密钥协议提供保护，防止恶意DHCP服务器使用重新配置消息在客户端上发起拒绝服务或中间人攻击。攻击者可以截获DHCP服务器向客户端发送密钥的初始消息，从而破坏该协议。
Communication between a server and a relay agent, and communication between relay agents, can be secured through the use of IPSec, as described in section 21.1. The use of manual configuration and installation of static keys are acceptable in this instance because relay agents and the server will belong to the same administrative domain and the relay agents will require other specific configuration (for example, configuration of the DHCP server address) as well as the IPSec configuration.
服务器和中继代理之间的通信以及中继代理之间的通信可以通过使用IPSec进行保护，如第21.1节所述。在这种情况下，可以使用手动配置和安装静态密钥，因为中继代理和服务器将属于同一管理域，中继代理将需要其他特定配置（例如，DHCP服务器地址的配置）以及IPSec配置。
This document defines several new name spaces associated with DHCPv6 and DHCPv6 options:
本文档定义了几个与DHCPv6和DHCPv6选项关联的新名称空间：
- Message types
- 消息类型
- Status codes
- 状态代码
- DUID
- 杜伊德
- Option codes
- 选项代码
IANA has established a registry of values for each of these name spaces, which are described in the remainder of this section. These name spaces will be managed by the IANA and all will be managed separately from the name spaces defined for DHCPv4.
IANA已经为每个名称空间建立了一个值注册表，本节的其余部分将对此进行描述。这些名称空间将由IANA管理，所有名称空间将与为DHCPv4定义的名称空间分开管理。
New multicast addresses, message types, status codes, and DUID types are assigned via Standards Action [11].
通过标准操作[11]分配新的多播地址、消息类型、状态代码和DUID类型。
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 [11]. The final assignment of DHCP option codes is through Standards Action, as defined in RFC 2434 [11].
新的DHCP选项代码在相关选项的规范（作为互联网草案发布）得到指定专家的专家审查后暂定分配[11]。DHCP选项代码的最终分配是通过RFC 2434[11]中定义的标准操作进行的。
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 RFC 3118 [4].
本文件还引用了第21节中与认证选项（第22.11节）相关的三个名称空间。这些名称空间由RFC 3118[4]中DHCPv4的身份验证机制定义。
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.
IANA当前注册的身份验证名称空间将同时适用于DHCPv6和DHCPv4。将来，定义新协议、算法和RDM机制的规范将明确定义新机制是与DHCPv4、DHCPv6一起使用，还是与两者一起使用。
Section 5.1 defines the following multicast addresses, which have been assigned by IANA for use by DHCPv6:
第5.1节定义了IANA分配给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
IANA has recorded the following message types (defined in section 5.3). IANA will maintain the registry of DHCP message types.
IANA记录了以下消息类型（定义见第5.3节）。IANA将维护DHCP消息类型的注册表。
SOLICIT 1
征集1
ADVERTISE 2
广告2
REQUEST 3
请求3
CONFIRM 4
确认4
RENEW 5
续约5
REBIND 6
重新绑定6
REPLY 7
答复7
RELEASE 8
第8版
DECLINE 9
拒绝9
RECONFIGURE 10
重新配置10
INFORMATION-REQUEST 11
信息-请求11
RELAY-FORW 12
继电器-FORW 12
RELAY-REPL 13
继电器-REPL 13
IANA has recorded the following option-codes (as defined in section 22). IANA will maintain the registry of DHCP option codes.
IANA记录了以下选项代码（定义见第22节）。IANA将维护DHCP选项代码的注册表。
OPTION_CLIENTID 1
选项\u客户ID 1
OPTION_SERVERID 2
选项\u服务器ID 2
OPTION_IA_NA 3
方案3
OPTION_IA_TA 4
方案4
OPTION_IAADDR 5
选项_IAADDR 5
OPTION_ORO 6
方案(六)
OPTION_PREFERENCE 7
选项(七)
OPTION_ELAPSED_TIME 8
选项\u已用\u时间8
OPTION_RELAY_MSG 9
选项\u继电器\u消息9
OPTION_AUTH 11
选项11
OPTION_UNICAST 12
选项_单播12
OPTION_STATUS_CODE 13
选项\状态\代码13
OPTION_RAPID_COMMIT 14
选项_快速_提交14
OPTION_USER_CLASS 15
选项\用户\类别15
OPTION_VENDOR_CLASS 16
选项\供应商\类别16
OPTION_VENDOR_OPTS 17
选项\供应商\选项17
OPTION_INTERFACE_ID 18
选项\u接口\u ID 18
OPTION_RECONF_MSG 19
选项重新确认消息19
OPTION_RECONF_ACCEPT 20
选项重新确认接受20
IANA has recorded the status codes defined in the following table. IANA will manage the definition of additional status codes in the future.
IANA已记录下表中定义的状态代码。IANA将在未来管理其他状态代码的定义。
Name Code Description
---------- ---- -----------
Success 0 Success.
UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
document.
NoAddrsAvail 2 Server has no addresses available to assign to
the IA(s).
NoBinding 3 Client record (binding) unavailable.
NotOnLink 4 The prefix for the address is not appropriate for
the link to which the client is attached.
UseMulticast 5 Sent by a server to a client to force the
client to send messages to the server.
using the All_DHCP_Relay_Agents_and_Servers
address.
Name Code Description
---------- ---- -----------
Success 0 Success.
UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
document.
NoAddrsAvail 2 Server has no addresses available to assign to
the IA(s).
NoBinding 3 Client record (binding) unavailable.
NotOnLink 4 The prefix for the address is not appropriate for
the link to which the client is attached.
UseMulticast 5 Sent by a server to a client to force the
client to send messages to the server.
using the All_DHCP_Relay_Agents_and_Servers
address.
IANA has recorded the following DUID types (as defined in section 9.1). IANA will manage the definition of additional DUID types in the future.
IANA记录了以下DUID类型（定义见第9.1节）。IANA将在将来管理其他DUID类型的定义。
DUID-LLT 1
DUID-LLT 1
DUID-EN 2
DUID-EN 2
DUID-LL 3
DUID-LL 3
Thanks to the DHC Working Group and the members of the IETF for their time and input into the specification. In particular, thanks also for the consistent input, ideas, and review by (in alphabetical order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont, Richard Hussong, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Mark Stapp, Matt Thomas, Sue Thomson, Tatuya Jinmei and Phil Wells.
感谢DHC工作组和IETF成员的时间和对规范的投入。特别要感谢伯纳德·阿博巴、比尔·阿博格、蒂鲁马莱什·巴特、史蒂夫·贝洛文、A.K.维贾亚巴斯卡、布赖恩·卡彭特、马特·克劳福德、弗朗西斯·杜邦、理查德·胡松、金·金尼尔、弗雷德里克·林德霍姆、托尼·林德斯特罗姆、乔什·利特菲尔德、杰拉尔德·马奎尔、杰克·麦肯（Jack McCann）等（按字母顺序）的一贯投入、想法和评论，三宅川申、托马斯·纳滕、埃里克·诺德马克、雅诺·拉贾哈尔梅、雅科夫·雷克特、马克·斯塔普、马特·托马斯、休·汤姆森、塔图亚·金梅和菲尔·威尔斯。
Thanks to Steve Deering and Bob Hinden, who have consistently taken the time to discuss the more complex parts of the IPv6 specifications.
感谢Steve Deering和Bob Hinden，他们一直花时间讨论IPv6规范中更复杂的部分。
And, thanks to Steve Deering for pointing out at IETF 51 in London that the DHCPv6 specification has the highest revision number of any Internet Draft.
此外，感谢Steve Deering在伦敦IETF 51上指出DHCPv6规范的修订号是所有互联网草案中最高的。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[2] Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[3] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[4] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[4] Droms，R.，Ed.和W.Arbaugh，Ed.，“DHCP消息的身份验证”，RFC31182001年6月。
[5] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[5] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[6] IANA. Private Enterprise Numbers. http://www.iana.org/assignments/enterprise-numbers.html.
[6] 伊安娜。私营企业编号。http://www.iana.org/assignments/enterprise-numbers.html.
[7] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[7] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[8] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[8] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[9] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[9] Mills，D.，“网络时间协议（版本3）规范，实施”，RFC13051992年3月。
[10] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987.
[10] Mockapetris，P.，“域名-实现和规范”，RFC10351987年11月。
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[11] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[12] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[12] Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC3041，2001年1月。
[13] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[13] Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[14] Plummer, D.C., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[14] Plummer，D.C.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[15] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[16] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[17] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[17] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[18] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[18] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[19] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[19] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[20] R. Droms, Ed. DNS Configuration options for DHCPv6. April 2002. Work in Progress.
[20] R.Droms，Ed.DHCPv6的DNS配置选项。2002年4月。正在进行的工作。
[21] A. K. Vijayabhaskar. Time Configuration Options for DHCPv6. May 2002. Work in Progress.
[21] A.K.Vijayabhaskar。DHCPv6的时间配置选项。2002年5月。正在进行的工作。
[22] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[22] Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
A. Appearance of Options in Message Types
A.消息类型中选项的外观
The following table indicates with a "*" the options are allowed in each DHCP message type:
下表用“*”表示每个DHCP消息类型中允许的选项：
Client Server IA_NA Option Pref Time Relay Auth. Server
ID ID IA_TA Request Msg. Unica.
Solicit * * * * *
Advert. * * * * *
Request * * * * * *
Confirm * * * * *
Renew * * * * * *
Rebind * * * * *
Decline * * * * * *
Release * * * * * *
Reply * * * * * *
Reconf. * * * *
Inform. * (see note) * * *
R-forw. * *
R-repl. * *
Client Server IA_NA Option Pref Time Relay Auth. Server
ID ID IA_TA Request Msg. Unica.
Solicit * * * * *
Advert. * * * * *
Request * * * * * *
Confirm * * * * *
Renew * * * * * *
Rebind * * * * *
Decline * * * * * *
Release * * * * * *
Reply * * * * * *
Reconf. * * * *
Inform. * (see note) * * *
R-forw. * *
R-repl. * *
NOTE:
注:
Only included in Information-Request messages that are sent in response to a Reconfigure (see section 19.4.3).
仅包含在响应重新配置而发送的信息请求消息中（见第19.4.3节）。
Status Rap. User Vendor Vendor Inter. Recon. Recon.
Code Comm. Class Class Spec. ID Msg. Accept
Solicit * * * * *
Advert. * * * * *
Request * * * *
Confirm * * *
Renew * * * *
Rebind * * * *
Decline * * *
Release * * *
Reply * * * * * *
Reconf. *
Inform. * * * *
R-forw. * * * *
R-repl. * * * *
Status Rap. User Vendor Vendor Inter. Recon. Recon.
Code Comm. Class Class Spec. ID Msg. Accept
Solicit * * * * *
Advert. * * * * *
Request * * * *
Confirm * * *
Renew * * * *
Rebind * * * *
Decline * * *
Release * * *
Reply * * * * * *
Reconf. *
Inform. * * * *
R-forw. * * * *
R-repl. * * * *
B. Appearance of Options in the Options Field of DHCP Options
B.在DHCP选项的选项字段中显示选项
The following table indicates with a "*" where options can appear in the options field of other options:
下表用“*”表示选项可出现在其他选项的选项字段中的位置：
Option IA_NA/ IAADDR Relay Relay
Field IA_TA Forw. Reply
Client ID *
Server ID *
IA_NA/IA_TA *
IAADDR *
ORO *
Preference *
Elapsed Time *
Relay Message * *
Authentic. *
Server Uni. *
Status Code * * *
Rapid Comm. *
User Class *
Vendor Class *
Vendor Info. *
Interf. ID * *
Reconf. MSG. *
Reconf. Accept *
Option IA_NA/ IAADDR Relay Relay
Field IA_TA Forw. Reply
Client ID *
Server ID *
IA_NA/IA_TA *
IAADDR *
ORO *
Preference *
Elapsed Time *
Relay Message * *
Authentic. *
Server Uni. *
Status Code * * *
Rapid Comm. *
User Class *
Vendor Class *
Vendor Info. *
Interf. ID * *
Reconf. MSG. *
Reconf. Accept *
Note: "Relay Forw" / "Relay Reply" options appear in the options
field of the message but may only appear in these messages.
Note: "Relay Forw" / "Relay Reply" options appear in the options
field of the message but may only appear in these messages.
Chair's Address
主席致辞
The working group can be contacted via the current chair:
可通过现任主席联系工作组：
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719
Ralph Droms思科系统公司马萨诸塞州博克斯伯勒大道1414号，邮编01719
Phone: (978) 936-1674 EMail: rdroms@cisco.com
电话：（978）936-1674电子邮件：rdroms@cisco.com
Authors' Addresses
作者地址
Jim Bound Hewlett Packard Corporation ZK3-3/W20 110 Spit Brook Road Nashua, NH 03062-2698 USA
Jim Bound Hewlett-Packard Corporation ZK3-3/W20美国新罕布什尔州纳舒亚市斯皮布鲁克路110号，邮编03062-2698
Phone: +1 603 884 0062
EMail: Jim.Bound@hp.com
Phone: +1 603 884 0062
EMail: Jim.Bound@hp.com
Bernie Volz 116 Hawkins Pond Road Center Harbor, NH 03226-3103 USA
伯尼沃尔兹美国新罕布什尔州霍金斯池塘路中心港116号，邮编03226-3103
Phone: +1-508-259-3734
EMail: volz@metrocast.net
Phone: +1-508-259-3734
EMail: volz@metrocast.net
Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 USA
Ted Lemon Nominum，Inc.美国加利福尼亚州红木市Charter Street 950号，邮编94043
EMail: Ted.Lemon@nominum.com
EMail: Ted.Lemon@nominum.com
Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
Charles E.Perkins通信系统实验室诺基亚研究中心313 Fairchild Drive Mountain View，加利福尼亚94043
Phone: +1-650 625-2986
EMail: charles.perkins@nokia.com
Phone: +1-650 625-2986
EMail: charles.perkins@nokia.com
Mike Carney Sun Microsystems, Inc 17 Network Circle Menlo Park, CA 94025 USA
Mike Carney Sun Microsystems，Inc.美国加利福尼亚州门罗公园17号网络圈，邮编94025
Phone: +1-650-786-4171
EMail: michael.carney@sun.com
Phone: +1-650-786-4171
EMail: michael.carney@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。