[要約] RFC 8156は、DHCPv6フェイルオーバープロトコルに関する標準化ドキュメントです。このプロトコルの目的は、DHCPv6サーバーの冗長性と可用性を向上させることです。
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フェールオーバーを提供するプロトコル実装を定義します。これは、サーバーに障害が発生した場合やネットワークパーティションが発生した場合に、どちらかのサーバーがクライアントのリースを引き継ぐ機能を持つ2つのサーバーを実行するためのメカニズムです。 「DHCPv6フェイルオーバー要件」（RFC 7031）で詳述されているDHCPv6フェイルオーバーの要件を満たしています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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
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フェイルオーバープロトコルを定義しています。これは、サーバーフェイルオーバーまたはネットワークパーティションの場合にいずれかのサーバーがクライアントのリースを引き継ぐ機能を持つ2つの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クライアントを保護するように設計されています。 DHCPクライアントがリースの期限切れや別のIPv6アドレスへのリースの再割り当てを経験することなく、IPv6アドレス[RFC3315]またはIPv6プレフィックス[RFC3633]にリースを提供し続けることができる正確に2つのサーバーを展開することが可能です2つのサーバーのいずれかで障害が発生した場合の接頭辞。
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.
フェイルオーバープロトコルはアクティブ/パッシブモードを定義し、「ホットスタンバイ」モデルとも呼ばれます。つまり、通常の操作中、1つのサーバーはアクティブ（つまり、クライアントの要求にアクティブに応答します）で、2番目のサーバーはパッシブ（つまり、クライアントの要求を受信しますが、特定のサーバーのみに応答します）です。セカンダリサーバーはバインディングデータベースのコピーを保持し、プライマリサーバーに障害が発生した場合にすべての受信クエリを引き継ぐ準備ができています。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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.
「絶対時間」とは、2000年1月1日午前0時からの秒単位の時間を指し、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.
「自動パートナーダウン」とは、オペレーターの介入なしに、フェイルオーバーサーバーが自動的にCOMMUNICATIONS-INTERRUPTED状態からPARTNER-DOWN状態に移行する機能を指します。
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クライアントが使用できるように割り当てることができる場合、リースまたは委任可能なプレフィックスを使用できます。これは、FREE状態のときにメインサーバーで使用でき、FREE-BACKUP状態のときにセカンダリサーバーで使用できます。 「使用可能」という用語は、「プライマリサーバーでは無料、セカンダリサーバーでは無料バックアップ」と言うのが難しい場合に使用されます。
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".
委任されたプレフィックスは、[RFC3633]で説明されているようにDHCPクライアントに委任されたプレフィックスです。コンテキストによっては、委任されたプレフィックスを「アドレスリース」と区別する必要がある場合に、「プレフィックスリース」と表現することもあります。
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.
フェイルオーバーエンドポイントはアクションを実行し、一意の状態を保持できます。通常、パートナー（サーバー）ごとに1つのフェールオーバーエンドポイントがありますが、それ以上ある場合もあります。
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".
プライマリサーバーは、フェイルオーバー関係に参加する2つの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）を含むメッセージにOPTION_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.
セカンダリサーバーは、フェイルオーバー関係に参加する2つのDHCPサーバーの2番目です。そのフェイルオーバーパートナーは「プライマリサーバー」と呼ばれます（上記で定義）。両方のサーバーが動作している場合、このサーバー（セカンダリ）は通常、クライアントトラフィックを処理せず、プライマリサーバーのバックアップとして機能します。ただし、それ専用のRENEWリクエストには応答します。
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サーバーを指します。 「サーバー」と「フェイルオーバーエンドポイント」は、サーバーが1つのフェイルオーバー関係のみに参加している場合にのみ同義です。
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.
このドキュメントでは、「状態」という用語を2つの方法で使用しています。フェイルオーバーエンドポイントは常にいくつかの状態にあり、フェイルオーバーエンドポイントが通過できる一連の状態があります。フェイルオーバーエンドポイントの状態の詳細については、セクション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.
現在、2つの割り当てアルゴリズムが定義されています。1つはアドレスリース用、もう1つはプレフィックスリース用です。
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アドレスがPENDING-FREE（セクション7.2を参照）になると、独立した割り当てアルゴリズムによって割り当てられたサーバーが所有します。
IPv6 addresses, which use the independent allocation approach, will be ignored when a server processes a POOLREQ message.
独立した割り当て方法を使用するIPv6アドレスは、サーバーがPOOLREQメッセージを処理するときに無視されます。
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.
COMMUNICATIONS-INTERRUPTEDイベントの間、パートナーは、クライアントからの要求に応じて、既存のアドレスリースを拡張し続けることができます（MAY）。運用パートナーは、ダウンしたパートナーに割り当てられ、後で期限切れになった、またはクライアントによって解放または拒否されたIPv6アドレスをリースしてはなりません（MUST NOT）。 PARTNER-DOWN状態の場合、サーバーは自身のプールから新しいリースを割り当てる必要があります。新しいリースを割り当てるためにそのパートナーのプールを使用してはなりません。
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です。
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を除くすべての状態で、自身の委任可能なプレフィックスのプールからのみプレフィックスを委任します。 PARTNER-DOWN状態では、運用パートナーはいずれかのプールからプレフィックスを委任できます（自身のパートナーと、いくつかの時間制約が経過した後のパートナーのプレフィックスの両方）。運用パートナーは、パートナーのプールを使用する前に、独自のプールから割り当てる必要があります。これらの委任可能なプレフィックスのプールの割り当てと保守は重要です。これは、2つのサーバー間で委任可能なプレフィックスの比率をほぼ一定に保つことを目的としているためです。
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).
委任可能なプレフィックスは、FREE-BACKUPの状態のOPTION_IAPREFIXを含むBNDUPDメッセージを使用して、プレフィックスリースとしてセカンダリに送信されます。これは、プレフィックスリースがセカンダリによる割り当てに使用できることを示します。メッセージが送信されると、プライマリはこれらのプレフィックスをDHCPクライアントへの割り当てに使用してはなりません（サーバーがPARTNER-DOWN状態の場合を除く）。
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.
プライマリサーバーは、プライマリまたはセカンダリの委任可能プレフィックスの数が所定の量を超えて変化するたびに、特定のプレフィックスについて、プライマリとセカンダリ間の委任可能なプレフィックスのバランスを検査する必要があります（SHOULD）。通常、この比較には、委任可能なプレフィックスの既存のインスタンスの数の実際の比較は含まれませんが、各サーバーに割り当てられた委任可能なプレフィックスのアドレス範囲を指定して委任できるプレフィックスの数を決定する必要があります。プライマリサーバーは、構成可能なデリゲートプレフィックスバランスを確保するために、必要に応じてデリゲートプレフィックスバランスを調整する必要があります（ただし、プライマリサーバーは、このバランスを維持するためのオーバーヘッドを最小限に抑えるために、このようなバランス調整にしきい値メカニズムを採用する必要があります（SHOULD）。
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.
プライマリサーバーは、いつでも、FREE-BACKUP状態の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.
サーバーがPARTNER-DOWN状態の場合、委任されたプレフィックスが別のクライアントに再割り当てされるまでの待機期間があります。サーバーがPARTNER-DOWN状態になったときに「使用可能」である委任可能なプレフィックスの場合、ピリオドは、エントリーからPARTNER-DOWN状態へのMCLTです。サーバーがPARTNER-DOWN状態になったときに使用できない委任されたプレフィックスの場合、期間は次の時間のうちの遅い方の後のMCLTです：acked-partner-lifetime、partner-lifetime（存在する場合）、expiration-time、またはPARTNER-DOWN時間へのエントリ。
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.
その他の状態では、サーバーは、最初にパートナーに（BNDUPDメッセージを介して）通知し、パートナーが最初のクライアントが使用していないことを認識しているという（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 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.
具体的には、サーバー上の「利用可能な」委任可能な接頭辞を任意のクライアントに割り当てることができます。クライアントに委任（リース）され、期限切れまたはそのクライアントによって解放されたプレフィックスは、それぞれEXPIREDまたはRELEASEDという新しい状態になります。次に、パートナーサーバーには、この委任されたプレフィックスがBNDUPDメッセージを介して期限切れまたは解放されたことが通知されます。送信サーバーが、委任されたプレフィックスのBNDREPLYメッセージを受信すると、それがFREEであることを示し、リースをEXPIREDまたはRELEASEDから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メッセージをパートナーに送信していなければ、EXPIREDまたはRELEASED状態の委任されたプレフィックスを制限なしで同じクライアントに再割り当てできます（MAY）。この状況は、たとえば、PARTNER-DOWN状態への移行後にプレフィックスリースが期限切れになった場合や解放された場合に発生します。
[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 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.
MCLTは通常、サーバーがクライアントを提供するように構成されている有効期間よりもはるかに短いため、サーバーが構成された有効期間をクライアントに提供できるようにするための戦略が必要です。遅延更新中、更新サーバーは、以前に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を超えてはなりません（MUST NOT）。
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).
サーバーがIPv6アドレスの新しいリースをDHCPクライアントに提供すると、サーバーは希望する有効期間（この場合は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.
サーバーがREPLYをDHCPクライアントに送信すると、BNDUPDメッセージを使用して、フェイルオーバーパートナーをリース情報で更新します。パートナーのライフタイムは、実際のライフタイムのT1フラクション（1/2）と、希望のライフタイムで構成されます。したがって、フェールオーバーパートナーは、パートナーのライフタイムが1/2時間+ 3日のBNDUPDメッセージを使用して更新されます。
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メッセージの情報がリースデータベースで更新されていることが確認されるまで、BNDUPDメッセージに応答してBNDREPLYメッセージを送信してはなりません（MUST NOT）。セクション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 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.
DHCPクライアントがT1（リースの開始から約1/2時間）に更新を試みると、プライマリサーバーは再び希望のライフタイムを決定します。これはまだ3日間です。次に、これを元の確認済みパートナーのライフタイム（1/2時間+ 3日）と比較し、セカンダリが最後に更新されてから経過した時間（1/2時間）を調整します。したがって、確認済みパートナー間隔の残り時間は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クライアントの更新REPLYの完了後にセカンダリ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 )
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 |
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 Bulk Leasequery」[RFC5460]のセクション5.1で指定されたフレーミングフォーマットを使用しますが、このドキュメントのセクション5.2で説明されているように、異なるメッセージフォーマットの異なるメッセージタイプを使用します。フェイルオーバーサーバー間のTCP接続は、特定のポート（dhcp-failoverポート、ポート647）に対して行われます。すべての情報は、[RFC3315]のセクション22.1で定義されている形式に従って、DHCPオプションを伝える一般的な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) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
transaction-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.
sent-timeメッセージが送信された時刻（可能な限り送信に近い値に設定）、2000年1月1日、2 ^ 32を法とする真夜中（UTC）からの秒数。フェールオーバーパートナーの時間のずれを判断するために使用されます。
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.
optionsこのメッセージで伝えられるオプション。これらのオプションはすべて、「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メッセージに表示されるOPTION_CLIENT_DATAオプションは1つだけです。 BNDUPDメッセージのすべてのデータがOPTION_CLIENT_DATAオプションで送信されるわけではないことに注意してください。特定のクライアントに現在割り当てられていない委任可能なプレフィックスに関する情報は、BNDUPDメッセージで送信されますが、OPTION_CLIENT_DATAオプション内では送信されません。パートナーは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.
1つのサーバーが更新要求メッセージUPDREQ（28）を使用して、パートナーがまだ確認されていないすべてのバインディングデータベースの変更を送信するように要求します。パートナーは、0個以上のBNDUPDメッセージで応答することが期待され、その後に、すべてのBNDUPDメッセージが送信され、それぞれに対応するBNDREPLYメッセージが受信されたことを示すUPDDONEメッセージが続きます。
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（29）は、要求側サーバーがそのバインディングの完全な損失から回復するために、他のサーバーに存在するすべてのバインディングデータベース情報を要求側サーバーに送信することを要求するために1つのサーバーによって使用されますデータベース。この要求を受信したサーバーは、0個以上のBNDUPDメッセージで応答し、その後に、すべてのBNDUPDメッセージが送信され、それぞれに対応するBNDREPLYメッセージが受信されたことを示すUPDDONEメッセージが続きます。
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）は、セカンダリサーバーがプライマリサーバーからのCONNECTメッセージに応答するために使用されます。
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）は、接続を閉じてシャットダウンするときに、どちらのサーバーでも使用されます。このメッセージに対する応答は不要です。 DISCONNECTメッセージには、適切なステータスのOPTION_STATUS_CODEオプションを含める必要があります（SHOULD）。多くの場合、これはServerShuttingDownになります。セクション5.6を参照してください。サーバーには、切断メッセージの原因に関する説明メッセージを含める必要があります（SHOULD）。
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）は、どちらのサーバーでも、フェイルオーバー状態の変更についてパートナーに通知するために使用されます。場合によっては、たとえば、COMMUNICATIONS-INTERRUPTEDまたはPARTNER-DOWN状態で接続が確立された後など、現在の状態についてパートナーに通知するために使用されることもあります。
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）は、どちらのサーバーでも、そのパートナーが接続を操作可能と見なし続けることを保証するために使用されます。他のメッセージトラフィックが流れていない場合は、確立されたすべての接続を介して定期的に送信する必要があり、いつでも送信できます（MAY）。セクション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 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.
メッセージ交換の開始者は、transaction-idを設定しなければなりません（セクション5.2を参照）。つまり、BNDREPLY、POOLRESP、UPDDONE、およびCONNECTREPLYを除く上記のすべてのメッセージで、トランザクションIDを設定する必要があります。 transaction-idは、フェイルオーバーパートナーに送信される現在未処理のすべてのメッセージ間で一意である必要があります。これを確実にする簡単な方法は、増分値を使用することです。ただし、1つの注意点があります。UPDREQメッセージとUPDREQALLメッセージは、UPDDONEメッセージを受信する前にかなりの時間離れている場合があります。通常のメッセージ交換パターンでは、パートナーがメッセージの開始の大部分を実行しますが、UPDREQまたはUPDREQALLメッセージを開始したパートナーが、24ビットのトランザクションIDをラップして複製するのに十分なメッセージを送信する可能性もあります。未解決のUPDREQまたはUPDREQALLメッセージのトランザクションID。したがって、現在未処理の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.
binding-statusは、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|
+-+-+-+-+-+-+-+-+
option-code OPTION_F_BINDING_STATUS (114) option-len 1 binding-status The binding-status. See below:
option-code OPTION_F_BINDING_STATUS（114）option-len 1 binding-statusバインディングステータス。下記参照：
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.
binding-statusの値については、セクション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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_CONNECT_FLAGS (115) option-len 2 flags flag bits. See below:
option-code OPTION_F_CONNECT_FLAGS（115）option-len 2フラグフラグビット。下記参照：
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に設定すると、指定された委任可能なプレフィックスから委任されたすべてのプレフィックスが同じプレフィックス長（サイズ）を持つことを示します。これが設定されていない場合、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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
option-code OPTION_F_DNS_REMOVAL_INFO（116）option-len変数オプション3つのカプセル化されたオプション：OPTION_F_DNS_HOST_NAME OPTION_F_DNS_ZONE_NAME OPTION_F_DNS_FLAGS
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].
これは、[RFC3315]のセクション8でも指定されているように、[RFC1035]で指定された形式を使用してエンコードされたDNS名です。
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) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_HOST_NAME (117) option-len length of host-name host-name hostname encoded per RFC 1035
option-code OPTION_F_DNS_HOST_NAME（117）RFC 1035に従ってエンコードされたホスト名host-nameホスト名のoption-lenの長さ
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].
これは、[RFC3315]のセクション8でも指定されているように、[RFC1035]で指定された形式を使用してエンコードされたDNS名です。
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) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_ZONE_NAME (118)
option-len length of zone-name
zone-name zone name encoded per 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_FLAGS (119) option-len 2 flags flag bits. See below:
option-code OPTION_F_DNS_FLAGS（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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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）：USING_REQUESTED_FQDN 1に設定すると、使用された名前が、クライアントから受信した完全修飾ドメイン名（FQDN）に由来することを示します。 13（S）：SYNTHESIZED_NAME 1に設定すると、名前が何らかのアルゴリズムに基づいて合成されたことを示します。 14（R）：REV_UPTODATE 1に設定すると、逆ゾーンが最新であることを示します。 15（F）：FWD_UPTODATE 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メッセージでパートナーにこれまでに確認応答した最大存続期間を指定します。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
option-code OPTION_F_EXPIRATION_TIME（120）option-len 4 expiration-time有効期限。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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接続をブロックせずにTCP接続を介して受け入れる準備ができているBNDUPDメッセージの最大数を指定します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_MAX_UNACKED_BNDUPD (121) option-len 4 max-unacked-bndupd Maximum number of unacked BNDUPD messages allowed
option-code 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_MCLT (122) option-len 4 mclt The MCLT, in seconds
option-code OPTION_F_MCLT（122）option-len 4 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アドレスを再利用できるようになるまでの時間を指定します。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
option-code OPTION_F_PARTNER_LIFETIME（123）option-len 4 partner-lifetimeパートナーのライフタイム。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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).
このオプションは、OPTION_F_PARTNER_LIFETIMEオプション（セクション5.5.7）で受信された時刻を示します。これは、OPTION_F_PARTNER_LIFETIMEオプションで受け取った時刻の正確な複製（エコー）です。いかなる方法でも調整されません。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
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).
このオプションは、サーバーが最後にフェイルオーバーパートナーとの通信を失った時間を指定します。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
option-code OPTION_F_PARTNER_DOWN_TIME（125）option-len 4 partner-down-time PARTNER-DOWN時間を含みます。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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クライアントと最後に対話した時刻を指定します。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-code OPTION_F_PARTNER_RAW_CLT_TIME（126）option-len 4 partner-raw-clt-time partner-raw-clt-timeが含まれます。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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.
プロトコルのバージョンにより、一方のフェイルオーバーパートナーは、もう一方のパートナーが使用しているプロトコルのバージョンを判別して、将来の変更やアップグレードに対応できます。大小の変更を1つの32ビット数で表すことができるように、2つのコンポーネントが用意されています。その意図は、大きな変更はメジャーバージョンの値の増加をもたらす一方で、小さな変更はマイナーバージョンの値の増加をもたらすであろうということです。このドキュメントのその後の更新と拡張では、これらの値の変更を適切と思われる方法で定義できるため、このドキュメントで「大」と「小」をさらに定義することはありません。
This option consists of two unsigned 16-bit integers in network byte order.
このオプションは、ネットワークバイトオーダーの2つの符号なし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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
option-code OPTION_F_PROTOCOL_VERSION（127）option-len 4 major-versionプロトコルのメジャーバージョン。最初は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".
このオプションは、サーバーがパートナーからメッセージを受信する必要がある秒数（間隔）を指定します。そうしないと、パートナーからの通信が「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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_KEEPALIVE_TIME (128) option-len 4 receive-time The keepalive-time. An interval of seconds.
option-code OPTION_F_KEEPALIVE_TIME（128）option-len 4 receive-timeキープアライブ時間。秒単位の間隔。
This option contains the information necessary for one failover partner to use the reconfigure-key created on the other failover partner.
このオプションには、1つのフェイルオーバーパートナーが他のフェイルオーバーパートナーで作成された再構成キーを使用するために必要な情報が含まれています。
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) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
option-code OPTION_F_RECONFIGURE_DATA（129）option-len 4 + reconfigure-keyの長さreconfigure-time reconfigure-keyが作成された時刻。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ2 ^ 32）。 reconfigure-key再構成キー
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.
このオプションは、このフェイルオーバー関係の名前を指定します。 2つのフェールオーバーサーバー間に複数のフェールオーバー関係がある場合に、関係を区別するために使用されます。
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) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
option-code OPTION_F_RELATIONSHIP_NAME（130）option-len length of relationship-name relationship-nameエンドユーザーへの表示に適したUTF-8でエンコードされたテキスト文字列。 nullで終了してはなりません。
The OPTION_F_SERVER_FLAGS option specifies information associated with the failover endpoint sending the option.
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 |
+-+-+-+-+-+-+-+-+
option-code OPTION_F_SERVER_FLAGS (131) option-len 1 server-flags The server flags. See below:
option-code OPTION_F_SERVER_FLAGS（131）option-len 1 server-flagsサーバーフラグ。下記参照：
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に設定して、最後に受信したOPTION_F_SERVER_FLAGSオプションにSTARTUPビットセットが含まれていたことを示します。 6（S）：サーバーがSTARTUP状態にあるときは常に、STARTUPを1に設定する必要があります。 7（C）：COMMUNICATED 1に設定して、送信サーバーがそのパートナーと通信したことを示します。
The OPTION_F_SERVER_STATE option specifies the endpoint state of the server sending the option.
OPTION_F_SERVER_STATEオプションは、オプションを送信するサーバーのエンドポイント状態を指定します。
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 |
+-+-+-+-+-+-+-+-+
option-code OPTION_F_SERVER_STATE (132) option-len 1 server-state Failover endpoint state
option-code OPTION_F_SERVER_STATE（132）option-len 1 server-state Failover endpoint state
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）STARTUP状態がパートナーサーバーに送信されることはありません。これは、OPTION_F_SERVER_FLAGSオプションのSTARTUPビットで示されます（セクション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).
OPTION_F_START_TIME_OF_STATEオプションは、関連する状態が現在の値を保持し始めた時刻を指定します。このオプションがSTATEメッセージに表示される場合、それが参照する状態はサーバーエンドポイントの状態です。 IA_NA-options、IA_TA-options、またはIA_PD-optionsフィールドに表示される場合、それが参照する状態は、それぞれOPTION_IA_NA、OPTION_IA_TA、またはOPTION_IA_PDオプションのbinding-status値です。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
option-code OPTION_F_START_TIME_OF_STATE（133）option-len 4 start-time-of-state現在の状態の開始時刻。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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).
OPTION_F_STATE_EXPIRATION_TIMEオプションは、このリースの現在の状態が期限切れになる時刻を指定します。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ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.
ACTIVE以外の状態には、時間が関連付けられている場合があることに注意してください。特に、リースの有効期限が切れた後、リースが一定期間再利用されない、ある種の「猶予期間」が存在した場合、EXPIREDに関連付けられた時間が存在する可能性があります。 ABANDONED状態には、フェイルオーバーに参加しているサーバーにクライアントへの割り当てのためにABANDONEDリースがプールに戻されるまでの時間があった場合、それに関連付けられた時間が存在する可能性があります。一般に、特定の状態に関連付けられたOPTION_STATE_EXPIRATION_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
option-code OPTION_F_STATE_EXPIRATION_TIME（134）option-len 4 state-expiration-timeリースの現在の状態が期限切れになる時刻。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数、モジュロ2 ^ 32）。
The following new status codes are defined to be used in the OPTION_STATUS_CODE option.
次の新しいステータスコードは、OPTION_STATUS_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）1つのサーバー上の1つのクライアントに、クライアントが別のサーバーに持っているリースと競合するリースがあります。または、アドレスを各サーバーの異なるIDアソシエーションID（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.
ConfigurationConflict（17）BNDUPDメッセージ内の情報（IPv6アドレスやプレフィックスアドレスなど）によって暗示される構成は、受信側サーバーが認識している情報と直接競合しています。
MissingBindingInformation (18) There is insufficient information in a BNDUPD message to effectively process it.
MissingBindingInformation（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.
ServerShuttingDown（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-failoverポート（647）へのTCP接続の作成を定期的に試行する必要があります（期間は実装に依存し、SHOULDが構成可能である必要があります）。 OPTION_STATUS_CODEオプションが含まれているCONNECTREPLYメッセージまたはDISCONNECTメッセージによって接続が拒否された場合、サーバーはそのサーバーへの接続を試行する頻度を減らす必要がありますが、定期的に接続を試行し続ける必要があります。
Every secondary server implementing the failover protocol MUST listen for TCP connection attempts on the dhcp-failover port (647) from a primary server.
フェイルオーバープロトコルを実装するすべてのセカンダリサーバーは、プライマリサーバーからのdhcp-failoverポート（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サーバー」として動作します。新しく確立された接続を介して送信されるメッセージは、ACTIVELEASEQUERYメッセージではなく、CONNECTメッセージです。
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 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.
セカンダリサーバーが接続試行を受信すると、セカンダリサーバーが持つ唯一の情報は、接続を開始するパートナーのIPアドレスです。セカンダリサーバーである接続サーバーと何らかの関係がある場合は、[RFC7653]のセクション9.1で説明されているように動作する必要があります。ただし、アクティブなLeasequeryメッセージを待機する代わりに、CONNECTメッセージを待機する点が異なります。 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メッセージを送信するために開始した接続を使用する必要があります。関係のセカンダリサーバーであるすべてのサーバーは、プライマリサーバーからの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交換が正常に機能するフェイルオーバー接続を生成すると、新しい接続を介して送信される次のメッセージはSTATEメッセージです。セクション6.3を参照してください。 STATEメッセージを受信すると、受信者は通信を「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 OPTION_F_PROTOCOL_VERSIONには、プライマリサーバーがフェイルオーバーメッセージを送信するときに使用するプロトコルバージョンが含まれます。
o OPTION_F_MCLT containing the configured MCLT.
o 構成されたMCLTを含むOPTION_F_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 OPTION_F_KEEPALIVE_TIMEには、サーバーがパートナーからメッセージを受信する必要がある秒数（間隔）が含まれます。そうしないと、パートナーからの通信が「OK」でないと見なされます。
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 OPTION_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 この接続が適用されるフェイルオーバー関係の名前を含むOPTION_F_RELATIONSHIP_NAME。 CONNECTメッセージにOPTION_F_RELATIONSHIP_NAMEがない場合は、このプライマリサーバーとセカンダリサーバーのペア間に単一の関係しかないことを示しています。
o OPTION_F_CONNECT_FLAGS containing information about certain attributes of the connecting servers.
o 接続サーバーの特定の属性に関する情報を含むOPTION_F_CONNECT_FLAGS。
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を参照してください。そうでない場合は、OPTION_STATUS_CODEでExcessiveTimeSkewを返し、CONNECTメッセージを拒否します。
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 OPTION_F_PROTOCOL_VERSION-セカンダリサーバーは、プライマリサーバーのプロトコルバージョンがセカンダリサーバーでサポートされているかどうかを判断します。そうでない場合は、OPTION_STATUS_CODEでNotSupportedを返し、CONNECTメッセージを拒否します。
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 OPTION_F_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 OPTION_F_KEEPALIVE_TIME-セクション6.6で説明されている到達不能検出アルゴリズムを実装するときは、キープアライブ時間をFO_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 OPTION_F_CONNECT_FLAGS-セカンダリサーバーがフラグで指定されているようにプライマリサーバーからの情報を処理できることを確認します。たとえば、セカンダリサーバーが同じ委任可能なプレフィックスから委任された可変サイズのプレフィックスでプレフィックス委任を処理できず、プライマリサーバーが処理できると言った場合、セカンダリは接続を拒否する必要があります。
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:
（1）接続を受け入れるか、（2）拒否の理由を示すステータスコードを含むOPTION_STATUS_CODEオプションを含めることによって接続を拒否するには、CONNECTメッセージの後に必ずCONNECTREPLYメッセージが続く必要があります（SHOULD）。接続試行を受け入れる場合は、次の情報を含むCONNECTREPLYメッセージを送信します。
o OPTION_F_PROTOCOL_VERSION containing the protocol version being used by the secondary server when sending failover messages.
o OPTION_F_PROTOCOL_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を含むOPTION_F_MCLT。これは、CONNECTメッセージのOPTION_F_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 OPTION_F_KEEPALIVE_TIMEには、サーバーがパートナーからメッセージを受信する必要がある秒数（間隔）が含まれます。そうしないと、パートナーからの通信が「OK」でないと見なされます。
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 OPTION_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_FLAGSには、プライマリが認識する必要のあるセカンダリサーバーの属性を説明する情報が含まれています。
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).
プライマリサーバーのCONNECTメッセージを受け入れるためにCONNECTREPLYメッセージを送信した後、セカンダリサーバーはSTATEメッセージを送信する必要があります（セクション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 OPTION_F_PROTOCOL_VERSION-プライマリサーバーは、セカンダリサーバーで使用されているプロトコルバージョンがプライマリサーバーでサポートされているかどうかを判断します。そうでない場合は、DISCONNECTメッセージを送信して接続をドロップします。サポートされている場合は、処理を続行します。プライマリサーバーとセカンダリサーバーがそれぞれ別のバージョンのプロトコルを他のサーバーに送信する可能性があります。
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.
これがサポートされる範囲は、バージョンが表すプロトコルのまだ未知の違いによって部分的に定義され、フェイルオーバー関係に含まれる2つの実装の機能によって部分的に定義されます。
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 OPTION_F_MCLT-受信したMCLTを構成済みのMCLTと比較します。それらが異なる場合は、DISCONNECTメッセージを送信して接続をドロップします。
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 OPTION_F_KEEPALIVE_TIME-セクション6.6で説明されている到達不能検出アルゴリズムを実装するときは、キープアライブ時間をFO_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 OPTION_F_CONNECT_FLAGS-プライマリサーバーがフラグで指定されたセカンダリサーバーからの情報を処理できることを確認します。たとえば、プライマリサーバーが同じ委任可能なプレフィックスから委任された可変サイズのプレフィックスを使用してプレフィックス委任を処理できず、セカンダリサーバーが処理できると言った場合、プライマリは接続をドロップする必要があります。
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).
プライマリサーバーのCONNECTメッセージを受け入れたCONNECTREPLYメッセージを受信した後、プライマリサーバーはSTATEメッセージを送信する必要があります（セクション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プレフィックスを複数のフェールオーバーエンドポイントに関連付けてはなりません（MUST NOT）。
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.
フェイルオーバープロトコルは、フェイルオーバーサーバーの各ペア間に1つのフェイルオーバー関係を設定する必要があります（SHOULD）。この場合、各フェールオーバーパートナーには、その関係に対して1つのフェールオーバーエンドポイントがあります。このフェイルオーバー関係には一意の名前が必要です。
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.
フェイルオーバー関係に参加する各プレフィックスに一意のフェイルオーバーエンドポイントがあるわけではありません。 1つのサーバーでは、パートナーと役割の組み合わせによって管理されるプレフィックスの数に関係なく、パートナーごとに（通常）1つのフェールオーバーエンドポイントがあります。特定のサーバーでは、フェイルオーバーに参加する特定のプレフィックスは、1つのフェイルオーバーエンドポイントに関連付けられます。
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.
サーバーは、フェイルオーバーエンドポイントの状態が変化するたびに、フェイルオーバーパートナーにSTATEメッセージを送信する必要があります。ときどき重複するSTATEメッセージを送信しても問題は発生しません。ただし、フェイルオーバーエンドポイントの状態変更に関する情報でフェイルオーバーパートナーを更新しないと、多くの場合、フェイルオーバープロトコル全体が動作しなくなる可能性があることに注意してください。
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:
STATEメッセージは、フェイルオーバー関係のエンドポイントの状態に関する情報とともに送信されます。 STATEメッセージには、オプション領域に少なくとも以下の情報が含まれている必要があります。
o OPTION_F_SERVER_STATE containing the state of this failover endpoint.
o このフェイルオーバーエンドポイントの状態を含むOPTION_F_SERVER_STATE。
o OPTION_F_SERVER_FLAGS containing the flag values associated with this failover endpoint.
o このフェイルオーバーエンドポイントに関連付けられたフラグ値を含むOPTION_F_SERVER_FLAGS。
o OPTION_F_START_TIME_OF_STATE containing the time when this became the state of this failover endpoint.
o OPTION_F_START_TIME_OF_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 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.
The server sending a STATE message SHOULD ensure that this information is written to stable storage prior to enqueuing it to its failover partner.
STATEメッセージを送信するサーバーは、フェイルオーバーパートナーにキューイングする前に、この情報が安定したストレージに書き込まれるようにする必要があります（SHOULD）。
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:
STATEメッセージを受信するサーバーは、メッセージ内の情報を処理し、情報への対応方法を決定する必要があります。処理は次のように実行されます。
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 OPTION_F_SERVER_STATE-これがフェイルオーバーパートナーの状態変化を表す場合は、セクション8.1の指示に従って対応してください。状態がPARTNER-DOWNではない場合、partner-down-timeのメモリをクリアします。
o OPTION_F_SERVER_FLAGS - Remember these flags in an appropriate data area so they can be referenced later.
o OPTION_F_SERVER_FLAGS-後で参照できるように、適切なデータ領域にこれらのフラグを覚えておいてください。
o OPTION_F_START_TIME_OF_STATE - Remember this information in an appropriate data area so it can be referenced later.
o OPTION_F_START_TIME_OF_STATE - Remember this information in an appropriate data area so it can be referenced later.
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_F_SERVER_STATEの値がPARTNER-DOWNの場合は、後で参照できるように、適切なデータ領域にこの情報を覚えておいてください。
A server receiving a STATE message SHOULD ensure that this information is written to stable storage.
STATEメッセージを受信するサーバーは、この情報が安定したストレージに書き込まれるようにする必要があります。
The following parameters and timers are used to ensure the integrity of the connections between two failover servers.
次のパラメータとタイマーは、2つのフェイルオーバーサーバー間の接続の整合性を保証するために使用されます。
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
FO_KEEPALIVE_TIME 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パートナーのFO_KEEPALIVE_TIME期間中に送信するCONTACTメッセージの数4
FO_SEND_TIMER timer counts down to time to send next CONTACT message
FO_SEND_TIMERタイマーは、次のCONTACTメッセージを送信する時間までカウントダウンします
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他のトラフィックがない場合にCONTACTメッセージを送信する間に待機する最大15時間。パートナーのFO_KEEPALIVE_TIMEをFO_CONTACT_PER_KEEPALIVE_TIMEで除算して作成
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_TIMERを維持する必要があります。特定の接続のFO_SEND_TIMERは、その接続でメッセージが送信されるたびにFO_SEND_TIMEにリセットされ、タイマーは1秒に1回カウントダウンします。タイマーがゼロに達すると、その接続でCONTACTメッセージが送信され、その接続のタイマーがFO_SEND_TIMEにリセットされます。 CONTACTメッセージはいつでも送信できます。実装は、パートナーの到達不能を検出するために追加のメカニズムを使用してもよい（MAY）。
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_SEND_TIMEは、構成されたFO_KEEPALIVE_TIMEをFO_CONTACT_PER_KEEPALIVE_TIMEで割った値から初期化されます。接続でCONNECTまたはCONNECTREPLYメッセージを受信すると、受信したOPTION_F_KEEPALIVE_TIMEオプションがチェックされ、そのオプションの値を使用して、構成済みのFO_CONTACT_PER_KEEPALIVE_TIMEで受信した値を除算することにより、その接続のFO_SEND_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_TIMERを維持する必要があります。このタイマーはFO_KEEPALIVE_TIMEに初期化され、1秒に1回カウントダウンします。その接続でメッセージが受信されると、FO_KEEPALIVE_TIMEにリセットされます。ゼロに達すると、その接続は停止していると見なされます。さらに、その接続のFO_KEEPALIVE_TIMEは、OPTION_F_KEEPALIVE_TIMEオプションの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.
パートナーは、既知のリース状態に関する情報を交換します。既知のリース状態をパートナーから受け取った更新と確実に比較するには、サーバーは、既知のリース状態に格納された時間と更新で受け取った時間を確実に比較できる必要があります。フェイルオーバープロトコルは、フェイルオーバーパートナーが何らかのメカニズムを使用して2台のサーバーのクロックを約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を参照）。送信サーバーは、これを実際の送信に可能な限り近く設定しなければなりません（MUST）。受信側パートナーは、受信のタイムスタンプを、実際の受信に可能な限り近く保存する必要があります。次に、受信したタイムスタンプ情報がローカルのタイムスタンプと比較されます。
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アドレスまたはプレフィックスのリースは、「リース状態」とも呼ばれるいくつかの異なるバインディングステータス値をとることができます。 2つの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に設定します。クライアントIDが表示されるべきです（SHOULD）。
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.
RELEASED-この値は、クライアントがRELEASEメッセージを送信したことを示します。パートナーが解放されたリースのBNDUPDメッセージを確認すると、サーバーはその内部状態をPENDING-FREEに設定します。クライアントIDが表示されるべきです（SHOULD）。
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またはFREE-BACKUPを意味します。実装は、この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サーバーがリースがクライアントによって使用されていないことを通知する必要があるが、ネットワーク管理者がリースを解放、期限切れ、またはリセットしただけではない場合に使用されます。パートナーがFREEリースのBNDUPDメッセージを確認すると、サーバーはそのリースをプライマリサーバーによる割り当てに使用可能としてマークします。 PARTNER-DOWN状態で実行されているセカンダリサーバーでは、MCLTを待機した後、リースがセカンダリサーバーによってクライアントに割り当てられる場合があります。クライアントIDが表示される場合があり、ヒントとして、このリースを使用した最後のクライアントを示します。
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-この値は、このリースがセカンダリサーバーによっていつでもクライアントに割り当てられることを示します。 PARTNER-DOWN状態で実行されているプライマリサーバーでは、MCLTを待機した後、比例アルゴリズムが使用されている場合、プライマリサーバーによってリースがクライアントに割り当てられる場合があります。クライアントIDが表示される場合があり、ヒントとして、このリースを使用した最後のクライアントを示します。
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.
ABANDONED-この値は、リースがDHCPシステムで使用不可と見なされていることを示します。このような状態になる主な理由は、リースのDECLINEメッセージの受信です。クライアントIDが表示される場合があります。
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.
RESET-この値は、このリースがオペレーターコマンドによって使用可能になったことを示します。これは明確な状態であるため、リースがFREEになった理由を判別できます。クライアントIDが表示される場合があります。
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などの一部のバインディングステータス値には、すべての実装でタイムアウト値がありますが、ABANDONEDなどの他の実装では、一部の実装ではタイムアウト値があり、他の実装ではタイムアウト値がありません。一部の実装では、バインディングステータス値は、特定の状況ではタイムアウトに関連付けられ、他の状況では関連付けられない場合があります。特定のバインディングステータス値とOPTION_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です。これに達すると、状態マシンはただちにFREEまたは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
PENDING-FREEトランジション
Figure 2: Lease State Machine
Figure 2: Lease State Machine
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）クライアントがRELEASEを送信し、リースが解放されます。
(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）パートナーは状態変更を確認します。この遷移は、サーバーがPARTNER-DOWN状態であり、MCLTがRELEASED、EXPIRED、またはRESET状態に入ってから経過した場合にも発生する可能性があります。
(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メッセージが交換されます）。プライマリサーバーに属する委任可能なプレフィックスは、セカンダリサーバーのプールに割り当てることができます（FREEからFREE-BACKUPへの移行）。
(8) The lease has expired.
(8) The lease has expired.
(9) A DECLINE message is received, or a lease is deemed unusable for other reasons.
（9）DECLINEメッセージが受信された、またはリースが他の理由で使用不可と見なされた。
(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）破棄されたリースを使用可能な状態に復元するための管理アクションが実行されます。この移行は、ABANDONEDリースの実装固有の処理が原因で発生する場合があります。これの1つの考えられる例は、アドレスがまだ使用されているかどうかを確認するための近隣探索または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.
（期限切れまたはリリースのために）使用されなくなったリースはPENDING-FREEになります。使用されている割り当てアルゴリズムに応じて、使用されなくなったリースは、プライマリプール（FREE）またはセカンダリプール（FREE-BACKUP）に戻ります。特定の遷移の条件を図3に示します。
+----------------+---------+-----------+
| \ 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.
expiration-time The greatest lifetime that this server has ever acked to its failover partner in a BNDREPLY message.
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.
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.
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.
start-time-of-stateこのリースのバインディングステータスが現在の値に変更された時刻。
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_DATAオプションの単一のクライアントバインディング、または（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:
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:
o OPTION_CLIENTID containing the DUID of the client most recently associated with this lease MUST appear.
o このリースに最後に関連付けられたクライアントのDUIDを含むOPTION_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 このOPTION_CLIENT_DATAオプションに情報が配置された絶対時間を含むOPTION_LQ_BASE_TIMEが表示されます（[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 OPTION_VSS（[RFC6607]のセクション3.4を参照）。このオプションは、このOPTION_CLIENT_DATAオプションの情報がグローバルなデフォルトVPNに関連付けられている場合は、表示してはなりません（MUST NOT）。このオプションは、このOPTION_CLIENT_DATAオプションの情報がグローバルなデフォルトのVPN以外のVPNに関連付けられている場合に表示する必要があります。 [RFC6607]のサポートは必要ありません。サポートされていない場合は、OPTION_VSSを表示してはなりません（MUST NOT）。 [RFC6607]がサポートされている場合、グローバルなデフォルトのVPN以外のVPNが使用される場合にのみ、OPTION_VSSが表示される必要があります。
o OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key, if any.
o OPTION_F_RECONFIGURE_DATAには、時刻と再構成キー（ある場合）が含まれています。
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で説明されている情報を含むOPTION_LQ_RELAY_DATA
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アドレスの場合はOPTION_IA_NAまたはOPTION_IA_TA、IPv6プレフィックスの場合はOPTION_IA_PD。これらのオプションのいずれかがこのクライアントに関連付けられている場合、これらのオプションのいずれかが複数表示される場合があります。 OPTION_IA_NA、OPTION_IA_TA、またはOPTION_IA_PDの少なくとも1つが表示される必要があります。
* 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-特定のリースを取得する際にクライアントが使用するIDアソシエーション。 （1）1つのクライアントが同時に多くのIAIDを使用する可能性があり、（2）OPTION_IA_NA、OPTION_IA_TA、およびOPTION_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アドレスのOPTION_IAADDRまたはIPv6プレフィックスのOPTION_IAPREFIXが表示されなければなりません（MUST）。
- 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-optionsまたはIAprefix-optionsの内部：
o OPTION_F_BINDING_STATUS containing the binding-status MUST appear.
o バインディングステータスを含むOPTION_F_BINDING_STATUSが表示される必要があります。
o OPTION_F_START_TIME_OF_STATE containing the start-time-of-state MUST appear.
o 状態の開始時刻を含むOPTION_F_START_TIME_OF_STATEが出現する必要があります。
o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time*.
o OPTION-F_STATE_EXPIRATION_TIME（絶対）には、状態の有効期限*が含まれます。
o OPTION_CLT_TIME (relative) containing the client-last-transaction-time. See [RFC5007] for a description of this option.
o OPTION_CLT_TIME（相対）、クライアントの最終トランザクション時間を含みます。このオプションの説明については、[RFC5007]を参照してください。
o OPTION_F_PARTNER_LIFETIME (absolute) containing the partner-lifetime*.
o OPTIONAL_F_PARTNER_LIFETIME（絶対）には、partner-lifetime *が含まれます。
o OPTION_F_PARTNER_RAW_CLT_TIME (absolute) containing the partner-raw-clt-time.
o OPTION_F_PARTNER_RAW_CLT_TIME（絶対）には、partner-raw-clt-timeが含まれます。
o OPTION_F_EXPIRATION_TIME (absolute) containing the expiration-time*.
o 有効期限*を含むOPTION_F_EXPIRATION_TIME（絶対）。
o OPTION_CLIENT_FQDN containing the FQDN information associated with this lease and client, if any.
o OPTION_CLIENT_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:
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:
o OPTION_IAPREFIX for a prefix lease.
o プレフィックスリースのOPTION_IAPREFIX。
* IPv6 prefix (with length).
* IPv6プレフィックス（長さあり）。
* Inside of the IAprefix-options section:
* IAprefix-optionsセクション内：
+ 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.
+ OPTION_VSS（[RFC6607]のセクション3.4を参照）。このオプションは、このOPTION_IAPREFIXオプションの情報がグローバルなデフォルトのVPNに関連付けられている場合は、表示しないでください。このオプションは、このOPTION_IAPREFIXオプションの情報がグローバルなデフォルトVPN以外のVPNに関連付けられている場合に表示する必要があります。 [RFC6607]のサポートは必要ありません。サポートされていない場合は、OPTION_VSSを表示してはなりません（MUST NOT）。 [RFC6607]がサポートされている場合、グローバルなデフォルトのVPN以外のVPNが使用される場合にのみ、OPTION_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.
+ この情報がこのOPTIONS_IAPREFIXオプションに配置された絶対時間を含むOPTION_LQ_BASE_TIME（[RFC7653]のセクション6.3.1を参照）が表示される必要があります。
+ OPTION_F_BINDING_STATUS containing the binding-status MUST appear.
+ バインディングステータスを含むOPTION_F_BINDING_STATUSが表示される必要があります。
+ OPTION_F_START_TIME_OF_STATE containing the start-time-of-state MUST appear.
+ 状態の開始時刻を含むOPTION_F_START_TIME_OF_STATEが出現する必要があります。
+ OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time*.
+ OPTION-F_STATE_EXPIRATION_TIME（絶対）には、状態の有効期限*が含まれます。
+ OPTION_F_PARTNER_LIFETIME (absolute) containing the partner-lifetime*.
+ OPTIONAL_F_PARTNER_LIFETIME（絶対）には、partner-lifetime *が含まれます。
+ OPTION_F_EXPIRATION_TIME (absolute) containing the expiration-time*.
+ 有効期限*を含むOPTION_F_EXPIRATION_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.
単一のアスタリスク（*）でマークされた項目は、OPTION_F_BINDING_STATUSの値がタイムアウトに関連付けられている場合にのみ表示される必要があります。それ以外の場合は表示されません。詳細については、セクション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.
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.
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を参照してください。パートナーが追加データの保持に関心を持つ可能性があるもう1つの理由は、Leasequery [RFC5007]、Bulk Leasequery [RFC5460]、またはActive 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秒を超える場合、受信サーバーは接続をドロップする必要があります（SHOULD）。接続が切断された理由を通知するメッセージをログに記録する必要があります。
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.
いつでも前、後、または本質的に別の時間と同じであることができます。 2つの時間の比較を実行するときに、別の時間の+/- 5秒になるすべての時間は、同じ時間を表すと見なされるべきです（SHOULD）。
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メッセージを送信してはなりません（MUST NOT）。
When a BNDUPD message is received, it MUST contain either a single OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option.
BNDUPDメッセージが受信されると、単一のOPTION_CLIENT_DATAオプションまたは単一のOPTION_IAPREFIXオプションのいずれかが含まれている必要があります。
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メッセージにそれを処理するための十分な情報がない場合、「MissingBindingInformation」のOPTION_STATUS_CODEで拒否されます。
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メッセージを受信するサーバーは、各OPTION_CLIENT_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メッセージには、BNDUPDメッセージで受信されたものに対応する、単一のOPTION_CLIENT_DATAオプションまたは単一のOPTION_IAPREFIXオプションのいずれかが含まれている必要があります。
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_CODEを含めるべきではありません。メッセージが必要です。
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.
OPTION_CLIENT_DATAオプションまたはOPTION_IAPREFIXオプションの情報の拒否を示すには、BNDREPLYメッセージのOPTION_CLIENT_DATAオプションまたはOPTION_IAPREFIXオプションのエラーを示すステータスコードにOPTION_STATUS_CODEを含める必要があります（SHOULD）。
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_IAPREFIXオプションの情報を処理する最初のタスクは、クライアント情報（存在する場合）およびリース情報をオプションから抽出し、サーバーのバインディングデータベースのアドレスリースまたはプレフィックスリース情報にアクセスすることです。
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, 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".
OPTION_CLIS_DATAオプションまたはOPTION_IAPREFIXオプションでOPTION_VSSオプションが指定されていて、OPTION_VSSオプションで指定されたVPNが受信サーバーの構成に表示されない場合は、OPTION_STATUS_CODEオプションにステータスを含めて、OPTION_CLIENT_DATAオプションまたはOPTION_IAPREFIXオプション全体を拒否します。 「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".
OPTION_CLIENT_DATAオプションまたはOPTION_IAPREFIXオプションで指定されたリースが、OPTION_CLIENT_DATAオプションを受け取ったフェイルオーバーエンドポイントに関連付けられたリースではない場合、ステータスコードが "ConfigurationConflict"のOPTION_STATUS_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.
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.
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メッセージからの時間が明らかに遅い場合は、OPTION_CLIENT_DATAオプションまたはOPTION_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
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.
受け入れる：OPTION_CLIENT_DATAオプションまたはOPTION_IAPREFIXオプションの時間値がサーバーのバインディングデータベースの時間値よりも遅い場合は、それを受け入れ、そうでない場合は拒否します。
time(1): If the current time is later than the receiving server's state-expiration-time, accept it, else reject it.
time（1）：現在の時刻が受信側サーバーのstate-expiration-timeより遅い場合は、それを受け入れ、そうでない場合は拒否します。
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.
time（2）：OPTION_CLIENT_DATAのOPTION_CLT_TIME値（表示されている場合）が、受信側サーバーのバインディングのstart-time-of-stateの時刻より後である場合は、それを受け入れ、そうでない場合は拒否します。
accept,time(1),time(2): If rejecting, use a status-code of "OutdatedBindingInformation".
accept、time（1）、time（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オプションと受信サーバーのバインディングのクライアントが異なる場合、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.
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.
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_IAPREFIXオプションの情報が受け入れられると、その情報の一部が受信サーバーのバインディングデータベースに格納され、対応するOPTION_CLIENT_DATAオプションまたはOPTION_IAPREFIXオプションがBNDREPLYメッセージに入力されます。 BNDREPLYメッセージのOPTION_CLIENT_DATAオプションまたはOPTION_IAPREFIXオプションに入力する情報については、セクション7.6で説明しています。
The information contained in an accepted OPTION_CLIENT_DATA option is stored in the receiving server's binding database as follows:
The information contained in an accepted OPTION_CLIENT_DATA option is stored in the receiving server's binding database as follows:
1. The OPTION_CLIENTID is used to find the client.
1. OPTION_CLIENTIDは、クライアントを見つけるために使用されます。
2. The other data contained in the top level of the OPTION_CLIENT_DATA option is stored with the client as appropriate.
2. OPTION_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_DATAオプションの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. OPTION_F_BINDING_STATUSは、バインディングステータスとして格納されます。
b. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time.
b. OPTION_F_PARTNER_LIFETIMEは、expiration-timeに格納されます。
c. OPTION_F_STATE_EXPIRATION_TIME is stored in the state-expiration-time.
c. OPTION_F_STATE_EXPIRATION_TIMEは、state-expiration-timeに格納されます。
d. OPTION_CLT_TIME [RFC5007] is stored in the partner-raw-clt-time.
d. OPTION_CLT_TIME [RFC5007]は、partner-raw-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. OPTION_F_PARTNER_RAW_CLT_TIMEは、現在のclient-last-transaction-timeより遅い場合、client-last-transaction-timeを置き換えます。
f. OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it is later than the current partner-lifetime.
f. OPTION_F_EXPIRATION_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:
OPTION_CLIENT_DATAオプションに含まれていない、受け入れられた単一のOPTION_IAPREFIXオプションに含まれる情報は、次のように受信サーバーのバインディングデータベースに格納されます。
1. The IPv6 prefix is used to find the prefix.
1. IPv6プレフィックスは、プレフィックスを見つけるために使用されます。
2. Inside of the IAprefix-options section:
2. IAprefix-optionsセクション内：
a. OPTION_F_BINDING_STATUS is stored as the binding-status.
a. OPTION_F_BINDING_STATUSは、バインディングステータスとして格納されます。
b. OPTION_F_PARTNER_LIFETIME (if any) is stored in the expiration-time.
b. OPTION_F_PARTNER_LIFETIME（存在する場合）は、expiration-timeに格納されます。
c. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the state-expiration-time.
c. OPTION_F_STATE_EXPIRATION_TIME（存在する場合）は、state-expiration-timeに格納されます。
d. OPTION_F_EXPIRATION_TIME (if any) replaces the partner-lifetime if it is later than the current partner-lifetime.
d. OPTION_F_EXPIRATION_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.
サーバーは、すべてのBNDUPDメッセージにBNDREPLYメッセージで応答する必要があります。 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メッセージのすべてまたは特定の部分の受け入れまたは拒否は、OPTION_STATUS_CODEオプションで通知されます。エラーを表すステータスコードを含むOPTION_STATUS_CODEオプションは重要ですが、ステータスコードに成功が含まれるOPTION_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メッセージ内の情報のすべてまたは一部の拒否は、ステータスコードフィールドにエラーがあるOPTION_STATUS_CODEメッセージを使用して、BNDREPLYメッセージで通知されます。この拒否は、オプション階層の最上位レベルまたはオプション階層の最下位レベルの2つのレベルのいずれかで発生します。
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全体：エラーを含むOPTION_STATUS_CODEが、BNDREPLYメッセージの最も外側のオプション（単一のOPTION_CLIENT_DATAオプションまたは単一のOPTION_IAPREFIXオプション）に存在します。この種のエラーの例は、OPTION_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. 単一のアドレスまたはプレフィックス：エラーを含むOPTION_STATUS_CODEは、それ自体がOPTION_IA_NA、OPTION_IA_TA、またはOPTION_IA_PDオプションに含まれている単一のIAADDRまたはIAPREFIXオプションに存在します。この種のエラーの例としては、特定のIPv6アドレスが、受信サーバーの構成に表示されないIAADDRオプションで指定されたことが考えられます。
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.
これらのレベルのいずれかで発生する拒否は、エラーを含むOPTION_STATUS_CODEオプションが表示されるオプション（そのオプションに含まれる他のオプションを含む）に含まれるすべての情報の拒否を示します。逆は当てはまりません。成功を含むOPTION_STATUS_CODEオプションは、含まれているすべての情報が受け入れられたことを意味しません。
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メッセージにOPTION_CLIENT_DATAオプションが含まれている場合、OPTION_CLIENT_DATAオプションには、少なくともclient-optionsセクションに以下に示すデータが含まれている必要があります。
o OPTION_CLIENTID containing the DUID of the client most recently associated with this IPv6 address.
o このIPv6アドレスに最後に関連付けられたクライアントのDUIDを含むOPTION_CLIENTID。
o OPTION_VSS from the BNDUPD message, if any.
o BNDUPDメッセージからのOPTION_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.
+ OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for an IPv6 prefix.
- IPv6 address or IPv6 prefix (with length).
- IPv6アドレスまたはIPv6プレフィックス（長さ付き）。
- Inside of the IAaddr-options or IAprefix-options:
- IAaddr-optionsまたはIAprefix-optionsの内部：
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 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 OPTION_F_BINDING_STATUS containing the binding-status received in the BNDUPD message.
o OPTION_F_BINDING_STATUSには、BNDUPDメッセージで受信したバインディングステータスが含まれます。
o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time received in the BNDUPD message.
o OPTION_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 BNDUPDメッセージで受信したOPTION_F_PARTNER_LIFETIMEの複製を含むOPTION_F_PARTNER_LIFETIME_SENT（絶対）。
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メッセージに、OPTION_CLIENT_DATAオプションに含まれていない単一のOPTION_IAPREFIXオプションが含まれている場合、OPTION_IAPREFIXオプションには少なくとも以下に示すデータが含まれている必要があります。
o IPv6 prefix (with length).
o IPv6プレフィックス（長さあり）。
o IAprefix-options:
o IAprefix-options：
* OPTION_VSS from the BNDUPD message, if any.
* BNDUPDメッセージからのOPTION_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.
* エラーコードを含むOPTION_STATUS_CODE、またはメッセージが必要な場合は成功コードを含みます。 BNDUPDメッセージ内の対応するOPTION_IAPREFIXの情報が受け入れられ、ステータスメッセージが必要ない場合（これは通常のケースです）、OPTION_STATUS_CODEオプションは表示されません。
* OPTION_F_BINDING_STATUS containing the binding-status received in the BNDREPLY message.
* OPTION_F_BINDING_STATUSには、BNDREPLYメッセージで受信したバインディングステータスが含まれます。
* OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time received in the BNDREPLY message.
* OPTION_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.
* BNDREPLYメッセージで受信したOPTION_F_PARTNER_LIFETIMEの複製を含むOPTION_F_PARTNER_LIFETIME_SENT（絶対）。
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メッセージを受信すると、OPTION_CLIENT_DATAオプション全体またはOPTION_IAPREFIXオプション全体に、BNDUPDメッセージ全体の拒否を表すエラーを含むOPTION_STATUS_CODEが含まれる場合があります。囲まれたOPTION_IA_NA、OPTION_IA_TA、またはOPTION_IA_PDオプションには、含まれているオプションのすべてが拒否されたことを示すエラーを含むOPTION_STATUS_CODEも含まれる場合があります。または、個々のIAADDRまたはIAPREFIXオプションに、IAADDRまたはIAPREFIXオプションが拒否されたことを示すエラーを含むOPTION_STATUS_CODEオプションが含まれている場合があります。成功コードを含むOPTION_STATUS_CODEは、どのレベルでも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:
承諾を表すOPTION_CLIENT_DATAのBNDREPLYメッセージに含まれる情報は、次のように適切なクライアントとリースとともに保存されます。
1. The OPTION_CLIENTID is used to find the client.
1. OPTION_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_DATAオプションの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. OPTION_F_PARTNER_LIFETIME_SENTは、acked-partner-lifetimeに格納されます。
b. The partner-lifetime is set to 0 to indicate that no more information needs to be sent to the partner.
b. partner-lifetimeは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_CLIENT_DATAオプションに含まれていない単一のOPTION_IAPREFIXオプションが含まれ、単一のプレフィックスリースに関する情報を表します。 OPTION_IAPREFIXオプションのIAprefix-optionsセクションにエラーを表すOPTION_STATUS_CODEが含まれている場合、対応するBNDUPDメッセージの拒否と見なされます。 OPTION_IAPREFIXオプションにOPTION_STATUS_CODEオプションが含まれていない場合、またはOPTION_STATUS_CODEオプションに成功ステータスが含まれている場合、次のリストの3つの項目は、OPTION_IAPREFIXオプションで表されるプレフィックスリースに関連付けられているセクションのリース状態データベースに格納されます。
1. OPTION_F_BINDING_STATUS containing the binding-status received in the BNDREPLY message.
1. OPTION_F_BINDING_STATUSには、BNDREPLYメッセージで受信したバインディングステータスが含まれます。
2. OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-expiration-time received in the BNDREPLY message.
2. OPTION_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. BNDREPLYメッセージで受信したOPTION_F_PARTNER_LIFETIMEの複製を含むOPTION_F_PARTNER_LIFETIME_SENT（絶対）。
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節で説明されている時間と、それらを送信するために使用されるオプションとの関係を示しています。また、1つのフェイルオーバーパートナーの時間を他のフェイルオーバーパートナーに関連付けます。
----------------------- BNDUPD ---------------------------------
Source on OPTION_F in Storage on
Sending Server -> BNDUPD message -> Receiving Server
[always update]
[常に更新]
partner-lifetime PARTNER_LIFETIME expiration-time
パートナーライフタイムPARTNER_LIFETIME有効期限
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
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
[update only if received > current]
[受信した場合のみ更新>最新]
expiration-time EXPIRATION_TIME partner-lifetime partner-raw-clt-time PARTNER_RAW_CLT_TIME client-last-transaction-time
有効期限EXPIRATION_TIME partner-lifetime partner-raw-clt-time PARTNER_RAW_CLT_TIME client-last-transaction-time
----------------------- BNDREPLY -------------------------------
Storage on OPTION_F in Storage on Receiving Server <- BNDUPD message <- Sending Server
受信サーバー上のストレージ内のOPTION_F上のストレージ<-BNDUPDメッセージ<-送信サーバー
[always update]
[常に更新]
acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received PARTNER_LIFETIME (nothing to update) STATE_EXPIRATION_TIME state-expiration-time
acked-partner-lifetime PARTNER_LIFETIME_SENT受信したPARTNER_LIFETIMEの複製（更新するものはありません）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 割り当てプール-SOLICITの受信時の通知またはREQUEST、RENEW、またはREBINDメッセージの受信時の割り当てに使用できるアドレス（またはプレフィックス）のプール。
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 通信ステータス（「OK」または「OK」ではない）。
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」の場合、STATEメッセージでフェイルオーバーパートナーに新しい状態を通知する必要があります。さらに、サーバーが新しい状態に移行するときは常に、新しい状態、パートナーの状態の現在の理解、および安定したストレージで新しい状態になった時刻を記録する必要があります。
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では、「レスポンシブ」、「rレスポンシブ」、および「レスポンシブ」という用語が状態に表示され、指定された状態のサーバーがそれぞれ応答可能、更新応答、または非応答を許可されているかどうかを示します。各状態の右上隅にある「+」、「-」、または「*」は、他のサーバーとの通信が進行中であるかどうかの表記です。「+」は通信が「OK」、「-」は意味します通信が中断されていること、および「*」は通信が「OK」または中断されていることを意味します。
+---------------+ 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 Current failover state.
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 現在のフェイルオーバー状態：プライマリ：PARTNER-DOWN、セカンダリ：RECOVER。
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 パートナーのフェイルオーバー状態：STATEメッセージを受信するまではありません。
o Start time of partner's failover state: None until reception of STATE message.
o パートナーのフェイルオーバー状態の開始時間：STATEメッセージを受信するまではありません。
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.
STARTUP状態は、サーバーがDHCPクライアントのサービスを開始する前にパートナーサーバーを調査する機会を提供します。サーバーがSTARTUP状態にある場合、サーバーはそのパートナーの状態を学習し、どの状態に入る必要があるかを（使用可能な場合はその情報を使用して）決定しようとします。
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.
STARTUP状態は、ステートマシン図（図6）に特定の状態遷移とともに表示されていません。これは、STARTUP状態中の処理によってサーバーが他の状態に遷移し、特定の状態遷移アークが他の状態遷移を隠すだけだからです。情報。
The server MUST NOT be responsive to DHCP clients in STARTUP state.
サーバーは、STARTUP状態のDHCPクライアントに応答してはなりません（MUST NOT）。
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.
STARTUP状態のときにSTATEメッセージがパートナーに送信される場合は常に、STARTUPフラグをOPTION_F_SERVER_FLAGSオプションに設定する必要があり、以前に記録されたフェイルオーバー状態をOPTION_F_SERVER_STATEオプションに配置する必要があります。
The algorithm below is followed every time the server initializes itself and enters STARTUP state.
以下のアルゴリズムは、サーバーがそれ自体を初期化してSTARTUP状態に入るたびに実行されます。
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.
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.
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を安定したストレージの最後に記録された値に設定し、TIME-OF-FAILUREをサーバーに障害が発生した時間または時間に設定しますそれを超えるとサーバーは動作しなかった可能性があり、ステップ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.
このサーバーの安定したストレージに以前のフェイルオーバー状態の記録がない場合は、PREVIOUS-STATEをRECOVERに設定し、TIME-OF-FAILUREを0に設定します。これにより、すでにリース情報を持っている2つのサーバーが自身を同期できます。運用前。
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サーバーとして動作します。この状況を適切に処理するために、サーバーは、起動期間中にパートナーに連絡できなかった場合に、起動期間が終了した後に直接PARTNER-DOWN状態に移行するように構成可能である必要があります。
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：実装は、フェイルオーバーエンドポイントの状態の状態マシンを処理する方法が異なります。多くの場合、状態遷移は、通信が「OK」から「失敗」または「失敗」から「OK」に移行するときに発生し、一部の実装では、これらの変更に基づいて状態マシン処理の一部を実装します。
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").
これらの場合、起動時にPREVIOUS-STATEが通信が「OK」であった場合、PREVIOUS-STATEをその状態にあるときの通信失敗状態遷移の結果である状態に設定します（そのような遷移が存在する場合） -一部の状態では、「通信OK」と「失敗」の両方が許可されているため、通信失敗状態遷移はありません）。
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：STARTUP状態タイマーを開始します。サーバーがSTARTUP状態のままである時間（そのパートナーとの通信がない場合）は、実装に依存しますが、短い必要があります。負荷の高いパートナーへの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：「通信OK」を待ちます。
When and if communications become "OK", clear the STARTUP flag, and set the CURRENT-STATE to the PREVIOUS-STATE.
通信が「OK」になったら、STARTUPフラグをクリアし、CURRENT-STATEを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.
パートナーがPARTNER-DOWN状態であり、PARTNER-DOWN状態になった時刻（STATEメッセージのOPTION_F_START_TIME_OF_STATEオプションで受信）がこのサーバーの最後に記録された操作時刻より遅い場合は、CURRENT-状態を回復します。 PARTNER-DOWN状態になった時刻が、このサーバーの最後に記録された操作時刻よりも早い場合は、CURRENT-STATEをPOTENTIAL-CONFLICTに設定します。
Then, transition to the CURRENT-STATE and take the "communications OK" state transition based on the CURRENT-STATE of this server and the partner.
次に、CURRENT-STATEに遷移し、このサーバーとパートナーのCURRENT-STATEに基づいて「通信OK」状態遷移を行います。
Step 6: If the startup time expires prior to communications becoming "OK", the server SHOULD transition to PREVIOUS-STATE.
ステップ6：通信が「OK」になる前に起動時間が切れた場合、サーバーはPREVIOUS-STATEに移行する必要があります（SHOULD）。
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.
PARTNER-DOWN状態は、いずれかのサーバーが入ることができる状態です。この状態のとき、サーバーは、それがクライアントベースで動作し、サービスを提供する唯一のサーバーであると想定します。一方のサーバーがPARTNER-DOWN状態の場合、もう一方のサーバーが動作していてはなりません。
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）PARTNER-DOWN状態のオプションの自動パートナーダウン機能の結果として、PARTNER-DOWN状態に入ることができます。サーバーが所定の期間COMMUNICATIONS-INTERRUPTED状態になった後、自動的に入力されます。
The server MUST be responsive in PARTNER-DOWN state, regardless of whether it is primary or secondary.
サーバーは、プライマリかセカンダリかに関係なく、PARTNER-DOWN状態で応答する必要があります。
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アドレス（PARTNER-DOWN状態に入ったとき）は、クライアントに割り当てるべきではありません（SHOULD NOT）。とにかくそうすることを選択した場合、PARTNER-DOWN状態へのエントリを超えて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.
PARTNER-DOWN状態のサーバーは、MCLTが次の最大時間を超えるまで、PARTNER-DOWN状態へのエントリ時に割り当てられたクライアントとは異なるDHCPクライアントにリースを割り当ててはなりません（MUST NOT）。最も最近送信されたパートナーのライフタイム、最も最近受信されたパートナーからのパートナー時間のack、および最も最近のパートナーへのパートナーのライフタイム。この時間が現在の時間とMCLTを足したものよりも早い場合、サーバーがPARTNER-DOWN状態になった時間とMCLTが使用されます。
The server is not restricted by the MCLT when offering valid lifetimes while in PARTNER-DOWN state.
PARTNER-DOWN状態のときに有効なライフタイムを提供する場合、サーバーは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.
2つのサーバーがPARTNER-DOWN状態で動作しているというまれなケースでは、同じプレフィックスに重複したリースが割り当てられる可能性があります。これにより、サーバーが接続を再確立すると、POTENTIAL-CONFLICT（応答なし）状態になります。サーバーが独自のプールから新しいリースを許可する限り、重複したリースのこの問題は防止できます。したがって、PARTNER-DOWN状態で動作しているサーバーは、ダウンしたパートナーのプールからリースを割り当てる前に、まず新しいリース用に独自のプールを使用する必要があります。
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.
PARTNER-DOWN状態のサーバーがそのパートナーへの接続の確立に成功した場合、そのアクションは、接続を確立するプロセスの一部として他のサーバーからSTATEメッセージで受信された状態とフラグを条件とします。
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.
受信したSTATEメッセージのOPTION_F_SERVER_FLAGSオプションでSTARTUPビットが設定されている場合、PARTNER-DOWN状態のサーバーは、通信の再確立に基づいて状態を遷移させてはなりません（MUST NOT）。サーバーがPARTNER-DOWN状態の場合、サーバーは、STATEメッセージのOPTION_F_SERVER_FLAGSオプションでSTARTUPビットが設定されているパートナーからのすべてのSTATEメッセージを無視します。
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):
パートナーから受信したSTATEメッセージのOPTION_F_SERVER_FLAGSオプションでSTARTUPビットが設定されていない場合、PARTNER-DOWN状態のサーバーは、STATEメッセージで受信したパートナーの状態に基づいて、次のアクションを実行します（直後のいずれか）通信を確立するか、いつでも新しい状態が受信されたとき）：
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 パートナーがNORMAL、COMMUNICATIONS-INTERRUPTED、PARTNER-DOWN、POTENTIAL-CONFLICT、RESOLUTION-INTERRUPTED、またはCONFLICT-DONE状態の場合、POTENTIAL-CONFLICT状態に移行します。
o If the partner is in RECOVER or RECOVER-WAIT state, then stay in PARTNER-DOWN state.
o パートナーがRECOVERまたはRECOVER-WAIT状態の場合、PARTNER-DOWN状態のままになります。
o If the partner is in RECOVER-DONE state, then transition to NORMAL state.
o パートナーがRECOVER-DONE状態の場合、NORMAL状態に移行します。
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.
この状態は、サーバーの安定したストレージに情報がないか、サーバーがダウンした後、PARTNER-DOWN状態のサーバーと再統合していることを示します。この状態のサーバーは、他のサーバーから安定したストレージを更新しようとする必要があります。
The server MUST NOT be responsive in RECOVER state.
サーバーはRECOVER状態で応答してはいけません。
A server in RECOVER state will attempt to reestablish communications with the other server.
RECOVER状態のサーバーは、他のサーバーとの通信を再確立しようとします。
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.
通信が再確立されたときに他のサーバーがPOTENTIAL-CONFLICT、RESOLUTION-INTERRUPTED、またはCONFLICT-DONE状態にある場合、RECOVER状態のサーバーはPOTENTIAL-CONFLICT状態に移行します。
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.
他のサーバーが他の状態にある場合、RECOVER状態のサーバーは、UPDREQメッセージを送信して、欠落しているバインディング情報の更新を要求します。サーバーは、パートナーが通信した記録があっても、パートナーと通信した記録がないために、安定したストレージを失ったと判断した場合、UPDREQALLメッセージを送信する必要があります。それ以外の場合は、UPDREQメッセージを送信する必要があります。
It will wait for an UPDDONE message, and upon receipt of that message it will transition to RECOVER-WAIT state.
UPDDONEメッセージを待ち、そのメッセージを受信するとRECOVER-WAIT状態に移行します。
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メッセージの結果の受信中に通信が失敗した場合、サーバーはRECOVER状態のままになり、通信が再確立されたときに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メッセージが受信されない場合、接続をドロップする必要があります（SHOULD）。
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)---------------> |
| |
| |
Figure 7: Transition out of RECOVER State
図7：RECOVER状態からの遷移
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.
サーバーがRECOVER状態にあるときにいつでも通信が失敗した場合、サーバーはRECOVER状態のままになります。通信が復元されると、RECOVER状態からの移行プロセスが再開されます。
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.
サーバーはRECOVER-WAIT状態で応答してはいけません。
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のTIME-OF-FAILURE）に等しい時間が設定されているタイマーを開始する必要があります（既知の場合）。サーバーが起動し（TIME-OF-FAILUREが不明の場合）、さらにMCLT。このタイマーが期限切れになると、サーバーはRECOVER-DONE状態に移行します。
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.
サーバーがフェイルオーバーを実行したことがない場合、この状態で待機する必要はなく、サーバーはすぐにRECOVER-DONE状態に移行する場合があります。ただし、このサーバーのフェールオーバーが実行されているかどうかを判断するには、このサーバーの安定したストレージが失われた可能性があるため、パートナーから提供された情報を利用することが重要です。
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.
サーバーがRECOVER-WAIT状態のときに通信が失敗しても、この状態の操作には影響しません。サーバーは引き続きタイマーを操作する必要があり（SHOULD）、他のサーバーとの通信が失敗した期間中にタイマーが期限切れになると、サーバーはRECOVER-DONE状態に移行する必要があります（SHOULD）。これはまれです-通信が中断されている間、フェイルオーバー状態の遷移は通常行われませんが、この場合、この遷移を禁止する理由はありません。
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.
この状態は、あるサーバーがRECOVER状態から、別のサーバーがPARTNER-DOWNまたはCOMMUNICATIONS-INTERRUPTED状態からNORMAL状態に連動して移行できるようにするために存在します。
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.
RECOVER-DONE状態のサーバーは、更新に応答する必要があり（SHOULD）、更新要求に応答する必要がありますが、更新要求に表示されるリースの状態のみを変更する必要があります。 RECOVER-DONE状態にある場合、追加のリースを割り当ててはならず、リースのレコードがすでにある場合にのみRENEW要求に応答する必要があります。
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.
RECOVER-DONE状態のサーバーは、そのパートナーサーバーがNORMALまたはRECOVER-DONE状態になったと判断すると、NORMAL状態に移行します。
If the partner server enters RECOVER or RECOVER-WAIT state, this server transitions to COMMUNICATIONS-INTERRUPTED.
パートナーサーバーがRECOVERまたはRECOVER-WAIT状態になると、このサーバーはCOMMUNICATIONS-INTERRUPTEDに移行します。
If the partner server enters POTENTIAL-CONFLICT state, this server enters POTENTIAL-CONFLICT state as well.
パートナーサーバーがPOTENTIAL-CONFLICT状態になると、このサーバーもPOTENTIAL-CONFLICT状態になります。
If communication fails while in RECOVER-DONE state, a server will stay in RECOVER-DONE state.
RECOVER-DONE状態で通信が失敗した場合、サーバーはRECOVER-DONE状態のままになります。
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.
NORMAL状態は、サーバーが他のサーバーと通信していて、必要な再同期が実行されているときに、サーバーによって使用される状態です。一部のバインディングデータベース同期はNORMAL状態で実行されますが、バインディングデータベースのデータ損失と同様に、潜在的な競合はNORMAL状態に入る前に解決されます。
When entering NORMAL state, a server will send to the other server all currently unacknowledged binding updates as BNDUPD messages.
NORMAL状態になると、サーバーは他のサーバーに現在未確認のすべてのバインディング更新を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.
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.
The primary server is responsive in NORMAL state. The secondary is renew responsive in NORMAL state.
プライマリサーバーはNORMAL状態で応答します。セカンダリは、NORMAL状態で更新応答します。
When in NORMAL state, a primary server will operate in the following manner:
NORMAL状態の場合、プライマリサーバーは次のように動作します。
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.
パートナーサーバーの遅延更新リース更新を含むREPLYをクライアントに送信した後、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メッセージをパートナーに送信し、バインディング状態をRELEASEDまたはEXPIREDに設定する必要があります。ただし、このメッセージの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).
NORMAL状態では、各サーバーは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 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.
NORMAL状態のサーバーが、実装に依存する期間、パートナーに送信されたメッセージへのACKの受信に失敗した場合、COMMUNICATIONS-INTERRUPTED状態に移行する場合があります。この状況は、パートナーサーバーがサーバー間のTCP接続を維持でき、CONTACTメッセージを定期的に送信できたが、（何らかの理由で）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」で定義されているように「OK」でないと判断された場合、サーバーはCOMMUNICATIONS-INTERRUPTED状態に移行する必要があります。
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.
NORMAL状態のサーバーが、パートナーがNORMAL状態のサーバーが予期する状態から状態を変更したパートナーからメッセージを受信した場合、サーバーはCOMMUNICATIONS-INTERRUPTED状態に移行し、そこから適切な状態移行を行う必要があります。たとえば、パートナーがPOTENTIAL-CONFLICT状態からNORMAL状態に移行すると予想されますが、パートナーがNORMAL状態からPOTENTIAL-CONFLICT状態に移行するとは予想されません。
If a server in NORMAL state receives a DISCONNECT message from its partner, then the server should transition into COMMUNICATIONS-INTERRUPTED state.
NORMAL状態のサーバーがそのパートナーからDISCONNECTメッセージを受信した場合、サーバーはCOMMUNICATIONS-INTERRUPTED状態に移行する必要があります。
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.
サーバーは、パートナーと通信できない場合は常にCOMMUNICATIONS-INTERRUPTED状態になります。プライマリサーバーとセカンダリサーバーは、それらの間のネットワーク接続が失敗して回復するとき、またはパートナーサーバーが稼働状態と非稼働状態の間を循環するときに、NORMAL状態とCOMMUNICATIONS-INTERRUPTED状態の間を（管理者の介入なしに）自動的に循環します。サーバーがこれらの状態の間を循環している間、重複したリースの割り当ては発生しません。
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.
サーバーがCOMMUNICATIONS-INTERRUPTED状態になると、COMMUNICATIONS-INTERRUPTED状態からPARTNER-DOWN状態への自動移行をサポートするように構成されている（つまり、自動パートナーダウンが構成されている）場合、タイマーが開始されます。設定された自動パートナーダウン期間の長さ。
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.
NORMAL状態からCOMMUNICATIONS-INTERRUPTED状態に移行するサーバーは、アラーム状態を発生させて、DHCPサブシステムの潜在的な問題について管理スタッフに警告する必要があります（SHOULD）。
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アドレス範囲から割り当てます。 RENEWメッセージに応答するとき、各サーバーはDHCPクライアントの現在のリースの継続的な更新を許可しますが、そのリースが受信側サーバーから出されたかどうかは関係ありませんが、更新期間は（1）以降のMCLTを超えてはなりません（MUST NOT）他のサーバーによってすでに確認されているパートナーの存続期間、または（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).
ただし、サーバーはこの状態ではパートナーと通信できないため、継続的なRENEWメッセージ処理にもかかわらず、確認されたパートナーの存続期間は更新されません。これにより、最終的に実際のライフタイムが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.
サーバーがCOMMUNICATIONS-INTERRUPTED状態のときに自動パートナーダウンタイマーが期限切れになると、すぐにPARTNER-DOWN状態に移行します。
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.
COMMUNICATIONS-INTERRUPTED状態のサーバーが、パートナーがダウンしていることを通知する外部コマンドを受信すると、すぐにPARTNER-DOWN状態に移行します。
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:
他のサーバーとの通信が復元されると、COMMUNICATIONS-INTERRUPTED状態のサーバーは、パートナーの状態に基づいて別の状態に移行します。
o NORMAL or COMMUNICATIONS-INTERRUPTED: Transition into NORMAL state.
o NORMALまたはCOMMUNICATIONS-INTERRUPTED：NORMAL状態への移行。
o RECOVER: Stay in COMMUNICATIONS-INTERRUPTED state.
o 回復：COMMUNICATIONS-INTERRUPTED状態のままにします。
o RECOVER-DONE: Transition into NORMAL state.
o RECOVER-DONE：NORMAL状態に移行します。
o PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE, or RESOLUTION-INTERRUPTED: Transition into POTENTIAL-CONFLICT state.
o PARTNER-DOWN、POTENTIAL-CONFLICT、CONFLICT-DONE、またはRESOLUTION-INTERRUPTED：POTENTIAL-CONFLICT状態への移行。
Figure 8 illustrates the transition from NORMAL state to COMMUNICATIONS-INTERRUPTED state and then back to NORMAL state again.
図8は、NORMAL状態からCOMMUNICATIONS-INTERRUPTED状態への遷移と、その後再びNORMAL状態への遷移を示しています。
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--< |
| |
Figure 8: Transition from NORMAL State to COMMUNICATIONS-INTERRUPTED State and Back
図8：NORMAL状態からCOMMUNICATIONS-INTERRUPTED状態への遷移とその逆
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.
この状態は、2つのサーバーが相互に再統合しようとしているが、少なくとも1つは自動再統合が可能であることを保証しない状態で実行されていたことを示します。 POTENTIAL-CONFLICT状態では、サーバーは、同じリースが2つの異なるクライアントによって提供および受け入れられたと判断する場合があります。
A goal of the failover protocol is to minimize the possibility that POTENTIAL-CONFLICT state is ever entered.
フェイルオーバープロトコルの目標は、POTENTIAL-CONFLICT状態が発生する可能性を最小限に抑えることです。
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.
プライマリサーバーがPOTENTIAL-CONFLICT状態になると、セカンダリサーバーにUPDREQメッセージを送信して、プライマリサーバーがまだ確認していないすべての更新をセカンダリサーバーに送信するように要求します。
A secondary server entering POTENTIAL-CONFLICT state will wait for the primary to send it an UPDREQ message.
POTENTIAL-CONFLICT状態に入るセカンダリサーバーは、プライマリサーバーがUPDREQメッセージを送信するのを待ちます。
Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming DHCP requests.
Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming DHCP requests.
If communication with the partner fails while in POTENTIAL-CONFLICT state, then the server will transition to RESOLUTION-INTERRUPTED state.
POTENTIAL-CONFLICT状態のときにパートナーとの通信が失敗すると、サーバーはRESOLUTION-INTERRUPTED状態に移行します。
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.
いずれかのサーバーがPOTENTIAL-CONFLICT状態のときにパートナーからUPDDONEメッセージを受信するたびに、新しい状態に遷移する必要があります。プライマリはCONFLICT-DONE状態に移行する必要があり、セカンダリはNORMAL状態に移行する必要があります。プライマリがUPDREQメッセージを送信してUPDDONEメッセージを受信してから、セカンダリがUPDREQメッセージを送信してそのUPDDONEメッセージを受信するため、これにより、プライマリサーバーはセカンダリの前にPOTENTIAL-CONFLICT状態を終了します。
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.
セカンダリサーバーは、プライマリサーバーがPOTENTIAL-CONFLICT状態からCONFLICT-DONE状態に移行したという指示を受信すると、UPDREQメッセージをプライマリサーバーに送信する必要があります（SHOULD）。
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--------------> |
| |
Figure 9: Transition out of POTENTIAL-CONFLICT State
図9：POTENTIAL-CONFLICT状態からの遷移
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.
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 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.
サーバーがPOTENTIAL-CONFLICT状態で応答しないため、RESOLUTION-INTERRUPTED状態が存在し、両方のサーバーがPOTENTIAL-CONFLICT状態であるときに一方のサーバーがサービスを停止すると、サービスを継続しているサーバーはDHCPクライアント要求を処理できなくなります。また、クライアント要求の処理に使用できるDHCPサーバーはありません。 RESOLUTION-INTERRUPTED状態は、POTENTIAL-CONFLICT状態の間にパートナーが消えた場合にサーバーが移動する状態です。
When a server enters RESOLUTION-INTERRUPTED state, it SHOULD raise an alarm condition to alert administrative staff of a problem in the DHCP subsystem.
サーバーがRESOLUTION-INTERRUPTED状態になると、アラーム状態を発生させて、DHCPサブシステムの問題を管理スタッフに警告する必要があります（SHOULD）。
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クライアント要求に応答する必要があります。新しいリースを割り当てる場合、各サーバーは独自のプールから割り当てる必要があります（決定可能な場合）。プライマリスプールはFREEリースのみを割り当て、セカンダリスレッドはFREE-BACKUPリースのみを割り当てる必要があります。更新要求に応答するとき、各サーバーはDHCPクライアントの現在のリースの継続的な更新を許可しますが、そのリースが受信側サーバーによって提供されたかどうかに関係なく、更新期間は（1）を超えてMCLTを超えてはなりません（MUST NOT）他のサーバーによってすでに確認されているパートナーの存続期間、または（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 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.
他のサーバーとの通信が復元されると、RESOLUTION-INTERRUPTED状態のサーバーはPOTENTIAL-CONFLICT状態に移行します。
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.
この状態は、2つのサーバーが相互に再統合しようとしているプロセス中に、プライマリサーバーがセカンダリサーバーからすべての更新を受信したことを示します。クライアントの負荷に完全に応答できるように、CONFLICT-DONE状態に移行します。プライマリサーバーのCONFLICT-DONEとNORMALの間に運用上の違いはありません。どちらの状態でも、プライマリサーバーはすべてのクライアントの要求に応答するためです。ロードバランシング拡張が定義されている場合、CONFLICT-DONE状態とNORMAL状態の区別が必要です。
A primary server in CONFLICT-DONE state is fully responsive to all DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED state).
CONFLICT-DONE状態のプライマリサーバーは、すべてのDHCPクライアントに完全に応答します（COMMUNICATIONS-INTERRUPTED状態の状況と同様）。
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.
通信が失敗した場合は、CONFLICT-DONE状態のままにします。通信が「OK」になった場合は、CONFLICT-DONE状態からの遷移条件が満たされるまでCONFLICT-DONE状態を維持します。
If communication with the partner fails while in CONFLICT-DONE state, then the server will remain in CONFLICT-DONE state.
CONFLICT-DONE状態でパートナーとの通信が失敗した場合、サーバーはCONFLICT-DONE状態のままになります。
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.
プライマリサーバーが、セカンダリサーバーがNORMAL状態に移行したと判断すると、プライマリサーバーもNORMAL状態に移行します。
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アップデート」を使用して、DHCPリースを維持しながらDNS名のマッピングを維持できます。 DHCP-DNS統合の多くの異なる管理モデルが可能です。これらのモデルのいくつかの説明、およびDHCPサーバーとクライアントがそれらを実行する際に従うべきガイドラインは、RFC 4704 [RFC4704]に記載されています。
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更新をサポートする場合は、フェイルオーバーパートナー間で正しく分散するために、ここで説明する手法を利用する必要があります。フェイルオーバーがなくてもDNSを更新するときにDHCPサーバーが潜在的な競合に対処する方法については、RFC 4704 [RFC4704]およびRFC 4703 [RFC4703]を参照してください。
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更新をサポートするように構成されていないサーバーは、フェールオーバーパートナーがDNS更新プロトコルをサポートしてDNSサーバーを更新するように構成されていることを示すBNDUPDメッセージを受信すると、警告メッセージを出力する必要があります（SHOULD）。実装はこれをエラーと見なし、BNDREPLYメッセージのOPTION_STATUS_CODEオプションでステータスDNSUpdateNotSupportedを返すことでBNDUPDメッセージの受け入れを拒否するか、何らかの方法で管理者に問題を警告して動作を選択する場合があります。
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. 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.
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. 2つのフェールオーバーサーバー間で十分な情報を伝達して、他のサーバーが最初にリースを許可した場合でも、1つが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. 1つのパートナーがリースバインディングに関連するリソースレコード（RR）を追加しようとしている一方で、他のパートナーが同じリースバインディングに関連するRRを削除しようとしている状況は避けてください。
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 RRとPTR RRの両方でこれらの操作を実行しますが、これは必須ではありません。 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. 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.
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. フェールオーバーパートナーがFQDNをDNSから削除できるようにするのに十分な情報（必要になった場合）。
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.
これらのデータ項目は、2つのフェールオーバーパートナーが確実に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メッセージにこの情報を含めないことを選択できます（MAY）。
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更新ステータスの概念を更新する必要があります（SHOULD）。
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更新が完了すると2番目のBNDUPDメッセージを送信します。他の実装では、2番目の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と一致しない場合があります。たとえば、いくつかのクライアントのFQDNで最も固有性の高いラベルを変更して、それらに固有のFQDNを生成しようとすることで（2つのプロセスが呼び出されることがあるプロセス）、2つ以上のDHCPクライアントFQDNが同一である状況を処理するように応答サーバーを構成できます。 「曖昧さ回避」）。または、クライアントがFQDNを形成するために提供する情報の一部またはすべてを使用するサイトでは、クライアントの構成が変更され、新しいデータの提供を開始する可能性があります。クライアントと対話するサーバーは、最初にクライアント用に追加したDNSレコードを削除し、クライアントの新しいFQDNを参照するレコードで置き換えることにより、反応する場合があります。このような場合、サーバーは、フェイルオーバーパートナー間で交換されるBNDUPDメッセージの後続のDNS更新オプションで使用された実際のFQDNを含める必要があります（SHOULD）。このサーバーは、BNDUPDメッセージに関連情報を含める必要があります（SHOULD）。この情報は、クライアントが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更新を開始する必要があります（SHOULD）。リースを許可しなかったサーバーは、リースが許可された後にBNDUPDメッセージを受信したときにDNS更新を開始してはなりません（SHOULD NOT）。フェイルオーバープロトコルは、一方のパートナーのみが個々のクライアントにリースを付与することを保証します。したがって、この要件により、両方のパートナーが同時に更新を開始することが防止されます。更新を開始するサーバーは、RFC 4704 [RFC4704]のプロトコルに従う必要があります（SHOULD）。サーバーは、そのクライアントに代わってAAAA RR更新を実行するように構成することも、しないように構成することもできます。通常、フェイルオーバーサーバーは、リースを更新するときにDNS更新を開始しません。ただし、次の2つの場合、フェイルオーバーサーバーは、既存のクライアントへのリースを更新するときに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更新を実行するようにサーバーを構成する前にリースが許可された場合、サーバーは、次に既存のリースを更新するときに更新を実行するように構成できます（MAY）。
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. サーバーがPARTNER-DOWN状態の場合、そのパートナーは既存のクライアントの更新を実行しようとしていないと結論付けることができます。残りのサーバーがバインディングの更新が正常に完了したことを記録していない場合、サーバーはDNS更新を開始できます（MAY）。 PARTNER-DOWN状態に入るとすぐにこの更新を開始したり、バックグラウンドで実行したり、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を更新することは、DHCPサーバーの情報に正確に対応する情報がDNSにあることを徐々に確認する1つの方法です。
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削除を開始する必要があります（SHOULD）。
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.
PARTNER-DOWN状態にないサーバーは、バインディングステータスがFREE、FREE-BACKUP、EXPIRED、またはRELEASEDのBNDUPDメッセージを開始すると、「リースをPENDING-FREEにする」。そのパートナーは、そのBNDUPDメッセージを確認することでこのステータスを確認し、BNDREPLYメッセージを受信すると、サーバーは「リースをPENDING-FREEにリースしました」。逆に、PARTNER-DOWN状態のサーバーは、バインディングステータスをFREEに設定すると、「リースをPENDING-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からRRを削除するためにDNS操作を開始するのはこの時点です。そのパートナーは、BNDREPLYメッセージの送信の一部として、リースバインディングに関連するDNSレコードのDNS削除を開始してはなりません（SHOULD NOT）。パートナーは、バインディングステータスがFREE、EXPIRED、またはRELEASEDの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.
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.
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.
このアプローチのもう1つの影響は、どちらのサーバーもCOMMUNICATIONS-INTERRUPTED状態にある間はDNS RR削除が実行されないことです。その期間中にリースはPENDING-FREE状態に移行しないためです。
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.
フェイルオーバーサーバーは、リースをPENDING-FREEにして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に入力されません。これは通常、クライアントから受け取った情報から検出または生成した名前です。この場合、この名前情報はフェイルオーバーパートナーに通信する必要があります（SHOULDは、パートナーが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フェールオーバーは、セキュアモードまたは非セキュアモードで動作できます。セキュアモード（トランスポート層セキュリティ（TLS）[RFC5246]を使用）は、フェイルオーバーパートナー間のTCP接続が外部の監視または傍受に対して開かれている場合に示されます。安全でないモードは、フェイルオーバーパートナー間の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サーバーとして機能することによって提供される以外に、アドレスの割り当てと構成を中断する機会はありません。単一のTCP接続のみを保護する必要があるため、両方の脅威からの保護は、基本的なDHCPv6よりも簡単です。セキュアモードを使用してその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を使用して接続を保護します。 [RFC7525]の推奨事項は、TLS接続をネゴシエートするときに従う必要があります。
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接続を作成するために提示されたデジタル証明書の検証と使用を通じて、着信接続のソースを制限する構成パラメーターを提供する必要があります（SHOULD）。また、受け入れられる接続の数を制限し、アイドル状態の接続を開いたままにする期間を制限する必要があります（SHOULD）。
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]は、このドキュメントで説明されているメッセージの安全な送信を試みるために使用してはなりません（MUST NOT）。認証が必要な場合は、[RFC7653]のセクション8.2および9.1で説明されているように、TLSを使用したセキュアモードを採用する必要があります（SHOULD）。
IANA has assigned values for the following new DHCPv6 message types in the registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>:
IANAは、<http://www.iana.org/assignments/ dhcpv6-parameters>で管理されているレジストリで、次の新しいDHCPv6メッセージタイプの値を割り当てました。
o BNDUPD (24)
o バンプ（24）
o BNDREPLY (25)
o 応急処置（25）
o POOLREQ (26)
o プール（26）
o POOLRESP (27)
o プールレス（27）
o UPDREQ (28)
o アップドレー（28）
o UPDREQALL (29)
o アップリクエスト（29）
o UPDDONE (30)
o アップドン（30）
o CONNECT (31)
o 接続（31）
o CONNECTREPLY (32)
o CONNECTREPLY（32）
o DISCONNECT (33)
o 切断する（33）
o STATE (34)
o 州（34）
o CONTACT (35) IANA has assigned values for the following new DHCPv6 option codes in the registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>:
o連絡先（35）IANAは、<http://www.iana.org/assignments/ dhcpv6-parameters>で管理されているレジストリで、次の新しいDHCPv6オプションコードの値を割り当てました。
o OPTION_F_BINDING_STATUS (114)
o OPTION_F_BINDING_STATUS (114)
o OPTION_F_CONNECT_FLAGS (115)
o OPTION_F_CONNECT_FLAGS（115）
o OPTION_F_DNS_REMOVAL_INFO (116)
o OPTION_F_DNS_REMOVAL_INFO（116）
o OPTION_F_DNS_HOST_NAME (117)
o OPTION_F_DNS_HOST_NAME（117）
o OPTION_F_DNS_ZONE_NAME (118)
o OPTION_F_DNS_ZONE_NAME（118）
o OPTION_F_DNS_FLAGS (119)
o OPTION_F_DNS_FLAGS（119）
o OPTION_F_EXPIRATION_TIME (120)
o OPTION_F_EXPIRATION_TIME（120）
o OPTION_F_MAX_UNACKED_BNDUPD (121)
o OPTION_F_MAX_UNACKED_BNDUPD（121）
o OPTION_F_MCLT (122)
o OPTION_F_MCLT（122）
o OPTION_F_PARTNER_LIFETIME (123)
o OPTION_F_PARTNER_LIFETIME（123）
o OPTION_F_PARTNER_LIFETIME_SENT (124)
o OPTION_F_PARTNER_LIFETIME_SENT（124）
o OPTION_F_PARTNER_DOWN_TIME (125)
o OPTION_F_PARTNER_DOWN_TIME（125）
o OPTION_F_PARTNER_RAW_CLT_TIME (126)
o OPTION_F_PARTNER_RAW_CLT_TIME（126）
o OPTION_F_PROTOCOL_VERSION (127)
o OPTION_F_PROTOCOL_VERSION（127）
o OPTION_F_KEEPALIVE_TIME (128)
o OPTION_F_KEEPALIVE_TIME（128）
o OPTION_F_RECONFIGURE_DATA (129)
o OPTION_F_RECONFIGURE_DATA（129）
o OPTION_F_RELATIONSHIP_NAME (130)
o OPTION_F_RELATIONSHIP_NAME（130）
o OPTION_F_SERVER_FLAGS (131)
o OPTION_F_SERVER_FLAGS（131）
o OPTION_F_SERVER_STATE (132)
o OPTION_F_SERVER_STATE (132)
o OPTION_F_START_TIME_OF_STATE (133)
o OPTION_F_START_TIME_OF_STATE（133）
o OPTION_F_STATE_EXPIRATION_TIME (134) IANA has assigned values for the following new DHCPv6 status codes in the registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>:
o OPTION_F_STATE_EXPIRATION_TIME（134）IANAは、<http://www.iana.org/assignments/ dhcpv6-parameters>で管理されているレジストリの次の新しいDHCPv6ステータスコードに値を割り当てました。
o AddressInUse (16)
o アドレス使用中（16）
o ConfigurationConflict (17)
o 構成の競合（17）
o MissingBindingInformation (18)
o MissingBindingInformation（18）
o OutdatedBindingInformation (19)
o OutdatedBindingInformation (19)
o ServerShuttingDown (20)
o ServerShuttingDown（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.、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>。
[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.、and M. Carney、 "Dynamic Host Configuration Protocol for 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] Brzozowski、J.、Kinnear、K.、Volz、B。、およびS. Zeng、「DHCPv6 Leasequery」、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、「The Transport Layer Security（TLS）Protocol Version 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 Bulk Leasequery」、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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（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 Active Leasequery」、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 / RFC7031、2013年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 Editorは、いくつかの重要な技術的問題も捉えました。著者は、洞察に満ちたコメントを提供してくれた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
Tomek Mrugalski Internet Systems Consortium、Inc. 950 Charter Street Redwood City、California 94063アメリカ合衆国
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. 200 Beaver Brook Road Boxborough、Massachusetts 01719アメリカ合衆国
Phone: +1 978 936 0000
Email: kkinnear@cisco.com