Internet Engineering Task Force (IETF) T. Mrugalski
Request for Comments: 8156 ISC
Category: Standards Track K. Kinnear
ISSN: 2070-1721 Cisco
June 2017
Internet Engineering Task Force (IETF) T. Mrugalski
Request for Comments: 8156 ISC
Category: Standards Track K. Kinnear
ISSN: 2070-1721 Cisco
June 2017
DHCPv6 Failover Protocol
DHCPv6故障转移协议
Abstract
摘要
DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" (RFC 3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC 7031).
“IPv6动态主机配置协议（DHCPv6）”（RFC 3315）中定义的DHCPv6不提供服务器冗余。本文档定义了一个协议实现，以提供DHCPv6故障切换，这是一种运行两台服务器的机制，其中一台服务器能够在服务器故障或网络分区时接管客户端的租约。它满足“DHCPv6故障切换要求”（RFC 7031）中详细说明的DHCPv6故障切换要求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8156.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8156.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................5
2. Requirements Language ...........................................5
3. Glossary ........................................................6
4. Failover Concepts and Mechanisms ...............................10
4.1. Required Server Configuration .............................10
4.2. IPv6 Address and Delegable Prefix Allocation ..............10
4.2.1. Independent Allocation .............................10
4.2.1.1. Independent Allocation Algorithm ..........11
4.2.2. Proportional Allocation ............................11
4.2.2.1. Reallocating Leases .......................13
4.3. Lazy Updates ..............................................14
4.4. Maximum Client Lead Time (MCLT) ...........................14
4.4.1. MCLT Example .......................................16
5. Message and Option Definitions .................................19
5.1. Message Framing for TCP ...................................19
5.2. Failover Message Format ...................................19
5.3. Messages ..................................................20
5.3.1. BNDUPD .............................................20
5.3.2. BNDREPLY ...........................................20
5.3.3. POOLREQ ............................................20
5.3.4. POOLRESP ...........................................21
5.3.5. UPDREQ .............................................21
5.3.6. UPDREQALL ..........................................21
5.3.7. UPDDONE ............................................21
5.3.8. CONNECT ............................................21
5.3.9. CONNECTREPLY .......................................22
5.3.10. DISCONNECT ........................................22
5.3.11. STATE .............................................22
5.3.12. CONTACT ...........................................22
5.4. Transaction-id ............................................22
5.5. Options ...................................................23
5.5.1. OPTION_F_BINDING_STATUS ............................23
5.5.2. OPTION_F_CONNECT_FLAGS .............................24
5.5.3. OPTION_F_DNS_REMOVAL_INFO ..........................25
5.5.3.1. OPTION_F_DNS_HOST_NAME ....................26
5.5.3.2. OPTION_F_DNS_ZONE_NAME ....................26
5.5.3.3. OPTION_F_DNS_FLAGS ........................27
5.5.4. OPTION_F_EXPIRATION_TIME ...........................28
5.5.5. OPTION_F_MAX_UNACKED_BNDUPD ........................29
5.5.6. OPTION_F_MCLT ......................................29
5.5.7. OPTION_F_PARTNER_LIFETIME ..........................30
5.5.8. OPTION_F_PARTNER_LIFETIME_SENT .....................30
5.5.9. OPTION_F_PARTNER_DOWN_TIME .........................31
5.5.10. OPTION_F_PARTNER_RAW_CLT_TIME .....................32
5.5.11. OPTION_F_PROTOCOL_VERSION .........................32
1. Introduction ....................................................5
2. Requirements Language ...........................................5
3. Glossary ........................................................6
4. Failover Concepts and Mechanisms ...............................10
4.1. Required Server Configuration .............................10
4.2. IPv6 Address and Delegable Prefix Allocation ..............10
4.2.1. Independent Allocation .............................10
4.2.1.1. Independent Allocation Algorithm ..........11
4.2.2. Proportional Allocation ............................11
4.2.2.1. Reallocating Leases .......................13
4.3. Lazy Updates ..............................................14
4.4. Maximum Client Lead Time (MCLT) ...........................14
4.4.1. MCLT Example .......................................16
5. Message and Option Definitions .................................19
5.1. Message Framing for TCP ...................................19
5.2. Failover Message Format ...................................19
5.3. Messages ..................................................20
5.3.1. BNDUPD .............................................20
5.3.2. BNDREPLY ...........................................20
5.3.3. POOLREQ ............................................20
5.3.4. POOLRESP ...........................................21
5.3.5. UPDREQ .............................................21
5.3.6. UPDREQALL ..........................................21
5.3.7. UPDDONE ............................................21
5.3.8. CONNECT ............................................21
5.3.9. CONNECTREPLY .......................................22
5.3.10. DISCONNECT ........................................22
5.3.11. STATE .............................................22
5.3.12. CONTACT ...........................................22
5.4. Transaction-id ............................................22
5.5. Options ...................................................23
5.5.1. OPTION_F_BINDING_STATUS ............................23
5.5.2. OPTION_F_CONNECT_FLAGS .............................24
5.5.3. OPTION_F_DNS_REMOVAL_INFO ..........................25
5.5.3.1. OPTION_F_DNS_HOST_NAME ....................26
5.5.3.2. OPTION_F_DNS_ZONE_NAME ....................26
5.5.3.3. OPTION_F_DNS_FLAGS ........................27
5.5.4. OPTION_F_EXPIRATION_TIME ...........................28
5.5.5. OPTION_F_MAX_UNACKED_BNDUPD ........................29
5.5.6. OPTION_F_MCLT ......................................29
5.5.7. OPTION_F_PARTNER_LIFETIME ..........................30
5.5.8. OPTION_F_PARTNER_LIFETIME_SENT .....................30
5.5.9. OPTION_F_PARTNER_DOWN_TIME .........................31
5.5.10. OPTION_F_PARTNER_RAW_CLT_TIME .....................32
5.5.11. OPTION_F_PROTOCOL_VERSION .........................32
5.5.12. OPTION_F_KEEPALIVE_TIME ...........................33
5.5.13. OPTION_F_RECONFIGURE_DATA .........................34
5.5.14. OPTION_F_RELATIONSHIP_NAME ........................35
5.5.15. OPTION_F_SERVER_FLAGS .............................36
5.5.16. OPTION_F_SERVER_STATE .............................37
5.5.17. OPTION_F_START_TIME_OF_STATE ......................38
5.5.18. OPTION_F_STATE_EXPIRATION_TIME ....................38
5.6. Status Codes ..............................................39
6. Connection Management ..........................................40
6.1. Creating Connections ......................................40
6.1.1. Sending a CONNECT Message ..........................41
6.1.2. Receiving a CONNECT Message ........................42
6.1.3. Receiving a CONNECTREPLY Message ...................43
6.2. Endpoint Identification ...................................44
6.3. Sending a STATE Message ...................................45
6.4. Receiving a STATE Message .................................46
6.5. Connection Maintenance Parameters .........................46
6.6. Unreachability Detection ..................................47
7. Binding Updates and Acks .......................................47
7.1. Time Skew .................................................47
7.2. Information Model .........................................48
7.3. Times Required for Exchanging Binding Updates .............52
7.4. Sending Binding Updates ...................................53
7.5. Receiving Binding Updates .................................56
7.5.1. Monitoring Time Skew ...............................56
7.5.2. Acknowledging Reception ............................56
7.5.3. Processing Binding Updates .........................57
7.5.4. Accept or Reject? ..................................57
7.5.5. Accepting Updates ..................................59
7.6. Sending Binding Replies ...................................61
7.7. Receiving Binding Acks ....................................63
7.8. BNDUPD/BNDREPLY Data Flow .................................65
8. Endpoint States ................................................66
8.1. State Machine Operation ...................................66
8.2. State Machine Initialization ..............................69
8.3. STARTUP State .............................................70
8.3.1. Operation in STARTUP State .........................70
8.3.2. Transition out of STARTUP State ....................70
8.4. PARTNER-DOWN State ........................................72
8.4.1. Operation in PARTNER-DOWN State ....................72
8.4.2. Transition out of PARTNER-DOWN State ...............73
8.5. RECOVER State .............................................74
8.5.1. Operation in RECOVER State .........................74
8.5.2. Transition out of RECOVER State ....................74
8.6. RECOVER-WAIT State ........................................76
8.6.1. Operation in RECOVER-WAIT State ....................76
8.6.2. Transition out of RECOVER-WAIT State ...............76
5.5.12. OPTION_F_KEEPALIVE_TIME ...........................33
5.5.13. OPTION_F_RECONFIGURE_DATA .........................34
5.5.14. OPTION_F_RELATIONSHIP_NAME ........................35
5.5.15. OPTION_F_SERVER_FLAGS .............................36
5.5.16. OPTION_F_SERVER_STATE .............................37
5.5.17. OPTION_F_START_TIME_OF_STATE ......................38
5.5.18. OPTION_F_STATE_EXPIRATION_TIME ....................38
5.6. Status Codes ..............................................39
6. Connection Management ..........................................40
6.1. Creating Connections ......................................40
6.1.1. Sending a CONNECT Message ..........................41
6.1.2. Receiving a CONNECT Message ........................42
6.1.3. Receiving a CONNECTREPLY Message ...................43
6.2. Endpoint Identification ...................................44
6.3. Sending a STATE Message ...................................45
6.4. Receiving a STATE Message .................................46
6.5. Connection Maintenance Parameters .........................46
6.6. Unreachability Detection ..................................47
7. Binding Updates and Acks .......................................47
7.1. Time Skew .................................................47
7.2. Information Model .........................................48
7.3. Times Required for Exchanging Binding Updates .............52
7.4. Sending Binding Updates ...................................53
7.5. Receiving Binding Updates .................................56
7.5.1. Monitoring Time Skew ...............................56
7.5.2. Acknowledging Reception ............................56
7.5.3. Processing Binding Updates .........................57
7.5.4. Accept or Reject? ..................................57
7.5.5. Accepting Updates ..................................59
7.6. Sending Binding Replies ...................................61
7.7. Receiving Binding Acks ....................................63
7.8. BNDUPD/BNDREPLY Data Flow .................................65
8. Endpoint States ................................................66
8.1. State Machine Operation ...................................66
8.2. State Machine Initialization ..............................69
8.3. STARTUP State .............................................70
8.3.1. Operation in STARTUP State .........................70
8.3.2. Transition out of STARTUP State ....................70
8.4. PARTNER-DOWN State ........................................72
8.4.1. Operation in PARTNER-DOWN State ....................72
8.4.2. Transition out of PARTNER-DOWN State ...............73
8.5. RECOVER State .............................................74
8.5.1. Operation in RECOVER State .........................74
8.5.2. Transition out of RECOVER State ....................74
8.6. RECOVER-WAIT State ........................................76
8.6.1. Operation in RECOVER-WAIT State ....................76
8.6.2. Transition out of RECOVER-WAIT State ...............76
8.7. RECOVER-DONE State ........................................77
8.7.1. Operation in RECOVER-DONE State ....................77
8.7.2. Transition out of RECOVER-DONE State ...............77
8.8. NORMAL State ..............................................77
8.8.1. Operation in NORMAL State ..........................78
8.8.2. Transition out of NORMAL State .....................78
8.9. COMMUNICATIONS-INTERRUPTED State ..........................79
8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State ......80
8.9.2. Transition out of COMMUNICATIONS-INTERRUPTED
State ..............................................80
8.10. POTENTIAL-CONFLICT State .................................82
8.10.1. Operation in POTENTIAL-CONFLICT State .............82
8.10.2. Transition out of POTENTIAL-CONFLICT State ........82
8.11. RESOLUTION-INTERRUPTED State .............................83
8.11.1. Operation in RESOLUTION-INTERRUPTED State .........84
8.11.2. Transition out of RESOLUTION-INTERRUPTED State ....84
8.12. CONFLICT-DONE State ......................................84
8.12.1. Operation in CONFLICT-DONE State ..................85
8.12.2. Transition out of CONFLICT-DONE State .............85
9. DNS Update Considerations ......................................85
9.1. Relationship between Failover and DNS Update ..............86
9.2. Exchanging DNS Update Information .........................87
9.3. Adding RRs to the DNS .....................................89
9.4. Deleting RRs from the DNS .................................90
9.5. Name Assignment with No Update of DNS .....................91
10. Security Considerations .......................................91
11. IANA Considerations ...........................................92
12. References ....................................................94
12.1. Normative References .....................................94
12.2. Informative References ...................................96
Acknowledgements ..................................................96
Authors' Addresses ................................................96
8.7. RECOVER-DONE State ........................................77
8.7.1. Operation in RECOVER-DONE State ....................77
8.7.2. Transition out of RECOVER-DONE State ...............77
8.8. NORMAL State ..............................................77
8.8.1. Operation in NORMAL State ..........................78
8.8.2. Transition out of NORMAL State .....................78
8.9. COMMUNICATIONS-INTERRUPTED State ..........................79
8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State ......80
8.9.2. Transition out of COMMUNICATIONS-INTERRUPTED
State ..............................................80
8.10. POTENTIAL-CONFLICT State .................................82
8.10.1. Operation in POTENTIAL-CONFLICT State .............82
8.10.2. Transition out of POTENTIAL-CONFLICT State ........82
8.11. RESOLUTION-INTERRUPTED State .............................83
8.11.1. Operation in RESOLUTION-INTERRUPTED State .........84
8.11.2. Transition out of RESOLUTION-INTERRUPTED State ....84
8.12. CONFLICT-DONE State ......................................84
8.12.1. Operation in CONFLICT-DONE State ..................85
8.12.2. Transition out of CONFLICT-DONE State .............85
9. DNS Update Considerations ......................................85
9.1. Relationship between Failover and DNS Update ..............86
9.2. Exchanging DNS Update Information .........................87
9.3. Adding RRs to the DNS .....................................89
9.4. Deleting RRs from the DNS .................................90
9.5. Name Assignment with No Update of DNS .....................91
10. Security Considerations .......................................91
11. IANA Considerations ...........................................92
12. References ....................................................94
12.1. Normative References .....................................94
12.2. Informative References ...................................96
Acknowledgements ..................................................96
Authors' Addresses ................................................96
This document defines a DHCPv6 failover protocol, which is a mechanism for running two DHCPv6 servers [RFC3315] with the capability for either server to take over clients' leases in case of server failover or network partition. For a general overview of DHCPv6 failover problems, use cases, benefits, and shortcomings, see [RFC7031].
本文档定义了DHCPv6故障转移协议，该协议是一种运行两台DHCPv6服务器[RFC3315]的机制，在服务器故障转移或网络分区的情况下，任何一台服务器都可以接管客户端的租约。有关DHCPv6故障切换问题、用例、优点和缺点的一般概述，请参阅[RFC7031]。
The failover protocol provides a means for cooperating DHCP servers to work together to provide a service to DHCP clients with availability that is increased beyond the availability that could be provided by a single DHCP server operating alone. It is designed to protect DHCP clients against server unreachability, including server failure and network partition. It is possible to deploy exactly two servers that are able to continue providing a lease for an IPv6 address [RFC3315] or on an IPv6 prefix [RFC3633] without the DHCP client experiencing lease expiration or a reassignment of a lease to a different IPv6 address or prefix in the event of failure by one or the other of the two servers.
故障切换协议提供了一种方法，使DHCP服务器能够协同工作，向DHCP客户端提供服务，其可用性的提高超出了单独运行的单个DHCP服务器所能提供的可用性。它旨在保护DHCP客户端不受服务器不可访问性的影响，包括服务器故障和网络分区。可以部署两台能够继续为IPv6地址[RFC3315]或IPv6前缀[RFC3633]提供租约的服务器，而DHCP客户端不会经历租约到期或在两台服务器中的一台或另一台出现故障时将租约重新分配到不同的IPv6地址或前缀。
The failover protocol defines an active-passive mode, sometimes also called a "hot standby" model. This means that during normal operation one server is active (i.e., it actively responds to clients' requests) while the second is passive (i.e., it receives clients' requests but responds only to those specifically directed to it). The secondary server maintains a copy of the binding database and is ready to take over all incoming queries in case the primary server fails.
故障切换协议定义了一种主动-被动模式，有时也称为“热备用”模式。这意味着在正常操作期间，一台服务器是主动的（即，它主动响应客户机的请求），而第二台服务器是被动的（即，它接收客户机的请求，但只响应专门针对它的请求）。辅助服务器维护绑定数据库的副本，并准备在主服务器出现故障时接管所有传入查询。
The failover protocol is designed to provide lease stability for leases with valid lifetimes beyond a short period. The DHCPv6 failover protocol MUST NOT be used for new leases shorter than 30 seconds. Leases reaching the end of their lifetimes are not affected by this restriction.
故障切换协议旨在为有效寿命超过短期的租约提供租约稳定性。DHCPv6故障切换协议不得用于短于30秒的新租约。租约到期时不受此限制的影响。
The failover protocol fulfills all DHCPv6 failover requirements defined in [RFC7031].
故障转移协议满足[RFC7031]中定义的所有DHCPv6故障转移要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This is a supplemental glossary that should be used in combination with the definitions in Section 2 of RFC 7031 [RFC7031].
这是一个补充术语表，应与RFC 7031[RFC7031]第2节中的定义结合使用。
o Absolute Time
o 绝对时间
"Absolute time" refers to the time in seconds since midnight January 1, 2000 UTC, modulo 2^32.
“绝对时间”是指自UTC 2000年1月1日午夜起的时间（以秒为单位），模数为2^32。
o Address Lease
o 地址租赁
"Address lease" refers to a lease involving an IPv6 address. Typically used when it is necessary to distinguish the lease for an IPv6 address from a lease for a DHCP prefix. See the definitions for "delegated prefix" and "prefix lease" below.
“地址租约”是指涉及IPv6地址的租约。通常在需要区分IPv6地址的租约和DHCP前缀的租约时使用。请参见下文“委托前缀”和“前缀租赁”的定义。
o auto-partner-down
o 自动伙伴关闭
"auto-partner-down" refers to a capability where a failover server will move from COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN state automatically, without operator intervention.
“自动合作伙伴关闭”是指故障切换服务器将自动从通信中断状态移动到合作伙伴关闭状态，而无需操作员干预的功能。
o Available (Lease or Prefix)
o 可用（租约或前缀）
A lease or delegable prefix is available if it could be allocated for use by a DHCP client. It is available on the main server when it is in the FREE state and available on the secondary server when it is in the FREE-BACKUP state. The term "available" is sometimes used when it would be awkward to say "FREE on the primary server and FREE-BACKUP on the secondary server".
如果可以将租约或可委派前缀分配给DHCP客户端使用，则该前缀可用。当主服务器处于空闲状态时，它在主服务器上可用；当辅助服务器处于空闲备份状态时，它在辅助服务器上可用。当说“主服务器上免费，辅助服务器上免费备份”有些尴尬时，有时会使用“可用”一词。
o Binding-Status
o 约束状态
A lease can hold a variety of states (see Section 5.5.1 for a list); these are also referred to as the "binding-status" of the lease.
租赁可持有多种状态（列表见第5.5.1节）；这些也被称为租约的“约束状态”。
o Delegable Prefix
o 可删除前缀
"Delegable prefix" refers to a prefix from which other prefixes may be delegated, using the mechanisms described in [RFC3633]. A prefix that has been delegated is known as a "delegated prefix" or a "prefix lease".
“可委派前缀”是指使用[RFC3633]中描述的机制委派其他前缀的前缀。已委托的前缀称为“委托前缀”或“前缀租约”。
o Delegated Prefix
o 委托前缀
A delegated prefix is a prefix that has been delegated to a DHCP client as described in [RFC3633]. Depending on the context, a delegated prefix may also be described as a "prefix lease" when it is necessary to distinguish it from an "address lease".
委派前缀是已委派给DHCP客户端的前缀，如[RFC3633]中所述。根据上下文，当需要将委托前缀与“地址租约”区分开来时，也可以将其描述为“前缀租约”。
o DHCP Prefix
o DHCP前缀
A DHCP prefix is part of the IPv6 address space configured to be managed by a DHCP server.
DHCP前缀是配置为由DHCP服务器管理的IPv6地址空间的一部分。
o Failover Endpoint
o 故障转移端点
The failover protocol permits a unique failover "endpoint" for each failover relationship in which a failover server participates. The failover relationship is defined by a relationship name and includes
故障转移协议允许故障转移服务器参与的每个故障转移关系具有唯一的故障转移“端点”。故障转移关系由关系名称定义，包括
* the failover partner IP address,
* 故障转移伙伴IP地址，
* the role this server takes with respect to that partner (primary or secondary), and
* 此服务器对该合作伙伴（主要或次要）所扮演的角色，以及
* the prefixes from which addresses can be leased, as well as prefixes from which other prefixes can be delegated (delegable prefixes), that are associated with that relationship.
* 可以从中租用地址的前缀，以及可以从中委派其他前缀（可委派前缀）的前缀，这些前缀与该关系关联。
The failover endpoint can take actions and hold unique states. Typically, there is one failover endpoint per partner (server), although there may be more.
故障转移终结点可以执行操作并保持唯一状态。通常，每个合作伙伴（服务器）有一个故障转移端点，尽管可能有更多。
o Failover Communication
o 故障转移通信
"Failover communication" refers to all messages exchanged between partners.
“故障切换通信”是指合作伙伴之间交换的所有消息。
o Independent Allocation
o 独立分配
"Independent allocation" refers to an allocation algorithm that splits the available pool of address leases between the primary and secondary servers. It is used for IPv6 address allocations. See Section 4.2.1.
“独立分配”是指在主服务器和辅助服务器之间分割可用地址租用池的分配算法。它用于IPv6地址分配。见第4.2.1节。
o Lease
o 租赁
A lease is an association of a DHCP client with an IPv6 address or delegated prefix. This might refer to either an existing association or a potential association.
租约是DHCP客户端与IPv6地址或委派前缀的关联。这可能是指现有关联或潜在关联。
o MCLT (Maximum Client Lead Time)
o MCLT（最大客户交付周期）
The fundamental relationship on which much of the correctness of the failover protocol depends is that the lease expiration time known to a DHCP client MUST NOT be greater by more than the MCLT beyond the later of the partner lifetime acknowledged by that server's failover partner or the current time (i.e., now). See Section 4.4.
故障切换协议的大部分正确性所依赖的基本关系是，DHCP客户端已知的租约到期时间不得超过该服务器的故障切换伙伴确认的伙伴生存期或当前时间（即现在）之后的MCLT。见第4.4节。
o Partner
o 配偶
The other DHCP server that participates in a failover relationship is referred to as the "partner". When the role (primary or secondary) is not important, the other server is referred to as a "failover partner" or sometimes simply "partner".
参与故障转移关系的另一台DHCP服务器称为“合作伙伴”。当角色（主服务器或辅助服务器）不重要时，另一台服务器称为“故障转移伙伴”，有时简称为“伙伴”。
o Prefix Lease
o 前缀租赁
A prefix lease is a lease involving a prefix that is delegated or could be delegated, as opposed to a lease for a single IPv6 address. A prefix lease can also be described as a "delegated prefix".
前缀租约是涉及已委派或可委派前缀的租约，与单个IPv6地址的租约不同。前缀租赁也可以描述为“委托前缀”。
o Primary Server
o 主服务器
The primary server is the first of the two DHCP servers that participate in a failover relationship. When both servers are operating, this server handles most of the client traffic. Its failover partner is referred to as the "secondary server".
主服务器是参与故障转移关系的两个DHCP服务器中的第一个。当两台服务器都在运行时，此服务器处理大部分客户端通信。其故障转移伙伴称为“辅助服务器”。
o Proportional Allocation
o 比例分配
"Proportional allocation" is an allocation algorithm that splits the delegable prefixes between the primary and secondary servers and maintains a more or less fixed proportion of the delegable prefixes between both servers. See Section 4.2.2.
“比例分配”是一种分配算法，它在主服务器和辅助服务器之间拆分可删除前缀，并在两台服务器之间保持大致固定的可删除前缀比例。见第4.2.2节。
o Renew Responsive
o 更新响应
A server that is "renew responsive" will respond to valid DHCP client messages that are directed to it by having an OPTION_SERVERID option in the message that contains the DHCP Unique Identifier (DUID) of the renew responsive server. See [RFC3315].
“响应续订”的服务器将通过在包含响应续订的服务器的DHCP唯一标识符（DUID）的消息中包含选项_SERVERID选项来响应指向它的有效DHCP客户端消息。参见[RFC3315]。
o Responsive
o 反应敏捷的
A server that is responsive will respond to all valid DHCP client messages.
响应的服务器将响应所有有效的DHCP客户端消息。
o Secondary Server
o 辅助服务器
The secondary server is the second of the two DHCP servers that participate in a failover relationship. Its failover partner is referred to as the "primary server" (as defined above). When both servers are operating, this server (the secondary) typically does not handle client traffic and acts as a backup to the primary server. However, it will respond to RENEW requests directed specifically to it.
辅助服务器是参与故障转移关系的两个DHCP服务器中的第二个。其故障转移伙伴称为“主服务器”（如上所述）。当两台服务器都在运行时，此服务器（辅助服务器）通常不处理客户端流量，而是充当主服务器的备份。但是，它将响应专门针对它的续订请求。
o Server
o 服务器
"Server" refers to a DHCP server that implements DHCPv6 failover. "Server" and "failover endpoint" are synonymous only if the server participates in only one failover relationship.
“服务器”是指实现DHCPv6故障切换的DHCP服务器。只有当服务器只参与一个故障转移关系时，“服务器”和“故障转移端点”才是同义词。
o State
o 状态
The term "state" is used in two ways in this document. A failover endpoint is always in some state, and there are a series of states that a failover endpoint can move through. See Section 8 for details of the failover endpoint states. A lease also has a state, and this is sometimes referred to as a "binding-status". See Section 5.5.1 for a list of the states a lease can hold.
本文件中“状态”一词有两种用法。故障转移端点始终处于某种状态，故障转移端点可以通过一系列状态移动。有关故障转移端点状态的详细信息，请参见第8节。租约也有状态，这有时被称为“约束状态”。参见第5.5.1节，了解租赁可持有的状态列表。
o Unresponsive
o 无反应
A server that is unresponsive will not respond to DHCP client messages.
无响应的服务器不会响应DHCP客户端消息。
The following concepts and mechanisms are necessary for the operation of the failover protocol. They are not currently employed by DHCPv6 [RFC3315]. The failover protocol provides support for all of these concepts and mechanisms.
以下概念和机制对于故障切换协议的操作是必要的。DHCPv6[RFC3315]目前没有使用它们。故障切换协议支持所有这些概念和机制。
Servers frequently have several kinds of leases available on a particular network segment. The failover protocol assumes that both the primary server and the secondary server are configured identically with regard to the prefixes and links involved in DHCP. For delegable prefixes (involved in proportional allocation), the primary server is responsible for allocating to the secondary server the correct proportion of the available delegable prefixes. IPv6 addresses (involved in independent allocation) are allocated to the primary and secondary servers algorithmically and do not require an explicit message transfer to be distributed.
服务器通常在特定的网段上有几种可用的租约。故障切换协议假定主服务器和辅助服务器在DHCP中涉及的前缀和链接方面配置相同。对于可删除前缀（涉及比例分配），主服务器负责向辅助服务器分配正确比例的可用可删除前缀。IPv6地址（涉及独立分配）通过算法分配给主服务器和辅助服务器，不需要分配明确的消息传输。
Currently, there are two allocation algorithms defined: one for address leases and one for prefix leases.
目前，定义了两种分配算法：一种用于地址租约，另一种用于前缀租约。
In this allocation scheme, which is used for allocating individual IPv6 addresses, available IPv6 addresses are permanently (until server configuration changes) split between servers. Available IPv6 addresses are split between the primary and secondary servers as part of initial connection establishment. Once IPv6 addresses are allocated to each server, there is no need to reassign them. The IPv6 address allocation is algorithmic in nature and does not require a message exchange for each server to know which IPv6 addresses it has been allocated. This algorithm is simpler than proportional allocation, since it does not require a rebalancing mechanism. It also assumes that the pool assigned to each server will never be depleted.
在此用于分配单个IPv6地址的分配方案中，可用IPv6地址在服务器之间永久分割（直到服务器配置更改）。作为初始连接建立的一部分，可用IPv6地址在主服务器和辅助服务器之间分割。一旦将IPv6地址分配给每个服务器，就不需要重新分配它们。IPv6地址分配本质上是算法性的，不需要为每台服务器交换消息来知道已分配了哪些IPv6地址。该算法比比例分配简单，因为它不需要再平衡机制。它还假设分配给每个服务器的池永远不会耗尽。
Once each server is assigned a pool of IPv6 addresses during initial connection establishment, it may allocate its assigned IPv6 addresses to clients. Once a client releases a lease or its lease on an IPv6 address expires, the returned IPv6 address returns to the pool for the server that leased it. A lease on an IPv6 address can be renewed by a responsive server or by a renew responsive server. When an IPv6 address goes PENDING-FREE (see Section 7.2), it is owned by whichever server it is allocated to by the independent allocation algorithm.
一旦在初始连接建立期间为每台服务器分配了一个IPv6地址池，它就可以将其分配的IPv6地址分配给客户端。一旦客户端释放租约或其对IPv6地址的租约到期，返回的IPv6地址将返回到租用该地址的服务器的池。IPv6地址的租约可以由响应服务器或续订响应服务器续订。当IPv6地址变为无挂起（参见第7.2节）时，它由独立分配算法分配给它的服务器所有。
IPv6 addresses, which use the independent allocation approach, will be ignored when a server processes a POOLREQ message.
当服务器处理POOLREQ消息时，将忽略使用独立分配方法的IPv6地址。
During COMMUNICATIONS-INTERRUPTED events, a partner MAY continue extending existing address leases as requested by clients. An operational partner MUST NOT lease IPv6 addresses that were assigned to its downed partner and later expired or that were released or declined by a client. When it is in PARTNER-DOWN state, a server MUST allocate new leases from its own pool. It MUST NOT use its partner's pool to allocate new leases.
在通信中断事件期间，合作伙伴可以根据客户端的请求继续扩展现有地址租约。运营合作伙伴不得租赁已分配给其宕机合作伙伴并随后过期的IPv6地址，或已被客户端释放或拒绝的IPv6地址。当服务器处于伙伴关闭状态时，它必须从自己的池中分配新租约。不得使用其合作伙伴的池分配新租约。
For each address that can be allocated, the primary server MUST allocate only IPv6 addresses when the low-order bit (i.e., bit 127) is equal to 1, and the secondary server MUST allocate only the IPv6 addresses when the low-order bit (i.e., bit 127) is equal to 0.
对于可以分配的每个地址，当低位（即位127）等于1时，主服务器必须仅分配IPv6地址，当低位（即位127）等于0时，辅助服务器必须仅分配IPv6地址。
In this allocation scheme, each server has its own pool of prefixes available for delegation, known as "delegable prefixes". These delegable prefixes may be prefixes from which other prefixes can be delegated, or they may be prefixes that are the correct size for delegation but are not, at present, delegated to a particular client. Remaining delegable prefixes are split between the primary and secondary servers in a configured proportion. Note that a delegated prefix (also known as a "prefix lease") is not "owned" by a particular server. Only a delegable prefix that is available is owned by a particular server -- once it has been delegated (leased) to a client, it becomes a prefix lease and is not owned by either failover partner. When it finally becomes available again, it will be initially owned by the primary server, and it may or may not be allocated to the secondary server by the primary server.
在这个分配方案中，每台服务器都有自己的前缀池可用于委派，称为“可委派前缀”。这些可委派前缀可以是其他前缀可以委派的前缀，也可以是委派大小正确但目前未委派给特定客户机的前缀。剩余的可删除前缀在主服务器和辅助服务器之间按配置的比例分配。请注意，委派的前缀（也称为“前缀租约”）不是由特定服务器“拥有”的。只有可用的可委派前缀由特定服务器拥有——一旦它被委派（租用）给客户机，它就成为前缀租用，不属于任何故障转移伙伴。当它最终再次可用时，它最初将由主服务器拥有，并且它可能由主服务器分配给辅助服务器，也可能不由主服务器分配给辅助服务器。
The flow of a delegable prefix is as follows: initially, the delegable prefix is part of a set of delegable prefixes, all of which are initially owned by the primary server. A delegable prefix may be allocated to the secondary server, and it is then owned by the secondary server. Either server can allocate and delegate prefixes out of the delegable prefixes that they own. Once these prefixes are delegated (leased) to clients, the servers cease to own them, and they are owned by the clients to which they have been delegated (leased). When the client releases the delegated prefix or the lease on it expires, the prefix will again become available, will again be a delegable prefix, and will be owned by the primary.
可委派前缀的流程如下：最初，可委派前缀是一组可委派前缀的一部分，所有这些前缀最初都由主服务器拥有。可委派前缀可分配给辅助服务器，然后由辅助服务器拥有。任何一台服务器都可以从它们拥有的可委派前缀中分配和委派前缀。一旦这些前缀被委托（租用）给客户机，服务器就不再拥有它们，它们由被委托（租用）给它们的客户机拥有。当客户端释放委派前缀或其租约到期时，该前缀将再次可用，将再次成为可委派前缀，并将由主客户端拥有。
A server delegates prefixes only from its own pool of delegable prefixes in all states except for PARTNER-DOWN. In PARTNER-DOWN state, the operational partner can delegate prefixes from either pool (both its own, and its partner's after some time constraints have elapsed). The operational partner SHOULD allocate from its own pool before using its partner's pool. The allocation and maintenance of these pools of delegable prefixes are important, since the goal is to maintain a more or less constant ratio of delegable prefixes between the two servers.
服务器仅从其自身的可委派前缀池中委派前缀，除合作伙伴关闭之外的所有状态。在PARTNER-DOWN状态下，运营合作伙伴可以从任意一个池中委派前缀（包括其自己的前缀，以及经过一段时间限制后其合作伙伴的前缀）。运营合作伙伴应在使用其合作伙伴的池之前从其自己的池中进行分配。这些可删除前缀池的分配和维护非常重要，因为目标是在两台服务器之间保持一个或多或少恒定的可删除前缀比率。
Each server knows which delegable prefixes are in its own pool as well as which are in its partner's pool, so that it can allocate delegable prefixes from its partner's pool without communication with its partner if that becomes necessary.
每个服务器都知道哪些可删除前缀在其自己的池中，哪些在其合作伙伴的池中，因此，如果有必要，它可以从其合作伙伴的池中分配可删除前缀，而无需与其合作伙伴通信。
The initial allocation of delegable prefixes from the primary to the secondary when the servers first integrate is triggered by the POOLREQ message from the secondary to the primary. This is followed (at some point) by the POOLRESP message, where the primary tells the secondary that it received and processed the POOLREQ message. The primary sends the allocated delegable prefixes to the secondary as prefix leases via BNDUPD messages. The POOLRESP message may be sent before, during, or at the completion of the BNDUPD message exchanges that were triggered by the POOLREQ message. The POOLREQ/POOLRESP message exchange is a trigger to the primary to perform a scan of its database and to ensure that the secondary has enough delegable prefixes (based on some configured ratio).
当服务器首次集成时，可删除前缀从主服务器到辅助服务器的初始分配由从辅助服务器到主服务器的POOLREQ消息触发。随后（在某一点上）会出现POOLRESP消息，其中主节点会告诉次节点它接收并处理了POOLREQ消息。主节点通过BNDUPD消息将分配的可删除前缀作为前缀租约发送给次节点。POOLRESP消息可以在由POOLREQ消息触发的BNDUPD消息交换之前、期间或完成时发送。POOLREQ/POOLRESP消息交换是主服务器的触发器，用于对其数据库执行扫描，并确保辅助服务器具有足够的可删除前缀（基于某些配置的比率）。
The delegable prefixes are sent to the secondary as prefix leases using the BNDUPD message containing an OPTION_IAPREFIX with a state of FREE-BACKUP, which indicates that the prefix lease is now available for allocation by the secondary. Once the message is sent, the primary MUST NOT use these prefixes for allocation to DHCP clients (except when the server is in PARTNER-DOWN state).
使用BNDUPD消息将可删除前缀作为前缀租约发送到辅助服务器，该消息包含一个选项前缀，该选项前缀的状态为FREE-BACKUP，这表示该前缀租约现在可供辅助服务器分配。消息发送后，主服务器不得使用这些前缀分配给DHCP客户端（服务器处于伙伴关闭状态时除外）。
The POOLREQ/POOLRESP message exchange initiated by the secondary is valid at any time both partners remain in contact, and the primary server SHOULD, whenever it receives the POOLREQ message, scan its database of delegable prefixes and determine if the secondary needs more delegable prefixes from any of the delegable prefixes that it currently owns.
辅助服务器启动的POOLREQ/POOLRESP消息交换在双方保持联系的任何时候都是有效的，并且主服务器应在收到POOLREQ消息时，扫描其可删除前缀数据库，并确定辅助服务器是否需要来自其当前拥有的任何可删除前缀的更多可删除前缀。
In order to support a reasonably dynamic balance of the leases between the failover partners, the primary server needs to do additional work to ensure that the secondary server has as many delegable prefixes as it needs (but that it doesn't have more than it needs).
为了支持故障转移伙伴之间租赁的合理动态平衡，主服务器需要做额外的工作，以确保辅助服务器具有其所需的尽可能多的可删除前缀（但不会超过其需要）。
The primary server SHOULD examine the balance of delegable prefixes between the primary and secondary for a particular prefix whenever the number of possibly delegable prefixes for either the primary or secondary changes by more than a predetermined amount. Typically, this comparison would not involve actually comparing the count of existing instances of delegable prefixes but would instead involve determining the number of prefixes that could be delegated given the address ranges of the delegable prefixes allocated to each server. The primary server SHOULD adjust the delegable prefix balance as required to ensure the configured delegable prefix balance, except that the primary server SHOULD employ some threshold mechanism to such a balance adjustment in order to minimize the overhead of maintaining this balance.
只要主前缀或次前缀的可能可删除前缀的数量变化超过预定量，主服务器就应该检查特定前缀的主前缀和次前缀之间的可删除前缀的平衡。通常，此比较不涉及实际比较可删除前缀的现有实例的计数，而是涉及在分配给每个服务器的可删除前缀的地址范围内确定可委派的前缀数量。主服务器应根据需要调整可删除前缀平衡，以确保配置的可删除前缀平衡，但主服务器应采用某种阈值机制进行此类平衡调整，以将维持此平衡的开销降至最低。
The primary server can, at any time, send an available delegable prefix to the secondary using a BNDUPD message with the state FREE-BACKUP. The primary server can attempt to take an available delegable prefix away from the secondary by sending a BNDUPD message with the state FREE. If the secondary accepts the BNDUPD message, then the lease is now available to the primary and not available to the secondary. Of course, the secondary MUST reject that BNDUPD message if it has already allocated that lease to a DHCP client.
主服务器可以随时使用BNDUPD消息向辅助服务器发送一个可用的可删除前缀，该消息带有状态自由备份。主服务器可以通过发送状态为FREE的BNDUPD消息，尝试从辅助服务器获取可用的可删除前缀。如果辅助服务器接受BNDUPD消息，则租约现在对主服务器可用，而对辅助服务器不可用。当然，如果已将该租约分配给DHCP客户端，则辅助服务器必须拒绝该BNDUPD消息。
When the server is in PARTNER-DOWN state, there is a waiting period after which a delegated prefix can be reallocated to another client. For delegable prefixes that are "available" when the server enters PARTNER-DOWN state, the period is the MCLT from the entry into PARTNER-DOWN state. For delegated prefixes that are not available when the server enters PARTNER-DOWN state, the period is the MCLT after the later of the following times: the acked-partner-lifetime, the partner-lifetime (if any), the expiration-time, or the entry into PARTNER-DOWN time.
当服务器处于伙伴关闭状态时，会有一段等待期，在此等待期之后，可以将委派的前缀重新分配给另一个客户端。对于服务器进入合作伙伴关闭状态时“可用”的可删除前缀，周期是从进入合作伙伴关闭状态开始的MCLT。对于服务器进入合作伙伴关闭状态时不可用的委派前缀，周期是以下时间中较晚者之后的MCLT：已确认的合作伙伴生存期、合作伙伴生存期（如果有）、过期时间或进入合作伙伴关闭时间。
In any other state, a server cannot reallocate a delegated prefix from one client to another without first notifying its partner (through a BNDUPD message) and receiving acknowledgement (through a BNDREPLY message) that its partner is aware that the first client is not using the lease.
在任何其他状态下，服务器都无法在未首先通知其合作伙伴（通过BNDREPLY消息）并接收确认（通过BNDREPLY消息）的情况下将委托前缀从一个客户端重新分配到另一个客户端，即其合作伙伴知道第一个客户端未使用租约。
Specifically, an "available" delegable prefix on a server may be allocated to any client. A prefix that was delegated (leased) to a client and that expired or was released by that client would take on a new state -- EXPIRED or RELEASED, respectively. The partner server would then be notified that this delegated prefix was EXPIRED or RELEASED through a BNDUPD message. When the sending server received the BNDREPLY message for that delegated prefix showing that it was
具体地说，服务器上的“可用”可删除前缀可以分配给任何客户端。委托（租用）给客户机且该客户机已过期或已释放的前缀将呈现新状态——分别为已过期或已释放。然后，将通过BNDUPD消息通知合作伙伴服务器此委派前缀已过期或已释放。当发送服务器收到该委派前缀的BNDREPLY消息时，表明该前缀已被删除
FREE, it would move the lease from EXPIRED or RELEASED to FREE, and the prefix would be available for allocation by the primary server to any clients.
FREE，它会将租约从过期或已释放移动到FREE，并且前缀可由主服务器分配给任何客户端。
A server MAY reallocate a delegated prefix in the EXPIRED or RELEASED state to the same client with no restrictions, provided it has not sent a BNDUPD message regarding the delegated prefix to its partner. This situation would exist if the prefix lease expired or was released after the transition into PARTNER-DOWN state, for instance.
如果服务器未向其合作伙伴发送有关委派前缀的BNDUPD消息，则可以将处于过期或释放状态的委派前缀重新分配给同一客户端，而不受任何限制。例如，如果前缀租约过期或在转换到合作伙伴关闭状态后释放，则会出现这种情况。
[RFC7031] includes the requirement that failover must not introduce significant performance impact on server response times (see Sections 7 and 5.2.2 of [RFC7031]). In order to realize this requirement, a server implementing the failover protocol must be able to respond to a DHCP client without waiting to update its failover partner whenever the binding database changes. The "lazy update" mechanism allows a server to allocate a new lease or extend an existing lease, respond to the DHCP client, and then update its failover partner as time permits.
[RFC7031]包括故障切换不得对服务器响应时间产生重大性能影响的要求（请参见[RFC7031]第7节和第5.2.2节）。为了实现这一要求，实现故障转移协议的服务器必须能够响应DHCP客户端，而无需在绑定数据库发生更改时等待更新其故障转移伙伴。“延迟更新”机制允许服务器分配新租约或扩展现有租约，响应DHCP客户端，然后在时间允许时更新其故障转移伙伴。
Although the "lazy update" mechanism does not introduce additional delays in server response times, it introduces other difficulties. The key problem with lazy update is that when a server fails after updating a DHCP client with a particular valid lifetime but before updating its failover partner, the failover partner will eventually believe that the client's lease has expired -- even though the DHCP client still retains a valid lease on that address or prefix. It is also possible that the failover partner will have no record at all of the lease being assigned to the DHCP client. Both of these issues are dealt with by using the MCLT when allocating or extending leases (see Section 4.4).
虽然“延迟更新”机制不会在服务器响应时间上引入额外的延迟，但它会带来其他困难。延迟更新的关键问题是，当服务器在使用特定的有效生存期更新DHCP客户端之后但在更新其故障转移伙伴之前发生故障时，故障转移伙伴最终会认为客户端的租约已过期，即使DHCP客户端仍保留该地址或前缀的有效租约。故障转移伙伴也可能在所有分配给DHCP客户端的租约中都没有记录。在分配或延长租赁时，使用MCLT处理这两个问题（见第4.4节）。
In order to handle problems introduced by lazy updates (see Section 4.3), a period of time known as the "Maximum Client Lead Time" (MCLT) is defined and must be known to both the primary server and the secondary server. Proper use of this time interval places an upper bound on the difference allowed between the valid lifetime provided to a DHCP client by a server and the valid lifetime known by that server's failover partner.
为了处理延迟更新带来的问题（参见第4.3节），定义了一段称为“最大客户提前期”（MCLT）的时间段，并且主服务器和辅助服务器都必须知道该时间段。正确使用此时间间隔会对服务器提供给DHCP客户端的有效生存期与该服务器的故障转移伙伴已知的有效生存期之间允许的差异设置上限。
The MCLT is typically much less than the valid lifetime that a server has been configured to offer a client, and so some strategy must exist to allow a server to offer the configured valid lifetime to a client. During a lazy update, the updating server updates its
MCLT通常比服务器配置为提供客户机的有效生存期小得多，因此必须存在某种策略，允许服务器向客户机提供配置的有效生存期。在延迟更新期间，更新服务器更新其
failover partner with a partner lifetime that is longer than the valid lifetime previously given to the DHCP client and that is longer than the valid lifetime that the server has been configured to give a client. This allows the server to give the configured valid lifetime to the client the next time the client renews its lease, since the time that it will give to the client will not be longer than the MCLT beyond the partner lifetime acknowledged by its partner or the current time.
故障转移伙伴，其伙伴生存期长于以前为DHCP客户端提供的有效生存期，并且长于服务器配置为为为客户端提供的有效生存期。这允许服务器在客户端下次续订其租约时向客户端提供配置的有效生存期，因为它向客户端提供的时间不会超过其合作伙伴确认的合作伙伴生存期或当前时间之外的MCLT。
The fundamental relationship on which the failover protocol depends is as follows: the lease expiration time known to a DHCP client MUST NOT be greater by more than the MCLT beyond the later of the partner lifetime acknowledged by that server's failover partner or the current time.
故障转移协议所依赖的基本关系如下：DHCP客户端已知的租约到期时间不得超过该服务器的故障转移伙伴确认的伙伴生存期或当前时间的较晚者的MCLT。
The remainder of this section makes the above fundamental relationship more explicit.
本节的其余部分使上述基本关系更加明确。
The failover protocol requires a DHCP server to deal with several different lease intervals and places specific restrictions on their relationships. The purpose of these restrictions is to allow the partner to be able to make certain assumptions in the absence of an ability to communicate between servers.
故障转移协议要求DHCP服务器处理几个不同的租用间隔，并对它们的关系设置特定的限制。这些限制的目的是让合作伙伴能够在服务器之间缺乏通信能力的情况下做出某些假设。
In the following explanation, all of the lifetimes are "valid" lifetimes, in the context of [RFC3315].
在下面的解释中，在[RFC3315]的上下文中，所有的生存期都是“有效”的生存期。
The different times are as follows:
不同的时间如下：
desired lifetime: The desired lifetime is the lease interval that a DHCP server would like to give to a DHCP client in the absence of any restrictions imposed by the failover protocol. Its determination is outside of the scope of the failover protocol. Typically, this is the result of external configuration of a DHCP server.
期望生存期：期望生存期是DHCP服务器在没有故障转移协议施加的任何限制的情况下希望给予DHCP客户端的租用间隔。其确定超出故障转移协议的范围。通常，这是DHCP服务器外部配置的结果。
actual lifetime: The actual lifetime is the lease interval that a DHCP server gives out to a DHCP client. It may be shorter than the desired lifetime (as explained below).
实际生存期：实际生存期是DHCP服务器向DHCP客户端发出的租用间隔。它可能比预期寿命短（如下所述）。
partner lifetime: The partner lifetime is the lease expiration interval the local server sends to its partner in a BNDUPD message.
合作伙伴生存期：合作伙伴生存期是本地服务器在BNDUPD消息中发送给其合作伙伴的租约到期时间间隔。
acknowledged partner lifetime: The acknowledged partner lifetime is the partner lifetime the partner server has most recently acknowledged in a BNDREPLY message.
确认的合作伙伴生存期：确认的合作伙伴生存期是合作伙伴服务器最近在BNDREPLY消息中确认的合作伙伴生存期。
The following example demonstrates the MCLT concept in practice. The values used are arbitrarily chosen and are not a recommendation for actual values. The MCLT in this case is 1 hour. The desired lifetime is 3 days, and its renewal time is half the lifetime.
以下示例在实践中演示了MCLT概念。使用的值是任意选择的，不是实际值的建议值。在这种情况下，MCLT为1小时。预期寿命为3天，其更新时间为寿命的一半。
When a server makes an offer for a new lease on an IPv6 address to a DHCP client, it determines the desired lifetime (in this case, 3 days). It then examines the acknowledged partner lifetime (which, in this case, is zero) and determines the remainder of the time left to run, which is also zero. It adds the MCLT to this value. Since the actual lifetime cannot be allowed to exceed the remainder of the current acknowledged partner lifetime plus the MCLT, the offer made to the client is for the remainder of the current acknowledged partner lifetime (i.e., zero) plus the MCLT. Thus, the actual lifetime is 1 hour (the MCLT).
当服务器向DHCP客户端提供IPv6地址的新租约时，它将确定所需的生存期（在本例中为3天）。然后，它检查确认的伙伴生存期（在本例中为零），并确定剩余的运行时间（也为零）。它将MCLT添加到此值。由于实际寿命不能超过当前确认的合作伙伴寿命加上MCLT的剩余时间，因此向客户提供的报价是针对当前确认的合作伙伴寿命（即零）加上MCLT的剩余时间。因此，实际寿命为1小时（MCLT）。
Once the server has sent the REPLY to the DHCP client, it will update its failover partner with the lease information using a BNDUPD message. The partner lifetime will be composed of the T1 fraction (1/2) of the actual lifetime added to the desired lifetime. Thus, the failover partner is updated using a BNDUPD message with a partner lifetime of 1/2 hour + 3 days.
服务器向DHCP客户端发送回复后，将使用BNDUPD消息使用租约信息更新其故障转移伙伴。合作伙伴寿命将由实际寿命的T1部分（1/2）加上期望寿命组成。因此，故障转移伙伴将使用BNDUPD消息进行更新，伙伴生存期为1/2小时+3天。
When the primary server receives a BNDREPLY to its update of the secondary server's (partner's) partner lifetime, it records that as the acknowledged partner lifetime. A server MUST NOT send a BNDREPLY message in response to a BNDUPD message until it is sure that the information in the BNDUPD message has been updated in its lease database. See Section 7.5.2. Thus, the primary server in this case can be sure that the secondary server has recorded the partner lifetime in its stable storage when the primary server receives a BNDREPLY message from the secondary server.
当主服务器接收到对其辅助服务器（合作伙伴）合作伙伴生存期的更新的BNDREPLY时，它会将其记录为已确认的合作伙伴生存期。在确定BNDUPD消息中的信息已在其租约数据库中更新之前，服务器不得发送BNDREPLY消息以响应BNDUPD消息。见第7.5.2节。因此，在这种情况下，当主服务器从辅助服务器接收到BNDREPLY消息时，主服务器可以确保辅助服务器已在其稳定存储器中记录了伙伴生存期。
When the DHCP client attempts to renew at T1 (approximately 1/2 hour from the start of the lease), the primary server again determines the desired lifetime, which is still 3 days. It then compares this with the original acknowledged partner lifetime (1/2 hour + 3 days) and adjusts for the time passed since the secondary was last updated (1/2 hour). Thus, the remaining time for the acknowledged partner
当DHCP客户端尝试在T1（大约从租约开始的1/2小时）续订时，主服务器再次确定所需的生存期，即仍然是3天。然后将其与原始确认的合作伙伴生存期（1/2小时+3天）进行比较，并根据自上次更新次合作伙伴以来经过的时间（1/2小时）进行调整。因此，已确认的合作伙伴的剩余时间
interval is 3 days. Adding the MCLT to this yields 3 days plus 1 hour, which is more than the desired lifetime of 3 days. So, the client may have its lease renewed for the desired lifetime -- 3 days.
间隔3天。将MCLT添加到其中会产生3天加1小时，这比预期的3天寿命要长。因此，客户可以在预期的使用期限内（3天）续租。
When the primary DHCP server updates the secondary DHCP server after the DHCP client's renewal REPLY is complete, it will calculate the partner lifetime as the T1 fraction of the actual client lifetime (1/2 of 3 days = 1.5 days). To this it will add the desired lifetime of 3 days, yielding a total partner lifetime of 4.5 days. In this way, the primary attempts to have the secondary always "lead" the client in its understanding of the client's lifetime so as to be able to always offer the client the desired lifetime.
当主DHCP服务器在DHCP客户端的续订回复完成后更新辅助DHCP服务器时，它将计算伙伴生存期，作为实际客户端生存期的T1部分（3天中的1/2=1.5天）。除此之外，它还将增加3天的预期寿命，从而使合作伙伴的总寿命达到4.5天。通过这种方式，主服务器试图让次服务器始终“引导”客户机了解客户机的生命周期，以便能够始终为客户机提供所需的生命周期。
Once the initial actual client lifetime of the MCLT has passed, the failover protocol operates effectively like DHCP does today in its behavior concerning lifetimes. However, the guarantee that the actual client lifetime will never exceed the partner server's remaining acknowledged partner lifetime by more than the MCLT allows full recovery from a variety of DHCP server failures.
一旦MCLT的初始实际客户端生存期结束，故障转移协议就会像DHCP今天在其生存期行为方面一样有效地运行。但是，保证实际客户端生存期不会超过伙伴服务器的剩余已确认伙伴生存期超过MCLT，从而允许从各种DHCP服务器故障中完全恢复。
Fundamental relationship:
lease time = floor( desired lifetime, acked-partner-lifetime + MCLT )
Fundamental relationship:
lease time = floor( desired lifetime, acked-partner-lifetime + MCLT )
Initial conditions: MCLT = 1h, desired lifetime = 3d
Initial conditions: MCLT = 1h, desired lifetime = 3d
DHCPv6 Primary Secondary time Client Server Server
DHCPv6主辅时间客户端服务器
| >-SOLICIT------> | |
| acknowledged partner lifetime = 0 |
| lease time = floor( 3d, 0 + 1h ) = 1h |
| <-----ADVERTISE-< | |
| lease-time = 1h | |
| >-REQUEST------> | |
t | <---------REPLY-< | |
| lease-time = 1h | |
| | >-BNDUPD------> |
| | partner-lifetime = 1/2h + 3d
| | <----BNDREPLY-< |
| | partner-lifetime = 1/2h + 3d
|acknowledged partner lifetime = 1/2h + 3d |
1/2h passes ... ... ...
t+1/2h | >-RENEW--------> | |
| acknowledged partner lifetime = 3d |
| lease time = floor( 3d, 3d + 1h ) = 3d |
| <---------REPLY-< | |
| lease-time = 3d | |
| | >-BNDUPD-------> |
| | partner-lifetime = 1.5d + 3d
| | <----BNDREPLY-< |
| | partner-lifetime = 1.5d + 3d
|acknowledged partner lifetime = 1.5d + 3d |
1.5d passes ... ... ...
| | |
t+1.5d + 1/2h | >-RENEW--------> | |
| acknowledged partner lifetime = 3d |
| lease time = floor( 3d, 3d + 1h ) = 3d |
| <---------REPLY-< | |
| lease-time = 3d | |
| | >-BNDUPD-------> |
| | partner-lifetime = 1.5d + 3d
| | <----BNDREPLY-< |
| | partner-lifetime = 1.5d + 3d
|acknowledged partner lifetime = 1.5d + 3d |
| >-SOLICIT------> | |
| acknowledged partner lifetime = 0 |
| lease time = floor( 3d, 0 + 1h ) = 1h |
| <-----ADVERTISE-< | |
| lease-time = 1h | |
| >-REQUEST------> | |
t | <---------REPLY-< | |
| lease-time = 1h | |
| | >-BNDUPD------> |
| | partner-lifetime = 1/2h + 3d
| | <----BNDREPLY-< |
| | partner-lifetime = 1/2h + 3d
|acknowledged partner lifetime = 1/2h + 3d |
1/2h passes ... ... ...
t+1/2h | >-RENEW--------> | |
| acknowledged partner lifetime = 3d |
| lease time = floor( 3d, 3d + 1h ) = 3d |
| <---------REPLY-< | |
| lease-time = 3d | |
| | >-BNDUPD-------> |
| | partner-lifetime = 1.5d + 3d
| | <----BNDREPLY-< |
| | partner-lifetime = 1.5d + 3d
|acknowledged partner lifetime = 1.5d + 3d |
1.5d passes ... ... ...
| | |
t+1.5d + 1/2h | >-RENEW--------> | |
| acknowledged partner lifetime = 3d |
| lease time = floor( 3d, 3d + 1h ) = 3d |
| <---------REPLY-< | |
| lease-time = 3d | |
| | >-BNDUPD-------> |
| | partner-lifetime = 1.5d + 3d
| | <----BNDREPLY-< |
| | partner-lifetime = 1.5d + 3d
|acknowledged partner lifetime = 1.5d + 3d |
Figure 1: MCLT Example
图1:MCLT示例
Failover communication is conducted over a TCP connection established between the partners. The failover protocol uses the framing format specified in Section 5.1 of "DHCPv6 Bulk Leasequery" [RFC5460] but uses different message types with a different message format, as described in Section 5.2 of this document. The TCP connection between failover servers is made to a specific port -- the dhcp-failover port, port 647. All information is sent over the connection as typical DHCP messages that convey DHCP options, following the format defined in Section 22.1 of [RFC3315].
故障切换通信通过合作伙伴之间建立的TCP连接进行。故障转移协议使用“DHCPv6批量租赁”[RFC5460]第5.1节中指定的帧格式，但使用不同消息类型和不同的消息格式，如本文档第5.2节所述。故障转移服务器之间的TCP连接连接到一个特定端口——dhcp故障转移端口，端口647。所有信息都作为典型的DHCP消息通过连接发送，这些消息按照[RFC3315]第22.1节中定义的格式传递DHCP选项。
All failover messages defined below share a common format with a fixed-size header and a variable format area for options. All values in the message header and in any included options are in network byte order.
下面定义的所有故障转移消息共享一种通用格式，其中包含一个固定大小的头和一个用于选项的可变格式区域。消息头和任何包含选项中的所有值均按网络字节顺序排列。
The following diagram illustrates the format (which is compatible with the format described in Section 6 of [RFC3315]) of DHCP messages exchanged between failover partners:
下图说明了故障转移伙伴之间交换的DHCP消息的格式（与[RFC3315]第6节中描述的格式兼容）：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sent-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sent-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. options .
. (variable) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type Identifies the DHCP message type; the available message types are listed below.
msg type标识DHCP消息类型；下面列出了可用的消息类型。
transaction-id The transaction-id for this message exchange.
事务id此消息交换的事务id。
sent-time The time the message was transmitted (set as close to transmission as practical), in seconds since midnight (UTC), January 1, 2000, modulo 2^32. Used to determine the time skew of the failover partners.
发送时间消息传输的时间（设置为尽可能接近传输），自2000年1月1日午夜（UTC）起以秒为单位，模数为2^32。用于确定故障转移伙伴的时间偏差。
options Options carried in this message. These options are all defined in the "Option Codes" sub-registry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry. A number of existing DHCPv6 options are used, and several more are defined in this document.
此消息中包含的选项。这些选项都在“IPv6动态主机配置协议（DHCPv6）”注册表的“选项代码”子注册表中定义。使用了许多现有的DHCPv6选项，本文档中还定义了更多选项。
The following sections list the new message types defined for failover communication.
以下各节列出了为故障切换通信定义的新消息类型。
The binding update message, BNDUPD (24), is used to send the binding lease changes to the partner. At most one OPTION_CLIENT_DATA option may appear in a BNDUPD message. Note that not all data in a BNDUPD message is sent in an OPTION_CLIENT_DATA option. Information about delegable prefixes not currently allocated to a particular client is sent in BNDUPD messages but not within OPTION_CLIENT_DATA options. The partner is expected to respond with a BNDREPLY message.
绑定更新消息BNDUPD（24）用于将绑定租约更改发送给合作伙伴。BNDUPD消息中最多可以出现一个选项\u客户端\u数据选项。请注意，并非BNDUPD消息中的所有数据都在选项\客户端\数据选项中发送。有关当前未分配给特定客户端的可删除前缀的信息在BNDUPD消息中发送，但不在OPTION_client_DATA options中发送。合作伙伴应以BNDREPLY消息进行响应。
The binding acknowledgement message, BNDREPLY (25), is used for confirmation of the received BNDUPD message. It may contain a positive or negative response (e.g., due to a detected lease conflict).
绑定确认消息BNDREPLY（25）用于确认接收到的BNDUPD消息。它可能包含肯定或否定响应（例如，由于检测到的租约冲突）。
The pool request message, POOLREQ (26), is used by the secondary server to request allocation of delegable prefixes from the primary server. The primary responds with a POOLRESP message.
池请求消息POOLREQ（26）由辅助服务器用于请求从主服务器分配可删除前缀。主服务器用POOLRESP消息进行响应。
The pool response message, POOLRESP (27), is used by the primary server to indicate that it has received the secondary server's request to ensure that delegable prefixes are balanced between the primary and secondary servers. It does not indicate that all of the BNDUPD messages that might be created from any rebalancing have been sent or responded to; it only indicates reception and acceptance of the task of ensuring that the balance is examined and corrected as necessary.
主服务器使用池响应消息POOLRESP（27）来指示它已收到辅助服务器的请求，以确保可删除前缀在主服务器和辅助服务器之间保持平衡。它并不表示可能通过任何再平衡创建的所有BNDUPD消息都已发送或响应；它仅表示接收并接受了确保余额在必要时得到检查和纠正的任务。
The update request message, UPDREQ (28), is used by one server to request that its partner send all binding database changes that have not yet been confirmed. The partner is expected to respond with zero or more BNDUPD messages, followed by an UPDDONE message that signals that all of the BNDUPD messages have been sent and a corresponding BNDREPLY message has been received for each of them.
一台服务器使用更新请求消息UPDREQ（28）请求其合作伙伴发送所有尚未确认的绑定数据库更改。合作伙伴预计将以零条或多条BNDUPD消息进行响应，然后是一条UPDDONE消息，该消息表示所有BNDUPD消息都已发送，并且每个消息都已收到相应的BNDREPLY消息。
The update request all message, UPDREQALL (29), is used by one server to request that all binding database information present in the other server be sent to the requesting server, in order for the requesting server to recover from a total loss of its binding database. A server receiving this request responds with zero or more BNDUPD messages, followed by an UPDDONE message that signals that all of the BNDUPD messages have been sent and a corresponding BNDREPLY message has been received for each of them.
一台服务器使用UPDREQALL消息UPDREQALL（29）请求将另一台服务器中存在的所有绑定数据库信息发送到请求服务器，以便请求服务器从其绑定数据库的完全丢失中恢复。接收此请求的服务器响应为零条或多条BNDUPD消息，然后是一条UPDDONE消息，该消息表示所有BNDUPD消息都已发送，并且每个消息都已收到相应的BNDREPLY消息。
The update done message, UPDDONE (30), is used by the server responding to an UPDREQ or UPDREQALL message to indicate that all requested updates have been sent by the responding server and acked by the requesting server.
更新完成消息UPDDONE（30）由响应UPDREQ或UPDREQALL消息的服务器使用，以指示所有请求的更新已由响应服务器发送并由请求服务器确认。
The connect message, CONNECT (31), is used by the primary server to establish a failover connection with the secondary server and to transmit several important configuration attributes between the servers. The partner is expected to confirm by responding with a CONNECTREPLY message.
主服务器使用connect（31）消息与辅助服务器建立故障切换连接，并在服务器之间传输几个重要的配置属性。合作伙伴应通过响应CONNECTREPLY消息进行确认。
The connect acknowledgement message, CONNECTREPLY (32), is used by the secondary server to respond to a CONNECT message from the primary server.
连接确认消息CONNECTREPLY（32）由辅助服务器用于响应来自主服务器的连接消息。
The disconnect message, DISCONNECT (33), is used by either server when closing a connection and shutting down. No response is required for this message. The DISCONNECT message SHOULD contain an OPTION_STATUS_CODE option with an appropriate status. Often, this will be ServerShuttingDown. See Section 5.6. A server SHOULD include a descriptive message as to what caused the disconnect message.
断开连接消息disconnect（33）由任一服务器在关闭连接和关闭时使用。此消息不需要响应。断开连接消息应包含具有适当状态的选项\状态\代码选项。通常，这会导致服务器关闭。见第5.6节。服务器应包含一条说明性消息，说明是什么导致了断开连接消息。
The state message, STATE (34), is used by either server to inform its partner about a change of failover state. In some cases, it may be used to also inform the partner about the current state, e.g., after connection is established in the COMMUNICATIONS-INTERRUPTED or PARTNER-DOWN states.
状态消息state（34）由任一服务器用于通知其伙伴故障转移状态的更改。在某些情况下，它还可用于通知伙伴当前状态，例如，在通信中断或伙伴停机状态下建立连接后。
The contact message, CONTACT (35), is used by either server to ensure that its partner continues to see the connection as operational. It MUST be transmitted periodically over every established connection if other message traffic is not flowing, and it MAY be sent at any time. See Section 6.5.
任何一台服务器都使用联系人消息contact（35），以确保其合作伙伴继续将连接视为可操作的。如果其他消息流量不流动，则必须在每个已建立的连接上周期性地发送，并且可以随时发送。见第6.5节。
The initiator of a message exchange MUST set the transaction-id (see Section 5.2). This means that all of the messages above except BNDREPLY, POOLRESP, UPDDONE, and CONNECTREPLY must set the transaction-id. The transaction-id MUST be unique among all currently outstanding messages sent to the failover partner. A straightforward way to ensure this is to simply use an incrementing value, with one caveat: The UPDREQ and UPDREQALL messages may be separated by a considerable time prior to the receipt of an UPDDONE message. While the usual pattern of message exchange would have the partner doing the vast majority of message initiation, it is remotely possible that the partner that initiated the UPDREQ or UPDREQALL messages might also send enough messages to wrap the 24-bit transaction-id and duplicate the transaction-id of the outstanding UPDREQ or UPDREQALL messages. Thus, it is important to ensure that
消息交换的发起人必须设置事务id（参见第5.2节）。这意味着，除BNDREPLY、POOLRESP、UPDDONE和CONNECTREPLY外，上述所有消息都必须设置事务id。事务id在发送给故障转移伙伴的所有当前未完成消息中必须是唯一的。确保这一点的一个简单方法是简单地使用递增值，但有一个警告：UPDREQ和UPDREQALL消息可能在收到UPDDONE消息之前被分隔相当长的时间。虽然通常的消息交换模式是由合作伙伴发起绝大多数消息，发起UPDREQ或UPDREQALL消息的伙伴也可能远程发送足够的消息来包装24位事务id，并复制未完成UPDREQ或UPDREQALL消息的事务id。因此，重要的是确保
the transaction-id of a currently outstanding UPDREQ or UPDREQALL message is not replicated in any message initiated prior to the receipt of the corresponding UPDDONE message.
当前未完成的UPDREQ或UPDREQALL消息的事务id不会在收到相应UPDDONE消息之前启动的任何消息中复制。
The following new options are defined.
定义了以下新选项。
The binding-status is an implementation-independent representation of the status (or the state) of a lease on an IPv6 address or prefix.
绑定状态是IPv6地址或前缀上租约状态（或状态）的独立于实现的表示。
This is an unsigned byte.
这是一个无符号字节。
The code for this option is 114.
此选项的代码为114。
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_F_BINDING_STATUS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| binding-status|
+-+-+-+-+-+-+-+-+
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_F_BINDING_STATUS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| binding-status|
+-+-+-+-+-+-+-+-+
option-code OPTION_F_BINDING_STATUS (114) option-len 1 binding-status The binding-status. See below:
选项代码选项绑定状态（114）选项len 1绑定状态绑定状态。见下文：
Value binding-status
----- --------------
0 reserved
1 ACTIVE
2 EXPIRED
3 RELEASED
4 PENDING-FREE
5 FREE
6 FREE-BACKUP
7 ABANDONED
8 RESET
Value binding-status
----- --------------
0 reserved
1 ACTIVE
2 EXPIRED
3 RELEASED
4 PENDING-FREE
5 FREE
6 FREE-BACKUP
7 ABANDONED
8 RESET
The binding-status values are discussed in Section 7.2.
第7.2节讨论了绑定状态值。
This option provides flags that indicate attributes of the connecting server.
此选项提供指示连接服务器属性的标志。
This option consists of an unsigned 16-bit integer in network byte order.
此选项由网络字节顺序的无符号16位整数组成。
The code for this option is 115.
此选项的代码为115。
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_F_CONNECT_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_F_CONNECT_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_CONNECT_FLAGS (115) option-len 2 flags flag bits. See below:
选项代码选项连接标志（115）选项长度2标志标志位。见下文：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the most significant bit in network byte order) are used as follows:
位（按网络字节顺序从最高有效位开始编号）使用如下：
0-14: MBZ Must be zero. 15 (F): FIXED_PD_LENGTH Set to 1 to indicate that all prefixes delegated from a given delegable prefix have the same prefix length (size). If this is not set, the prefixes delegated from one delegable prefix may have different sizes.
0-14:MBZ必须为零。15（F）：FIXED_PD_LENGTH设置为1，表示从给定可委派前缀委派的所有前缀具有相同的前缀长度（大小）。如果未设置，则从一个可委派前缀委派的前缀可能具有不同的大小。
If the FIXED_PD_LENGTH bit is not set, it indicates that prefixes of a range of sizes can be delegated from a given delegable prefix. Note that if the FIXED_PD_LENGTH bit is set, each delegable prefix may have its own fixed size -- this flag does not imply that all prefixes delegated will be the same size, but rather that all prefixes delegated from the same delegable prefix will be the same size.
如果未设置FIXED_PD_LENGTH位，则表示可以从给定的可委派前缀委派一系列大小的前缀。请注意，如果设置了FIXED_PD_LENGTH位，则每个可委派前缀可能有其自己的固定大小——此标志并不意味着所有委派的前缀都将具有相同的大小，而是意味着从相同的可委派前缀委派的所有前缀都将具有相同的大小。
If the FIXED_PD_LENGTH bit is set, the length used for each prefix is specified independently of the failover protocol but must be known to both failover partners. It might be specified in the configuration for each delegable prefix, or it might be fixed for the entire server.
如果设置了FIXED_PD_LENGTH位，则每个前缀使用的长度独立于故障切换协议指定，但必须为两个故障切换伙伴所知。它可能在配置中为每个可委派前缀指定，也可能为整个服务器固定。
This option contains the information necessary to remove a DNS name that was entered by the failover partner.
此选项包含删除故障转移伙伴输入的DNS名称所需的信息。
The code for this option is 116.
此选项的代码为116。
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_F_DNS_REMOVAL_INFO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encapsulated-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_DNS_REMOVAL_INFO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encapsulated-options |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_REMOVAL_INFO (116) option-len variable options Three possible encapsulated options: OPTION_F_DNS_HOST_NAME OPTION_F_DNS_ZONE_NAME OPTION_F_DNS_FLAGS
选项代码选项\u F\u DNS\u删除\u信息（116）选项len变量选项三种可能的封装选项：选项\u F\u DNS\u主机\u名称选项\u F\u DNS\u区域\u名称选项\u F\u DNS\u标志
This option contains the hostname that was entered into the DNS by the failover partner.
此选项包含故障转移伙伴输入DNS的主机名。
This is a DNS name encoded using the format specified in [RFC1035], as also specified in Section 8 of [RFC3315].
这是使用[RFC1035]中指定的格式编码的DNS名称，也在[RFC3315]第8节中指定。
The code for this option is 117.
此选项的代码为117。
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_F_DNS_HOST_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. host-name .
. (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_DNS_HOST_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. host-name .
. (variable) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_HOST_NAME (117) option-len length of host-name host-name hostname encoded per RFC 1035
选项代码选项F\U DNS\U主机名（117）选项长度主机名主机名主机名按照RFC 1035编码
This option contains the zone name that was entered into the DNS by the failover partner.
此选项包含故障转移伙伴在DNS中输入的区域名称。
This is a DNS name encoded using the format specified in [RFC1035], as also specified in Section 8 of [RFC3315].
这是使用[RFC1035]中指定的格式编码的DNS名称，也在[RFC3315]第8节中指定。
The code for this option is 118.
此选项的代码为118。
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_F_DNS_ZONE_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. zone-name .
. (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_DNS_ZONE_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. zone-name .
. (variable) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_ZONE_NAME (118) option-len length of zone-name zone-name zone name encoded per RFC 1035
选项代码选项\u F\u DNS\u区域\u名称（118）选项长度区域名称区域名称根据RFC 1035编码的区域名称
This option provides flags that indicate what needs to be done to remove this DNS name.
此选项提供指示删除此DNS名称所需操作的标志。
This option consists of an unsigned 16-bit integer in network byte order.
此选项由网络字节顺序的无符号16位整数组成。
The code for this option is 119.
此选项的代码为119。
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_F_DNS_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_F_DNS_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_FLAGS (119) option-len 2 flags flag bits. See below:
选项代码option_F_DNS_标志（119）option len 2标志位。见下文：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |U|S|R|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |U|S|R|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the most significant bit in network byte order) are used as follows:
位（按网络字节顺序从最高有效位开始编号）使用如下：
0-11: MBZ Must be zero. 12 (U): USING_REQUESTED_FQDN Set to 1 to indicate that the name used came from the Fully Qualified Domain Name (FQDN) that was received from the client. 13 (S): SYNTHESIZED_NAME Set to 1 to indicate that the name was synthesized based on some algorithm. 14 (R): REV_UPTODATE Set to 1 to indicate that the reverse zone is up to date. 15 (F): FWD_UPTODATE Set to 1 to indicate that the forward zone is up to date.
0-11:MBZ必须为零。12（U）：使用_REQUESTED_FQDN设置为1，以指示所使用的名称来自从客户端接收的完全限定域名（FQDN）。13（S）：合成的_名称设置为1，表示该名称是根据某种算法合成的。14（R）：REV_Update设置为1，表示反向区域是最新的。15（F）：FWD_Update设置为1，表示前进区是最新的。
If both the U bit and the S bit are unset, then the name must have been provided from some alternative configuration, such as client registration in some database accessible to the DHCP server.
如果U位和S位都未设置，则必须从其他配置中提供名称，例如在DHCP服务器可访问的数据库中注册客户端。
This option specifies the greatest lifetime that this server has ever acked to its partner in a BNDREPLY message for a particular lease or prefix. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
此选项指定此服务器在BNDREPLY消息中为特定租约或前缀向其合作伙伴确认的最长生存期。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 120.
此选项的代码为120。
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_F_EXPIRATION_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| expiration-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_F_EXPIRATION_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| expiration-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_EXPIRATION_TIME (120) option-len 4 expiration-time The expiration time. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
选项代码选项过期时间（120）选项len 4过期时间过期时间。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This option specifies the maximum number of BNDUPD messages that this server is prepared to accept over the TCP connection without causing the TCP connection to block.
此选项指定此服务器准备通过TCP连接接受的最大BNDUPD消息数，而不会导致TCP连接阻塞。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 121.
此选项的代码为121。
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_F_MAX_UNACKED_BNDUPD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max-unacked-bndupd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_F_MAX_UNACKED_BNDUPD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max-unacked-bndupd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_MAX_UNACKED_BNDUPD (121) option-len 4 max-unacked-bndupd Maximum number of unacked BNDUPD messages allowed
选项代码option_F_MAX_UNACKED_BNDUPD（121）option len 4 MAX UNACKED BNDUPD允许的最大未确认BNDUPD消息数
The Maximum Client Lead Time (MCLT) is the upper bound on the difference allowed between the valid lifetime provided to a DHCP client by a server and the valid lifetime known by that server's failover partner. It is an interval, measured in seconds. See Section 4.4.
最大客户机交付周期（MCLT）是服务器提供给DHCP客户机的有效生存期与该服务器的故障转移伙伴已知的有效生存期之间允许的差值的上限。这是一个间隔，以秒为单位。见第4.4节。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 122.
此选项的代码为122。
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_F_MCLT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mclt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_F_MCLT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mclt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_MCLT (122) option-len 4 mclt The MCLT, in seconds
选项代码选项F\U MCLT（122）选项len 4 MCLT MCLT MCLT，以秒为单位
This option specifies the time after which the partner can consider an IPv6 address expired and is able to reuse the IPv6 address. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
此选项指定伙伴可以考虑IPv6地址过期并能够重用IPv6地址的时间。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 123.
此选项的代码为123。
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_F_PARTNER_LIFETIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_F_PARTNER_LIFETIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_LIFETIME (123) option-len 4 partner-lifetime The partner lifetime. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
选项代码选项合作伙伴生命周期（123）选项len 4合作伙伴生命周期合作伙伴生命周期。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This option indicates the time that was received in an OPTION_F_PARTNER_LIFETIME option (Section 5.5.7). This is an exact duplicate (echo) of the time received in the OPTION_F_PARTNER_LIFETIME option; it is not adjusted in any way. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
此选项表示在选项\u F\u合作伙伴\u终身选项中收到的时间（第5.5.7节）。这是选项\u F\u PARTNER\u life选项中接收到的时间的精确副本（回显）；它不会以任何方式进行调整。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 124.
此选项的代码为124。
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_F_PARTNER_LIFETIME_SENT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-lifetime-sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_F_PARTNER_LIFETIME_SENT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-lifetime-sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_LIFETIME_SENT (124) option-len 4 partner-lifetime-sent The partner-lifetime received in an OPTION_F_PARTNER_LIFETIME option. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
选项代码选项\u F\u PARTNER\u LIFETIME\u SENT（124）选项len 4 PARTNER LIFETIME SENT在选项\u F\u PARTNER\u LIFETIME选项中接收的PARTNER LIFETIME。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This option specifies the time that the server most recently lost communications with its failover partner. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
此选项指定服务器最近与其故障转移伙伴失去通信的时间。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 125.
此选项的代码为125。
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_F_PARTNER_DOWN_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-down-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_F_PARTNER_DOWN_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-down-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_DOWN_TIME (125) option-len 4 partner-down-time Contains the PARTNER-DOWN time. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
选项代码选项F伙伴停止时间（125）选项len 4伙伴停止时间包含伙伴停止时间。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This option specifies the time when the partner most recently interacted with the DHCP client associated with this IPv6 address or prefix. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
此选项指定合作伙伴最近与与此IPv6地址或前缀关联的DHCP客户端交互的时间。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 126.
此选项的代码为126。
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_F_PARTNER_RAW_CLT_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-raw-clt-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_F_PARTNER_RAW_CLT_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-raw-clt-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_RAW_CLT_TIME (126) option-len 4 partner-raw-clt-time Contains the partner-raw-clt-time. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
选项代码option_F_PARTNER_RAW_CLT_TIME（126）option len 4 PARTNER RAW CLT TIME包含PARTNER RAW CLT TIME。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
The protocol version allows one failover partner to determine the version of the protocol being used by the other partner, to allow for changes and upgrades in the future. Two components are provided, to allow large and small changes to be represented in one 32-bit number. The intent is that large changes would result in an increment of the value of major-version, while small changes would result in an increment of the value of minor-version. As subsequent updates and extensions of this document can define changes to these values in any way deemed appropriate, no attempt is made to further define "large" and "small" in this document.
协议版本允许一个故障切换伙伴确定另一个伙伴正在使用的协议版本，以便将来进行更改和升级。提供了两个组件，以允许在一个32位数字中表示大小更改。其目的是，较大的更改将导致主要版本的值增加，而较小的更改将导致次要版本的值增加。由于本文件的后续更新和扩展可以以任何被认为合适的方式定义对这些值的更改，因此本文件中没有进一步定义“大”和“小”。
This option consists of two unsigned 16-bit integers in network byte order.
此选项由两个网络字节顺序的无符号16位整数组成。
The code for this option is 127.
此选项的代码为127。
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_F_PROTOCOL_VERSION | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| major-version | minor-version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_F_PROTOCOL_VERSION | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| major-version | minor-version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PROTOCOL_VERSION (127) option-len 4 major-version The major version of the protocol. Initially 1. minor-version The minor version of the protocol. Initially 0.
选项代码选项F协议版本（127）选项len 4主要版本协议的主要版本。最初是1。次要版本协议的次要版本。最初是0。
This option specifies the number of seconds (an interval) within which the server must receive a message from its partner, or it will assume that communications from the partner are not "OK".
此选项指定服务器必须从其合作伙伴接收消息的秒数（间隔），否则它将假定来自合作伙伴的通信不“正常”。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 128.
此选项的代码为128。
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_F_KEEPALIVE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keepalive-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_F_KEEPALIVE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keepalive-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_KEEPALIVE_TIME (128) option-len 4 receive-time The keepalive-time. An interval of seconds.
选项代码选项保持有效时间（128）选项len 4接收时间保持有效时间。几秒钟的间隔。
This option contains the information necessary for one failover partner to use the reconfigure-key created on the other failover partner.
此选项包含一个故障切换伙伴使用在另一个故障切换伙伴上创建的重新配置密钥所需的信息。
The code for this option is 129.
此选项的代码为129。
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_F_RECONFIGURE_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reconfigure-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. reconfigure-key .
. (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_RECONFIGURE_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reconfigure-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. reconfigure-key .
. (variable) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_RECONFIGURE_DATA (129) option-len 4 + length of reconfigure-key reconfigure-time Time at which reconfigure-key was created. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32). reconfigure-key The reconfigure key
选项代码选项重新配置数据（129）选项长度4+重新配置密钥的长度重新配置时间创建重新配置密钥的时间。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。重新配置密钥重新配置密钥
This option specifies a name for this failover relationship. It is used to distinguish between relationships when there are multiple failover relationships between two failover servers.
此选项指定此故障转移关系的名称。当两个故障转移服务器之间存在多个故障转移关系时，它用于区分关系。
This is a UTF-8 encoded text string suitable for display to an end user. It MUST NOT be null-terminated.
这是一个UTF-8编码的文本字符串，适合向最终用户显示。它不能以null结尾。
The code for this option is 130.
此选项的代码为130。
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_F_RELATIONSHIP_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. relationship-name .
. (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_RELATIONSHIP_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. relationship-name .
. (variable) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_RELATIONSHIP_NAME (130) option-len length of relationship-name relationship-name A UTF-8 encoded text string suitable for display to an end user. MUST NOT be null-terminated.
选项代码选项关系名称（130）选项长度关系名称的长度关系名称适合显示给最终用户的UTF-8编码文本字符串。不能以null结尾。
The OPTION_F_SERVER_FLAGS option specifies information associated with the failover endpoint sending the option.
选项_F_SERVER_FLAGS选项指定与发送该选项的故障转移端点相关的信息。
This is an unsigned byte.
这是一个无符号字节。
The code for this option is 131.
此选项的代码为131。
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_F_SERVER_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-flags |
+-+-+-+-+-+-+-+-+
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_F_SERVER_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-flags |
+-+-+-+-+-+-+-+-+
option-code OPTION_F_SERVER_FLAGS (131) option-len 1 server-flags The server flags. See below:
选项代码选项服务器标志（131）选项len 1服务器标志服务器标志。见下文：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |A|S|C|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |A|S|C|
+-+-+-+-+-+-+-+-+
The bits (numbered from the most significant bit in network byte order) are used as follows:
位（按网络字节顺序从最高有效位开始编号）使用如下：
0-4: MBZ Must be zero. 5 (A): ACK_STARTUP Set to 1 to indicate that the OPTION_F_SERVER_FLAGS option that was most recently received contained the STARTUP bit set. 6 (S): STARTUP MUST be set to 1 whenever the server is in STARTUP state. 7 (C): COMMUNICATED Set to 1 to indicate that the sending server has communicated with its partner.
0-4:MBZ必须为零。5（A）：ACK_STARTUP设置为1，表示最近收到的选项_F_SERVER_FLAGS选项包含启动位集。6（S）：每当服务器处于启动状态时，必须将STARTUP设置为1。7（C）：已通信设置为1，表示发送服务器已与其伙伴通信。
The OPTION_F_SERVER_STATE option specifies the endpoint state of the server sending the option.
选项“服务器状态”选项指定发送该选项的服务器的端点状态。
This is an unsigned byte.
这是一个无符号字节。
The code for this option is 132.
此选项的代码为132。
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_F_SERVER_STATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-state |
+-+-+-+-+-+-+-+-+
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_F_SERVER_STATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-state |
+-+-+-+-+-+-+-+-+
option-code OPTION_F_SERVER_STATE (132) option-len 1 server-state Failover endpoint state
选项代码选项服务器状态（132）选项len 1服务器状态故障切换终结点状态
Value Server State
----- -------------------------------------------------------------
0 reserved
1 STARTUP Startup state (1)
2 NORMAL Normal state
3 COMMUNICATIONS-INTERRUPTED Communications interrupted
4 PARTNER-DOWN Partner down
5 POTENTIAL-CONFLICT Synchronizing
6 RECOVER Recovering bindings from partner
7 RECOVER-WAIT Waiting out MCLT after RECOVER
8 RECOVER-DONE Interlock state prior to NORMAL
9 RESOLUTION-INTERRUPTED Comm. failed during resolution
10 CONFLICT-DONE Primary resolved its conflicts
Value Server State
----- -------------------------------------------------------------
0 reserved
1 STARTUP Startup state (1)
2 NORMAL Normal state
3 COMMUNICATIONS-INTERRUPTED Communications interrupted
4 PARTNER-DOWN Partner down
5 POTENTIAL-CONFLICT Synchronizing
6 RECOVER Recovering bindings from partner
7 RECOVER-WAIT Waiting out MCLT after RECOVER
8 RECOVER-DONE Interlock state prior to NORMAL
9 RESOLUTION-INTERRUPTED Comm. failed during resolution
10 CONFLICT-DONE Primary resolved its conflicts
These states are discussed in detail in Section 8.
第8节详细讨论了这些状态。
(1) The STARTUP state is never sent to the partner server; it is indicated by the STARTUP bit in the OPTION_F_SERVER_FLAGS option (see Section 8.3).
(1) 启动状态从未发送到伙伴服务器；它由选项\u F\u服务器\u标志选项中的启动位指示（见第8.3节）。
The OPTION_F_START_TIME_OF_STATE option specifies the time at which the associated state began to hold its current value. When this option appears in a STATE message, the state to which it refers is the server endpoint state. When it appears in an IA_NA-options, IA_TA-options, or IA_PD-options field, the state to which it refers is the binding-status value in the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD option, respectively. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
选项“状态的开始时间”指定关联状态开始保持其当前值的时间。当此选项出现在状态消息中时，它所指的状态是服务器端点状态。当它出现在IA_NA-options、IA_TA-options或IA_PD-options字段中时，它所指的状态分别是OPTION、OPTION或OPTION中的绑定状态值。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 133.
此选项的代码为133。
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_F_START_TIME_OF_STATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start-time-of-state |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_F_START_TIME_OF_STATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start-time-of-state |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_START_TIME_OF_STATE (133) option-len 4 start-time-of-state The start time of the current state. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
选项代码选项状态的开始时间（133）选项len 4状态的开始时间当前状态的开始时间。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
The OPTION_F_STATE_EXPIRATION_TIME option specifies the time at which the current state of this lease will expire. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
选项_F_STATE _EXPIRATION _TIME指定此租约的当前状态将到期的时间。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
Note that states other than ACTIVE may have a time associated with them. In particular, EXPIRED might have a time associated with it, in the event that some sort of "grace period" existed where the lease would not be reused for a period after the lease expired. The ABANDONED state might have a time associated with it, in the event that the servers participating in failover had a time after which an ABANDONED lease might be placed back into a pool for allocation to a client. In general, if there is an OPTION_STATE_EXPIRATION_TIME associated with a particular state, that indicates that the associated state will expire and move to a different state at that time.
请注意，活动状态以外的状态可能有与其关联的时间。特别是，如果存在某种“宽限期”，租约在租约到期后的一段时间内不会重新使用，则过期可能有一段时间与之相关。如果参与故障转移的服务器有一段时间可以将放弃的租约放回池中以分配给客户端，则放弃的状态可能有一段时间与之关联。通常，如果存在与特定状态关联的选项“状态”“过期时间”，则表示关联状态将过期并在该时间移到其他状态。
This is an unsigned 32-bit integer in network byte order.
这是网络字节顺序的无符号32位整数。
The code for this option is 134.
此选项的代码为134。
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_F_STATE_EXPIRATION_TIME| option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| state-expiration-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_F_STATE_EXPIRATION_TIME| option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| state-expiration-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_STATE_EXPIRATION_TIME (134) option-len 4 state-expiration-time The time at which the current state of the lease will expire. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
选项代码选项状态到期时间（134）选项len 4状态到期时间租约当前状态到期的时间。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数，模2^32）。
The following new status codes are defined to be used in the OPTION_STATUS_CODE option.
以下新的状态代码定义用于选项\u status\u CODE选项。
AddressInUse (16) One client on one server has leases that are in conflict with the leases that the client has on another server. Alternatively, the address could be associated with a different Identity Association Identifier (IAID) on each server.
AddressInUse（16）一台服务器上的一个客户端的租约与该客户端在另一台服务器上的租约冲突。或者，地址可以与每个服务器上的不同身份关联标识符（IAID）关联。
ConfigurationConflict (17) The configuration implied by the information in a BNDUPD message (e.g., the IPv6 address or prefix address) is in direct conflict with the information known to the receiving server.
配置冲突（17）BNDUPD消息中的信息（例如IPv6地址或前缀地址）所隐含的配置与接收服务器已知的信息直接冲突。
MissingBindingInformation (18) There is insufficient information in a BNDUPD message to effectively process it.
丢失绑定信息（18）BNDUPD消息中没有足够的信息来有效处理它。
OutdatedBindingInformation (19) The information in a server's binding database conflicts with the information found in an incoming BNDUPD message and the server believes that the information in its binding database more accurately reflects reality.
OutdatedBindingInformation（19）服务器绑定数据库中的信息与传入BNDUPD消息中的信息冲突，服务器认为其绑定数据库中的信息更准确地反映了现实情况。
ServerShuttingDown (20) The server is undergoing an operator-directed or otherwise planned shutdown.
服务器关闭（20）服务器正在经历操作员指示或计划的关闭。
DNSUpdateNotSupported (21) A server receives a BNDUPD message with DNS update information included and the server doesn't support DNS update.
DNSUpdateNotSupported（21）服务器接收到包含DNS更新信息的BNDUPD消息，但服务器不支持DNS更新。
ExcessiveTimeSkew (22) A server detects that the time skew between its current time and its partner's current time is greater than 5 seconds.
ExcessiveTimeSkew（22）服务器检测到其当前时间与其伙伴当前时间之间的时间偏差大于5秒。
Communication between failover partners takes place over a long-lived TCP connection. This connection is always initiated by the primary server, and if the long-lived connection is lost it is the responsibility of the primary server to attempt to reconnect to the secondary server. The detailed process used by the primary server when initiating a connection and by the secondary server when responding to a connection attempt as documented in Section 6.1 is followed each time a connection is established, regardless of any previous connection between the failover partners.
故障转移合作伙伴之间的通信通过长寿命TCP连接进行。此连接始终由主服务器启动，如果长期连接丢失，则主服务器负责尝试重新连接到辅助服务器。每次建立连接时，都会遵循主服务器在启动连接时以及辅助服务器在响应第6.1节中记录的连接尝试时所使用的详细过程，而不管故障转移伙伴之间以前是否有任何连接。
Every primary server implementing the failover protocol MUST periodically attempt to create a TCP connection to the dhcp-failover port (647) of all of its configured partners, where the period is implementation dependent and SHOULD be configurable. In the event that a connection has been rejected by a CONNECTREPLY message with an OPTION_STATUS_CODE option contained in it or a DISCONNECT message, a server SHOULD reduce the frequency with which it attempts to connect to that server, but it MUST continue to attempt to connect periodically.
每个实现故障切换协议的主服务器必须定期尝试创建到其所有配置伙伴的dhcp故障切换端口（647）的TCP连接，该连接周期取决于实现，并且应该是可配置的。如果连接被包含选项_STATUS _CODE选项的CONNECTREPLY消息或断开连接消息拒绝，服务器应降低尝试连接到该服务器的频率，但必须继续定期尝试连接。
Every secondary server implementing the failover protocol MUST listen for TCP connection attempts on the dhcp-failover port (647) from a primary server.
每个实现故障转移协议的辅助服务器都必须侦听来自主服务器的dhcp故障转移端口（647）上的TCP连接尝试。
After a primary server successfully establishes a TCP connection to a secondary server, it MUST continue the connection process as described in Section 8.2 of [RFC7653]. In the language of that section, the primary failover server operates as the "requestor" and the secondary failover server operates as the "DHCP server". The message that is sent over the newly established connection is a CONNECT message, instead of an ACTIVELEASEQUERY message.
主服务器成功建立到辅助服务器的TCP连接后，必须按照[RFC7653]第8.2节所述继续连接过程。在该部分的语言中，主故障切换服务器作为“请求者”运行，辅助故障切换服务器作为“DHCP服务器”运行。通过新建立的连接发送的消息是CONNECT消息，而不是ActiveLeaRequesty消息。
When a secondary server receives a connection attempt, the only information that the secondary server has is the IP address of the partner initiating a connection. If it has any relationships with the connecting server for which it is a secondary server, it should
当辅助服务器接收到连接尝试时，辅助服务器拥有的唯一信息是启动连接的伙伴的IP地址。如果它与作为辅助服务器的连接服务器有任何关系，则应该
operate as described in Section 9.1 of [RFC7653], with the exception that instead of waiting for an Active Leasequery message it will wait for a CONNECT message. Once it has received the CONNECT message, it will use the information in that message to determine which relationship this connection is to service.
按照[RFC7653]第9.1节所述操作，但不等待活动租赁请求消息，而是等待连接消息。一旦收到CONNECT消息，它将使用该消息中的信息来确定此连接与服务的关系。
If it has no secondary relationships with the connecting server, it MUST drop the connection.
如果它与连接服务器没有辅助关系，则必须断开连接。
To summarize -- a primary server MUST use a connection that it has initiated in order to send a CONNECT message. Every server that is a secondary server in a relationship MUST listen for CONNECT messages from the primary server.
总而言之，主服务器必须使用它已启动的连接才能发送连接消息。关系中作为辅助服务器的每台服务器都必须侦听来自主服务器的CONNECT消息。
When the CONNECT and CONNECTREPLY exchange successfully produces a working failover connection, the next message sent over a new connection is a STATE message. See Section 6.3. Upon the receipt of the STATE message, the receiver can consider communications "OK".
当CONNECT和CONNECTREPLY exchange成功生成工作故障转移连接时，通过新连接发送的下一条消息是状态消息。见第6.3节。在接收到状态消息后，接收方可以考虑通信“OK”。
The CONNECT message is sent with information about the failover configuration on the primary server. The message MUST contain at least the following information in the options area:
将发送CONNECT消息，其中包含有关主服务器上故障切换配置的信息。消息的选项区域中必须至少包含以下信息：
o OPTION_F_PROTOCOL_VERSION containing the protocol version that the primary server will use when sending failover messages.
o 选项\u F\u协议\u版本包含主服务器在发送故障转移消息时将使用的协议版本。
o OPTION_F_MCLT containing the configured MCLT.
o 包含已配置MCLT的选项\u F\u MCLT。
o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an interval) within which the server must receive a message from its partner, or it will assume that communications from the partner are not "OK".
o 选项_F_KEEPALIVE_TIME包含服务器必须从其合作伙伴接收消息的秒数（间隔），否则它将假定来自合作伙伴的通信不“正常”。
o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of BNDUPD messages that this server is prepared to accept over the failover connection without causing the connection to block. This implements application-level flow control over the connection, so that a flood of BNDUPD messages does not cause the connection to block and thereby prevent other messages from being transmitted over the connection and received by the failover partner.
o 选项_F_MAX_UNACKED_BNDUPD包含此服务器准备通过故障转移连接接受的最大BNDUPD消息数，而不会导致连接阻塞。这在连接上实现了应用程序级流控制，因此大量的BNDUPD消息不会导致连接阻塞，从而防止其他消息通过连接传输并由故障转移伙伴接收。
o OPTION_F_RELATIONSHIP_NAME containing the name of the failover relationship to which this connection applies. If there is no OPTION_F_RELATIONSHIP_NAME in the CONNECT message, it indicates that there is only a single relationship between this pair of primary and secondary servers.
o 选项\u F\u RELATIONSHIP\u NAME包含应用此连接的故障转移关系的名称。如果连接消息中没有选项\u F\u RELATIONSHIP\u NAME，则表示这对主服务器和辅助服务器之间只有一个关系。
o OPTION_F_CONNECT_FLAGS containing information about certain attributes of the connecting servers.
o 选项\u F\u CONNECT\u标志包含有关连接服务器的某些属性的信息。
A server receiving a CONNECT message must process the information in the message and decide whether or not to accept the connection. The processing is performed as follows:
接收CONNECT消息的服务器必须处理消息中的信息，并决定是否接受连接。处理按如下方式执行：
o sent-time - The secondary server checks the sent-time to see if it is within 5 seconds of its current time. See Section 7.1. If it is not, return ExcessiveTimeSkew in the OPTION_STATUS_CODE to reject the CONNECT message.
o 发送时间-辅助服务器检查发送时间是否在当前时间的5秒内。见第7.1节。如果不是，请在选项_STATUS_代码中返回ExcessiveTimeSkew以拒绝连接消息。
o OPTION_F_PROTOCOL_VERSION - The secondary server decides if the protocol version of the primary server is supported by the secondary server. If it is not, return NotSupported in the OPTION_STATUS_CODE to reject the CONNECT message.
o 选项\u F\u协议\u版本-辅助服务器决定辅助服务器是否支持主服务器的协议版本。如果不支持，请在选项_STATUS_代码中返回NotSupported以拒绝连接消息。
o OPTION_F_MCLT - Use this MCLT supplied by the primary server. Remember this MCLT, and use it until a different MCLT is supplied by some subsequent CONNECT message.
o 选项\u F\u MCLT-使用主服务器提供的此MCLT。记住此MCLT，并使用它，直到后续的某个CONNECT消息提供不同的MCLT。
o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the FO_KEEPALIVE_TIME (Section 6.5) when implementing the Unreachability Detection algorithm described in Section 6.6.
o 选项_F_KEEPALIVE_TIME-在实施第6.6节所述的不可达性检测算法时，记住KEEPALIVE TIME作为fou KEEPALIVE_TIME（第6.5节）。
o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of unacked BNDUPD messages queued to the primary server never exceeds the value in the OPTION_F_MAX_UNACKED_BNDUPD option.
o OPTION_F_MAX_UNACKED_BNDUPD-确保排队到主服务器的未确认BNDUPD消息的最大数量永远不会超过OPTION_F_MAX_UNACKED_BNDUPD选项中的值。
o OPTION_F_CONNECT_FLAGS - Ensure that the secondary server can process information from the primary server as specified in the flags. For example, if the secondary server cannot process prefix delegation with variable-sized prefixes delegated from the same delegable prefix and the primary server says that it can, the secondary should reject the connection.
o 选项\u F\u连接\u标志-确保辅助服务器可以按照标志中的指定处理来自主服务器的信息。例如，如果辅助服务器无法处理从同一可委派前缀委派的大小可变的前缀委派，而主服务器表示可以，则辅助服务器应拒绝连接。
A CONNECT message SHOULD always be followed by a CONNECTREPLY message, to either (1) accept the connection or (2) reject the connection by including an OPTION_STATUS_CODE option with a status-code indicating the reason for the rejection. If accepting the connection attempt, then send a CONNECTREPLY message with the following information:
CONNECT消息后应始终跟随CONNECTREPLY消息，以便（1）接受连接或（2）通过包含选项_STATUS _CODE选项以及指示拒绝原因的状态代码来拒绝连接。如果接受连接尝试，则发送包含以下信息的CONNECTREPLY消息：
o OPTION_F_PROTOCOL_VERSION containing the protocol version being used by the secondary server when sending failover messages.
o 选项\u F_PROTOCOL \u VERSION包含辅助服务器在发送故障转移消息时使用的协议版本。
o OPTION_F_MCLT containing the MCLT currently in use on the secondary server. This MUST equal the MCLT that was in the OPTION_F_MCLT option in the CONNECT message.
o 包含辅助服务器上当前正在使用的MCLT的选项\u F\u MCLT。这必须等于CONNECT消息中选项\u F\u MCLT选项中的MCLT。
o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an interval) within which the server must receive a message from its partner, or it will assume that communications from the partner are not "OK".
o 选项_F_KEEPALIVE_TIME包含服务器必须从其合作伙伴接收消息的秒数（间隔），否则它将假定来自合作伙伴的通信不“正常”。
o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of BNDUPD messages that this server is prepared to accept over the failover connection without causing the connection to block. This implements application-level flow control over the connection, so that a flood of BNDUPD messages does not cause the connection to block and thereby prevent other messages from being transmitted over the connection and received by the failover partner.
o 选项_F_MAX_UNACKED_BNDUPD包含此服务器准备通过故障转移连接接受的最大BNDUPD消息数，而不会导致连接阻塞。这在连接上实现了应用程序级流控制，因此大量的BNDUPD消息不会导致连接阻塞，从而防止其他消息通过连接传输并由故障转移伙伴接收。
o OPTION_F_CONNECT_FLAGS containing information describing the attributes of the secondary server that the primary needs to know about.
o OPTION_F_CONNECT_标志，包含描述主服务器需要了解的辅助服务器属性的信息。
After sending a CONNECTREPLY message to accept the primary server's CONNECT message, the secondary server MUST send a STATE message (see Section 6.3).
发送CONNECTREPLY消息以接受主服务器的CONNECT消息后，辅助服务器必须发送状态消息（请参阅第6.3节）。
A server receiving a CONNECTREPLY message must process the information in the message and decide whether or not to continue to employ the connection. The processing is performed as follows:
接收CONNECTREPLY消息的服务器必须处理消息中的信息，并决定是否继续使用连接。处理按如下方式执行：
o OPTION_F_PROTOCOL_VERSION - The primary server decides if the protocol version in use by the secondary server is supported by the primary server. If it is not, send a DISCONNECT message and drop the connection. If it is supported, continue processing. It is possible that the primary and secondary servers will each be sending different versions of the protocol to the other server.
o 选项\u F_协议\u版本-主服务器决定主服务器是否支持辅助服务器使用的协议版本。如果不是，请发送断开连接消息并断开连接。如果支持，请继续处理。主服务器和辅助服务器可能各自向另一台服务器发送不同版本的协议。
The extent to which this is supported will be defined partly by as-yet-unknown differences in the protocols that the versions represent and partly by the capabilities of the two implementations involved in the failover relationship.
支持这一点的程度部分取决于版本所代表的协议之间的未知差异，部分取决于故障切换关系中涉及的两个实现的功能。
o OPTION_F_MCLT - Compare the MCLT received with the configured MCLT. If they are different, send a DISCONNECT message and drop the connection.
o 选项\u F\u MCLT-将接收到的MCLT与配置的MCLT进行比较。如果它们不同，请发送断开连接消息并断开连接。
o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the FO_KEEPALIVE_TIME (Section 6.5) when implementing the Unreachability Detection algorithm described in Section 6.6.
o 选项_F_KEEPALIVE_TIME-在实施第6.6节所述的不可达性检测算法时，记住KEEPALIVE TIME作为fou KEEPALIVE_TIME（第6.5节）。
o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of unacked BNDUPD messages queued to the secondary server never exceeds the value in the OPTION_F_MAX_UNACKED_BNDUPD option.
o OPTION_F_MAX_UNACKED_BNDUPD-确保排队到辅助服务器的未确认BNDUPD消息的最大数量永远不会超过OPTION_F_MAX_UNACKED_BNDUPD选项中的值。
o OPTION_F_CONNECT_FLAGS - Ensure that the primary server can process information from the secondary server as specified in the flags. For example, if the primary server cannot process prefix delegation with variable-sized prefixes delegated from the same delegable prefix and the secondary server says that it can, the primary should drop the connection.
o 选项\u F\u连接\u标志-确保主服务器可以按照标志中的指定处理来自辅助服务器的信息。例如，如果主服务器无法使用从同一可委派前缀委派的可变大小前缀处理前缀委派，而辅助服务器表示可以，则主服务器应断开连接。
After receiving a CONNECTREPLY message that accepted the primary server's CONNECT message, the primary server MUST send a STATE message (see Section 6.3).
接收到接受主服务器连接消息的CONNECTREPLY消息后，主服务器必须发送状态消息（请参阅第6.3节）。
A failover endpoint is always associated with a set of DHCP prefixes that are configured on the DHCP server where the endpoint appears. A DHCP prefix MUST NOT be associated with more than one failover endpoint.
故障转移终结点始终与一组DHCP前缀相关联，这些前缀在出现终结点的DHCP服务器上配置。DHCP前缀不得与多个故障转移终结点关联。
The failover protocol SHOULD be configured with one failover relationship between each pair of failover servers. In this case, there is one failover endpoint for that relationship on each failover partner. This failover relationship MUST have a unique name.
故障转移协议应在每对故障转移服务器之间配置一个故障转移关系。在这种情况下，每个故障转移伙伴上都有一个该关系的故障转移端点。此故障转移关系必须具有唯一的名称。
Any failover endpoint can take actions and hold unique states.
任何故障转移终结点都可以执行操作并保持唯一状态。
This document frequently describes the behavior of the failover protocol in terms of primary and secondary servers, not primary and secondary failover endpoints. However, it is important to remember that every "server" described in this document is in reality a failover endpoint that resides in a particular process and that several failover endpoints may reside in the same server process.
本文档经常从主服务器和辅助服务器（而不是主和辅助故障切换端点）的角度描述故障切换协议的行为。但是，请务必记住，本文档中描述的每个“服务器”实际上都是驻留在特定进程中的故障转移端点，并且多个故障转移端点可能驻留在同一个服务器进程中。
It is not the case that there is a unique failover endpoint for each prefix that participates in a failover relationship. On one server, there is (typically) one failover endpoint per partner, regardless of how many prefixes are managed by that combination of partner and role. On a particular server, any given prefix that participates in failover will be associated with exactly one failover endpoint.
参与故障转移关系的每个前缀都不是唯一的故障转移端点。在一台服务器上，每个合作伙伴（通常）有一个故障转移端点，而不管合作伙伴和角色的组合管理了多少前缀。在特定服务器上，参与故障转移的任何给定前缀都将仅与一个故障转移端点关联。
When a connection is received from the partner, the unique failover endpoint to which the message is directed is determined solely by the IPv6 address of the partner, the relationship name, and the role of the receiving server.
从合作伙伴接收连接时，消息指向的唯一故障切换端点仅由合作伙伴的IPv6地址、关系名称和接收服务器的角色确定。
A server MUST send a STATE message to its failover partner whenever the state of the failover endpoint changes. Sending the occasional duplicate STATE message will not cause any problems; note, however, that not updating the failover partner with information about a failover endpoint state change can, in many cases, cause the entire failover protocol to be inoperative.
每当故障转移终结点的状态发生更改时，服务器必须向其故障转移伙伴发送状态消息。偶尔发送重复状态消息不会导致任何问题；但是，请注意，在许多情况下，如果不使用有关故障切换端点状态更改的信息更新故障切换伙伴，可能会导致整个故障切换协议不起作用。
The STATE message is sent with information about the endpoint state of the failover relationship. The STATE message MUST contain at least the following information in the options area:
状态消息随故障转移关系的端点状态信息一起发送。“选项”区域中的状态消息必须至少包含以下信息：
o OPTION_F_SERVER_STATE containing the state of this failover endpoint.
o 包含此故障转移终结点状态的选项\u F\u服务器\u状态。
o OPTION_F_SERVER_FLAGS containing the flag values associated with this failover endpoint.
o 选项\u F\u服务器\u包含与此故障转移终结点关联的标志值的标志。
o OPTION_F_START_TIME_OF_STATE containing the time when this became the state of this failover endpoint.
o 选项\u F\u START\u TIME\u OF \u STATE，其中包含此故障转移终结点成为状态的时间。
o OPTION_F_PARTNER_DOWN_TIME containing the time that this failover endpoint went into PARTNER-DOWN state if this server is in PARTNER-DOWN state. If this server isn't in PARTNER-DOWN state, do not include this option.
o 选项\u F\u PARTNER\u DOWN\u TIME包含此故障转移终结点进入伙伴关闭状态（如果此服务器处于伙伴关闭状态）的时间。如果此服务器未处于合作伙伴关闭状态，请不要包括此选项。
The server sending a STATE message SHOULD ensure that this information is written to stable storage prior to enqueuing it to its failover partner.
发送状态消息的服务器应确保将此信息写入稳定存储，然后再将其排入故障转移伙伴。
A server receiving a STATE message must process the information in the message and decide how to react to the information. The processing is performed as follows:
接收状态消息的服务器必须处理消息中的信息，并决定如何对信息做出反应。处理按如下方式执行：
o OPTION_F_SERVER_STATE - If this represents a change in state for the failover partner, react according to the instructions in Section 8.1. If the state is not PARTNER-DOWN, clear any memory of the partner-down-time.
o 选项\u F\u服务器\u状态-如果这表示故障转移伙伴的状态发生变化，请根据第8.1节中的说明作出反应。如果状态不是伙伴停机，请清除伙伴停机时间的所有内存。
o OPTION_F_SERVER_FLAGS - Remember these flags in an appropriate data area so they can be referenced later.
o 选项_F_服务器_标志-在适当的数据区域中记住这些标志，以便以后可以引用。
o OPTION_F_START_TIME_OF_STATE - Remember this information in an appropriate data area so it can be referenced later.
o 选项\u F\u STATE的\u START\u TIME\u-在适当的数据区域中记住此信息，以便以后可以引用。
o OPTION_F_PARTNER_DOWN_TIME - If the value of the OPTION_F_SERVER_STATE is PARTNER-DOWN, remember this information in an appropriate data area so it can be referenced later.
o OPTION_F_PARTNER_DOWN_TIME-如果OPTION_SERVER_STATE的值为PARTNER-DOWN，请在适当的数据区域中记住此信息，以便以后可以引用。
A server receiving a STATE message SHOULD ensure that this information is written to stable storage.
接收状态消息的服务器应确保将此信息写入稳定存储器。
The following parameters and timers are used to ensure the integrity of the connections between two failover servers.
以下参数和计时器用于确保两台故障切换服务器之间连接的完整性。
Parameter Default Description
---------------------------------------------------------------------
FO_KEEPALIVE_TIMER timer counts down to time
connection assumed dead
due to lack of messages
Parameter Default Description
---------------------------------------------------------------------
FO_KEEPALIVE_TIMER timer counts down to time
connection assumed dead
due to lack of messages
FO_KEEPALIVE_TIME 60 maximum time server will consider connection still up with no messages
FooKePayLaveIt 60最大时间服务器将考虑连接仍然没有消息
FO_CONTACT_PER_KEEPALIVE_TIME 4 number of CONTACT messages to send during partner's FO_KEEPALIVE_TIME period
FO_CONTACT_PER_KEEPALIVE_TIME 4在合作伙伴FO_KEEPALIVE_期间发送的联系信息数
FO_SEND_TIMER timer counts down to time to send next CONTACT message
FO_SEND_定时器倒计时至发送下一条联系信息的时间
FO_SEND_TIME 15 maximum time to wait between sending CONTACT messages if no other traffic. Created from partner's FO_KEEPALIVE_TIME divided by FO_CONTACT_PER_KEEPALIVE_TIME
FO_SEND_TIME 15如果没有其他流量，发送联系信息之间的最长等待时间。根据合作伙伴的FO_KEEPALIVE_时间除以Fou CONTACT_PER_KEEPALIVE_时间创建
Each partner MUST maintain an FO_SEND_TIMER for each failover connection. The FO_SEND_TIMER for a particular connection is reset to FO_SEND_TIME every time any message is transmitted on that connection, and the timer counts down once per second. If the timer reaches zero, a CONTACT message is transmitted on that connection and the timer for that connection is reset to FO_SEND_TIME. The CONTACT message may be transmitted at any time. An implementation MAY use additional mechanisms to detect partner unreachability.
每个合作伙伴必须为每个故障切换连接维护一个FO SEND\ U计时器。每次在特定连接上传输任何消息时，都会将特定连接的FO_SEND_计时器重置为FO_SEND_TIME，并且计时器每秒倒计时一次。如果计时器达到零，则会在该连接上发送一条联系消息，该连接的计时器将重置为fou SEND_TIME。联系人消息可以在任何时候发送。一个实现可以使用额外的机制来检测伙伴的不可访问性。
The FO_SEND_TIME is initialized from the configured FO_KEEPALIVE_TIME divided by FO_CONTACT_PER_KEEPALIVE_TIME. When a CONNECT or CONNECTREPLY message is received on a connection, the received OPTION_F_KEEPALIVE_TIME option is checked, and the value in that option is used to calculate the FO_SEND_TIME for that connection by dividing the value received by the configured FO_CONTACT_PER_KEEPALIVE_TIME.
FO_发送时间由配置的FO_KEEPALIVE_时间除以FO_CONTACT_PER_KEEPALIVE_时间初始化。当在连接上接收到CONNECT或CONNECTREPLY消息时，将选中received（接收）选项\u F_KEEPALIVE_TIME（保持时间）选项，该选项中的值用于计算该连接的fou SEND_时间，方法是将收到的值除以配置的fou CONTACT_PER_KEEPALIVE_TIME（保持时间）。
Each partner MUST maintain an FO_KEEPALIVE_TIMER for each failover connection. This timer is initialized to FO_KEEPALIVE_TIME and counts down once per second. It is reset to FO_KEEPALIVE_TIME whenever a message is received on that connection. If it ever reaches zero, that connection is considered dead. In addition, the FO_KEEPALIVE_TIME for that connection MUST be sent to the failover partner on every CONNECT or CONNECTREPLY message in the OPTION_F_KEEPALIVE_TIME option.
每个合作伙伴必须为每个故障切换连接维护一个FO_KEEPALIVE_计时器。此计时器初始化为FO_KEEPALIVE_TIME，并每秒倒计时一次。每当在该连接上收到消息时，它将重置为fou KEEPALIVE_TIME。如果它曾经达到零，那么这个连接就被认为是死的。此外，该连接的FO_KEEPALIVE_时间必须在选项\u F_KEEPALIVE_时间选项中的每个CONNECT或CONNECTREPLY消息上发送给故障转移伙伴。
Partners exchange information about known lease states. To reliably compare a known lease state with an update received from a partner, servers must be able to reliably compare the times stored in the known lease state with the times received in the update. The failover protocol adopts the simple approach of requiring that the failover partners use some mechanism to synchronize the clocks on the two servers to within an accuracy of roughly 5 seconds.
合作伙伴交换有关已知租赁状态的信息。要可靠地比较已知租约状态与从合作伙伴接收的更新，服务器必须能够可靠地比较存储在已知租约状态中的时间与在更新中接收的时间。故障切换协议采用了一种简单的方法，要求故障切换伙伴使用某种机制将两台服务器上的时钟同步到大约5秒的精度。
A mechanism to measure and track relative time differences between servers is necessary to ensure this synchronization. To do so, each message contains the time of the transmission in the sent-time field of the message (see Section 5.2). The transmitting server MUST set this as close to the actual transmission as possible. The receiving partner MUST store its own timestamp of reception as close to the actual reception as possible. The received timestamp information is then compared with the local timestamp.
为了确保同步，需要一种测量和跟踪服务器之间相对时间差的机制。为此，每条消息在消息的发送时间字段中包含传输时间（见第5.2节）。传输服务器必须将其设置为尽可能接近实际传输。接收合作伙伴必须将自己的接收时间戳存储在尽可能接近实际接收的位置。然后将接收到的时间戳信息与本地时间戳进行比较。
In most DHCP servers, a lease on an IPv6 address or a prefix can take on several different binding-status values, sometimes also called "lease states". While no two DHCP server implementations will have exactly the same possible binding-status values, [RFC3315] enforces some commonality among the general semantics of the binding-status values used by various DHCP server implementations.
在大多数DHCP服务器中，IPv6地址或前缀上的租约可以具有多个不同的绑定状态值，有时也称为“租约状态”。虽然没有两个DHCP服务器实现具有完全相同的可能绑定状态值，[RFC3315]在各种DHCP服务器实现所使用的绑定状态值的一般语义中实施了一些共性。
In order to transmit binding database updates between one server and another using the failover protocol, some common binding-status values must be defined. It is not expected that these values correspond to any actual implementation of DHCPv6 in a DHCP server, but rather that the binding-status values defined in this document should be convertible back and forth between those defined below and those in use by many DHCP server implementations.
为了使用故障转移协议在一台服务器和另一台服务器之间传输绑定数据库更新，必须定义一些常见的绑定状态值。这些值不应与DHCP服务器中DHCPv6的任何实际实现相对应，而是本文档中定义的绑定状态值应在以下定义的值和许多DHCP服务器实现中使用的值之间来回转换。
The lease binding-status values defined for the failover protocol are listed below. Unless otherwise noted below, there MAY be client information associated with each of these binding-status values.
下面列出了为故障转移协议定义的租约绑定状态值。除非下文另有说明，否则可能存在与这些绑定状态值中的每一个相关联的客户端信息。
ACTIVE - The lease is assigned to a client. Client identification data MUST appear.
活动-租约已分配给客户。必须显示客户端标识数据。
EXPIRED - This value indicates that a client's binding on a given lease has expired. When the partner acks the BNDUPD message of an expired lease, the server sets its internal state to PENDING-FREE. Client identification SHOULD appear.
EXPIRED-此值表示客户端对给定租约的绑定已过期。当合作伙伴确认过期租约的BNDUPD消息时，服务器将其内部状态设置为PENDING-FREE。应显示客户端标识。
RELEASED - This value indicates that a client sent a RELEASE message. When the partner acks the BNDUPD message of a released lease, the server sets its internal state to PENDING-FREE. Client identification SHOULD appear.
已发布-此值表示客户端发送了一条发布消息。当合作伙伴确认已释放租约的BNDUPD消息时，服务器将其内部状态设置为PENDING-FREE。应显示客户端标识。
PENDING-FREE - Once a lease is expired or released, its state becomes PENDING-FREE. Depending on which algorithm was used to allocate a given lease, PENDING-FREE may mean either FREE or FREE-BACKUP. Implementations do not have to implement this PENDING-FREE state but may choose to switch to the destination state directly. For clarity of representation, this transitional PENDING-FREE state is treated as a separate state.
PENDING-FREE—租约到期或解除后，其状态变为PENDING-FREE。根据分配给定租约时使用的算法，PENDING-FREE可能意味着免费或免费备份。实现不必实现这个挂起的自由状态，但可以选择直接切换到目标状态。为清楚起见，这种过渡的无未决状态被视为一个单独的状态。
FREE - This value is used when a DHCP server needs to communicate that a lease is unused by any client, but it was not just released, expired, or reset by a network administrator. When the partner acks the BNDUPD message of a FREE lease, the server marks the lease as available for assignment by the primary server. Note that on a secondary server running in PARTNER-DOWN state, after waiting the MCLT, the lease MAY be allocated to a client by the secondary server. Client identification MAY appear and indicates, as a hint, the last client to have used this lease.
FREE-当DHCP服务器需要告知任何客户端都未使用租约，但网络管理员不仅释放、过期或重置了租约时，使用此值。当合作伙伴确认免费租约的BNDUPD消息时，服务器将该租约标记为可由主服务器分配。请注意，在以伙伴关闭状态运行的辅助服务器上，在等待MCLT后，辅助服务器可能会将租约分配给客户端。可能会出现客户标识，并提示最后一个使用此租约的客户。
FREE-BACKUP - This value indicates that this lease can be allocated by the secondary server to a client at any time. Note that on the primary server running in PARTNER-DOWN state, after waiting the MCLT, the lease MAY be allocated to a client by the primary server if the proportional algorithm was used. Client identification MAY appear and indicates, as a hint, the last client to have used this lease.
FREE-BACKUP—此值表示辅助服务器可以随时将此租约分配给客户端。请注意，在伙伴关闭状态下运行的主服务器上，在等待MCLT后，如果使用比例算法，则主服务器可能会将租约分配给客户机。可能会出现客户标识，并提示最后一个使用此租约的客户。
ABANDONED - This value indicates that a lease is considered unusable by the DHCP system. The primary reason for entering such a state is the reception of a DECLINE message for the lease. Client identification MAY appear.
放弃-此值表示DHCP系统认为租约不可用。进入这种状态的主要原因是接收到租约的拒绝消息。可能会出现客户标识。
RESET - This value indicates that this lease was made available by an operator command. This is a distinct state so that the reason that the lease became FREE can be determined. Client identification MAY appear.
重置-此值表示此租约由操作员命令提供。这是一种独特的状态，因此可以确定租赁变得自由的原因。可能会出现客户标识。
Which binding-status values are associated with a timeout is implementation dependent. Some binding-status values, such as ACTIVE, will have a timeout value in all implementations, while others, such as ABANDONED, will have a timeout value in some implementations and not in others. In some implementations, a binding-status value may be associated with a timeout in some circumstances and not in others. The receipt of a BNDUPD message with a particular binding-status value and an OPTION_F_STATE_EXPIRATION_TIME indicates that this particular binding-status value is associated with a timeout.
哪些绑定状态值与超时关联取决于实现。某些绑定状态值（如ACTIVE）在所有实现中都有一个超时值，而其他绑定状态值（如Forced）在某些实现中有一个超时值，而在其他实现中没有。在某些实现中，绑定状态值可能在某些情况下与超时相关联，而在其他情况下与超时无关。接收到具有特定绑定状态值和选项_F_STATE _EXPIRATION _TIME的BNDUPD消息表示此特定绑定状态值与超时相关联。
The lease state machine is presented in Figure 2. Most states are stationary, i.e., the lease stays in a given state until an external event triggers transition to another state. The only transitive state is PENDING-FREE. Once it is reached, the state machine immediately transitions to either FREE or FREE-BACKUP state.
租赁状态机如图2所示。大多数状态是静止的，即租约保持在给定状态，直到外部事件触发转换到另一个状态。唯一的可传递状态是PENDING-FREE。一旦达到该状态，状态机立即转换为空闲或空闲备份状态。
+---------+
/------------->| ACTIVE |<--------------\
| +---------+ |
| | | | |
| /--(8)--/ (3) \--(9)-\ |
| | | | |
| V V V |
| +-------+ +--------+ +---------+ |
| |EXPIRED| |RELEASED| |ABANDONED| |
| +-------+ +--------+ +---------+ |
| | | | |
| | | (10) |
| | | V |
| | | +---------+ |
| | | | RESET | |
| | | +---------+ |
| | | | |
| \--(4)--\ (4) /--(4)--/ |
| | | | |
(1) V V V (2)
| /---------\ |
| | PENDING-| |
| | FREE | |
| \---------/ |
| | | |
| /-(5)--/ \-(6)-\ |
| | | |
| V V |
| +-------+ +-----------+ |
\----| FREE |<--(7)-->|FREE-BACKUP|-----/
+-------+ +-----------+
+---------+
/------------->| ACTIVE |<--------------\
| +---------+ |
| | | | |
| /--(8)--/ (3) \--(9)-\ |
| | | | |
| V V V |
| +-------+ +--------+ +---------+ |
| |EXPIRED| |RELEASED| |ABANDONED| |
| +-------+ +--------+ +---------+ |
| | | | |
| | | (10) |
| | | V |
| | | +---------+ |
| | | | RESET | |
| | | +---------+ |
| | | | |
| \--(4)--\ (4) /--(4)--/ |
| | | | |
(1) V V V (2)
| /---------\ |
| | PENDING-| |
| | FREE | |
| \---------/ |
| | | |
| /-(5)--/ \-(6)-\ |
| | | |
| V V |
| +-------+ +-----------+ |
\----| FREE |<--(7)-->|FREE-BACKUP|-----/
+-------+ +-----------+
PENDING-FREE transition
无挂起转换
Figure 2: Lease State Machine
图2：租赁状态机
Transitions between states will result from the following events:
以下事件将导致状态之间的转换：
(1) The primary server allocates a lease.
(1) 主服务器分配租约。
(2) The secondary server allocates a lease.
(2) 辅助服务器分配租约。
(3) The client sends RELEASE, and the lease is released.
(3) 客户端发送释放，租约被释放。
(4) The partner acknowledges the state change. This transition MAY also occur if the server is in PARTNER-DOWN state and the MCLT has passed since the entry into RELEASED, EXPIRED, or RESET states.
(4) 合伙人承认状态变化。如果服务器处于伙伴关闭状态，并且MCLT自进入释放、过期或重置状态后已通过，则也可能发生此转换。
(5) The lease belongs to a pool that is governed by proportional allocation, or independent allocation is used and this lease belongs to the primary server's pool.
(5) 租约属于由比例分配管理的池，或者使用独立分配，并且此租约属于主服务器的池。
(6) The lease belongs to a pool that is governed by independent allocation, and the lease belongs to the secondary server.
(6) 租约属于由独立分配管理的池，租约属于辅助服务器。
(7) A pool rebalance event occurs (POOLREQ/POOLRESP messages are exchanged). Delegable prefixes belonging to the primary server can be assigned to the secondary server's pool (transition from FREE to FREE-BACKUP) or vice versa.
(7) 发生池重新平衡事件（交换POOLREQ/POOLRESP消息）。可以将属于主服务器的可删除前缀分配给辅助服务器的池（从空闲到空闲备份的转换），反之亦然。
(8) The lease has expired.
(8) 租约到期了。
(9) A DECLINE message is received, or a lease is deemed unusable for other reasons.
(9) 收到拒绝消息，或由于其他原因租赁被视为不可用。
(10) An administrative action is taken to restore an abandoned lease to a usable state. This transition MAY occur due to implementation-specific handling of an ABANDONED lease. One possible example of this is a Neighbor Discovery or ICMPv6 Echo check to see if the address is still in use.
（10） 执行管理操作以将放弃的租约恢复到可用状态。这种转换可能是由于特定于实施的废弃租赁处理而发生的。一个可能的例子是邻居发现或ICMPv6回送检查，以查看地址是否仍在使用中。
The lease that is no longer in use (due to expiration or release) becomes PENDING-FREE. Depending on what allocation algorithm is used, the lease that is no longer in use returns to the primary pool (FREE) or the secondary pool (FREE-BACKUP). The conditions for specific transitions are depicted in Figure 3.
不再使用的租约（由于到期或解除）将变为无挂起租约。根据使用的分配算法，不再使用的租约将返回主池（空闲）或辅助池（空闲备份）。图3描述了特定转换的条件。
+----------------+---------+-----------+
| \ Lease owner| | |
| \----------\ | Primary | Secondary |
|Algorithm \ | | |
+----------------+---------+-----------+
| Proportional | FREE |FREE-BACKUP|
| Independent | FREE | FREE |
+----------------+---------+-----------+
+----------------+---------+-----------+
| \ Lease owner| | |
| \----------\ | Primary | Secondary |
|Algorithm \ | | |
+----------------+---------+-----------+
| Proportional | FREE |FREE-BACKUP|
| Independent | FREE | FREE |
+----------------+---------+-----------+
Figure 3: PENDING-FREE State Transitions
图3：挂起的自由状态转换
Each server must keep track of the following specific times beyond those required by the base DHCP specification [RFC3315].
除基本DHCP规范[RFC3315]要求的时间外，每个服务器必须跟踪以下特定时间。
expiration-time The greatest lifetime that this server has ever acked to its failover partner in a BNDREPLY message.
过期时间此服务器在BNDREPLY消息中向其故障转移伙伴确认的最长生存期。
acked-partner-lifetime The greatest lifetime that the failover partner has ever acked to this server in a BNDREPLY message.
acked partner lifetime故障转移伙伴在BNDREPLY消息中确认此服务器的最大生存期。
partner-lifetime The time value that will be sent (or that has been sent) to the partner to indicate the time after which the partner can consider the lease expired. When a BNDUPD message is received, this value can be updated from the received OPTION_F_EXPIRATION_TIME.
伙伴生命周期将被发送（或已发送）给伙伴的时间值，以指示合伙人可以考虑租约期满的时间。当接收到BNDUPD消息时，可以从接收选项\u F\u EXPIRATION\u TIME更新此值。
client-last-transaction-time The time when this server most recently interacted with the client associated with this lease.
client last transaction time此服务器最近与与此租约关联的客户端交互的时间。
partner-raw-clt-time The time when the partner most recently interacted with the client associated with this lease. This time remains exactly as it was received by this server and MUST NOT be adjusted in any way.
partner raw clt time合作伙伴最近与与此租约关联的客户端进行交互的时间。此时间与此服务器接收的时间完全相同，不得以任何方式进行调整。
start-time-of-state The time when the binding-status of this lease was changed to its current value.
状态的开始时间此租约的绑定状态更改为其当前值的时间。
state-expiration-time The time when the current state of this lease will expire.
state expiration time此租约的当前状态将到期的时间。
Every BNDUPD message contains information about either (1) a single client binding in an OPTION_CLIENT_DATA option that includes IAADDR or IAPREFIX options associated with that client or (2) a single prefix lease in an OPTION_IAPREFIX option for prefixes that are currently not associated with any clients.
每个BNDUPD消息都包含以下信息：（1）包含与该客户机关联的IAADDR或IAPREFIX选项的OPTION_client_数据选项中的单个客户机绑定，或（2）当前未与任何客户机关联的前缀的OPTION_IAPREFIX选项中的单个前缀租用。
All information about a particular client binding MUST be contained in a single OPTION_CLIENT_DATA option (see Section 4.1.2.2 of [RFC5007]). The OPTION_CLIENT_DATA option contains at least the data shown below in its client-options section:
关于特定客户机绑定的所有信息必须包含在单个选项\u客户机\u数据选项中（见[RFC5007]第4.1.2.2节）。选项_CLIENT _DATA选项至少包含其客户端选项部分中显示的以下数据：
o OPTION_CLIENTID containing the DUID of the client most recently associated with this lease MUST appear.
o 必须出现包含最近与此租约关联的客户端DUID的选项\u CLIENTID。
o OPTION_LQ_BASE_TIME containing the absolute time that the information was placed in this OPTION_CLIENT_DATA option (see Section 6.3.1 of [RFC7653]) MUST appear.
o 必须出现选项_LQ _BASE _TIME，其中包含信息放置在此选项_CLIENT _DATA选项中的绝对时间（参见[RFC7653]第6.3.1节）。
o OPTION_VSS (see Section 3.4 of [RFC6607]). This option MUST NOT appear if the information in this OPTION_CLIENT_DATA option is associated with the global, default VPN. This option MUST appear if the information in this OPTION_CLIENT_DATA option is associated with a VPN other than the global, default VPN. Support of [RFC6607] is not required, and if it is not supported, then an OPTION_VSS MUST NOT appear. If [RFC6607] is supported, then an OPTION_VSS MUST appear if and only if a VPN other than the global, default VPN is used.
o 选项_VSS（见[RFC6607]第3.4节）。如果此选项_CLIENT _DATA选项中的信息与全局默认VPN关联，则不得显示此选项。如果此选项_CLIENT _DATA选项中的信息与全局默认VPN以外的VPN关联，则必须显示此选项。不需要支持[RFC6607]，如果不支持该选项，则不得出现选项。如果支持[RFC6607]，则当且仅当使用了全局默认VPN以外的VPN时，必须显示选项_VSS。
o OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key, if any.
o 选项\u F\u重新配置\u包含时间和重新配置密钥的数据（如果有）。
o OPTION_LQ_RELAY_DATA containing information described in Section 4.1.2.4 of [RFC5007], if any exists.
o 包含[RFC5007]第4.1.2.4节所述信息的选项LQ继电器数据（如有）。
o OPTION_IA_NA or OPTION_IA_TA for an IPv6 address, or OPTION_IA_PD for an IPv6 prefix. More than one of either of these options MAY appear if more than one of them are associated with this client. At least one of an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD must appear.
o 用于IPv6地址的选项a\u NA或选项a\u TA，或用于IPv6前缀的选项a\u PD。如果这些选项中有多个与此客户端关联，则可能会出现多个选项。必须至少显示选项a\u NA、选项a\u TA或选项a\u PD中的一个。
* IAID - Identity Association used by the client, while obtaining a given lease. Note that (1) one client may use many IAIDs simultaneously and (2) IAIDs for OPTION_IA_NA, OPTION_IA_TA, and OPTION_IA_PD are orthogonal number spaces.
* IAID—客户端在获取给定租约时使用的标识关联。请注意，（1）一个客户机可能同时使用多个IAID，（2）选项_IA_NA、选项_IA_TA和选项_IA_PD的IAID是正交数空间。
* T1 time sent to client.
* T1发送到客户端的时间。
* T2 time sent to client.
* T2发送到客户端的时间。
* Inside of the IA_NA-options, IA_TA-options, or IA_PD-options sections:
* IA_NA-options、IA_TA-options或IA_PD-options部分的内部：
+ OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for an IPv6 prefix MUST appear.
+ 必须显示IPv6地址的选项\u IAADDR或IPv6前缀的选项\u IAPREFIX。
- IPv6 address or IPv6 prefix (with length).
- IPv6地址或IPv6前缀（带长度）。
- Preferred lifetime sent to client.
- 首选生存期发送到客户端。
- Valid lifetime sent to client.
- 发送到客户端的有效生存期。
- Inside of the IAaddr-options or IAprefix-options:
- IAaddr选项或IAprefix选项的内部：
o OPTION_F_BINDING_STATUS containing the binding-status MUST appear.
o 包含绑定状态的选项\u F\u BINDING\u STATUS必须出现。
o OPTION_F_START_TIME_OF_STATE containing the start-time-of-state MUST appear.
o 必须出现包含状态开始时间的状态选项“开始时间”。
o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time*.
o 包含状态过期时间*的选项\u F\u STATE\u EXPIRATION\u TIME（绝对值）。
o OPTION_CLT_TIME (relative) containing the client-last-transaction-time. See [RFC5007] for a description of this option.
o 包含客户端上次事务时间的选项\u CLT\u TIME（相对）。有关此选项的说明，请参见[RFC5007]。
o OPTION_F_PARTNER_LIFETIME (absolute) containing the partner-lifetime*.
o 包含合作伙伴生存期*的选项\u F\u合作伙伴\u生存期（绝对值）。
o OPTION_F_PARTNER_RAW_CLT_TIME (absolute) containing the partner-raw-clt-time.
o 包含合作伙伴原始CLT时间的选项\u F\u PARTNER\u RAW\u CLT\u TIME（绝对值）。
o OPTION_F_EXPIRATION_TIME (absolute) containing the expiration-time*.
o 包含过期时间*的选项\u F\u EXPIRATION\u TIME（绝对值）。
o OPTION_CLIENT_FQDN containing the FQDN information associated with this lease and client, if any.
o 选项\客户端\包含与此租约和客户端（如果有）关联的FQDN信息的FQDN。
Information about a prefix lease is contained in a single OPTION_IAPREFIX option. Only a single OPTION_IAPREFIX option may appear in a BNDUPD message outside of an OPTION_CLIENT_DATA option. In detail:
有关前缀租约的信息包含在单个选项中。在选项客户端数据选项之外的BNDUPD消息中只能出现一个选项前缀选项。详细内容：
o OPTION_IAPREFIX for a prefix lease.
o 选项\u为前缀租约指定前缀。
* IPv6 prefix (with length).
* IPv6前缀（带长度）。
* Inside of the IAprefix-options section:
* 在IAprefix选项部分的内部：
+ OPTION_VSS (see Section 3.4 of [RFC6607]). This option MUST NOT appear if the information in this OPTION_IAPREFIX option is associated with the global, default VPN. This option MUST appear if the information in this OPTION_IAPREFIX option is associated with a VPN other than the global, default VPN. Support of [RFC6607] is not required, and if it is not supported, then an OPTION_VSS MUST NOT appear. If [RFC6607] is supported, then an OPTION_VSS MUST appear if and only if a VPN other than the global, default VPN is used.
+ 选项_VSS（见[RFC6607]第3.4节）。如果此选项中的信息与全局默认VPN关联，则此选项不得出现。如果此选项中的信息与全局默认VPN以外的VPN相关联，则必须显示此选项。不需要支持[RFC6607]，如果不支持该选项，则不得出现选项。如果支持[RFC6607]，则当且仅当使用了全局默认VPN以外的VPN时，必须显示选项_VSS。
+ OPTION_LQ_BASE_TIME containing the absolute time that this information was placed in this OPTIONS_IAPREFIX option (see Section 6.3.1 of [RFC7653]) MUST appear.
+ 必须出现选项_LQ _BASE _TIME，其中包含将此信息放置在此选项中的绝对时间_前缀选项（见[RFC7653]第6.3.1节）。
+ OPTION_F_BINDING_STATUS containing the binding-status MUST appear.
+ 包含绑定状态的选项\u F\u BINDING\u STATUS必须出现。
+ OPTION_F_START_TIME_OF_STATE containing the start-time-of-state MUST appear.
+ 必须出现包含状态开始时间的状态选项“开始时间”。
+ OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time*.
+ 包含状态过期时间*的选项\u F\u STATE\u EXPIRATION\u TIME（绝对值）。
+ OPTION_F_PARTNER_LIFETIME (absolute) containing the partner-lifetime*.
+ 包含合作伙伴生存期*的选项\u F\u合作伙伴\u生存期（绝对值）。
+ OPTION_F_EXPIRATION_TIME (absolute) containing the expiration-time*.
+ 包含过期时间*的选项\u F\u EXPIRATION\u TIME（绝对值）。
Items marked with a single asterisk (*) MUST appear only if the value in the OPTION_F_BINDING_STATUS is associated with a timeout; otherwise, it MUST NOT appear. See Section 7.2 for details.
仅当选项绑定状态中的值与超时关联时，标有单个星号（*）的项目才能出现；否则，它不能出现。详见第7.2节。
The OPTION_CLT_TIME MUST, if it appears, be the time that the server last interacted with the DHCP client. It MUST NOT be, for instance, the time that the lease expired if there has been no interaction with the DHCP client in question.
选项_CLT_TIME（如果出现）必须是服务器上次与DHCP客户端交互的时间。例如，如果没有与所讨论的DHCP客户端进行交互，则该时间不得为租约到期的时间。
A server SHOULD be prepared to clean up DNS information once the lease expires or is released. See Section 9 for a detailed discussion about DNS update. Another reason the partner may be interested in keeping additional data is to enable better support for Leasequery [RFC5007], Bulk Leasequery [RFC5460], or Active Leasequery [RFC7653], some of which feature queries based on Relay-ID, link address, or Remote-ID.
一旦租约到期或解除，服务器应准备清理DNS信息。有关DNS更新的详细讨论，请参见第9节。合作伙伴可能有兴趣保留额外数据的另一个原因是为了更好地支持Leasequery[RFC5007]、批量Leasequery[RFC5460]或活动Leasequery[RFC7653]，其中一些功能基于中继ID、链路地址或远程ID进行查询。
The sent-time from the failover message is compared with the current time of the receiving server as recorded when it received the message. The difference is noted, and if it is greater than 5 seconds the receiving server SHOULD drop the connection. A message SHOULD be logged to signal the reason for the connection being dropped.
将故障转移消息的发送时间与接收服务器接收消息时记录的当前时间进行比较。注意差异，如果超过5秒，则接收服务器应断开连接。应记录一条消息，说明断开连接的原因。
Any time can be before, after, or essentially the same as another time. Any time that ends up being +/- 5 seconds of another time SHOULD be considered to be representing the same time when performing a comparison between two times.
任何时间都可以在另一个时间之前、之后，或者本质上与另一个时间相同。在进行两次比较时，任何最后为另一时间+/-5秒的时间应视为代表相同的时间。
Upon acceptance of a binding update, the server MUST notify its partner that it has processed the binding update (and updated its lease state database if necessary) by sending a BNDREPLY message. A server MUST NOT send the BNDREPLY message before its binding database is updated.
在接受绑定更新后，服务器必须通过发送BNDREPLY消息通知其合作伙伴已处理绑定更新（并在必要时更新其租约状态数据库）。在更新绑定数据库之前，服务器不得发送BNDREPLY消息。
When a BNDUPD message is received, it MUST contain either a single OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option.
接收到BNDUPD消息时，它必须包含单个选项\u客户端\u数据选项或单个选项\u前缀选项。
When analyzing a BNDUPD message from a partner server, if there is insufficient information in the BNDUPD message to process it, then it is rejected with an OPTION_STATUS_CODE of "MissingBindingInformation".
在分析来自合作伙伴服务器的BNDUPD消息时，如果BNDUPD消息中没有足够的信息来处理它，那么它将被拒绝，选项_STATUS_代码为“MissingBindingInformation”。
The server receiving a BNDUPD message from its partner must evaluate the received information in each OPTION_CLIENT_DATA or IAPREFIX option to see if it is consistent with the server's already-known state and, if it is not, decide to accept or reject the information. Section 7.5.4 provides details regarding how the server makes this determination.
从其合作伙伴接收BNDUPD消息的服务器必须评估每个选项\u CLIENT\u DATA或IAPREFIX选项中接收到的信息，以查看其是否与服务器的已知状态一致，如果不一致，则决定接受或拒绝该信息。第7.5.4节提供了有关服务器如何进行此确定的详细信息。
A server receiving a BNDUPD message MUST respond to the sender of that message with a BNDREPLY message that contains the same transaction-id as the BNDUPD message. This BNDREPLY message MUST contain either a single OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option, corresponding to whatever was received in the BNDUPD message.
接收BNDUPD消息的服务器必须使用包含与BNDUPD消息相同事务id的BNDREPLY消息响应该消息的发送方。此BNDREPLY消息必须包含一个选项\u CLIENT\u DATA选项或一个选项\u IAPREFIX选项，与BNDUPD消息中接收到的内容相对应。
An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the BNDREPLY message that is accepted SHOULD NOT contain an OPTION_STATUS_CODE unless a status message needs to be sent to the failover partner, in which case it SHOULD include an OPTION_STATUS_CODE option with a status-code indicating success and whatever message is needed.
BNDREPLY消息中已接受的OPTION_CLIENT_DATA选项或OPTION_IAPREFIX选项不应包含OPTION_STATUS_代码，除非需要将状态消息发送给故障切换伙伴，在这种情况下，它应包含OPTION_STATUS_代码选项，该选项的状态代码指示成功以及所需的任何消息。
To indicate rejection of the information in an OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option, an OPTION_STATUS_CODE SHOULD be included with a status-code indicating an error in the OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY message.
要指示拒绝选项\u客户机\u数据选项或选项\u IAPREFIX选项中的信息，应将选项\u状态\u代码与状态代码一起包含，状态代码指示BNDREPLY消息中的选项\u客户机\u数据选项或选项\u IAPREFIX选项中的错误。
The first task in processing the information in an OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is to extract the client information (if any) and lease information out of the option and to access the address lease or prefix lease information in the server's binding database.
处理OPTION_CLIENT_DATA OPTION或OPTION_IAPREFIX OPTION中的信息的第一个任务是从该选项中提取客户端信息（如果有）和租约信息，并访问服务器绑定数据库中的地址租约或前缀租约信息。
If an OPTION_VSS option is specified in the OPTION_CLIENT_DATA option or OPTION_IAPREFIX option and the VPN specified in the OPTION_VSS option does not appear in the configuration of the receiving server,
如果在选项_CLIENT _DATA选项或选项_IAPREFIX选项中指定了选项_VSS选项，并且在选项_VSS选项中指定的VPN未出现在接收服务器的配置中，
then reject the entire OPTION_CLIENT_DATA option or OPTION_IAPREFIX option by including an OPTION_STATUS_CODE option with a status-code of "ConfigurationConflict".
然后通过包含状态代码为“ConfigurationConflict”的选项状态代码选项，拒绝整个选项客户端数据选项或选项前缀选项。
If the lease specified in the OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is not a lease associated with the failover endpoint that received the OPTION_CLIENT_DATA option, then reject it by including an OPTION_STATUS_CODE option with a status-code of "ConfigurationConflict".
如果选项\u CLIENT\u DATA选项或选项\u IAPREFIX选项中指定的租约不是与接收选项\u CLIENT\u DATA选项的故障转移终结点关联的租约，则通过包含状态代码为“ConfigurationConflict”的选项\u STATUS\u CODE选项来拒绝该租约。
In general, acceptance or rejection is based on the comparison of two different time values -- one from the OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDUPD message, and one from the receiving server's binding database associated with the address or prefix lease found in the BNDUPD message. The time for the BNDUPD message where the OPTION_F_BINDING_STATUS is ACTIVE, EXPIRED, or RELEASED is the OPTION_CLT_TIME if one appears, or the OPTION_F_START_TIME_OF_STATE if one does not. For other binding-status values, the time for the BNDUPD message is the later of (1) the OPTION_CLT_TIME if one appears or (2) the OPTION_F_START_TIME_OF_STATE. The time for the lease in the server's binding database is the client-last-transaction-time if one appears, or the start-time-of-state if one does not.
一般来说，接受或拒绝基于两个不同时间值的比较——一个来自BNDUPD消息中的OPTION_CLIENT_DATA选项或OPTION_IAPREFIX选项，另一个来自与BNDUPD消息中的地址或前缀租约相关联的接收服务器绑定数据库。BNDUPD消息中选项“绑定”状态为“活动”、“过期”或“释放”的时间，如果出现，则为选项“关闭”时间；如果未出现，则为选项“启动”时间。对于其他绑定状态值，BNDUPD消息的时间是（1）选项\u CLT\u time（如果出现）或（2）选项\u F\u START\u time（状态）中的较晚者。服务器绑定数据库中的租约时间是客户端上次事务时间（如果出现），或者是状态开始时间（如果未出现）。
The basic approach is to compare these times, and if the one from the BNDUPD message is clearly later, then accept the information in the OPTION_CLIENT_DATA option or OPTION_IAPREFIX option. If the one from the server's binding database is clearly later, then reject the information in the BNDUPD message. The challenge comes when they are essentially the same (i.e., +/- 5 seconds). In this case, they are considered identical, despite the minor differences. Figure 4 shows a table containing the rules for dealing with all of these situations.
基本方法是比较这些时间，如果BNDUPD消息中的时间明显较晚，则接受选项\u CLIENT\u DATA选项或选项\u IAPREFIX选项中的信息。如果服务器的绑定数据库中的信息明显更晚，则拒绝BNDUPD消息中的信息。当它们基本相同时（即+/-5秒），挑战就来了。在这种情况下，它们被认为是相同的，尽管有细微的差异。图4显示了一个包含处理所有这些情况的规则的表。
binding-status in received OPTION_CLIENT_DATA
or OPTION_IAPREFIX
binding-status in
receiving server's FREE RESET
lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED
---------------------------------------------------------------------
ACTIVE accept(3) time(1) accept time(1) accept
EXPIRED accept accept accept accept accept
RELEASED accept accept accept accept accept
FREE/FREE-BACKUP accept accept accept accept accept
RESET time(2) accept accept accept accept
ABANDONED accept accept accept accept accept
binding-status in received OPTION_CLIENT_DATA
or OPTION_IAPREFIX
binding-status in
receiving server's FREE RESET
lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED
---------------------------------------------------------------------
ACTIVE accept(3) time(1) accept time(1) accept
EXPIRED accept accept accept accept accept
RELEASED accept accept accept accept accept
FREE/FREE-BACKUP accept accept accept accept accept
RESET time(2) accept accept accept accept
ABANDONED accept accept accept accept accept
Figure 4: Conflict Resolution
图4：冲突解决
accept: If the time value in the OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is later than the time value in the server's binding database, accept it, else reject it.
接受：如果选项\u CLIENT\u DATA选项或选项\u IAPREFIX选项中的时间值晚于服务器绑定数据库中的时间值，请接受它，否则拒绝它。
time(1): If the current time is later than the receiving server's state-expiration-time, accept it, else reject it.
时间（1）：如果当前时间晚于接收服务器的状态过期时间，则接受它，否则拒绝它。
time(2): If the OPTION_CLT_TIME value (if it appears) in the OPTION_CLIENT_DATA is later than the start-time-of-state in the receiving server's binding, accept it, else reject it.
时间（2）：如果选项\u CLIENT\u数据中的选项\u CLT\u time值（如果出现）晚于接收服务器绑定中状态的开始时间，则接受它，否则拒绝它。
accept,time(1),time(2): If rejecting, use a status-code of "OutdatedBindingInformation".
接受、时间（1）、时间（2）：如果拒绝，请使用状态代码“OutdatedBindingInformation”。
accept(3): If the clients in an OPTION_CLIENT_DATA option and in a receiving server's binding differ, then if time(2) or the receiving server is a secondary accept it, else reject it with a status-code of "AddressInUse". If the clients match, accept the update.
accept（3）：如果OPTION_CLIENT_DATA OPTION和接收服务器绑定中的客户端不同，则如果time（2）或接收服务器是辅助服务器，则接受它，否则拒绝它，状态代码为“AddressInUse”。如果客户端匹配，则接受更新。
The lease update may be accepted or rejected. If a lease is rejected with "OutdatedBindingInformation", then the flag in the lease that indicates that the partner should be updated with the information in this lease SHOULD be set; otherwise, it SHOULD NOT be changed. If this flag was previously not set, then an update MAY be transmitted immediately to the partner (though the BNDREPLY to this BNDUPD message SHOULD be sent first). If this flag was previously set, an update SHOULD NOT be transmitted immediately to the partner. In this case, an update will be sent during the next periodic scan, but not immediately, thus preventing a possible update storm should the servers be unable to agree. Ultimately, the server with the most recent binding information should have its update accepted by its partner.
可以接受或拒绝租约更新。如果使用“OutdatedBindingInformation”拒绝租约，则应设置租约中指示合作伙伴应使用此租约中的信息进行更新的标志；否则，就不应该改变。如果之前未设置此标志，则可立即向合作伙伴发送更新（尽管应首先发送此BNDUPD消息的BNDREPLY）。如果之前设置了此标志，则不应立即向合作伙伴发送更新。在这种情况下，更新将在下一次定期扫描期间发送，但不会立即发送，从而防止在服务器无法达成一致时可能出现的更新风暴。最终，具有最新绑定信息的服务器应该让其伙伴接受其更新。
When the information in an OPTION_CLIENT_DATA option or OPTION_IAPREFIX option has been accepted, some of that information is stored in the receiving server's binding database, and a corresponding OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is entered into a BNDREPLY message. The information to enter into the OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY message is described in Section 7.6.
当已接受OPTION_CLIENT_DATA OPTION或OPTION_IAPREFIX OPTION中的信息时，其中一些信息存储在接收服务器的绑定数据库中，相应的OPTION_CLIENT_DATA OPTION或OPTION_IAPREFIX OPTION被输入到BNDREPLY消息中。第7.6节描述了在BNDREPLY消息中输入选项_CLIENT_DATA选项或选项_IAPREFIX选项的信息。
The information contained in an accepted OPTION_CLIENT_DATA option is stored in the receiving server's binding database as follows:
接受选项_CLIENT _DATA选项中包含的信息存储在接收服务器的绑定数据库中，如下所示：
1. The OPTION_CLIENTID is used to find the client.
1. 选项_CLIENTID用于查找客户端。
2. The other data contained in the top level of the OPTION_CLIENT_DATA option is stored with the client as appropriate.
2. 选项_CLIENT _data选项顶层包含的其他数据将根据需要与客户端一起存储。
3. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD options in the OPTION_CLIENT_DATA option and for each of the OPTION_IAADDR or OPTION_IAPREFIX options in the IA_* options:
3. 对于OPTION_CLIENT_数据选项中的每个OPTION_IA_NA、OPTION_IA_TA或OPTION_IA_PD选项，以及IA_*选项中的每个OPTION_IAADDR或OPTION_IAPREFIX选项：
a. OPTION_F_BINDING_STATUS is stored as the binding-status.
a. 选项绑定状态存储为绑定状态。
b. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time.
b. 选项\u F\u合作伙伴\u生存期存储在到期时间中。
c. OPTION_F_STATE_EXPIRATION_TIME is stored in the state-expiration-time.
c. 选项_F_STATE _EXPIRATION _TIME存储在状态过期时间中。
d. OPTION_CLT_TIME [RFC5007] is stored in the partner-raw-clt-time.
d. 选项\u CLT\u TIME[RFC5007]存储在合作伙伴原始CLT TIME中。
e. OPTION_F_PARTNER_RAW_CLT_TIME replaces the client-last-transaction-time if it is later than the current client-last-transaction-time.
e. 如果客户上次交易时间晚于当前客户上次交易时间，则选项\u F\u PARTNER\u RAW\u CLT\u TIME将替换客户上次交易时间。
f. OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it is later than the current partner-lifetime.
f. 如果合作伙伴生存期晚于当前合作伙伴生存期，则选项\u F\u EXPIRATION\u TIME将替换合作伙伴生存期。
The information contained in an accepted single OPTION_IAPREFIX option that is not contained in an OPTION_CLIENT_DATA option is stored in the receiving server's binding database as follows:
接受的单个选项\u IAPREFIX选项中包含的信息（不包含在选项\u客户端\u数据选项中）存储在接收服务器的绑定数据库中，如下所示：
1. The IPv6 prefix is used to find the prefix.
1. IPv6前缀用于查找前缀。
2. Inside of the IAprefix-options section:
2. 在IAprefix选项部分的内部：
a. OPTION_F_BINDING_STATUS is stored as the binding-status.
a. 选项绑定状态存储为绑定状态。
b. OPTION_F_PARTNER_LIFETIME (if any) is stored in the expiration-time.
b. 选项_F_PARTNER_生存期（如果有）存储在过期时间中。
c. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the state-expiration-time.
c. 选项_F_STATE _EXPIRATION _TIME（如果有）存储在状态过期时间中。
d. OPTION_F_EXPIRATION_TIME (if any) replaces the partner-lifetime if it is later than the current partner-lifetime.
d. 如果合作伙伴生存期晚于当前合作伙伴生存期，则选项\u F\u EXPIRATION\u TIME（如果有）将替换合作伙伴生存期。
A server MUST respond to every BNDUPD message with a BNDREPLY message. The BNDREPLY message MUST contain an OPTION_CLIENT_DATA option if the BNDUPD message contained an OPTION_CLIENT_DATA option, or it MUST contain an OPTION_IAPREFIX option if the BNDUPD message contained an OPTION_IAPREFIX option. The BNDREPLY message MUST have the same transaction-id as the BNDUPD message to which it is a response.
服务器必须用BNDREPLY消息响应每个BNDUPD消息。如果BNDUPD消息包含OPTION_CLIENT_DATA选项，则BNDREPLY消息必须包含OPTION_CLIENT_DATA选项；如果BNDUPD消息包含OPTION_IAPREFIX选项，则必须包含OPTION_IAPREFIX选项。BNDREPLY消息必须与作为响应的BNDUPD消息具有相同的事务id。
Acceptance or rejection of all of or a particular part of the BNDUPD message is signaled with an OPTION_STATUS_CODE option. An OPTION_STATUS_CODE option containing a status-code representing an error is significant, while an OPTION_STATUS_CODE option whose status-code contains success is considered informational but does not affect the processing of the BNDREPLY message when it is received by the server that sent the BNDUPD message.
BNDUPD消息的全部或特定部分的接受或拒绝通过选项\状态\代码选项发出信号。包含表示错误的状态代码的选项_STATUS _CODE选项是重要的，而状态代码包含success的选项_STATUS _CODE选项被认为是信息性的，但在发送BNDUPD消息的服务器接收到BNDREPLY消息时不影响对其的处理。
Rejection of all of or part of the information in a BNDUPD message is signaled in a BNDREPLY message by using the OPTION_STATUS_CODE message with an error in the status-code field. This rejection can take place at either of two levels -- the top level of the option hierarchy or the bottom level of the option hierarchy:
拒绝BNDUPD消息中的全部或部分信息在BNDREPLY消息中通过使用选项_STATUS_CODE message（状态代码字段中有错误）发出信号。此拒绝可以在两个级别中的任意一个级别发生—选项层次结构的顶层或选项层次结构的底层：
1. Entire BNDUPD: The OPTION_STATUS_CODE containing an error is present in the outermost option of the BNDREPLY message -- either the single OPTION_CLIENT_DATA option or the single OPTION_IAPREFIX option. An example of this sort of error might be that an OPTION_VSS option was present and specified a VPN that might not exist in the receiving server.
1. 完整的BNDUPD：包含错误的选项\u状态\u代码出现在BNDREPLY消息的最外层选项中——单选项\u客户端\u数据选项或单选项\u前缀选项。此类错误的一个示例可能是存在一个选项\u VSS选项，并指定了一个接收服务器中可能不存在的VPN。
2. Single address or prefix: The OPTION_STATUS_CODE containing an error is present in a single IAADDR or IAPREFIX option that is itself contained in an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD option. An example of this sort of error might be that a particular IPv6 address was specified in an IAADDR option that doesn't appear in the receiving server's configuration.
2. 单个地址或前缀：包含错误的选项状态代码出现在单个IAADDR或IAPREFIX选项中，该选项本身包含在选项IA、选项IA或选项PD中。此类错误的一个示例可能是在接收服务器的配置中未出现的IAADDR选项中指定了特定IPv6地址。
Rejection occurring at either of these levels indicates rejection of all of the information contained in the option (including any other options contained in that option) where the OPTION_STATUS_CODE option containing an error appears. The converse is not true -- an OPTION_STATUS_CODE option containing success does not signify that all of the contained information has been accepted.
在这些级别发生的拒绝表示拒绝包含在选项中的所有信息（包括包含在该选项中的任何其他选项），其中出现包含错误的选项\状态\代码选项。反之亦然——包含success的选项\状态\代码选项并不表示所有包含的信息都已被接受。
If the BNDREPLY message contains an OPTION_CLIENT_DATA option, then the OPTION_CLIENT_DATA option MUST contain at least the data shown below in its client-options section:
如果BNDREPLY消息包含选项\u CLIENT\u DATA选项，则选项\u CLIENT\u DATA选项必须至少包含其CLIENT options部分中显示的数据：
o OPTION_CLIENTID containing the DUID of the client most recently associated with this IPv6 address.
o 选项\u CLIENTID，包含最近与此IPv6地址关联的客户端的DUID。
o OPTION_VSS from the BNDUPD message, if any.
o 来自BNDUPD消息的选项_VSS（如果有）。
o OPTION_IA_NA or OPTION_IA_TA for an IPv6 address or OPTION_IA_PD for an IPv6 prefix. More than one of either of these options MAY appear if there are more than one of them associated with this client.
o IPv6地址的OPTION_IA_NA或OPTION_IA_TA或IPv6前缀的OPTION_IA_PD。如果这些选项中有多个与此客户端关联，则可能会出现多个选项。
* Inside of the IA_NA-options, IA_TA-options, or IA_PD-options sections:
* IA_NA-options、IA_TA-options或IA_PD-options部分的内部：
+ OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for an IPv6 prefix.
+ IPv6地址的选项IAADDR或IPv6前缀的选项IAPREFIX。
- IPv6 address or IPv6 prefix (with length).
- IPv6地址或IPv6前缀（带长度）。
- Inside of the IAaddr-options or IAprefix-options:
- IAaddr选项或IAprefix选项的内部：
o OPTION_STATUS_CODE containing an error code, or containing a success code if a message is required. An OPTION_STATUS_CODE option SHOULD NOT appear with a success code unless a message associated with the success code needs to be included. The lack of an OPTION_STATUS_CODE option is an indication of success.
o 选项\状态\包含错误代码的代码，或者如果需要消息，则包含成功代码。选项\状态\代码选项不应与成功代码一起出现，除非需要包含与成功代码关联的消息。缺少选项\状态\代码选项表示成功。
o OPTION_F_BINDING_STATUS containing the binding-status received in the BNDUPD message.
o 选项_F_BINDING_STATUS包含在BNDUPD消息中接收到的绑定状态。
o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time received in the BNDUPD message.
o 选项_F_STATE_EXPIRATION_TIME（绝对值），包含在BNDUPD消息中接收到的状态过期时间。
o OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate of the OPTION_F_PARTNER_LIFETIME received in the BNDUPD message.
o 发送的选项\u F\u PARTNER\u LIFETIME\u（绝对）包含在BNDUPD消息中接收的选项\u F\u PARTNER\u LIFETIME的副本。
If the BNDREPLY message contains a single OPTION_IAPREFIX option not contained in an OPTION_CLIENT_DATA option, then the OPTION_IAPREFIX option MUST contain at least the data shown below:
如果BNDREPLY消息包含一个选项\u IAPREFIX选项，但该选项未包含在选项\u CLIENT\u DATA选项中，则选项\u IAPREFIX选项必须至少包含如下所示的数据：
o IPv6 prefix (with length).
o IPv6前缀（带长度）。
o IAprefix-options:
o IAprefix选项：
* OPTION_VSS from the BNDUPD message, if any.
* 来自BNDUPD消息的选项_VSS（如果有）。
* OPTION_STATUS_CODE containing an error code, or containing a success code if a message is required. If the information in the corresponding OPTION_IAPREFIX in the BNDUPD message was accepted and no status message was required (which is the usual case), no OPTION_STATUS_CODE option appears.
* 选项\状态\包含错误代码的代码，或者如果需要消息，则包含成功代码。如果BNDUPD消息中相应选项_IAPREFIX中的信息已被接受，并且不需要状态消息（通常情况下），则不会显示选项_status_CODE选项。
* OPTION_F_BINDING_STATUS containing the binding-status received in the BNDREPLY message.
* 选项_F_BINDING _STATUS包含在BNDREPLY消息中接收到的绑定状态。
* OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time received in the BNDREPLY message.
* 选项_F_STATE_EXPIRATION_TIME（绝对值），包含在BNDREPLY消息中接收到的状态过期时间。
* OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate of the OPTION_F_PARTNER_LIFETIME received in the BNDREPLY message.
* 发送的选项\u F\u PARTNER\u LIFETIME\u（绝对）包含在BNDREPLY消息中接收的选项\u F\u PARTNER\u LIFETIME的副本。
When a BNDREPLY message is received, the overall OPTION_CLIENT_DATA option or the overall OPTION_IAPREFIX option may contain an OPTION_STATUS_CODE containing an error that represents a rejection of the entire BNDUPD message. An enclosed OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD option may also contain an OPTION_STATUS_CODE containing an error that indicates that everything in the containing option has been rejected. Alternatively, an individual IAADDR or IAPREFIX option may contain an OPTION_STATUS_CODE option containing an error that indicates that the IAADDR or IAPREFIX option has been rejected. An OPTION_STATUS_CODE containing a success code has no bearing on the acceptance status of the BNDREPLY message at any level.
当接收到BNDREPLY消息时，全局选项_CLIENT _DATA选项或全局选项_IAPREFIX选项可能包含一个选项_STATUS _代码，其中包含一个表示拒绝整个BNDUPD消息的错误。封闭的选项\u IA\u NA、选项\u IA\u TA或选项\u IA\u PD选项也可能包含一个选项\u状态\u代码，该代码包含一个错误，表明包含选项中的所有内容都已被拒绝。或者，单个IAADDR或IAPREFIX选项可能包含选项_STATUS _CODE选项，该选项包含一个错误，指示IAADDR或IAPREFIX选项已被拒绝。包含成功代码的选项状态代码对任何级别的BNDREPLY消息的接受状态都没有影响。
Receipt of a rejection (or a part of a BNDREPLY message that has been rejected) requires no processing, other than remembering that it has been encountered.
接收拒绝（或已被拒绝的BNDREPLY消息的一部分）无需处理，只需记住已遇到拒绝。
The information contained in the BNDREPLY message in an OPTION_CLIENT_DATA that represents an acceptance is stored with the appropriate client and lease, as follows:
表示接受的选项_CLIENT_数据中的BNDREPLY消息中包含的信息与相应的客户端和租约一起存储，如下所示：
1. The OPTION_CLIENTID is used to find the client.
1. 选项_CLIENTID用于查找客户端。
2. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD options in the OPTION_CLIENT_DATA option and for each of the OPTION_IAADDR or OPTION_IAPREFIX options they contain:
2. 对于OPTION_CLIENT_数据选项中的每个OPTION_IA_NA、OPTION_IA_TA或OPTION_IA_PD选项以及每个OPTION_IAADDR或OPTION_IAPREFIX选项，它们包含：
a. OPTION_F_PARTNER_LIFETIME_SENT is stored in the acked-partner-lifetime.
a. 发送的选项\u F\u PARTNER\u LIFETIME\u存储在已确认的PARTNER LIFETIME中。
b. The partner-lifetime is set to 0 to indicate that no more information needs to be sent to the partner.
b. 合作伙伴生存期设置为0，表示无需向合作伙伴发送更多信息。
Alternatively, the BNDREPLY message may contain a single OPTION_IAPREFIX option not contained in an OPTION_CLIENT_DATA option, representing information concerning a single prefix lease. If the IAprefix-options section of the OPTION_IAPREFIX option contains an OPTION_STATUS_CODE representing an error, then it is considered a rejection of the corresponding BNDUPD message. If the OPTION_IAPREFIX option does not contain an OPTION_STATUS_CODE option or if the OPTION_STATUS_CODE option contains a success status, then the three items in the following list are stored in the lease state database, in the section associated with the prefix lease represented by the OPTION_IAPREFIX option.
或者，BNDREPLY消息可以包含不包含在OPTION\u CLIENT\u数据选项中的单个OPTION\u前缀选项，表示关于单个前缀租约的信息。如果OPTION_IAprefix选项的IAprefix options部分包含表示错误的OPTION_STATUS_代码，则视为拒绝相应的BNDUPD消息。如果选项\u IAPREFIX选项不包含选项\u STATUS\u CODE选项，或者选项\u STATUS\u CODE选项包含成功状态，则以下列表中的三项将存储在租约状态数据库中，存储在与选项\u IAPREFIX选项表示的前缀租约相关联的部分中。
1. OPTION_F_BINDING_STATUS containing the binding-status received in the BNDREPLY message.
1. 选项_F_BINDING _STATUS包含在BNDREPLY消息中接收到的绑定状态。
2. OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time received in the BNDREPLY message.
2. 选项_F_STATE_EXPIRATION_TIME（绝对值），包含在BNDREPLY消息中接收到的状态过期时间。
3. OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate of the OPTION_F_PARTNER_LIFETIME received in the BNDREPLY message.
3. 发送的选项\u F\u PARTNER\u LIFETIME\u（绝对）包含在BNDREPLY消息中接收的选项\u F\u PARTNER\u LIFETIME的副本。
Figure 5 shows the relationship of the times described in Section 7.3 to the options used to transmit them. It also relates the times on one failover partner to the other failover partner.
图5显示了第7.3节中描述的时间与用于传输时间的选项之间的关系。它还将一个故障切换伙伴的时间与另一个故障切换伙伴的时间关联起来。
----------------------- BNDUPD ---------------------------------
----------------------- BNDUPD ---------------------------------
Source on OPTION_F in Storage on
Sending Server -> BNDUPD message -> Receiving Server
Source on OPTION_F in Storage on
Sending Server -> BNDUPD message -> Receiving Server
[always update]
[始终更新]
partner-lifetime PARTNER_LIFETIME expiration-time
合作伙伴生命周期合作伙伴生命周期到期时间
client-last-transaction-time CLT_TIME partner-raw-clt-time start-time-of-state START_TIME_OF_STATE start-time-of-state state-expiration-time STATE_EXPIRATION_TIME state-expiration-time
客户端上次事务时间CLT\U时间合作伙伴原始CLT时间开始时间状态开始时间状态开始时间状态开始时间状态到期时间状态到期时间状态到期时间状态到期时间状态到期时间
[update only if received > current]
[仅在收到>当前时更新]
expiration-time EXPIRATION_TIME partner-lifetime partner-raw-clt-time PARTNER_RAW_CLT_TIME client-last-transaction-time
过期时间过期时间合作伙伴生存期合作伙伴原始clt时间合作伙伴原始clt时间客户上次交易时间
----------------------- BNDREPLY -------------------------------
----------------------- BNDREPLY -------------------------------
Storage on OPTION_F in Storage on Receiving Server <- BNDUPD message <- Sending Server
接收服务器上的存储中的选项F上的存储<-BNDUPD消息<-发送服务器
[always update]
[始终更新]
acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received PARTNER_LIFETIME (nothing to update) STATE_EXPIRATION_TIME state-expiration-time
已确认的合作伙伴生存期合作伙伴生存期发送的已接收合作伙伴的副本生存期（无需更新）状态到期时间状态到期时间
----------------------------------------------------------------
----------------------------------------------------------------
Figure 5: BNDUPD and BNDREPLY Time Handling
图5:BNDUPD和BNDREPLY时间处理
Each server (or, more accurately, failover endpoint) can take on a variety of failover states. These states play a crucial role in determining the actions that a server will perform when processing a request from a DHCP client as well as dealing with changing external conditions (e.g., loss of connection to a failover partner).
每个服务器（或者更准确地说，故障转移端点）都可以具有各种故障转移状态。这些状态在确定服务器在处理来自DHCP客户端的请求以及处理不断变化的外部条件（例如，与故障切换伙伴的连接中断）时将执行的操作方面起着至关重要的作用。
The failover state in which a server is running controls the following behaviors:
服务器运行时的故障转移状态控制以下行为：
o Responsiveness - the server is either responsive to DHCP client requests, renew responsive, or unresponsive.
o 响应-服务器响应DHCP客户端请求、续订响应或无响应。
o Allocation Pool - which pool of addresses (or prefixes) can be used for advertisement on receipt of a SOLICIT or allocation on receipt of a REQUEST, RENEW, or REBIND message.
o 分配池-哪一个地址池（或前缀）可在收到请求时用于广告，或在收到请求、续订或重新绑定消息时用于分配。
o MCLT - ensure that valid lifetimes are not beyond what the partner has acked plus the MCLT (unless the failover state doesn't require this restriction).
o MCLT-确保有效生存期不超过合作伙伴已确认的时间加上MCLT（除非故障转移状态不需要此限制）。
A server will transition from one failover state to another based on the specific values held by the following state variables:
服务器将根据以下状态变量持有的特定值从一种故障切换状态转换到另一种故障切换状态：
o Current failover state.
o 当前故障转移状态。
o Communications status ("OK" or not "OK").
o 通信状态（“正常”或“不正常”）。
o Partner's failover state (if known).
o 合作伙伴的故障转移状态（如果已知）。
Whenever any of the above state variables change state, the state machine is invoked, which may then trigger a change in the current failover state. Thus, whenever the communications status changes, the state machine processing is invoked. This may or may not result in a change in the current failover state.
每当上述任何状态变量更改状态时，都会调用状态机，从而触发当前故障转移状态的更改。因此，每当通信状态改变时，就会调用状态机处理。这可能会也可能不会导致当前故障切换状态的更改。
Whenever a server transitions to a new failover state, the new state MUST be communicated to its failover partner in a STATE message if the communications status is "OK". In addition, whenever a server makes a transition into a new state, it MUST record the new state, its current understanding of its partner's state, and the time at which it entered the new state in stable storage.
每当服务器转换到新的故障转移状态时，如果通信状态为“OK”，则必须在状态消息中将新状态传送给其故障转移伙伴。此外，每当服务器转换到新状态时，它都必须在稳定存储中记录新状态、对伙伴状态的当前理解以及进入新状态的时间。
The state transition diagram below (Figure 6) gives a condensed view of the state machine. If there are any differences between text describing a particular state and the information shown in Figure 6, the text should be considered authoritative.
下面的状态转换图（图6）给出了状态机的简明视图。如果描述特定状态的文本与图6中所示的信息之间存在任何差异，则应认为该文本具有权威性。
In Figure 6, the terms "responsive", "r-responsive", and "unresponsive" appear in the states and refer to whether the server in the indicated state is allowed to be responsive, renew responsive, or unresponsive, respectively. The "+", "-", or "*" in the upper right corner of each state is a notation about whether communication is ongoing with the other server, with "+" meaning that communications are "OK", "-" meaning that communications are interrupted, and "*" meaning that communications may be either "OK" or interrupted.
在图6中，术语“responsive”、“r-responsive”和“unresponsive”出现在状态中，分别指处于指示状态的服务器是否允许响应、续订响应或无响应。每个状态右上角的“+”、“-”或“*”表示是否正在与另一台服务器进行通信，“+”表示通信正常，“-”表示通信中断，“*”表示通信可能正常或中断。
+---------------+ V +--------------+
| RECOVER * | | | STARTUP - |
|(unresponsive) | +->+(unresponsive)|
+------+--------+ +--------------+
+-Comm. OK +-----------------+
| Other State: | PARTNER-DOWN - +<---------------------+
| RESOLUTION-INTER. | (responsive) | ^
All POTENTIAL- +----+------------+ |
Others CONFLICT------------ | --------+ |
| CONFLICT-DONE Comm. OK | +--------------+ |
UPDREQ or Other State: | +--+ RESOLUTION - | |
UPDREQALL | | | | | INTERRUPTED | |
Rcv UPDDONE RECOVER All | | | (responsive) | |
| +---------------+ | Others | | +------+-----+-+ |
+->+RECOVER-WAIT * | RECOVER- | | | ^ | |
|(unresponsive) | WAIT or | | Comm. | Ext. |
+-----------+---+ DONE | | OK Comm. Cmd---->+
Comm.---+ Wait MCLT | V V V Failed |
Changed | V +---+ +---+-----+--+-+ | |
| +---+----------++ | | POTENTIAL + +-------+ |
| |RECOVER-DONE * | Wait | CONFLICT +------+ |
+->+(unresponsive) | for |(unresponsive)| Primary |
+------+--------+ Other +>+----+--------++ resolve Comm. |
Comm. OK State: | | ^ conflict Changed|
+---Other State:-+ RECOVER- | Secondary | V V | |
| | | DONE | resolve | +----+-------+--++ |
| All Others: POTENT. | | conflict | |CONFLICT-DONE * | |
| Wait for CONFLICT--|-----+ | | | (responsive) | |
| Other State: V V | +-------+--------+ |
| NORMAL or RECOVER- ++------------+---+ | Other State: NORMAL |
| | DONE | NORMAL + +<--------------+ |
| +--+----------+-->+ pri: responsive +-------External Command-->+
| ^ ^ |sec: r-responsive| | |
| | | +--------+--------+ | |
| | | | | |
| Wait for Comm. OK Comm. Failed | External
| Other Other | | Command
| State: State: Start Auto | or
| RECOVER-DONE NORMAL Partner Down Comm. OK Auto
| | COMM.-INT. Timer Other State: Partner
| Comm. OK | V All Others Down
| Other State: | +---------+--------+ | expiration
| RECOVER +--+ COMMUNICATIONS - +----+ |
| +-------------+ INTERRUPTED | |
RECOVER | (responsive) +------------------------->+
RECOVER-WAIT--------->+------------------+
+---------------+ V +--------------+
| RECOVER * | | | STARTUP - |
|(unresponsive) | +->+(unresponsive)|
+------+--------+ +--------------+
+-Comm. OK +-----------------+
| Other State: | PARTNER-DOWN - +<---------------------+
| RESOLUTION-INTER. | (responsive) | ^
All POTENTIAL- +----+------------+ |
Others CONFLICT------------ | --------+ |
| CONFLICT-DONE Comm. OK | +--------------+ |
UPDREQ or Other State: | +--+ RESOLUTION - | |
UPDREQALL | | | | | INTERRUPTED | |
Rcv UPDDONE RECOVER All | | | (responsive) | |
| +---------------+ | Others | | +------+-----+-+ |
+->+RECOVER-WAIT * | RECOVER- | | | ^ | |
|(unresponsive) | WAIT or | | Comm. | Ext. |
+-----------+---+ DONE | | OK Comm. Cmd---->+
Comm.---+ Wait MCLT | V V V Failed |
Changed | V +---+ +---+-----+--+-+ | |
| +---+----------++ | | POTENTIAL + +-------+ |
| |RECOVER-DONE * | Wait | CONFLICT +------+ |
+->+(unresponsive) | for |(unresponsive)| Primary |
+------+--------+ Other +>+----+--------++ resolve Comm. |
Comm. OK State: | | ^ conflict Changed|
+---Other State:-+ RECOVER- | Secondary | V V | |
| | | DONE | resolve | +----+-------+--++ |
| All Others: POTENT. | | conflict | |CONFLICT-DONE * | |
| Wait for CONFLICT--|-----+ | | | (responsive) | |
| Other State: V V | +-------+--------+ |
| NORMAL or RECOVER- ++------------+---+ | Other State: NORMAL |
| | DONE | NORMAL + +<--------------+ |
| +--+----------+-->+ pri: responsive +-------External Command-->+
| ^ ^ |sec: r-responsive| | |
| | | +--------+--------+ | |
| | | | | |
| Wait for Comm. OK Comm. Failed | External
| Other Other | | Command
| State: State: Start Auto | or
| RECOVER-DONE NORMAL Partner Down Comm. OK Auto
| | COMM.-INT. Timer Other State: Partner
| Comm. OK | V All Others Down
| Other State: | +---------+--------+ | expiration
| RECOVER +--+ COMMUNICATIONS - +----+ |
| +-------------+ INTERRUPTED | |
RECOVER | (responsive) +------------------------->+
RECOVER-WAIT--------->+------------------+
Figure 6: Failover Endpoint State Machine
图6：故障转移端点状态机
The state machine is characterized by storage (in stable storage) of at least the following information:
状态机的特点是至少存储（稳定存储）以下信息：
o Current failover state.
o 当前故障转移状态。
o Previous failover state.
o 以前的故障转移状态。
o Start time of current failover state.
o 当前故障转移状态的开始时间。
o Partner's failover state.
o 伙伴的故障转移状态。
o Start time of partner's failover state.
o 合作伙伴故障转移状态的开始时间。
o Time most recent message received from partner.
o 从合作伙伴处收到的最新消息的时间。
The state machine is initialized by reading these data items from stable storage and restoring their values from the information saved. If there is no information in stable storage concerning these items, then they should be initialized as follows:
状态机是通过从稳定存储器中读取这些数据项并从保存的信息中恢复它们的值来初始化的。如果稳定存储器中没有关于这些项目的信息，则应按如下方式对其进行初始化：
o Current failover state: Primary: PARTNER-DOWN, Secondary: RECOVER.
o 当前故障转移状态：主：伙伴关闭，辅助：恢复。
o Previous failover state: None.
o 以前的故障转移状态：无。
o Start time of current failover state: Current time.
o 当前故障转移状态的开始时间：当前时间。
o Partner's failover state: None until reception of STATE message.
o 合作伙伴的故障转移状态：在收到状态消息之前无。
o Start time of partner's failover state: None until reception of STATE message.
o 伙伴故障转移状态的开始时间：在收到状态消息之前无。
o Time most recent message received from partner: None until message received.
o 从合作伙伴收到的最新消息的时间：在收到消息之前无。
The STARTUP state affords an opportunity for a server to probe its partner server before starting to service DHCP clients. When in the STARTUP state, a server attempts to learn its partner's state and determine (using that information if it is available) what state it should enter.
启动状态为服务器提供了在开始为DHCP客户端提供服务之前探测其伙伴服务器的机会。处于启动状态时，服务器会尝试了解其合作伙伴的状态，并确定（如果可用，则使用该信息）应进入的状态。
The STARTUP state is not shown with any specific state transitions in the state machine diagram (Figure 6) because the processing during the STARTUP state can cause the server to transition to any of the other states, so that specific state transition arcs would only obscure other information.
启动状态在状态机图（图6）中没有显示任何特定的状态转换，因为启动状态期间的处理可能会导致服务器转换到任何其他状态，因此特定的状态转换弧只会掩盖其他信息。
The server MUST NOT be responsive to DHCP clients in STARTUP state.
服务器不得在启动状态下响应DHCP客户端。
Whenever a STATE message is sent to the partner while in STARTUP state, the STARTUP flag MUST be set in the OPTION_F_SERVER_FLAGS option and the previously recorded failover state MUST be placed in the OPTION_F_SERVER_STATE option, each of which is included in the STATE message.
无论何时在启动状态下向合作伙伴发送状态消息，都必须在选项\u F_服务器\u标志选项中设置启动标志，并且之前记录的故障转移状态必须放置在选项\u F_服务器\u状态选项中，每个选项都包含在状态消息中。
The algorithm below is followed every time the server initializes itself and enters STARTUP state.
每次服务器初始化并进入启动状态时，都会遵循下面的算法。
The variables PREVIOUS-STATE and CURRENT-STATE are defined for use in the algorithm description below. PREVIOUS-STATE is simply for storage of a state, while CURRENT-STATE not only stores the current state but also changes the current state of the failover endpoint to whatever state is set in CURRENT-STATE.
变量PREVIOUS-STATE和CURRENT-STATE定义用于下面的算法描述。PREVIOUS-STATE仅用于存储状态，而CURRENT-STATE不仅存储当前状态，还将故障转移端点的当前状态更改为当前状态中设置的任何状态。
Step 1: If there is any record of a previous failover state in stable storage for this server, then set the PREVIOUS-STATE to the last recorded value in stable storage and the TIME-OF-FAILURE to the time the server failed or a time beyond which the server could not have been operating, and go to Step 2.
步骤1：如果此服务器的稳定存储中存在以前故障转移状态的任何记录，则将previous-state设置为稳定存储中上次记录的值，并将故障时间设置为服务器发生故障的时间或服务器无法运行的时间，然后转到步骤2。
If there is no record of any previous failover state in stable storage for this server, then set the PREVIOUS-STATE to RECOVER, and set the TIME-OF-FAILURE to 0. This will allow two servers that already have lease information to synchronize themselves prior to operating.
如果此服务器的稳定存储中没有任何以前故障转移状态的记录，请将以前的状态设置为“恢复”，并将故障时间设置为0。这将允许两台已经拥有租约信息的服务器在运行之前进行同步。
In some cases, an existing server will be commissioned as a failover server and brought back into operation when its partner is not yet available. In this case, the newly commissioned failover server will not operate until its partner comes online -- but it has operational responsibilities as a DHCP server nonetheless. To properly handle this situation, a server SHOULD be configurable in such a way as to move directly into PARTNER-DOWN state after the startup period expires if it has been unable to contact its partner during the startup period.
在某些情况下，现有服务器将作为故障转移服务器进行调试，并在其合作伙伴尚不可用时恢复运行。在这种情况下，新委托的故障转移服务器在其合作伙伴联机之前不会运行，但它作为DHCP服务器仍负有运行责任。为了正确处理这种情况，服务器应该可以这样配置：如果在启动期间无法联系其合作伙伴，则在启动期间到期后，服务器应直接进入合作伙伴关闭状态。
Step 2: Implementations will differ in the ways that they deal with the state machine for failover endpoint states. In many cases, state transitions will occur when communications go from "OK" to failed or from failed to "OK", and some implementations will implement a portion of their state machine processing based on these changes.
步骤2：实现将在处理故障转移端点状态的状态机的方式上有所不同。在许多情况下，当通信从“正常”变为失败或从失败变为“正常”时，会发生状态转换，一些实现将基于这些更改实现其状态机处理的一部分。
In these cases, during startup, if the PREVIOUS-STATE is one where communications were "OK", then set the PREVIOUS-STATE to the state that is the result of the communication failed state transition when in that state (if such a transition exists -- some states don't have a communication failed state transition, since they allow both "communications OK" and "failed").
在这些情况下，在启动过程中，如果前一个状态是通信“正常”的状态，则将前一个状态设置为处于该状态时通信失败状态转换的结果状态（如果存在这种转换，则有些状态不具有通信失败状态转换，因为它们同时允许通信失败状态转换）“通信正常”和“故障”）。
Step 3: Start the STARTUP state timer. The time that a server remains in the STARTUP state (absent any communications with its partner) is implementation dependent but SHOULD be short. It SHOULD be long enough for a TCP connection to a heavily loaded partner to be created across a slow network.
步骤3：启动启动状态计时器。服务器保持启动状态的时间（没有与其伙伴进行任何通信）取决于实现，但应该很短。它应该足够长，以便通过慢速网络创建到重载伙伴的TCP连接。
Step 4: If the server is a primary server, attempt to create a TCP connection to the failover partner. If the server is a secondary server, listen on the failover port and wait for the primary server to connect. See Section 6.1.
步骤4：如果服务器是主服务器，请尝试创建到故障转移伙伴的TCP连接。如果服务器是辅助服务器，请侦听故障转移端口并等待主服务器连接。见第6.1节。
Step 5: Wait for "communications OK".
步骤5：等待“通讯正常”。
When and if communications become "OK", clear the STARTUP flag, and set the CURRENT-STATE to the PREVIOUS-STATE.
当通信变为“正常”时，清除启动标志，并将当前状态设置为前一状态。
If the partner is in PARTNER-DOWN state and if the time at which it entered PARTNER-DOWN state (as received in the OPTION_F_START_TIME_OF_STATE option in the STATE message) is later than the last recorded time of operation of this server, then set CURRENT-STATE to RECOVER. If the time at which it entered PARTNER-DOWN state is earlier than the last recorded time of operation of this server, then set CURRENT-STATE to POTENTIAL-CONFLICT.
如果合作伙伴处于合作伙伴关闭状态，并且其进入合作伙伴关闭状态的时间（在状态消息中的选项\u F\u START\u time\u OF\u state选项中接收）晚于此服务器上次记录的操作时间，则将当前状态设置为恢复。如果进入伙伴关闭状态的时间早于此服务器上次记录的运行时间，则将当前状态设置为潜在冲突。
Then, transition to the CURRENT-STATE and take the "communications OK" state transition based on the CURRENT-STATE of this server and the partner.
然后，转换到当前状态，并根据此服务器和伙伴的当前状态进行“通信正常”状态转换。
Step 6: If the startup time expires prior to communications becoming "OK", the server SHOULD transition to PREVIOUS-STATE.
步骤6：如果启动时间在通信变为“正常”之前过期，服务器应转换到前一状态。
PARTNER-DOWN state is a state either server can enter. When in this state, the server assumes that it is the only server operating and serving the client base. If one server is in PARTNER-DOWN state, the other server MUST NOT be operating.
伙伴关闭状态是服务器可以进入的状态。处于此状态时，服务器假定它是唯一一个操作和服务于客户端的服务器。如果一台服务器处于伙伴关闭状态，则另一台服务器不得运行。
A server can enter PARTNER-DOWN state as a result of either (1) operator intervention (when an operator determines that the server's partner is, indeed, down) or (2) an optional auto-partner-down capability where PARTNER-DOWN state is entered automatically after a server has been in COMMUNICATIONS-INTERRUPTED state for a predetermined period of time.
由于（1）操作员干预（当操作员确定服务器的伙伴确实停机时）或（2）的结果，服务器可以进入伙伴停机状态一种可选的自动伙伴关闭功能，在服务器处于通信中断状态达预定时间段后，自动进入伙伴关闭状态。
The server MUST be responsive in PARTNER-DOWN state, regardless of whether it is primary or secondary.
服务器必须在伙伴关闭状态下响应，无论它是主服务器还是辅助服务器。
It will allow renewal of all outstanding leases.
它将允许续签所有未完成的租约。
For delegable prefixes, the server will allocate leases from its own pool, and after a fixed period of time (the MCLT interval) has elapsed from entry into PARTNER-DOWN state, it may allocate delegable prefixes from the set of all available pools. The server MUST fully deplete its own pool before starting allocations from its downed partner's pool.
对于可删除前缀，服务器将从其自己的池中分配租约，并且在从进入PARTNER-DOWN状态经过固定时间段（MCLT间隔）后，它可以从所有可用池集中分配可删除前缀。服务器必须先完全耗尽自己的池，然后才能从其宕机伙伴的池开始分配。
IPv6 addresses available for independent allocation by the other server (upon entering PARTNER-DOWN state) SHOULD NOT be allocated to a client. If one elects to do so anyway, they MUST NOT be allocated to a new client until the MCLT beyond the entry into PARTNER-DOWN state has elapsed.
可由其他服务器独立分配的IPv6地址（在进入伙伴关闭状态时）不应分配给客户端。如果选择这样做，则在进入合作伙伴关闭状态之后的MCLT结束之前，不得将其分配给新客户端。
A server in PARTNER-DOWN state MUST NOT allocate a lease to a DHCP client different from the client to which it was allocated at the time of entry into PARTNER-DOWN state until the MCLT beyond the maximum of the following times: client expiration time, most recently transmitted partner-lifetime, most recently received ack of the partner-time from the partner, and most recently acked partner-lifetime to the partner. If this time would be earlier than the current time plus the MCLT, then the time the server entered PARTNER-DOWN state plus the MCLT is used.
处于伙伴关闭状态的服务器不得将租约分配给与进入伙伴关闭状态时分配给的客户端不同的DHCP客户端，直到MCLT超过以下时间的最大值：客户端过期时间、最近传输的伙伴生存期、，最近收到来自合作伙伴的合作伙伴时间确认，最近收到来自合作伙伴的合作伙伴生命周期确认。如果此时间早于当前时间加上MCLT，则使用服务器进入伙伴关闭状态加上MCLT的时间。
The server is not restricted by the MCLT when offering valid lifetimes while in PARTNER-DOWN state.
在伙伴关闭状态下提供有效生存期时，服务器不受MCLT的限制。
In the unlikely case when there are two servers operating in PARTNER-DOWN state, there is a chance that duplicate leases for the same prefix could be assigned. This leads to a POTENTIAL-CONFLICT (unresponsive) state when the servers reestablish contact. This issue of duplicate leases can be prevented as long as the server grants new leases from its own pool; therefore, the server operating in PARTNER-DOWN state MUST use its own pool first for new leases before assigning any leases from its downed partner's pool.
在不太可能的情况下，当有两台服务器在合作伙伴关闭状态下运行时，可能会为同一前缀分配重复的租约。当服务器重新建立联系时，这会导致潜在的冲突（无响应）状态。只要服务器从其自己的池中授予新租约，就可以防止重复租约的问题；因此，在伙伴关闭状态下运行的服务器必须先使用自己的池进行新租约，然后再从其已关闭伙伴的池中分配任何租约。
When a server in PARTNER-DOWN state succeeds in establishing a connection to its partner, its actions are conditional on the state and flags received in the STATE message from the other server as part of the process of establishing the connection.
当处于伙伴关闭状态的服务器成功建立与其伙伴的连接时，其操作取决于作为建立连接过程的一部分从另一台服务器收到的状态消息中的状态和标志。
If the STARTUP bit is set in the OPTION_F_SERVER_FLAGS option of a received STATE message, a server in PARTNER-DOWN state MUST NOT take any state transitions based on reestablishing communications. If a server is in PARTNER-DOWN state, it ignores all STATE messages from its partner that have the STARTUP bit set in the OPTION_F_SERVER_FLAGS option of the STATE message.
如果在接收到的状态消息的选项\u F\u SERVER\u FLAGS选项中设置了启动位，则处于伙伴关闭状态的服务器不得基于重新建立通信进行任何状态转换。如果服务器处于伙伴关闭状态，它将忽略来自其伙伴的所有状态消息，这些消息在状态消息的选项\u F\u server\u FLAGS选项中设置了启动位。
If the STARTUP bit is not set in the OPTION_F_SERVER_FLAGS option of a STATE message received from its partner, then a server in PARTNER-DOWN state takes the following actions, based on the state of the partner as received in a STATE message (either immediately after establishing communications or at any time later when a new state is received):
如果未在从其伙伴接收的状态消息的选项\u F\u SERVER\u FLAGS选项中设置启动位，则处于伙伴关闭状态的服务器将根据在状态消息中接收到的伙伴状态（在建立通信后立即或在接收到新状态后的任何时间）采取以下操作：
o If the partner is in NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN, POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or CONFLICT-DONE state, then transition to POTENTIAL-CONFLICT state.
o 如果合作伙伴处于正常、通信中断、合作伙伴关闭、潜在冲突、解决中断或冲突结束状态，则转换为潜在冲突状态。
o If the partner is in RECOVER or RECOVER-WAIT state, then stay in PARTNER-DOWN state.
o 如果伙伴处于恢复或恢复等待状态，则保持伙伴关闭状态。
o If the partner is in RECOVER-DONE state, then transition to NORMAL state.
o 如果合作伙伴处于恢复完成状态，则转换到正常状态。
This state indicates that the server has no information in its stable storage or that it is reintegrating with a server in PARTNER-DOWN state after it has been down. A server in this state MUST attempt to refresh its stable storage from the other server.
此状态表示服务器的稳定存储中没有任何信息，或者在服务器关闭后，它正在与处于伙伴关闭状态的服务器重新集成。处于此状态的服务器必须尝试从其他服务器刷新其稳定存储。
The server MUST NOT be responsive in RECOVER state.
服务器在恢复状态下不能响应。
A server in RECOVER state will attempt to reestablish communications with the other server.
处于恢复状态的服务器将尝试重新建立与其他服务器的通信。
If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or CONFLICT-DONE state when communications are reestablished, then the server in RECOVER state will move itself to POTENTIAL-CONFLICT state.
如果在重新建立通信时，另一台服务器处于潜在冲突、解决中断或冲突结束状态，则处于恢复状态的服务器将自身移动到潜在冲突状态。
If the other server is in any other state, then the server in RECOVER state will request an update of missing binding information by sending an UPDREQ message. If the server has determined that it has lost its stable storage because it has no record of ever having talked to its partner even though its partner does have a record of communicating with it, it MUST send an UPDREQALL message; otherwise, it MUST send an UPDREQ message.
如果另一台服务器处于任何其他状态，则处于恢复状态的服务器将通过发送UPDREQ消息请求更新丢失的绑定信息。如果服务器已确定其已丢失其稳定存储，因为即使其合作伙伴确实有与其通信的记录，它也没有与其合作伙伴交谈的记录，则它必须发送UPDREQALL消息；否则，它必须发送UPDREQ消息。
It will wait for an UPDDONE message, and upon receipt of that message it will transition to RECOVER-WAIT state.
它将等待UPDDONE消息，收到该消息后将转换为恢复等待状态。
If communication fails during the reception of the results of the UPDREQ or UPDREQALL message, the server will remain in RECOVER state and will reissue the UPDREQ or UPDREQALL message when communications are reestablished.
如果在接收UPDREQ或UPDREQALL消息的结果期间通信失败，服务器将保持恢复状态，并在重新建立通信时重新发出UPDREQ或UPDREQALL消息。
If an UPDDONE message isn't received within an implementation-dependent amount of time and no BNDUPD messages are being received, the connection SHOULD be dropped.
如果在与实现相关的时间内未收到UPDDONE消息，并且未收到BNDUPD消息，则应断开连接。
A B Server Server
B服务器
| |
RECOVER PARTNER-DOWN
| |
| >--UPDREQ--------------------> |
| |
| <---------------------BNDUPD--< |
| >--BNDREPLY------------------> |
... ...
| |
| <---------------------BNDUPD--< |
| >--BNDREPLY------------------> |
| |
| <--------------------UPDDONE--< |
| |
RECOVER-WAIT |
| |
| >--STATE-(RECOVER-WAIT)------> |
| |
| |
Wait MCLT from last known |
time of failover operation |
| |
RECOVER-DONE |
| |
| >--STATE-(RECOVER-DONE)------> |
| NORMAL
| <-------------(NORMAL)-STATE--< |
NORMAL |
| >---- State-(NORMAL)---------------> |
| |
| |
| |
RECOVER PARTNER-DOWN
| |
| >--UPDREQ--------------------> |
| |
| <---------------------BNDUPD--< |
| >--BNDREPLY------------------> |
... ...
| |
| <---------------------BNDUPD--< |
| >--BNDREPLY------------------> |
| |
| <--------------------UPDDONE--< |
| |
RECOVER-WAIT |
| |
| >--STATE-(RECOVER-WAIT)------> |
| |
| |
Wait MCLT from last known |
time of failover operation |
| |
RECOVER-DONE |
| |
| >--STATE-(RECOVER-DONE)------> |
| NORMAL
| <-------------(NORMAL)-STATE--< |
NORMAL |
| >---- State-(NORMAL)---------------> |
| |
| |
Figure 7: Transition out of RECOVER State
图7：脱离恢复状态的转换
If at any time while a server is in RECOVER state communication fails, the server will stay in RECOVER state. When communications are restored, it will restart the process of transitioning out of RECOVER state.
如果在服务器处于恢复状态的任何时候通信失败，服务器将保持恢复状态。恢复通信后，它将重新启动从恢复状态过渡的过程。
This state indicates that the server has sent an UPDREQ or UPDREQALL message and has received the UPDDONE message indicating that it has received all outstanding binding update information. In the RECOVER-WAIT state, the server will wait for the MCLT in order to ensure that any processing that this server might have done prior to losing its stable storage will not cause future difficulties.
此状态表示服务器已发送UPDREQ或UPDREQALL消息，并已收到UPDDONE消息，表示已收到所有未完成的绑定更新信息。在RECOVER-WAIT状态下，服务器将等待MCLT，以确保此服务器在丢失其稳定存储之前可能进行的任何处理不会导致将来的问题。
The server MUST NOT be responsive in RECOVER-WAIT state.
服务器在恢复等待状态下不能响应。
Upon entry into RECOVER-WAIT state, the server MUST start a timer whose expiration is set to a time equal to the time the server went down (the TIME-OF-FAILURE from Section 8.3.2), if known, or the time the server started (if the TIME-OF-FAILURE is unknown), plus the MCLT. When this timer expires, the server will transition into RECOVER-DONE state.
进入RECOVER-WAIT状态后，服务器必须启动一个计时器，其过期时间设置为等于服务器停机时间（第8.3.2节中的故障时间），如果已知，或服务器启动时间（如果故障时间未知），加上MCLT。此计时器过期时，服务器将转换为恢复完成状态。
This allows any IPv6 addresses or prefixes that were allocated by this server prior to the loss of its client binding information in stable storage to contact the other server or to time out.
这允许此服务器在稳定存储中丢失其客户端绑定信息之前分配的任何IPv6地址或前缀与其他服务器联系或超时。
If the server has never before run failover, then there is no need to wait in this state, and the server MAY transition immediately to RECOVER-DONE state. However, to determine if this server has run failover, it is vital that the information provided by the partner be utilized, since the stable storage of this server may have been lost.
如果服务器以前从未运行过故障转移，则无需在此状态下等待，并且服务器可能会立即转换到恢复完成状态。但是，要确定此服务器是否已运行故障转移，必须利用合作伙伴提供的信息，因为此服务器的稳定存储可能已丢失。
If communication fails while a server is in RECOVER-WAIT state, it has no effect on the operation of this state. The server SHOULD continue to operate its timer, and if the timer expires during the period where communications with the other server have failed, then the server SHOULD transition to RECOVER-DONE state. This is rare -- failover state transitions are not usually made while communications are interrupted, but in this case there is no reason to inhibit this transition.
如果在服务器处于恢复等待状态时通信失败，则不会影响此状态的操作。服务器应继续运行其计时器，如果计时器在与其他服务器的通信失败期间过期，则服务器应转换为恢复完成状态。这种情况很少见——通常在通信中断时不会进行故障转移状态转换，但在这种情况下，没有理由禁止这种转换。
This state exists to allow an interlocked transition for one server from RECOVER state and another server from PARTNER-DOWN or COMMUNICATIONS-INTERRUPTED state into NORMAL state.
此状态的存在允许一台服务器从恢复状态和另一台服务器从伙伴关闭或通信中断状态互锁转换为正常状态。
A server in RECOVER-DONE state SHOULD be renew responsive and MAY respond to RENEW requests but MUST only change the state of a lease that appears in the RENEW request. It MUST NOT allocate any additional leases when in RECOVER-DONE state and should only respond to RENEW requests where it already has a record of the lease.
处于“恢复完成”状态的服务器应该是响应续订的，并且可以响应续订请求，但必须仅更改续订请求中显示的租约的状态。当处于“恢复完成”状态时，它不得分配任何其他租约，并且只应在它已经有租约记录的情况下响应续订请求。
When a server in RECOVER-DONE state determines that its partner server has entered NORMAL or RECOVER-DONE state, it will transition into NORMAL state.
当处于恢复完成状态的服务器确定其伙伴服务器已进入正常或恢复完成状态时，它将转换为正常状态。
If the partner server enters RECOVER or RECOVER-WAIT state, this server transitions to COMMUNICATIONS-INTERRUPTED.
如果伙伴服务器进入恢复或恢复等待状态，此服务器将转换为通信中断状态。
If the partner server enters POTENTIAL-CONFLICT state, this server enters POTENTIAL-CONFLICT state as well.
如果伙伴服务器进入潜在冲突状态，则此服务器也将进入潜在冲突状态。
If communication fails while in RECOVER-DONE state, a server will stay in RECOVER-DONE state.
如果在恢复完成状态下通信失败，服务器将保持恢复完成状态。
NORMAL state is the state used by a server when it is communicating with the other server and any required resynchronization has been performed. While some binding database synchronization is performed in NORMAL state, potential conflicts are resolved prior to entry into NORMAL state, as is binding database data loss.
正常状态是服务器与其他服务器通信且已执行任何所需的重新同步时所使用的状态。虽然某些绑定数据库同步是在正常状态下执行的，但在进入正常状态之前，潜在的冲突会得到解决，绑定数据库数据丢失也是如此。
When entering NORMAL state, a server will send to the other server all currently unacknowledged binding updates as BNDUPD messages.
当进入正常状态时，服务器将把所有当前未确认的绑定更新作为BNDUPD消息发送给另一台服务器。
When the above process is complete, if the server entering NORMAL state is a secondary server, then it will request delegable prefixes for allocation using the POOLREQ message.
当上述过程完成时，如果进入正常状态的服务器是辅助服务器，那么它将使用POOLREQ消息请求分配可删除前缀。
The primary server is responsive in NORMAL state. The secondary is renew responsive in NORMAL state.
主服务器在正常状态下响应。辅助系统在正常状态下响应更新。
When in NORMAL state, a primary server will operate in the following manner:
在正常状态下，主服务器将按以下方式运行：
Valid lifetime calculations As discussed in Section 4.4, the lease interval given to a DHCP client can never be more than the MCLT greater than the most recently acknowledged partner lifetime received from the failover partner or the current time, whichever is later.
有效生存期计算如第4.4节所述，提供给DHCP客户端的租约间隔不能超过MCLT，也不能大于从故障转移伙伴收到的最近确认的伙伴生存期或当前时间，以较晚者为准。
As long as a server adheres to this constraint, the specifics of the lease interval that it gives to a DHCP client or the value of the partner lifetime sent to its failover partner are implementation dependent.
只要服务器遵守此约束，它提供给DHCP客户端的租用间隔或发送给其故障转移伙伴的伙伴生存期的值的具体细节就取决于实现。
Lazy update of partner server After sending a REPLY that includes a lease update to a client, the server servicing a DHCP client request attempts to update its partner with the new binding information. See Section 4.3.
伙伴服务器的延迟更新向客户端发送包含租约更新的答复后，为DHCP客户端请求提供服务的服务器将尝试使用新的绑定信息更新其伙伴。见第4.3节。
Reallocation of leases between clients Whenever a client binding is released or expires, a BNDUPD message must be sent to the partner, setting the binding state to RELEASED or EXPIRED. However, until a BNDREPLY is received for this message, the lease cannot be allocated to another client. It cannot be allocated to the same client again if a BNDUPD message was sent; otherwise, it can. See Section 4.2.2.1 for details.
在客户端之间重新分配租约每当客户端绑定被释放或过期时，必须向合作伙伴发送BNDUPD消息，将绑定状态设置为已释放或过期。但是，在收到此消息的BNDREPLY之前，无法将租约分配给其他客户端。如果发送了BNDUPD消息，则无法再次将其分配给同一客户端；否则，它可以。详见第4.2.2.1节。
In NORMAL state, each server receives binding updates from its partner server in BNDUPD messages (see Section 7.5.5). It records these in its binding database in stable storage and then sends a corresponding BNDREPLY message to its partner server (see Section 7.6).
在正常状态下，每台服务器从其伙伴服务器接收BNDUPD消息中的绑定更新（参见第7.5.5节）。它将这些记录在稳定存储的绑定数据库中，然后向其合作伙伴服务器发送相应的BNDREPLY消息（参见第7.6节）。
If a server in NORMAL state receives an external command informing it that its partner is down, it will transition immediately into PARTNER-DOWN state. Generally, this would be an unusual situation, where some external agency knew the partner server was down prior to the failover server discovering it on its own.
如果处于正常状态的服务器收到一条外部命令，通知其伙伴已关闭，它将立即转换为伙伴关闭状态。通常，这是一种不寻常的情况，在故障转移服务器发现伙伴服务器之前，某些外部机构知道伙伴服务器已关闭。
If a server in NORMAL state fails to receive acks to messages sent to its partner for an implementation-dependent period of time, it MAY move into COMMUNICATIONS-INTERRUPTED state. This situation might occur if the partner server was capable of maintaining the TCP connection between the server and also capable of sending a CONTACT message periodically but was (for some reason) incapable of processing BNDUPD messages.
如果处于正常状态的服务器在与实现相关的一段时间内未能接收发送给其伙伴的消息的确认，则它可能会进入通信中断状态。如果合作伙伴服务器能够维护服务器之间的TCP连接，并且能够定期发送联系消息，但是（出于某种原因）无法处理BNDUPD消息，则可能会发生这种情况。
If it is determined that communications are not "OK" (as defined in Section 6.6), then the server should transition into COMMUNICATIONS-INTERRUPTED state.
如果确定通信不“正常”（如第6.6节所定义），则服务器应转换为通信中断状态。
If a server in NORMAL state receives any messages from its partner where the partner has changed state from that expected by the server in NORMAL state, then the server should transition into COMMUNICATIONS-INTERRUPTED state and take the appropriate state transition from there. For example, it would be expected that the partner would transition from POTENTIAL-CONFLICT state into NORMAL state but not that the partner would transition from NORMAL state into POTENTIAL-CONFLICT state.
如果处于正常状态的服务器从其合作伙伴接收到任何消息，而该合作伙伴的状态已从处于正常状态的服务器预期的状态更改，则服务器应转换为通信中断状态，并从该状态进行适当的状态转换。例如，预计合作伙伴将从潜在冲突状态过渡到正常状态，但合作伙伴不会从正常状态过渡到潜在冲突状态。
If a server in NORMAL state receives a DISCONNECT message from its partner, then the server should transition into COMMUNICATIONS-INTERRUPTED state.
如果处于正常状态的服务器从其伙伴接收到断开连接消息，则服务器应转换为通信中断状态。
A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is unable to communicate with its partner. Primary and secondary servers cycle automatically (without administrative intervention) between NORMAL state and COMMUNICATIONS-INTERRUPTED state as the network connection between them fails and recovers, or as the partner server cycles between operational and non-operational. No allocation of duplicate leases can occur while the servers cycle between these states.
每当服务器无法与其合作伙伴通信时，它就会进入通信中断状态。主服务器和辅助服务器在正常状态和通信中断状态之间自动循环（无需管理干预），因为它们之间的网络连接失败并恢复，或者伙伴服务器在运行和非运行之间循环。当服务器在这些状态之间循环时，无法分配重复租约。
When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been configured to support an automatic transition out of COMMUNICATIONS-INTERRUPTED state and into PARTNER-DOWN state (i.e., auto-partner-down has been configured), then a timer is started for the length of the configured auto-partner-down period.
当服务器进入通信中断状态时，如果已将其配置为支持从通信中断状态自动转换到伙伴关闭状态（即，已配置自动伙伴关闭），则将启动一个计时器，以确定所配置的自动伙伴关闭期间的长度。
A server transitioning into the COMMUNICATIONS-INTERRUPTED state from the NORMAL state SHOULD raise an alarm condition to alert administrative staff to a potential problem in the DHCP subsystem.
从正常状态过渡到通信中断状态的服务器应发出警报条件，以提醒管理人员DHCP子系统中存在潜在问题。
In this state, a server MUST respond to all DHCP client requests. When allocating new leases, each server allocates from its own pool, where the primary MUST allocate only FREE delegable prefixes and the secondary MUST allocate only FREE-BACKUP delegable prefixes, and each server allocates from its own independent IPv6 address ranges. When responding to RENEW messages, each server will allow continued renewal of a DHCP client's current lease, regardless of whether that lease was given out by the receiving server or not, although the renewal period MUST NOT exceed the MCLT beyond the later of (1) the partner lifetime already acknowledged by the other server or (2) now.
在此状态下，服务器必须响应所有DHCP客户端请求。分配新租约时，每个服务器从其自己的池进行分配，其中主服务器必须只分配自由可删除前缀，次服务器必须只分配自由备份可删除前缀，每个服务器从其自己的独立IPv6地址范围进行分配。在响应续订消息时，每个服务器都将允许继续续订DHCP客户端的当前租约，无论该租约是否由接收服务器发出，但续订期不得超过MCLT（1）其他服务器已确认的伙伴生存期或（2）现在。
However, since the server cannot communicate with its partner in this state, the acknowledged partner lifetime will not be updated, despite continued RENEW message processing. This is likely to eventually cause the actual lifetimes to converge to the MCLT (unless this is greater than the desired lease time, which would be unusual).
但是，由于服务器在此状态下无法与其合作伙伴通信，因此即使继续进行续订消息处理，也不会更新已确认的合作伙伴生存期。这可能最终导致实际寿命收敛到MCLT（除非这大于预期的租赁时间，这是不寻常的）。
The server should continue to try to establish a connection with its partner.
服务器应继续尝试与其伙伴建立连接。
If the auto-partner-down timer expires while a server is in COMMUNICATIONS-INTERRUPTED state, it will transition immediately into PARTNER-DOWN state.
如果自动伙伴关闭计时器在服务器处于通信中断状态时过期，它将立即转换为伙伴关闭状态。
If a server in COMMUNICATIONS-INTERRUPTED state receives an external command informing it that its partner is down, it will transition immediately into PARTNER-DOWN state.
如果处于通信中断状态的服务器收到一条外部命令，通知其伙伴已关闭，它将立即转换为伙伴关闭状态。
If communications with the other server are restored, then the server in COMMUNICATIONS-INTERRUPTED state will transition into another state based on the state of the partner:
如果恢复与其他服务器的通信，则处于通信中断状态的服务器将根据伙伴的状态转换为另一个状态：
o NORMAL or COMMUNICATIONS-INTERRUPTED: Transition into NORMAL state.
o 正常或通信中断：转换到正常状态。
o RECOVER: Stay in COMMUNICATIONS-INTERRUPTED state.
o 恢复：保持通信中断状态。
o RECOVER-DONE: Transition into NORMAL state.
o 恢复完成：转换到正常状态。
o PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE, or RESOLUTION-INTERRUPTED: Transition into POTENTIAL-CONFLICT state.
o 合作伙伴下降、潜在冲突、冲突完成或解决中断：过渡到潜在冲突状态。
Figure 8 illustrates the transition from NORMAL state to COMMUNICATIONS-INTERRUPTED state and then back to NORMAL state again.
图8说明了从正常状态到通信中断状态的转换，然后再次回到正常状态。
Primary Secondary Server Server
主辅助服务器
NORMAL NORMAL
| >--CONTACT-------------------> |
| <--------------------CONTACT--< |
| [TCP connection broken] |
COMMUNICATIONS- : COMMUNICATIONS-
INTERRUPTED : INTERRUPTED
| [attempt new TCP connection] |
| [connection succeeds] |
| |
| >--CONNECT-------------------> |
| <---------------CONNECTREPLY--< |
| >--STATE---------------------> |
| NORMAL
| <-------------------STATE-----< |
NORMAL |
| |
| >--BNDUPD--------------------> |
| <-------------------BNDREPLY--< |
| |
| <---------------------BNDUPD--< |
| >------BNDREPLY--------------> |
... ...
| |
| <--------------------POOLREQ--< |
| >--POOLRESP------------------> |
| |
| >--BNDUPD-(#1)---------------> |
| <-------------------BNDREPLY--< |
| |
| >--BNDUPD-(#2)---------------> |
| <-------------------BNDREPLY--< |
| |
NORMAL NORMAL
| >--CONTACT-------------------> |
| <--------------------CONTACT--< |
| [TCP connection broken] |
COMMUNICATIONS- : COMMUNICATIONS-
INTERRUPTED : INTERRUPTED
| [attempt new TCP connection] |
| [connection succeeds] |
| |
| >--CONNECT-------------------> |
| <---------------CONNECTREPLY--< |
| >--STATE---------------------> |
| NORMAL
| <-------------------STATE-----< |
NORMAL |
| |
| >--BNDUPD--------------------> |
| <-------------------BNDREPLY--< |
| |
| <---------------------BNDUPD--< |
| >------BNDREPLY--------------> |
... ...
| |
| <--------------------POOLREQ--< |
| >--POOLRESP------------------> |
| |
| >--BNDUPD-(#1)---------------> |
| <-------------------BNDREPLY--< |
| |
| >--BNDUPD-(#2)---------------> |
| <-------------------BNDREPLY--< |
| |
Figure 8: Transition from NORMAL State to COMMUNICATIONS-INTERRUPTED State and Back
图8：从正常状态到通信中断状态的转换
This state indicates that the two servers are attempting to reintegrate with each other but at least one of them was running in a state that did not guarantee that automatic reintegration would be possible. In POTENTIAL-CONFLICT state, the servers may determine that the same lease has been offered and accepted by two different clients.
此状态表示这两台服务器正试图相互重新整合，但其中至少有一台服务器的运行状态无法保证自动重新整合成为可能。在潜在冲突状态下，服务器可能会确定两个不同的客户端提供并接受了相同的租约。
A goal of the failover protocol is to minimize the possibility that POTENTIAL-CONFLICT state is ever entered.
故障切换协议的一个目标是最大限度地减少进入潜在冲突状态的可能性。
When a primary server enters POTENTIAL-CONFLICT state, it should request that the secondary send it all updates that the primary server has not yet acknowledged by sending an UPDREQ message to the secondary server.
当主服务器进入潜在冲突状态时，应通过向辅助服务器发送UPDREQ消息，请求辅助服务器向其发送主服务器尚未确认的所有更新。
A secondary server entering POTENTIAL-CONFLICT state will wait for the primary to send it an UPDREQ message.
进入潜在冲突状态的辅助服务器将等待主服务器向其发送UPDREQ消息。
Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming DHCP requests.
任何处于潜在冲突状态的服务器都不能处理任何传入的DHCP请求。
If communication with the partner fails while in POTENTIAL-CONFLICT state, then the server will transition to RESOLUTION-INTERRUPTED state.
如果在潜在冲突状态下与合作伙伴的通信失败，则服务器将转换为解决中断状态。
Whenever either server receives an UPDDONE message from its partner while in POTENTIAL-CONFLICT state, it MUST transition to a new state. The primary MUST transition to CONFLICT-DONE state, and the secondary MUST transition to NORMAL state. This will cause the primary server to leave POTENTIAL-CONFLICT state prior to the secondary, since the primary sends an UPDREQ message and receives an UPDDONE message before the secondary sends an UPDREQ message and receives its UPDDONE message.
当任一服务器在潜在冲突状态下从其合作伙伴接收到UPDDONE消息时，它必须转换到新状态。主服务器必须转换为冲突完成状态，次服务器必须转换为正常状态。这将导致主服务器在次服务器之前离开潜在冲突状态，因为在次服务器发送UPDREQ消息并接收UPDDONE消息之前，主服务器发送UPDREQ消息并接收UPDDONE消息。
When a secondary server receives an indication that the primary server has made a transition from POTENTIAL-CONFLICT to CONFLICT-DONE state, it SHOULD send an UPDREQ message to the primary server.
当辅助服务器收到主服务器已从潜在冲突状态转换为冲突完成状态的指示时，它应向主服务器发送UPDREQ消息。
Primary Secondary Server Server
主辅助服务器
| |
POTENTIAL-CONFLICT POTENTIAL-CONFLICT
| |
| >--UPDREQ--------------------> |
| |
| <---------------------BNDUPD--< |
| >--BNDREPLY------------------> |
... ...
| |
| <---------------------BNDUPD--< |
| >--BNDREPLY------------------> |
| |
| <--------------------UPDDONE--< |
CONFLICT-DONE |
| >--STATE--(CONFLICT-DONE)----> |
| <---------------------UPDREQ--< |
| |
| >--BNDUPD--------------------> |
| <-------------------BNDREPLY--< |
... ...
| >--BNDUPD--------------------> |
| <-------------------BNDREPLY--< |
| |
| >--UPDDONE-------------------> |
| NORMAL
| <------------STATE--(NORMAL)--< |
NORMAL |
| >--STATE--(NORMAL)-----------> |
| |
| <--------------------POOLREQ--< |
| >------POOLRESP--------------> |
| |
| |
POTENTIAL-CONFLICT POTENTIAL-CONFLICT
| |
| >--UPDREQ--------------------> |
| |
| <---------------------BNDUPD--< |
| >--BNDREPLY------------------> |
... ...
| |
| <---------------------BNDUPD--< |
| >--BNDREPLY------------------> |
| |
| <--------------------UPDDONE--< |
CONFLICT-DONE |
| >--STATE--(CONFLICT-DONE)----> |
| <---------------------UPDREQ--< |
| |
| >--BNDUPD--------------------> |
| <-------------------BNDREPLY--< |
... ...
| >--BNDUPD--------------------> |
| <-------------------BNDREPLY--< |
| |
| >--UPDDONE-------------------> |
| NORMAL
| <------------STATE--(NORMAL)--< |
NORMAL |
| >--STATE--(NORMAL)-----------> |
| |
| <--------------------POOLREQ--< |
| >------POOLRESP--------------> |
| |
Figure 9: Transition out of POTENTIAL-CONFLICT State
图9：从潜在冲突状态过渡
This state indicates that the two servers were attempting to reintegrate with each other in POTENTIAL-CONFLICT state but communication failed prior to completion of reintegration.
此状态表示两台服务器试图在潜在冲突状态下相互重新整合，但在重新整合完成之前通信失败。
The RESOLUTION-INTERRUPTED state exists because servers are not responsive in POTENTIAL-CONFLICT state, and if one server drops out of service while both servers are in POTENTIAL-CONFLICT state, the server that remains in service will not be able to process DHCP
解决中断状态的存在是因为服务器在潜在冲突状态下没有响应，如果一台服务器在两台服务器都处于潜在冲突状态时退出服务，则仍在服务中的服务器将无法处理DHCP
client requests and there will be no DHCP server available to process client requests. The RESOLUTION-INTERRUPTED state is the state that a server moves to if its partner disappears while it is in POTENTIAL-CONFLICT state.
客户端请求，并且将没有可用于处理客户端请求的DHCP服务器。解析中断状态是指当服务器处于潜在冲突状态时，如果其伙伴消失，服务器将移动到的状态。
When a server enters RESOLUTION-INTERRUPTED state, it SHOULD raise an alarm condition to alert administrative staff of a problem in the DHCP subsystem.
当服务器进入解析中断状态时，它应发出警报条件，以提醒管理人员DHCP子系统中存在问题。
In this state, a server MUST respond to all DHCP client requests. When allocating new leases, each server SHOULD allocate from its own pool (if that can be determined), where the primary SHOULD allocate only FREE leases and the secondary SHOULD allocate only FREE-BACKUP leases. When responding to renewal requests, each server will allow continued renewal of a DHCP client's current lease, independent of whether that lease was given out by the receiving server or not, although the renewal period MUST NOT exceed the MCLT beyond the later of (1) the partner lifetime already acknowledged by the other server or (2) now.
在此状态下，服务器必须响应所有DHCP客户端请求。分配新租约时，每个服务器都应该从自己的池中进行分配（如果可以确定），其中主服务器应该只分配自由租约，而辅助服务器应该只分配自由备份租约。在响应续订请求时，每台服务器都将允许继续续订DHCP客户端的当前租约，无论该租约是否由接收服务器发出，尽管续订期不得超过MCLT（1）另一台服务器已确认的伙伴生存期或（2）现在。
However, since the server cannot communicate with its partner in this state, the acknowledged partner lifetime will not be updated in any new bindings.
但是，由于服务器无法在此状态下与其伙伴通信，因此在任何新绑定中都不会更新已确认的伙伴生存期。
If a server in RESOLUTION-INTERRUPTED state receives an external command informing it that its partner is down, it will transition immediately into PARTNER-DOWN state.
如果处于解析中断状态的服务器收到一个外部命令，通知其伙伴已关闭，它将立即转换为伙伴关闭状态。
If communications with the other server are restored, then the server in RESOLUTION-INTERRUPTED state will transition into POTENTIAL-CONFLICT state.
如果恢复与其他服务器的通信，则处于解决中断状态的服务器将转换为潜在冲突状态。
This state indicates that during the process where the two servers are attempting to reintegrate with each other, the primary server has received all of the updates from the secondary server. It makes a transition into CONFLICT-DONE state so that it can be totally responsive to the client load. There is no operational difference between CONFLICT-DONE and NORMAL for the primary server, as in both states it responds to all clients' requests. The distinction between CONFLICT-DONE and NORMAL states is necessary in the event that a load-balancing extension is ever defined.
此状态表示在两台服务器尝试彼此重新集成的过程中，主服务器已收到来自辅助服务器的所有更新。它将转换为冲突完成状态，以便完全响应客户端负载。主服务器的冲突完成和正常之间没有操作上的区别，因为在这两种状态下，它都会响应所有客户端的请求。如果定义了负载平衡扩展，则必须区分冲突完成状态和正常状态。
A primary server in CONFLICT-DONE state is fully responsive to all DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED state).
处于冲突完成状态的主服务器完全响应所有DHCP客户端（类似于通信中断状态下的情况）。
If communication fails, remain in CONFLICT-DONE state. If communication becomes "OK", remain in CONFLICT-DONE state until the conditions for transition out of CONFLICT-DONE state are satisfied.
如果通信失败，则保持冲突结束状态。如果通信变为“OK”，则保持冲突结束状态，直到满足从冲突结束状态过渡的条件。
If communication with the partner fails while in CONFLICT-DONE state, then the server will remain in CONFLICT-DONE state.
如果在冲突完成状态下与合作伙伴的通信失败，则服务器将保持冲突完成状态。
When a primary server determines that the secondary server has made a transition into NORMAL state, the primary server will also transition into NORMAL state.
当主服务器确定辅助服务器已转换为正常状态时，主服务器也将转换为正常状态。
DHCP servers (and clients) can use "DNS update" as described in RFC 2136 [RFC2136] to maintain DNS name mappings as they maintain DHCP leases. Many different administrative models for DHCP-DNS integration are possible. Descriptions of several of these models, and guidelines that DHCP servers and clients should follow in carrying them out, are laid out in RFC 4704 [RFC4704].
DHCP服务器（和客户端）可以使用RFC 2136[RFC2136]中描述的“DNS更新”来维护DNS名称映射，因为它们维护DHCP租约。许多不同的DHCP-DNS集成管理模型是可能的。RFC 4704[RFC4704]中列出了对其中几个模型的描述，以及DHCP服务器和客户端在执行这些模型时应遵循的准则。
The nature of the failover protocol introduces some issues concerning DNS updates that are not part of non-failover environments. This section describes these issues and defines the information that failover partners should exchange in order to ensure consistent behavior. The presence of this section should not be interpreted as a requirement that an implementation of the DHCPv6 failover protocol also support DNS updates.
故障转移协议的性质带来了一些与DNS更新有关的问题，这些更新不是非故障转移环境的一部分。本节描述了这些问题，并定义了故障切换伙伴为确保行为一致而应交换的信息。本节的存在不应解释为DHCPv6故障切换协议的实现也支持DNS更新的要求。
The purpose of this discussion is to clarify the areas where the failover and DHCP DNS update protocols intersect for the benefit of implementations that support both protocols, not to introduce a new requirement into the DHCPv6 failover protocol. Thus, a DHCP server that implements the failover protocol MAY also support DNS updates, but if it does support DNS updates it SHOULD utilize the techniques described here in order to correctly distribute them between the failover partners. See RFC 4704 [RFC4704] as well as RFC 4703 [RFC4703] for information on how DHCP servers deal with potential conflicts when updating DNS even without failover.
本讨论的目的是澄清故障切换和DHCP DNS更新协议相交的领域，以利于支持这两个协议的实现，而不是在DHCPv6故障切换协议中引入新的要求。因此，实现故障转移协议的DHCP服务器也可能支持DNS更新，但如果它确实支持DNS更新，则应利用此处描述的技术，以便在故障转移伙伴之间正确分发这些更新。请参阅RFC 4704[RFC4704]和RFC 4703[RFC4703]，了解DHCP服务器在更新DNS时如何处理潜在冲突的信息，即使没有故障切换。
From the standpoint of the failover protocol, there is no reason why a server that is utilizing the DNS update protocol to update a DNS server should not be a partner with a server that is not utilizing the DNS update protocol to update a DNS server. However, a server that is not able to support DNS update or is not configured to support DNS update SHOULD output a warning message when it receives BNDUPD messages that indicate that its failover partner is configured to support the DNS update protocol to update a DNS server. An implementation MAY consider this an error and refuse to accept the BNDUPD message by returning the status DNSUpdateNotSupported in an OPTION_STATUS_CODE option in the BNDREPLY message, or it MAY choose to operate anyway, having warned the administrator of the problem in some way.
从故障转移协议的角度来看，没有理由认为使用DNS更新协议更新DNS服务器的服务器不应该是不使用DNS更新协议更新DNS服务器的服务器的合作伙伴。但是，无法支持DNS更新或未配置为支持DNS更新的服务器在收到BNDUPD消息时应输出警告消息，该消息指示其故障转移伙伴已配置为支持DNS更新协议以更新DNS服务器。一个实现可能会认为这是一个错误，并且通过在BNDReLead消息中返回OpTythStasuSoLoad选项中支持的状态DNSUpDATENOTE选项拒绝接受BNDUPDD消息，或者它可以选择无论如何运行，以某种方式警告管理员这个问题。
The failover protocol describes the conditions under which each failover server may renew a lease to its current DHCP client and describes the conditions under which it may grant a lease to a new DHCP client. An analogous set of conditions determines when a failover server should initiate a DNS update, and when it should attempt to remove records from the DNS. The failover protocol's conditions are based on the desired external behavior: avoiding duplicate address and prefix assignments, allowing clients to continue using leases that they obtained from one failover partner even if they can only communicate with the other partner, and allowing the secondary DHCP server to grant new leases even if it is unable to communicate with the primary server. The desired external DNS update behavior for DHCPv6 failover servers is similar to that described above for the failover protocol itself:
故障转移协议描述了每个故障转移服务器可以向其当前DHCP客户端续订租约的条件，以及可以向新DHCP客户端授予租约的条件。一组类似的条件确定故障转移服务器何时应启动DNS更新，以及何时应尝试从DNS中删除记录。故障转移协议的条件基于所需的外部行为：避免重复的地址和前缀分配，允许客户端继续使用从一个故障转移伙伴获得的租约，即使它们只能与另一个伙伴通信，以及允许辅助DHCP服务器即使无法与主服务器通信也授予新租约。DHCPv6故障转移服务器所需的外部DNS更新行为与故障转移协议本身的上述行为类似：
1. Allow timely DNS updates from the server that grants a lease to a client. Recognize that there is often a DNS update "lifecycle" that parallels the DHCP lease lifecycle. This is likely to include the addition of records when the lease is granted and the removal of DNS records when the lease is subsequently made available for allocation to a different client.
1. 允许从向客户端授予租约的服务器及时进行DNS更新。认识到DNS更新“生命周期”通常与DHCP租约生命周期平行。这可能包括在授予租赁时添加记录，以及在租赁随后可用于分配给不同客户时删除DNS记录。
2. Communicate enough information between the two failover servers to allow one to complete the DNS update lifecycle even if the other server originally granted the lease.
2. 在两个故障切换服务器之间通信足够的信息，以允许一个服务器完成DNS更新生命周期，即使另一个服务器最初授予了租约。
3. Avoid redundant or overlapping DNS updates where both failover servers are attempting to perform DNS updates for the same lease-client binding.
3. 当两个故障转移服务器都试图对同一租约客户端绑定执行DNS更新时，请避免冗余或重叠的DNS更新。
4. Avoid situations where one partner is attempting to add resource records (RRs) related to a lease binding while the other partner is attempting to remove RRs related to the same lease binding.
4. 避免一个合作伙伴尝试添加与租约绑定相关的资源记录（RRs），而另一个合作伙伴尝试删除与同一租约绑定相关的RRs的情况。
While DHCPv6 servers configured for DNS update typically perform these operations on both the AAAA and the PTR RRs, this is not required. It is entirely possible that a DHCPv6 server could be configured to only update the DNS with PTR records, and the DHCPv6 clients could be responsible for updating the DNS with their own AAAA records. In this case, the discussions here would apply only to the PTR records.
虽然为DNS更新配置的DHCPv6服务器通常在AAAA和PTR RRs上执行这些操作，但这不是必需的。完全有可能将DHCPv6服务器配置为仅使用PTR记录更新DNS，并且DHCPv6客户端可以负责使用其自己的AAAA记录更新DNS。在这种情况下，此处的讨论仅适用于PTR记录。
In order for either server to be able to complete a DNS update or to remove DNS records that were added by its partner, both servers need to know the FQDN associated with the lease-client binding. In addition, to properly handle DNS updates, additional information is required. All of the following information needs to be transmitted between the failover partners:
为了使任一服务器能够完成DNS更新或删除其合作伙伴添加的DNS记录，两台服务器都需要知道与租约客户端绑定关联的FQDN。此外，要正确处理DNS更新，还需要其他信息。需要在故障切换伙伴之间传输以下所有信息：
1. The FQDN that the client requested be associated with the lease. If the client doesn't request a particular FQDN and one is synthesized by the failover server or if the failover server is configured to replace a client-requested FQDN with a different FQDN, then the server-generated value would be used.
1. 客户端请求的FQDN与租约关联。如果客户端未请求特定FQDN，而故障转移服务器合成了一个FQDN，或者故障转移服务器配置为使用不同的FQDN替换客户端请求的FQDN，则将使用服务器生成的值。
2. The FQDN that was actually placed in the DNS for this lease. It may differ from the client-requested FQDN due to some form of disambiguation or other DHCP server configuration (as described above).
2. 实际放置在此租约的DNS中的FQDN。由于某种形式的歧义消除或其他DHCP服务器配置（如上所述），它可能不同于客户端请求的FQDN。
3. The status of any DNS update operations in progress or completed.
3. 正在进行或已完成的任何DNS更新操作的状态。
4. Information sufficient to allow the failover partner to remove the FQDN from the DNS, should that become necessary.
4. 如果需要，足够的信息允许故障转移伙伴从DNS中删除FQDN。
These data items are the minimum necessary set to reliably allow two failover partners to successfully share the responsibility to keep the DNS up to date with the leases allocated to clients.
这些数据项是可靠地允许两个故障切换伙伴成功分担责任的最低必要设置，以使DNS与分配给客户端的租约保持最新。
This information would typically be included in BNDUPD messages sent from one failover partner to the other. Failover servers MAY choose not to include this information in BNDUPD messages if there has been no change in the status of any DNS update related to the lease.
此信息通常包含在从一个故障切换伙伴发送到另一个故障切换伙伴的BNDUPD消息中。如果与租约相关的任何DNS更新的状态没有变化，故障转移服务器可以选择不在BNDUPD消息中包含此信息。
The partner server receiving BNDUPD messages containing the DNS update information SHOULD compare the status information and the FQDN with the current DNS update information it has associated with the lease binding and update its notion of the DNS update status accordingly.
接收包含DNS更新信息的BNDUPD消息的合作伙伴服务器应将状态信息和FQDN与其与租约绑定关联的当前DNS更新信息进行比较，并相应地更新其DNS更新状态的概念。
Some implementations will instead choose to send a BNDUPD message without waiting for the DNS update to complete and then will send a second BNDUPD message once the DNS update is complete. Other implementations will delay sending the partner a BNDUPD message until the DNS update has been acknowledged by the DNS server, or until some time limit has elapsed, in order to avoid sending a second BNDUPD message.
一些实现会选择在不等待DNS更新完成的情况下发送BNDUPD消息，然后在DNS更新完成后发送第二条BNDUPD消息。其他实现将延迟向合作伙伴发送BNDUPD消息，直到DNS服务器确认DNS更新，或者直到经过某个时间限制，以避免发送第二条BNDUPD消息。
The FQDN option contains the FQDN that will be associated with the AAAA RR (if the server is performing a AAAA RR update for the client). The PTR RR can be generated automatically from the IPv6 address value. The FQDN may be composed in any of several ways, depending on server configuration and the information provided by the client in its DHCP messages. The client may supply a hostname that it would like the server to use in forming the FQDN, or it may supply the entire FQDN. The server may be configured to attempt to use the information the client supplies, it may be configured with an FQDN to use for the client, or it may be configured to synthesize an FQDN.
FQDN选项包含将与AAAA RR关联的FQDN（如果服务器正在为客户端执行AAAA RR更新）。PTR RR可以根据IPv6地址值自动生成。FQDN可以通过几种方式中的任何一种组成，具体取决于服务器配置和客户端在其DHCP消息中提供的信息。客户端可以提供希望服务器在形成FQDN时使用的主机名，也可以提供整个FQDN。服务器可以配置为尝试使用客户端提供的信息，可以配置为用于客户端的FQDN，也可以配置为合成FQDN。
Since the server interacting with the client may not have completed the DNS update at the time it sends the first BNDUPD message about the lease binding, there may be cases where the FQDN in later BNDUPD messages does not match the FQDN included in earlier messages. For example, the responsive server may be configured to handle situations where two or more DHCP client FQDNs are identical by modifying the most-specific label in the FQDNs of some of the clients in an attempt to generate unique FQDNs for them (a process sometimes called "disambiguation"). Alternatively, at sites that use some or all of the information that clients supply to form the FQDN, it's possible that a client's configuration may be changed so that it begins to supply new data. The server interacting with the client may react by removing the DNS records that it originally added for the client and replacing them with records that refer to the client's new FQDN. In such cases, the server SHOULD include the actual FQDN that was used in subsequent DNS update options in any BNDUPD messages exchanged between the failover partners. This server SHOULD include relevant information in its BNDUPD messages. This information may be necessary in order to allow the non-responsive partner to detect client configuration changes that change the hostname or FQDN data that the client includes in its DHCPv6 requests.
由于与客户端交互的服务器在发送有关租约绑定的第一条BNDUPD消息时可能尚未完成DNS更新，因此可能存在以下情况：后面BNDUPD消息中的FQDN与前面消息中包含的FQDN不匹配。例如，响应服务器可被配置为处理两个或多个DHCP客户端fqdn相同的情况，方法是修改一些客户端的fqdn中最特定的标签，以尝试为它们生成唯一的fqdn（这一过程有时称为“消歧”）。或者，在使用客户端提供的部分或全部信息来形成FQDN的站点上，可能会更改客户端的配置，以便开始提供新数据。与客户端交互的服务器可能会做出反应，删除它最初为客户端添加的DNS记录，并将其替换为引用客户端新FQDN的记录。在这种情况下，服务器应在故障转移伙伴之间交换的任何BNDUPD消息中包含后续DNS更新选项中使用的实际FQDN。此服务器应在其BNDUPD消息中包含相关信息。此信息可能是必要的，以允许非响应合作伙伴检测更改了客户端在其DHCPv6请求中包含的主机名或FQDN数据的客户端配置更改。
A failover server that is going to perform DNS updates SHOULD initiate the DNS update when it grants a new lease to a client. The server that did not grant the lease SHOULD NOT initiate a DNS update when it receives the BNDUPD message after the lease has been granted. The failover protocol ensures that only one of the partners will grant a lease to any individual client, so it follows that this requirement will prevent both partners from initiating updates simultaneously. The server initiating the update SHOULD follow the protocol in RFC 4704 [RFC4704]. The server may be configured to perform a AAAA RR update on behalf of its clients, or not. Ordinarily, a failover server will not initiate DNS updates when it renews leases. In two cases, however, a failover server MAY initiate a DNS update when it renews a lease to its existing client:
将要执行DNS更新的故障转移服务器应在向客户端授予新租约时启动DNS更新。未授予租约的服务器在授予租约后收到BNDUPD消息时不应启动DNS更新。故障切换协议确保只有一个合作伙伴将租约授予任何单个客户机，因此该要求将防止两个合作伙伴同时启动更新。启动更新的服务器应遵循RFC 4704[RFC4704]中的协议。服务器可以配置为代表其客户端执行AAAA-RR更新，也可以不执行。通常，故障转移服务器在续订租约时不会启动DNS更新。但是，在两种情况下，故障转移服务器在向其现有客户端续订租约时可能会启动DNS更新：
1. When the lease was granted before the server was configured to perform DNS updates, the server MAY be configured to perform updates when it next renews existing leases.
1. 如果在服务器配置为执行DNS更新之前授予了租约，则服务器可以配置为在下次续订现有租约时执行更新。
2. If a server is in PARTNER-DOWN state, it can conclude that its partner is no longer attempting to perform an update for the existing client. If the remaining server has not recorded that an update for the binding has been successfully completed, the server MAY initiate a DNS update. It may initiate this update immediately upon entry into PARTNER-DOWN state, it may perform this in the background, or it may initiate this update upon next hearing from the DHCP client.
2. 如果服务器处于伙伴关闭状态，则可以断定其伙伴不再尝试对现有客户端执行更新。如果其余服务器未记录绑定更新已成功完成，则服务器可能会启动DNS更新。它可以在进入伙伴关闭状态时立即启动此更新，也可以在后台执行此操作，或者在下次听到DHCP客户端的消息时启动此更新。
Note that, regardless of the use of failover, there is a use case for updating the DNS on every lease renewal. If there is a concern that the information in the DNS does not match the information in the DHCP server, updating the DNS on lease renewal is one way to gradually ensure that the DNS has information that corresponds correctly to the information in the DHCP server.
请注意，无论使用何种故障切换，每次续订租约时都有更新DNS的用例。如果担心DNS中的信息与DHCP服务器中的信息不匹配，则在租约续订时更新DNS是逐步确保DNS具有与DHCP服务器中的信息正确对应的信息的一种方法。
The failover server that makes a lease PENDING-FREE SHOULD initiate any DNS deletes if it has recorded that DNS records were added on behalf of the client.
如果故障转移服务器已记录代表客户端添加了DNS记录，则使租约处于挂起状态的故障转移服务器应启动任何DNS删除。
A server not in PARTNER-DOWN state "makes a lease PENDING-FREE" when it initiates a BNDUPD message with a binding-status of FREE, FREE-BACKUP, EXPIRED, or RELEASED. Its partner confirms this status by acking that BNDUPD message, and upon receipt of the BNDREPLY message the server has "made the lease PENDING-FREE". Conversely, a server in PARTNER-DOWN state "makes a lease PENDING-FREE" when it sets the binding-status to FREE, since in PARTNER-DOWN state no communications with the partner are required.
当服务器启动绑定状态为FREE、FREE-BACKUP、EXPIRED或RELEASED的BNDUPD消息时，未处于PARTNER-DOWN状态的服务器“使租约处于挂起状态”。其合作伙伴通过确认该BNDUPD消息来确认此状态，并且在收到BNDREPLY消息后，服务器已“使租约处于待决状态”。相反，处于PARTNER-DOWN状态的服务器在将绑定状态设置为FREE时“使租约处于挂起状态”，因为在PARTNER-DOWN状态下不需要与合作伙伴进行通信。
It is at this point that it should initiate the DNS operations to delete RRs from the DNS. Its partner SHOULD NOT initiate DNS deletes for DNS records related to the lease binding as part of sending the BNDREPLY message. The partner MAY have issued BNDUPD messages with a binding-status of FREE, EXPIRED, or RELEASED previously, but the other server will have rejected these BNDUPD messages.
正是在这一点上，它应该启动DNS操作以从DNS中删除RRs。作为发送BNDREPLY消息的一部分，其合作伙伴不应启动与租约绑定相关的DNS记录的DNS删除。合作伙伴可能已发布绑定状态为FREE、EXPIRED或RELEASED Previous的BNDUPD消息，但其他服务器将拒绝这些BNDUPD消息。
The failover protocol ensures that only one of the two partner servers will be able to make a lease PENDING-FREE. The server making the lease PENDING-FREE may be doing so while it is communicating in NORMAL state with its partner, or it may be in PARTNER-DOWN state. If a server is in PARTNER-DOWN state, it may be performing DNS deletes for RRs that its partner added originally. This allows a single remaining partner server to assume responsibility for all of the DNS update activity that the two servers were undertaking.
故障切换协议确保两个合作伙伴服务器中只有一个能够进行无挂起的租约。使租约挂起的服务器可能在正常状态下与其合作伙伴通信时执行此操作，也可能处于合作伙伴关闭状态。如果服务器处于合作伙伴关闭状态，则可能正在对其合作伙伴最初添加的RRs执行DNS删除。这允许一个剩余的伙伴服务器负责两台服务器正在进行的所有DNS更新活动。
Another implication of this approach is that no DNS RR deletes will be performed while either server is in COMMUNICATIONS-INTERRUPTED state, since no leases are moved into the PENDING-FREE state during that period.
此方法的另一个含义是，当任一服务器处于通信中断状态时，不会执行DNS RR删除，因为在此期间，没有租约移动到挂起-空闲状态。
A failover server SHOULD ensure that a server failure while making a lease PENDING-FREE and initiating a DNS delete does not somehow leave the lease with an RR in the DNS with nothing recorded in the lease state database to trigger a DNS delete.
故障转移服务器应确保在使租约处于挂起状态并启动DNS删除时，服务器故障不会以某种方式使租约在DNS中保留RR，而租约状态数据库中未记录任何内容以触发DNS删除。
In some cases, a DHCP server is configured to return a name to the DHCP client but not enter that name into the DNS. This is typically a name that it has discovered or generated from information it has received from the client. In this case, this name information SHOULD be communicated to the failover partner, if only to ensure that they will return the same name in the event the partner becomes the server with which the DHCP client begins to interact.
在某些情况下，DHCP服务器配置为向DHCP客户端返回名称，但不将该名称输入DNS。这通常是它从客户端收到的信息中发现或生成的名称。在这种情况下，应将此名称信息传递给故障转移伙伴，以确保在该伙伴成为DHCP客户端开始与之交互的服务器时，它们将返回相同的名称。
DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all security considerations from Section 23 of [RFC3315] and Section 15 of [RFC3633] related to the server apply.
DHCPv6故障切换是标准DHCPv6协议的扩展，因此[RFC3315]第23节和[RFC3633]第15节中与服务器相关的所有安全注意事项均适用。
The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCP server's available TCP connection resources can compromise the ability of legitimate partners to receive service. Malicious requestors who succeed in establishing connections but who then send invalid messages, partial messages, or no messages at all can also exhaust a server's pool of available connections.
TCP的使用带来了一些额外的问题。试图耗尽DHCP服务器可用TCP连接资源的攻击可能会损害合法合作伙伴接收服务的能力。成功建立连接但随后发送无效消息、部分消息或根本不发送消息的恶意请求者也会耗尽服务器的可用连接池。
DHCPv6 failover can operate in secure or insecure mode. Secure mode (using Transport Layer Security (TLS) [RFC5246]) would be indicated when the TCP connection between failover partners is open to external monitoring or interception. Insecure mode should only be used when the TCP connection between failover partners remains within a set of protected systems. Details of such protections are beyond the scope of this document. Failover servers MUST use the approach documented in Section 9.1 of [RFC7653] to decide whether or not to use TLS when connecting with the failover partner.
DHCPv6故障切换可以在安全或不安全模式下运行。当故障转移伙伴之间的TCP连接开放给外部监视或拦截时，将指示安全模式（使用传输层安全性（TLS）[RFC5246]）。仅当故障转移伙伴之间的TCP连接保持在一组受保护的系统内时，才应使用不安全模式。此类保护的详细信息超出了本文件的范围。故障转移服务器必须使用[RFC7653]第9.1节中记录的方法来决定在与故障转移伙伴连接时是否使用TLS。
The threats created by using failover directly mirror those from using DHCPv6 itself: information leakage through monitoring, and disruption of address assignment and configuration. Monitoring the failover TCP connection provides no additional data beyond that available from monitoring the interactions between DHCPv6 clients and the DHCPv6 server. Likewise, manipulating the data flow between failover servers provides no additional opportunities to disrupt address assignment and configuration beyond that provided by acting as a counterfeit DHCP server. Protection from both threats is easier than with basic DHCPv6, as only a single TCP connection needs to be protected. Either use secure mode to protect that TCP connection or ensure that it can only exist with a set of protected systems.
使用故障切换造成的威胁直接反映了使用DHCPv6本身造成的威胁：通过监视造成的信息泄漏，以及地址分配和配置中断。监视故障转移TCP连接不会提供除监视DHCPv6客户端和DHCPv6服务器之间的交互之外的其他数据。同样，操作故障转移服务器之间的数据流不会提供额外的机会来中断地址分配和配置，而不仅仅是充当假冒的DHCP服务器。与基本的DHCPv6相比，这两种威胁的保护更容易，因为只需要保护单个TCP连接。使用安全模式保护该TCP连接，或者确保它只能与一组受保护的系统一起存在。
When operating in secure mode, TLS is used to secure the connection. The recommendations in [RFC7525] SHOULD be followed when negotiating a TLS connection.
在安全模式下操作时，TLS用于保护连接。协商TLS连接时，应遵循[RFC7525]中的建议。
Servers SHOULD offer configuration parameters to limit the sources of incoming connections through validation and use of the digital certificates presented to create a TLS connection. They SHOULD also limit the number of accepted connections and limit the period of time during which an idle connection will be left open.
服务器应提供配置参数，通过验证和使用提供的数字证书来创建TLS连接，从而限制传入连接的来源。它们还应该限制可接受连接的数量，并限制空闲连接保持打开的时间段。
Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to attempt to secure transmission of the messages described in this document. If authentication is desired, secure mode using TLS SHOULD be employed as described in Sections 8.2 and 9.1 of [RFC7653].
DHCPv6消息的身份验证[RFC3315]不得用于尝试确保本文档中所述消息的传输安全。如果需要身份验证，则应按照[RFC7653]第8.2节和第9.1节所述使用TLS的安全模式。
IANA has assigned values for the following new DHCPv6 message types in the registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>:
IANA在维护的注册表中为以下新的DHCPv6消息类型分配了值<http://www.iana.org/assignments/ dhcpv6参数>：
o BNDUPD (24)
o BND（24）
o BNDREPLY (25)
o BNDREPLY（25）
o POOLREQ (26)
o 普尔雷克（26）
o POOLRESP (27)
o 普尔雷斯普（27）
o UPDREQ (28)
o UPDREQ（28）
o UPDREQALL (29)
o UPDREQALL（29）
o UPDDONE (30)
o UPDDONE（30）
o CONNECT (31)
o 连接（31）
o CONNECTREPLY (32)
o 答复（32）
o DISCONNECT (33)
o 断开（33）
o STATE (34)
o 国家（34）
o CONTACT (35)
o 联络人（35）
IANA has assigned values for the following new DHCPv6 option codes in the registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>:
IANA在维护的注册表中为以下新的DHCPv6选项代码分配了值：<http://www.iana.org/assignments/ dhcpv6参数>：
o OPTION_F_BINDING_STATUS (114)
o 选项绑定状态（114）
o OPTION_F_CONNECT_FLAGS (115)
o 选项连接标志（115）
o OPTION_F_DNS_REMOVAL_INFO (116)
o 选项\u F\u DNS\u删除\u信息（116）
o OPTION_F_DNS_HOST_NAME (117)
o 选项\u F\u DNS\u主机\u名称（117）
o OPTION_F_DNS_ZONE_NAME (118)
o 选项名称（118）
o OPTION_F_DNS_FLAGS (119)
o 选项F\u DNS\u标志（119）
o OPTION_F_EXPIRATION_TIME (120)
o 选项失效时间（120）
o OPTION_F_MAX_UNACKED_BNDUPD (121)
o 选项最大未确认重复（121）
o OPTION_F_MCLT (122)
o 选项F\U MCLT（122）
o OPTION_F_PARTNER_LIFETIME (123)
o 期权、合伙人、终身（123）
o OPTION_F_PARTNER_LIFETIME_SENT (124)
o 选项\u F\u合作伙伴\u终身\u发送（124）
o OPTION_F_PARTNER_DOWN_TIME (125)
o 选项合作伙伴停机时间（125）
o OPTION_F_PARTNER_RAW_CLT_TIME (126)
o 选项合作伙伴原始CLT时间（126）
o OPTION_F_PROTOCOL_VERSION (127)
o 选项F协议版本（127）
o OPTION_F_KEEPALIVE_TIME (128)
o 选项保持有效时间（128）
o OPTION_F_RECONFIGURE_DATA (129)
o 选项重新配置数据（129）
o OPTION_F_RELATIONSHIP_NAME (130)
o 选项关系名称（130）
o OPTION_F_SERVER_FLAGS (131)
o 选项\u F\u服务器\u标志（131）
o OPTION_F_SERVER_STATE (132)
o 选项服务器状态（132）
o OPTION_F_START_TIME_OF_STATE (133)
o 选项状态的开始时间（133）
o OPTION_F_STATE_EXPIRATION_TIME (134)
o 选项状态到期时间（134）
IANA has assigned values for the following new DHCPv6 status codes in the registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>:
IANA has assigned values for the following new DHCPv6 status codes in the registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>:translate error, please retry
o AddressInUse (16)
o 地址使用（16）
o ConfigurationConflict (17)
o 配置冲突（17）
o MissingBindingInformation (18)
o 丢失绑定信息（18）
o OutdatedBindingInformation (19)
o 过时的绑定信息（19）
o ServerShuttingDown (20)
o 服务器关闭（20）
o DNSUpdateNotSupported (21)
o DNSUpdateNotSupported（21）
o ExcessiveTimeSkew (22)
o 过度时间基尤（22）
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，DOI 10.17487/RFC2136，1997年4月<http://www.rfc-editor.org/info/rfc2136>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients", RFC 4703, DOI 10.17487/RFC4703, October 2006, <http://www.rfc-editor.org/info/rfc4703>.
[RFC4703]Stapp，M.和B.Volz，“解决动态主机配置协议（DHCP）客户端之间的完全限定域名（FQDN）冲突”，RFC 4703，DOI 10.17487/RFC4703，2006年10月<http://www.rfc-editor.org/info/rfc4703>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, <http://www.rfc-editor.org/info/rfc4704>.
[RFC4704]Volz，B.，“IPv6（DHCPv6）客户端完全限定域名（FQDN）选项的动态主机配置协议”，RFC 4704，DOI 10.17487/RFC4704，2006年10月<http://www.rfc-editor.org/info/rfc4704>.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, September 2007, <http://www.rfc-editor.org/info/rfc5007>.
[RFC5007]Brzowski，J.，Kinnear，K.，Volz，B.，和S.Zeng，“DHCPv6租赁”，RFC 5007，DOI 10.17487/RFC5007，2007年9月<http://www.rfc-editor.org/info/rfc5007>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, DOI 10.17487/RFC5460, February 2009, <http://www.rfc-editor.org/info/rfc5460>.
[RFC5460]Stapp，M.，“DHCPv6散装租赁”，RFC 5460，DOI 10.17487/RFC5460，2009年2月<http://www.rfc-editor.org/info/rfc5460>.
[RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", RFC 6607, DOI 10.17487/RFC6607, April 2012, <http://www.rfc-editor.org/info/rfc6607>.
[RFC6607]Kinnear，K.，Johnson，R.，和M.Stapp，“DHCPv4和DHCPv6的虚拟子网选择选项”，RFC 6607，DOI 10.17487/RFC6607，2012年4月<http://www.rfc-editor.org/info/rfc6607>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, October 2015, <http://www.rfc-editor.org/info/rfc7653>.
[RFC7653]Raghuvanshi，D.，Kinnear，K.，和D.Kukrety，“DHCPv6主动租赁”，RFC 7653，DOI 10.17487/RFC7653，2015年10月<http://www.rfc-editor.org/info/rfc7653>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Requirements", RFC 7031, DOI 10.17487/RFC7031, September 2013, <http://www.rfc-editor.org/info/rfc7031>.
[RFC7031]Mrugalski，T.和K.Kinnear，“DHCPv6故障切换要求”，RFC 7031，DOI 10.17487/RFC70312013年9月<http://www.rfc-editor.org/info/rfc7031>.
Acknowledgements
致谢
This document extensively uses concepts, definitions, and other parts of an effort to document failover for DHCPv4. The authors would like to thank Shawn Routhier, Greg Rabil, Bernie Volz, and Marcin Siodelski for their significant involvement and contributions. In particular, Bernie Volz and Shawn Routhier provided detailed and substantive technical reviews of the document. The RFC Editor also caught several important technical issues. The authors would like to thank Vithalprasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki, and Michal Hoeft for their insightful comments.
本文档广泛使用概念、定义和其他部分来记录DHCPv4的故障切换。作者要感谢Shawn Routhier、Greg Rabil、Bernie Volz和Marcin Siodelski的重要参与和贡献。Bernie Volz和Shawn Routhier特别对该文件进行了详细和实质性的技术审查。RFC编辑还抓住了几个重要的技术问题。作者要感谢Vithalprasad Gaitonde、Krzysztof Gierlowski、Krzysztof Nowicki和Michal Hoeft的富有洞察力的评论。
Authors' Addresses
作者地址
Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, California 94063 United States of America
美国加利福尼亚州红木市查特街950号托梅克·姆鲁加尔斯基互联网系统联合公司，邮编94063
Email: tomasz.mrugalski@gmail.com
Email: tomasz.mrugalski@gmail.com
Kim Kinnear Cisco Systems, Inc. 200 Beaver Brook Road Boxborough, Massachusetts 01719 United States of America
Kim Kinnear Cisco Systems，Inc.美国马萨诸塞州Boxborough市海弗布鲁克路200号01719
Phone: +1 978 936 0000
Email: kkinnear@cisco.com
Phone: +1 978 936 0000
Email: kkinnear@cisco.com