[要約] RFC 7031は、DHCPv6のフェイルオーバー要件に関する規格です。このRFCの目的は、DHCPv6サーバの冗長性と可用性を向上させるためのフェイルオーバー機能の要件を定義することです。
Internet Engineering Task Force (IETF) T. Mrugalski
Request for Comments: 7031 ISC
Category: Informational K. Kinnear
ISSN: 2070-1721 Cisco
September 2013
DHCPv6 Failover Requirements
DHCPv6フェイルオーバー要件
Abstract
概要
The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. RFC 3315 allows for, but does not define, any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol.
RFC 3315で定義されているDHCPv6プロトコルでは、複数のサーバーが単一のネットワーク上で動作することができます。ただし、サーバーが現在アクティブなクライアントとそのリースに関する情報を共有する方法は定義されていません。一部のサイトでは、サーバーに障害が発生した場合に可用性を向上させるような方法で複数のサーバーを実行することに関心があります。これが確実に機能するためには、連携するプライマリサーバーとセカンダリサーバーがリース情報の一貫したデータベースを維持する必要があります。 RFC 3315では、冗長性やフェイルオーバーのメカニズムは許可されていますが、定義されていません。このドキュメントでは、DHCPv6フェールオーバーの要件の概要を示し、関連する問題を列挙し、実施すべき作業の提案された範囲について説明します。このドキュメントでは、DHCPv6フェイルオーバープロトコルを定義していません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション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/rfc7031.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7031で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 ....................................................3
2. Definitions .....................................................3
3. Scope of Work ...................................................5
3.1. Alternatives to Failover ...................................5
3.1.1. Short-Lived Addresses ...............................5
3.1.2. Redundant Servers ...................................6
3.1.3. Distributed Databases ...............................6
3.1.4. Load Balancing ......................................7
4. Failover Scenarios ..............................................7
4.1. Hot Standby Model ..........................................7
4.2. Geographically Distributed Failover ........................7
4.3. Load Balancing .............................................8
4.4. 1-to-1, m-to-1, and m-to-n Models ..........................8
4.5. Split Prefixes .............................................8
4.6. Long-Lived Connections .....................................8
4.7. Partial Server Communication Loss ..........................9
5. Principles of DHCPv6 Failover ...................................9
5.1. Failure Modes ..............................................9
5.1.1. Server Failure .....................................10
5.1.2. Network Partition ..................................10
5.2. Synchronization Mechanisms ................................11
5.2.1. Lockstep ...........................................11
5.2.2. Lazy Updates .......................................12
6. DHCPv4 and DHCPv6 Failover Comparison ..........................12
7. DHCPv6 Failover Requirements ...................................13
7.1. Features out of Scope .....................................14
8. Security Considerations ........................................15
9. Acknowledgements ...............................................15
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................16
The DHCPv6 protocol, defined in [RFC3315], allows for multiple servers to be operating on a single network; however, it does not define how the servers can share the same address and prefix delegation pools and allow a client to seamlessly extend its existing leases when the original server is down. [RFC3315] provides for these capabilities but does not document how the servers cooperate and communicate to provide this capability. Some sites are interested in running multiple servers in such a way as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information.
[RFC3315]で定義されているDHCPv6プロトコルにより、複数のサーバーを単一のネットワーク上で動作させることができます。ただし、サーバーが同じアドレスとプレフィックス委任プールを共有し、クライアントが元のサーバーがダウンしたときに既存のリースをシームレスに拡張できるようにする方法は定義していません。 [RFC3315]はこれらの機能を提供しますが、この機能を提供するためにサーバーがどのように連携および通信するかを文書化していません。一部のサイトでは、サーバーに障害が発生した場合に冗長性を提供するような方法で複数のサーバーを実行することに関心があります。これが確実に機能するためには、連携するプライマリサーバーとセカンダリサーバーがリース情報の一貫したデータベースを維持する必要があります。
This document discusses failover implementations scenarios, failure modes, and synchronization approaches to provide background to the list of requirements for a DHCPv6 failover protocol. It then defines a minimum set of requirements that failover must provide to be useful, while acknowledging that additional features may be specified as extensions. This document does not define a DHCPv6 failover protocol.
このドキュメントでは、フェールオーバーの実装シナリオ、障害モード、および同期アプローチについて説明し、DHCPv6フェールオーバープロトコルの要件リストの背景を提供します。次に、追加機能が拡張機能として指定される場合があることを認めながら、フェイルオーバーが役立つために提供する必要のある一連の最小要件を定義します。このドキュメントでは、DHCPv6フェイルオーバープロトコルを定義していません。
The failover model, to which these requirements apply, will initially be a pairwise "hot standby" model (see Section 4.1) with a primary server used in normal operation switching over to a backup secondary server in the event of failure. Optionally, a secondary server may provide failover service for multiple primary servers. However, the requirements will not preclude a future load-balancing extension where there is a symmetric failover relationship.
これらの要件が適用されるフェイルオーバーモデルは、最初はペアワイズの「ホットスタンバイ」モデル（セクション4.1を参照）になり、通常の運用でプライマリサーバーが使用され、障害が発生するとバックアップセカンダリサーバーに切り替わります。オプションで、セカンダリサーバーは複数のプライマリサーバーにフェイルオーバーサービスを提供できます。ただし、この要件は、対称的なフェイルオーバー関係がある将来のロードバランシング拡張を妨げるものではありません。
The DHCPv6 failover concept borrows heavily from its DHCPv4 counterpart [DHCPV4-FAILOVER] that never completed the standardization process but has several successful, operationally proven vendor-specific implementations. For a discussion about commonalities and differences, see Section 6.
DHCPv6フェイルオーバーの概念は、標準化プロセスを完了していないものの、運用上実証されたベンダー固有の実装がいくつか成功しているDHCPv4の対応物[DHCPV4-FAILOVER]から大きく借りています。共通点と相違点については、セクション6を参照してください。
This section defines terms that are relevant to DHCPv6 failover.
このセクションでは、DHCPv6フェイルオーバーに関連する用語を定義します。
Definitions from [RFC3315] are included by reference. In particular, "client" means any device, e.g., end-user host, CPE (Customer Premises Equipment), or other router that implements client functionality of the DHCPv6 protocol. A "server" is a DHCPv6 server, unless explicitly noted otherwise. A "relay" is a DHCPv6 relay.
[RFC3315]の定義は参照により含まれています。特に、「クライアント」とは、DHCPv6プロトコルのクライアント機能を実装する任意のデバイス、たとえばエンドユーザーホスト、CPE（顧客宅内機器）、またはその他のルーターを意味します。 「サーバー」は、特に明記されていない限り、DHCPv6サーバーです。 「リレー」はDHCPv6リレーです。
Binding (or client binding): a group of server data records containing the information the server has about the addresses in an IA (Identity Association, see Section 10 of [RFC3315]) or configuration information explicitly assigned to the client. Configuration information that has been returned to a client through a policy -- for example, the information returned to all clients on the same link -- does not require a binding.
バインド（またはクライアントバインド）：IA（ID関連付け、[RFC3315]のセクション10を参照）のアドレスについてサーバーが持つ情報、またはクライアントに明示的に割り当てられた構成情報を含むサーバーデータレコードのグループ。ポリシーを介してクライアントに返された構成情報（たとえば、同じリンク上のすべてのクライアントに返された情報）は、バインディングを必要としません。
DNS Update: the capability to update a DNS server's name database using the on-the-wire protocol defined in [RFC2136]. Clients and servers can negotiate the scope of such updates as defined in [RFC4704].
DNS更新：[RFC2136]で定義されているオンザワイヤプロトコルを使用してDNSサーバーの名前データベースを更新する機能。クライアントとサーバーは、[RFC4704]で定義されているように、そのような更新の範囲を交渉できます。
Failover: the ability of one partner to continue offering services provided by another partner, with minimal or no impact on clients.
フェイルオーバー：クライアントへの影響を最小限に抑えて、またはまったく影響を与えずに、あるパートナーが別のパートナーが提供するサービスを継続して提供する能力
FQDN: a fully qualified domain name. A fully qualified domain name generally is a host name with at least one domain label under the top-level domain. For example, "dhcp.example.org" is a fully qualified domain name.
FQDN：完全修飾ドメイン名。完全修飾ドメイン名は通常、トップレベルドメインの下に少なくとも1つのドメインラベルが付いたホスト名です。たとえば、「dhcp.example.org」は完全修飾ドメイン名です。
High Availability: a desired property of DHCPv6 servers to continue providing services despite experiencing unwanted events such as server crashes, link failures, or network partitions.
高可用性：サーバークラッシュ、リンク障害、ネットワークパーティションなどの不要なイベントが発生してもサービスを継続して提供するためのDHCPv6サーバーの望ましい特性。
Load Balancing: the ability for two or more servers to each process some portion of the client request traffic in a conflict-free fashion.
負荷分散：2つ以上のサーバーがクライアントの要求トラフィックの一部を競合のない方法でそれぞれ処理する機能。
Lease: an IPv6 address, an IPv6 prefix, or other resource that was assigned ("leased") by a server to a specific client. A lease may include additional information, like associated fully qualified domain name (FQDN) and/or information about associated DNS updates. A client obtains a lease for a specified period of time (valid lifetime).
リース：サーバーによって特定のクライアントに割り当てられた（「リースされた」）IPv6アドレス、IPv6プレフィックス、またはその他のリソース。リースには、関連する完全修飾ドメイン名（FQDN）や関連するDNS更新に関する情報などの追加情報が含まれる場合があります。クライアントは、指定された期間（有効な有効期間）のリースを取得します。
Partner: A "partner", for the purpose of this document, refers to a failover server, typically the other failover server in a failover relationship.
パートナー：このドキュメントでは、「パートナー」とは、フェイルオーバーサーバー、通常はフェイルオーバー関係にある他のフェイルオーバーサーバーを指します。
Stable Storage: each DHCP server is required to keep its lease database in some form of storage (known as "stable storage") that will be consistent throughout reboots, crashes, and power failures.
安定した記憶域：各DHCPサーバーは、リースデータベースを何らかの形の記憶域（ "安定した記憶域"と呼ばれます）に保持する必要があります。これは、再起動、クラッシュ、電源障害が発生しても一貫しています。
Partner Failure: A power outage, unexpected shutdown, crash, or other type of failure that renders a partner unable to continue its operation.
パートナーの障害：停電、予期しないシャットダウン、クラッシュ、またはパートナーが操作を続行できなくなるその他の種類の障害。
In order to fit within the IETF process effectively and efficiently, the standardization effort for DHCPv6 failover is expected to proceed with the creation of documents of increasing specificity.
IETFプロセス内に効果的かつ効率的に適合するために、DHCPv6フェイルオーバーの標準化作業では、より詳細なドキュメントの作成を進めることが期待されています。
Requirements document: It begins with this document specifying the requirements for DHCPv6 failover.
要件ドキュメント：DHCPv6フェイルオーバーの要件を指定するこのドキュメントから始まります。
Design document: A later document is expected to address the design of the DHCPv6 failover protocol.
設計文書：DHCPv6フェイルオーバープロトコルの設計に対処するための新しい文書が予定されています。
Protocol document: If sufficient interest exists, a later document is expected to address the protocol details required to implement the DHCPv6 failover protocol itself.
プロトコルドキュメント：十分な関心が存在する場合、DHCPv6フェールオーバープロトコル自体を実装するために必要なプロトコルの詳細に対処するために、後のドキュメントが期待されます。
The goal of this partitioning is, in part, to ease the validation, review, and approval of the DHCPv6 failover protocol by presenting it in comprehensible parts to the larger community.
このパーティショニングの目的の1つは、DHCPv6フェールオーバープロトコルの検証、レビュー、および承認を、大規模なコミュニティにわかりやすい部分で提供することにより、DHCPv6フェールオーバープロトコルの検証を容易にすることです。
Additional documents describing extensions may also be defined.
拡張機能を説明する追加のドキュメントも定義できます。
DHCPv6 failover requirements are presented in Section 7.
DHCPv6フェイルオーバー要件については、セクション7で説明します。
There are many scenarios in which a failover capability would be useful. However, there are often much simpler approaches that will meet the required goals. This section documents examples where failover is not really needed.
フェイルオーバー機能が役立つシナリオは多数あります。ただし、多くの場合、必要な目標を達成するためのより単純なアプローチがあります。このセクションでは、フェイルオーバーが実際に必要ない例について説明します。
There are cases when IPv6 addresses are used only for a short time, but there is a need to have high degree of confidence that those addresses will be served. A notable example is PXE (Preboot eXecution Environment) [RFC5970]. This is a mechanism for obtaining configuration early in the process of bootstrapping over the network.
IPv6アドレスが短時間だけ使用される場合がありますが、それらのアドレスが提供されるという高い信頼度が必要です。注目すべき例は、PXE（Preboot eXecution Environment）[RFC5970]です。これは、ネットワークを介したブートストラッププロセスの早い段階で構成を取得するためのメカニズムです。
The PXE BIOS acquires an address in order to load the operating system image and continue booting. Address and possibly other configuration parameters are used during the boot process and are discarded thereafter. Any lack of available DHCPv6 service at this time will prevent such devices from booting.
PXE BIOSは、オペレーティングシステムイメージをロードしてブートを続行するためにアドレスを取得します。アドレスおよびその他の構成パラメーターは、ブートプロセス中に使用され、その後破棄されます。現時点で利用可能なDHCPv6サービスがないと、そのようなデバイスは起動できなくなります。
Instead of deploying failover, it is better to use the much simpler preference mechanism, defined in [RFC3315]. For example, consider two or more servers with each having a distinct preference set (e.g., 10 and 20). Both will answer a client's request. The client should choose the one with the larger preference value. In case of failure of the most preferred server, the next server will keep responding to clients' queries. This approach is simple to deploy but does not offer lease stability, i.e., in case of server failure, clients' addresses and prefixes will change.
フェイルオーバーを配備する代わりに、[RFC3315]で定義されている、はるかに単純な設定メカニズムを使用することをお勧めします。たとえば、2つ以上のサーバーがあり、それぞれに異なるプリファレンスセット（10と20など）があるとします。どちらもクライアントの要求に答えます。クライアントは、設定値が大きい方を選択する必要があります。最も優先されるサーバーに障害が発生した場合、次のサーバーがクライアントのクエリに応答し続けます。このアプローチは簡単に導入できますが、リースの安定性はありません。つまり、サーバーに障害が発生した場合、クライアントのアドレスとプレフィックスが変更されます。
In some cases, the desire to deploy failover is motivated by high availability, i.e., to continue providing services despite server failure. If there are no additional requirements, that goal may be fulfilled with simply deploying two or more independent servers on the same link.
場合によっては、フェイルオーバーを導入したいという願望は、高可用性、つまりサーバー障害が発生してもサービスの提供を継続することによって動機付けられます。追加の要件がない場合は、同じリンクに2つ以上の独立したサーバーを配置するだけでその目標を達成できます。
There are several well-documented approaches showing how such a deployment could work. They are discussed in detail in [RFC6853]. Each of those approaches is simpler to deploy and maintain than full failover.
このような展開がどのように機能するかを示す、十分に文書化されたアプローチがいくつかあります。それらは[RFC6853]で詳細に議論されています。これらのアプローチはそれぞれ、完全なフェイルオーバーよりも導入と保守が簡単です。
Some servers may allow their lease database to be stored in external databases. Another possible alternative to failover is to configure two servers to connect to the same distributed database.
一部のサーバーでは、リースデータベースを外部データベースに保存できます。フェイルオーバーのもう1つの方法は、同じ分散データベースに接続するように2つのサーバーを構成することです。
Care should be taken to understand how inconsistencies are solved in such database backends and how such conflict resolutions affect DHCPv6 server operation.
このようなデータベースバックエンドで不整合がどのように解決されるか、およびそのような競合解決がDHCPv6サーバーの動作にどのように影響するかを理解するように注意する必要があります。
It is also essential to use only a database that provides equivalent reliability and failover capability. Otherwise, the single point of failure is only moved to a different location (database rather than DHCPv6 server). Such a configuration does not improve redundancy but significantly complicates deployment.
また、同等の信頼性とフェイルオーバー機能を提供するデータベースのみを使用することも不可欠です。それ以外の場合、単一障害点は別の場所（DHCPv6サーバーではなくデータベース）にのみ移動されます。このような構成では冗長性は向上しませんが、展開が大幅に複雑になります。
A common misconception regarding database-based redundancy is the assumption that a conflict resolution after recovering from a network partition is not necessary. To explain that fallacy, let's consider an example where there is a very small pool with only one address. There are two servers, each connected to a co-located database node (i.e., running on the same hardware). Network partition occurs. Each server is operating but has lost connection to its partner. Two clients request an address, one from each server. Each server consults its database and discovers that only one address is available, so it is assigned to the client. Unfortunately, each server assigned the same address to a different client. Making the scenario more realistic (millions of addresses rather than one) just decreased failure probability, but it did not eliminate the underlying issue.
データベースベースの冗長性に関する一般的な誤解は、ネットワークパーティションから回復した後の競合解決は不要であるという仮定です。その誤りを説明するために、アドレスが1つだけの非常に小さなプールがある例を考えてみましょう。 2つのサーバーがあり、それぞれが同じ場所にあるデータベースノードに接続されています（つまり、同じハードウェアで実行されています）。ネットワークパーティションが発生します。各サーバーは動作していますが、パートナーとの接続が失われています。 2つのクライアントが、各サーバーに1つずつアドレスを要求します。各サーバーはそのデータベースを調べ、使用可能なアドレスが1つだけであることを検出し、そのアドレスがクライアントに割り当てられます。残念ながら、各サーバーは異なるクライアントに同じアドレスを割り当てました。シナリオをより現実的なものにすると（1つではなく数百万のアドレス）、失敗の可能性が減少しましたが、根本的な問題は解消されませんでした。
Any solution that involves a distributed database implementation of DHCPv6 failover must take into account the requirements for security. See Section 8 for additional information.
DHCPv6フェイルオーバーの分散データベース実装を含むソリューションでは、セキュリティの要件を考慮する必要があります。詳細については、セクション8を参照してください。
Sometimes the desire to deploy more than one server is based on the assumption that they will share the client traffic. Administrators that are interested in such a capability are advised to deploy a load-balancing mechanism, defined in [LOAD-BALANCING].
複数のサーバーを展開したいという要求は、クライアントトラフィックを共有するという前提に基づいている場合があります。このような機能に関心がある管理者は、[LOAD-BALANCING]で定義されている負荷分散メカニズムをデプロイすることをお勧めします。
The following sections provide several examples of deployment scenarios and use cases that may be associated with capabilities commonly referred to as "failover". These scenarios may be in or out of scope for the DHCPv6 failover protocol to which this document's requirements apply; they are enumerated here to provide a common basis for discussion.
以下のセクションでは、一般に「フェイルオーバー」と呼ばれる機能に関連付けられている可能性のあるデプロイメントシナリオとユースケースのいくつかの例を示します。これらのシナリオは、このドキュメントの要件が適用されるDHCPv6フェールオーバープロトコルの範囲内または範囲外である可能性があります。それらは、議論のための共通の基礎を提供するためにここに列挙されています。
In the simplest case, there are two partners that are connected to the same network. Only one of the partners ("primary") provides services to clients. In case of its failure, the second partner ("secondary") continues handling services previously handled by the first partner. As both servers are connected to the same network, a partner that fails to communicate with its partner while also receiving requests from clients may assume with high probability that its partner is down and the network is functional. This assumption may affect its operation.
最も単純なケースでは、同じネットワークに接続された2つのパートナーがあります。パートナーの1つ（「プライマリ」）のみがクライアントにサービスを提供します。障害が発生した場合、2番目のパートナー（「セカンダリ」）は、最初のパートナーが以前に処理したサービスの処理を続行します。両方のサーバーが同じネットワークに接続されているため、クライアントからの要求も受信しながらパートナーとの通信に失敗したパートナーは、そのパートナーがダウンしていてネットワークが機能している可能性が高いと考えています。この仮定はその動作に影響を与える可能性があります。
Servers may be physically located in separate locations. A common example of such a topology is where a service provider has at least a regional high performance network between geographically distributed data centers. In such a scenario, one server is located in one data center, and its failover partner is located in another remote data center. In this scenario, when one partner finds that it cannot communicate with the other partner, it does not necessarily mean that the other partner is down.
サーバーは物理的に別の場所に配置されている場合があります。このようなトポロジの一般的な例は、サービスプロバイダーが地理的に分散したデータセンター間に少なくとも地域の高性能ネットワークを持っている場合です。このようなシナリオでは、1つのサーバーが1つのデータセンターに配置され、そのフェールオーバーパートナーが別のリモートデータセンターに配置されます。このシナリオでは、一方のパートナーが他方のパートナーと通信できないことがわかっても、必ずしも他方のパートナーがダウンしているとは限りません。
A desire to have more than one server in a network may also be created by the desire to have incoming traffic be handled by several servers. This decreases the load each server must endure when all servers are operational. Although such a capability does not, strictly, require failover -- it is clear that failover makes such an architecture more straightforward.
ネットワークに複数のサーバーを配置したいという要望は、着信トラフィックを複数のサーバーで処理したいという要望によっても作成されます。これにより、すべてのサーバーが稼働しているときに各サーバーが耐えなければならない負荷が軽減されます。そのような機能は、厳密にはフェイルオーバーを必要としませんが、フェイルオーバーがそのようなアーキテクチャーをより簡単にすることは明らかです。
Note that in a load-balancing situation that includes failover, each individual server must be able to handle the full load normally handled by both servers working together, or there is not a true increase in availability.
フェイルオーバーを含む負荷分散の状況では、個々のサーバーが、両方のサーバーが連携して通常処理する全負荷を処理できる必要があります。そうしないと、真の可用性が向上しません。
A failover relationship for a specific network is provided by two failover partners. Those partners communicate with each other and back up all pools. This scenario is sometimes referred to as the 1-to-1 model and is considered relatively simple. In larger networks, one server may be participating in several failover relationships, i.e., it provides failover for several address or prefix pools, each served by separate partners. Such a scenario can be referred to as m-to-1. The most complex scenario, m-to-n, assumes that each partner participates in multiple failover relationships.
特定のネットワークのフェイルオーバー関係は、2つのフェイルオーバーパートナーによって提供されます。これらのパートナーは互いに通信し、すべてのプールをバックアップします。このシナリオは1対1モデルと呼ばれることもあり、比較的単純であると考えられています。大規模なネットワークでは、1つのサーバーが複数のフェイルオーバー関係に参加している可能性があります。つまり、1つのサーバーが複数のアドレスまたはプレフィックスプールにフェイルオーバーを提供し、それぞれが別々のパートナーによって提供されます。このようなシナリオは、m-to-1と呼ばれます。最も複雑なシナリオであるm-to-nは、各パートナーが複数のフェイルオーバー関係に参加していることを前提としています。
Due to the extensive IPv6 address space, it is possible to provide semi-redundant service by splitting the available pool of addressees into two or more non-overlapping pools, with each server handling its own smaller pool. Several versions of such a scenario are discussed in [RFC6853].
広範なIPv6アドレス空間により、利用可能なアドレスのプールを2つ以上の重複しないプールに分割し、各サーバーが独自の小さなプールを処理することで、半冗長サービスを提供できます。そのようなシナリオのいくつかのバージョンは[RFC6853]で議論されています。
Certain nodes may maintain long-lived connections. Since the IPv6 address space is large, techniques exist (e.g., [RFC6853]) that use the easy availability of IPv6 addresses in order to provide increased DHCPv6 availability. However, these approaches do not generally provide for stable IPv6 addresses for DHCPv6 clients should the server with which the client is interacting become unavailable.
特定のノードは、存続期間の長い接続を維持する場合があります。 IPv6アドレス空間は大きいので、DHCPv6の可用性を向上させるためにIPv6アドレスの簡単な可用性を使用する手法（[RFC6853]など）が存在します。ただし、これらのアプローチは、クライアントが対話しているサーバーが利用できなくなった場合、DHCPv6クライアントに安定したIPv6アドレスを提供しません。
The obvious benefit of stable addresses is the ability to update DNS infrequently. While DNS can be updated every time an IPv6 address changes, it introduces delays, and (depending on DNS configuration) old entries may be cached for prolonged periods of time.
安定したアドレスの明らかな利点は、DNSをたまに更新する機能です。 DNSはIPv6アドレスが変更されるたびに更新できますが、遅延が発生し、（DNS構成によっては）古いエントリが長期間キャッシュされる場合があります。
The other benefit of having a stable address is that many monitoring solutions provide statistics on a per-IP basis, so IP changes make measuring characteristics of a given box more difficult.
安定したアドレスを持つもう1つの利点は、多くの監視ソリューションがIPごとの統計を提供するため、IPの変更により特定のボックスの特性の測定がより困難になることです。
There is a scenario where the DHCPv6 server may be configured to serve clients on one network adapter and communicate with a partner server (server-to-server traffic) on a different network adapter. In this scenario, if the server loses connectivity on the network adapter used to communicate with the clients because of network adapter (hardware) failure, there is no intimation of the loss of service to the partner in the DHCPv6 failover protocol. Since the servers are able to communicate with each other, the partner remains ignorant of the loss of service to clients.
DHCPv6サーバーが1つのネットワークアダプター上のクライアントにサービスを提供し、別のネットワークアダプター上のパートナーサーバー（サーバー間トラフィック）と通信するように構成されているシナリオがあります。このシナリオでは、ネットワークアダプター（ハードウェア）の障害が原因で、サーバーがクライアントとの通信に使用されているネットワークアダプターの接続を失った場合、DHCPv6フェールオーバープロトコルでパートナーへのサービスが失われることはありません。サーバーは相互に通信できるため、パートナーはクライアントへのサービスが失われたことを知らないままです。
This section describes important issues that will affect any DHCPv6 failover protocol. This section is not intended to define implementation details but rather describes high-level concepts and issues that are important to DHCPv6 failover. These issues form a basis for later documents that will deal with the solutions to these issues.
このセクションでは、DHCPv6フェイルオーバープロトコルに影響を与える重要な問題について説明します。このセクションは、実装の詳細を定義することを意図したものではなく、DHCPv6フェイルオーバーに重要な高レベルの概念と問題について説明しています。これらの問題は、これらの問題の解決策を扱う後のドキュメントの基礎を形成します。
The general failover concept assumes that there are backup servers that can provide service in case of a primary server failure. In theory, there could be more than one backup server that could take up the role if such a need arises. However, having more than two servers introduces a very difficult issue of synchronizing between partners. In the case of just a pair of cooperating servers, the notification and processes can result in only one of two states: fully successful (got response from a partner) and total failure (no response, failure event occurred). Were there more than two partners participating in a relationship, there would be intermediate, inconsistent states where some partners had updated their state and some had not. This would greatly complicate the protocol design and would give little advantage in return. Therefore, an approach that assumes a pair of cooperating servers was chosen.
一般的なフェイルオーバーの概念は、プライマリサーバーに障害が発生した場合にサービスを提供できるバックアップサーバーがあることを前提としています。理論的には、このようなニーズが発生した場合に、役割を果たすことができるバックアップサーバーが複数存在する可能性があります。ただし、3つ以上のサーバーがあると、パートナー間の同期が非常に困難になります。連携するサーバーのペアが1つしかない場合、通知とプロセスの結果は、完全に成功（パートナーからの応答を受け取った）と完全な障害（応答なし、障害イベントが発生）の2つの状態のいずれかになります。 2人以上のパートナーが関係に参加している場合、一部のパートナーが自分の状態を更新し、一部のパートナーが更新しなかった中間の一貫性のない状態が発生します。これはプロトコル設計を非常に複雑にし、見返りにほとんど利点を与えません。したがって、連携するサーバーのペアを想定するアプローチが選択されました。
This section documents failure modes. This requirements document does not make any claims whether those two failures are distinguishable by a server.
このセクションでは、障害モードについて説明します。この要件ドキュメントは、これらの2つの障害がサーバーによって識別可能であるかどうかについては主張していません。
Servers may become unresponsive due to a software crash, hardware failure, power outage, or any number of other reasons. The failover partner will detect such an event due to lack of responses from the down partner. In this failure mode, the assumption is that the server is the only equipment that is off-line and all other network equipment is operating normally. In particular, communication between other nodes is not interrupted.
ソフトウェアのクラッシュ、ハードウェアの障害、停電、その他の理由により、サーバーが応答しなくなる場合があります。フェイルオーバーパートナーは、ダウンしているパートナーからの応答がないため、このようなイベントを検出します。この障害モードでは、オフラインである唯一の機器がサーバーであり、他のすべてのネットワーク機器は正常に動作していると想定されています。特に、他のノード間の通信は中断されません。
When working under the assumption that this is the only type of failure that can happen, the server may safely assume that its partner unreachability means that it is down, so other nodes (clients, in particular) are not able to reach it either, and no services are provided.
これが発生する可能性のある唯一のタイプの障害であるという仮定の下で作業する場合、サーバーは、パートナーの到達不能がダウンしていることを意味するため、他のノード（特にクライアント）も到達できないと安全に想定できます。サービスは提供されません。
It should be noted that recovery after the failed server is brought back on-line is straightforward, due to the fact that it just needs to download current information from the lease database of the healthy partner and there is no conflict resolution required.
正常なパートナーのリースデータベースから現在の情報をダウンロードする必要があるだけで、競合の解決は必要ないため、障害が発生したサーバーをオンラインに戻した後の回復は簡単です。
This is by far the most common failure mode between two failover partners.
これは、2つのフェールオーバーパートナー間で最も一般的な障害モードです。
When the two servers are located physically close to each other, possibly in the same room, the probability that a failure to communicate between failover partners is due to server failure is increased.
2つのサーバーが物理的に互いに近い場所にある場合、おそらく同じ部屋にある場合、フェイルオーバーパートナー間の通信の失敗がサーバーの障害が原因である可能性が高くなります。
Another possible cause of partner unreachability is a failure in the network that connects the two servers. This may be caused by failure of any kind of network equipment: router, switch, physical cables, or optic fibers. As a result of such a failure, the network is split into two or more disjoint sections (partitions) that are not able to communicate with each other. Such an event is called "network partition". If failover partners are located in different partitions, they won't be able to communicate with each other. Nevertheless, each partner may still be able to serve clients that happen to be part of the same partition.
パートナーが到達不能になるもう1つの原因は、2つのサーバーを接続するネットワークの障害です。これは、ルーター、スイッチ、物理ケーブル、光ファイバーなど、あらゆる種類のネットワーク機器の障害が原因である可能性があります。このような障害の結果、ネットワークは、互いに通信できない2つ以上のばらばらのセクション（パーティション）に分割されます。このようなイベントは「ネットワークパーティション」と呼ばれます。フェールオーバーパートナーが異なるパーティションに配置されている場合、それらは互いに通信できません。それにもかかわらず、各パートナーは、たまたま同じパーティションの一部であるクライアントにサービスを提供できる場合があります。
If this failure mode is taken into consideration, a server can't assume that partner unreachability automatically means that its partner is down. They must consider the fact that the partner may continue operating and interacting with a subset of the clients. The only valid assumption is that the partner also detected the network partition event and follows procedures specified for such a situation.
この障害モードが考慮されている場合、サーバーは、パートナーが到達不能であることは、そのパートナーがダウンしていることを自動的に意味するとは想定できません。彼らは、パートナーがクライアントのサブセットと運用し、対話し続ける可能性があるという事実を考慮する必要があります。唯一の有効な前提は、パートナーもネットワークパーティションイベントを検出し、そのような状況に対して指定された手順に従うことです。
It should be noted that recovery after a partitioned network is rejoined is significantly more complicated than recovery from a server failure event. As both servers may have kept serving clients, they have two separate lease databases, and they need to agree on the state of each lease (or follow any other algorithm to bring their lease databases into agreement).
パーティション分割されたネットワークに再参加した後の回復は、サーバー障害イベントからの回復よりもはるかに複雑であることに注意してください。両方のサーバーがクライアントにサービスを提供し続けている可能性があるため、2つの別個のリースデータベースがあり、各リースの状態について合意する必要があります（または他のアルゴリズムに従って、リースデータベースを合意します）。
This failure mode is more likely (though still rare) in the situation where two servers are in physically distant locations with multiple network elements between them. This is the case in geographically distributed failover (see Section 4.2).
この障害モードは、2つのサーバーが物理的に離れた場所にあり、それらの間に複数のネットワーク要素がある状況で発生する可能性が高くなります（まだまれです）。これは、地理的に分散したフェイルオーバーの場合です（セクション4.2を参照）。
Partners must exchange information about changes made to the lease database. There are at least two types of synchronization methods that may be used (see Sections 5.2.1 and 5.2.2). These concepts are related to distributed databases, so some familiarity with distributed database technology is useful to better understand this topic.
パートナーは、リースデータベースに加えられた変更に関する情報を交換する必要があります。使用できる同期方法は少なくとも2種類あります（セクション5.2.1および5.2.2を参照）。これらの概念は分散データベースに関連しているため、このトピックをよりよく理解するには、分散データベーステクノロジーにある程度精通していることが役立ちます。
When a server receives a REQUEST message from a client, it consults its lease database and assigns requested addresses and/or prefixes. To make sure that its partner maintains a consistent database, it then sends information about a new or just updated lease to the partner and waits for the partner's response. After the response from its partner is received, the REPLY message is transmitted to the client.
サーバーはクライアントからREQUESTメッセージを受信すると、そのリースデータベースを調べて、要求されたアドレスやプレフィックスを割り当てます。そのパートナーが一貫したデータベースを維持することを確認するために、パートナーは新しいリースまたは更新されたばかりのリースに関する情報をパートナーに送信し、パートナーの応答を待ちます。パートナーからの応答を受信すると、REPLYメッセージがクライアントに送信されます。
This approach has the benefit of having a completely consistent lease database between partners at all times. Unfortunately, there is typically a significant performance penalty for this approach as each response sent to a client is delayed by the total sum of the delays caused by two transmissions between partners and the processing by the second partner. The second partner is expected to update its own copy of the lease database in permanent storage, so this delay is not negligible, even in fast networks.
このアプローチには、常にパートナー間で完全に一貫したリースデータベースを使用できるという利点があります。残念ながら、クライアントへ送信される各応答は、パートナー間の2つの送信と2番目のパートナーによる処理によって引き起こされる遅延の合計によって遅延されるため、このアプローチには通常、パフォーマンスが大幅に低下します。 2番目のパートナーは、リースデータベースの独自のコピーを永続的なストレージに更新することが期待されているため、高速ネットワークでもこの遅延は無視できません。
Due to the advent of fast SSD (solid state disk) and battery-backed RAM (random access memory) disk technology, this write performance penalty can be limited to some degree.
高速SSD（ソリッドステートディスク）およびバッテリーバックアップRAM（ランダムアクセスメモリ）ディスクテクノロジーの登場により、この書き込みパフォーマンスのペナルティはある程度制限される可能性があります。
Another approach to synchronizing the lease databases is to transmit the REPLY message to the client before completing the update to the partner. The server sends the REPLY to the client immediately after assigning appropriate addresses and/or prefixes and initiates the partner update at a later time, depending on the algorithm chosen. Another variation of this approach is to initiate transmission to the partner but not wait for its response before sending the REPLY to the client.
リースデータベースを同期する別の方法は、パートナーへの更新を完了する前にクライアントにREPLYメッセージを送信することです。サーバーは、適切なアドレスやプレフィックスを割り当てた直後にクライアントにREPLYを送信し、選択したアルゴリズムに応じて、後でパートナーの更新を開始します。このアプローチの別のバリエーションは、パートナーへの送信を開始するが、クライアントに応答を送信する前にその応答を待たないことです。
This approach has the benefit of a minimal impact on server response times; it is thus much better from a performance perspective. However, it makes the lease databases loosely synchronized between partners. This makes the synchronization more complex (particularly the re-integration after a network partition event), as there may be cases where one client has been given a lease on an address or prefix of which the partner is not aware (e.g., if the server crashes after sending the REPLY to the client but before sending update information to its partner).
このアプローチには、サーバーの応答時間への影響を最小限に抑えるという利点があります。したがって、パフォーマンスの観点からははるかに優れています。ただし、リースデータベースはパートナー間で緩やかに同期されます。これにより、1つのクライアントに、パートナーが認識していないアドレスまたはプレフィックスのリースが付与されている場合があるため（たとえば、サーバーがクライアントにREPLYを送信した後、更新情報をパートナーに送信する前にクラッシュします）。
There are significant similarities between existing DHCPv4 and envisaged DHCPv6 failovers. In particular, both serve IP addresses to clients, require maintaining consistent databases among partners, need to perform consistent DNS updates, must be able take over bindings offered by a failed partner, and must be able to resume operation after the partner is recovered. DNS conflict resolution works on the same principles in both DHCPv4 and DHCPv6.
既存のDHCPv4と想定されるDHCPv6フェイルオーバーの間には、大きな類似点があります。特に、どちらもクライアントにIPアドレスを提供し、パートナー間で一貫したデータベースを維持する必要があり、一貫したDNS更新を実行する必要があり、障害が発生したパートナーによって提供されたバインディングを引き継ぐことができ、パートナーが回復した後に操作を再開できる必要があります。 DNS競合解決は、DHCPv4とDHCPv6の両方で同じ原理で機能します。
Nevertheless, there are significant differences. IPv6 introduced prefix delegation [RFC3633], which is a crucial element of the DHCPv6 protocol. IPv6 also introduced the concept of deprecated addresses with separate preferred and valid lifetimes, both configured via DHCPv6. Negative response (NACK) in DHCPv4 has been replaced with the ability in DHCPv6 to provide a corrected response in a REPLY message, which differs from a REQUEST.
それにもかかわらず、大きな違いがあります。 IPv6では、プレフィックス委任[RFC3633]が導入されました。これは、DHCPv6プロトコルの重要な要素です。 IPv6はまた、DHCPv6を介して構成された、優先ライフタイムと有効ライフタイムが別々の非推奨アドレスの概念も導入しました。 DHCPv4の否定応答（NACK）は、DHCPv6の機能に置き換えられ、REPLYメッセージでREQUESTとは異なる修正された応答を提供するようになりました。
Also, the typical large address space (close to 2^64 addresses on /64 prefixes expected to be available on most networks) may make managing address assignment significantly different from DHCPv4 failover. In DHCPv4, it was not possible to use a hash or calculated technique to divide the significantly more limited address space, and therefore, much of the protocol that deals with pool balancing and rebalancing might not be necessary and can be done mathematically. Also, because of the much lower degree of contention for IP addresses, the DHCPv6 failover protocol does not need to be tuned to support rapid reclamation of IPv6 addresses following the loss of a failover peer's database.
また、一般的な大きなアドレス空間（/ 64プレフィックスの2 ^ 64に近いアドレスがほとんどのネットワークで利用可能であると予想される）により、アドレス割り当ての管理がDHCPv4フェイルオーバーとは大幅に異なる場合があります。 DHCPv4では、ハッシュまたは計算された手法を使用して大幅に制限されたアドレススペースを分割することができなかったため、プールのバランシングとリバランシングを処理するプロトコルの多くは不要であり、数学的に実行できます。また、IPアドレスの競合の程度がはるかに低いため、フェイルオーバーピアのデータベースが失われた後のIPv6アドレスの迅速な再利用をサポートするために、DHCPv6フェイルオーバープロトコルを調整する必要はありません。
However, DHCPv6 prefix delegation is similar to IPv4 addressing in terms of the number of available leases, and therefore, techniques for pool balancing and rebalancing and more rapid reclamation of prefixes allocated by a failed peer will be needed.
ただし、DHCPv6プレフィックス委任は、使用可能なリースの数の点でIPv4アドレッシングと同様であるため、プールのバランシングとリバランシング、および障害が発生したピアによって割り当てられたプレフィックスのより迅速な再利用の技術が必要になります。
This section summarizes the requirements for DHCPv6 failover.
このセクションでは、DHCPv6フェイルオーバーの要件をまとめています。
Certain capabilities may be useful in some, but not all, scenarios. Such additional features will be considered optional parts of failover and will be defined in separate documents. As such, this document can be considered an attempt to define requirements for the DHCPv6 failover "core" protocol.
特定の機能は、すべてではなく一部のシナリオで役立つ場合があります。このような追加機能はフェイルオーバーのオプション部分と見なされ、別のドキュメントで定義されます。そのため、このドキュメントは、DHCPv6フェールオーバー「コア」プロトコルの要件を定義する試みと見なすことができます。
The core of the DHCPv6 failover protocol is expected to provide the following properties:
DHCPv6フェールオーバープロトコルのコアは、次のプロパティを提供することが期待されています。
1. The number of supported partners must be exactly two, i.e., there are at most two servers that are aware of a specific lease.
1. サポートされるパートナーの数は正確に2つである必要があります。つまり、特定のリースを認識するサーバーは最大で2つです。
2. For each prefix or address pool, a server must not participate in more than one failover relationship.
2. プレフィックスまたはアドレスプールごとに、サーバーは複数のフェイルオーバー関係に参加してはなりません。
3. The defined protocol must support the m-to-1 model (i.e., one server may form more than one relationship), but an implementation may choose to implement only the 1-to-1 model (i.e., everything from one server is backed on another).
3. 定義されたプロトコルはm-to-1モデルをサポートする必要があります（つまり、1つのサーバーが複数の関係を形成する場合があります）が、実装は1-to-1モデルのみを実装することを選択できます（つまり、1つのサーバーのすべてがサポートされます）別の）。
4. One partner must be able to continue serving leases offered by the other partner. This property is also sometimes called "lease stability". The failure of either failover partner should have minimal or no impact on client connectivity. In particular, it must not force the client to change addresses and/or change prefixes delegated to it. Lease stability has the aim of avoiding disturbance to long-lived connections.
4. 一方のパートナーは、他方のパートナーが提供するリースを引き続き提供できる必要があります。この特性は、「リースの安定性」とも呼ばれます。どちらかのフェイルオーバーパートナーの障害がクライアントの接続に与える影響は最小限であるか、まったくないはずです。特に、クライアントにアドレスの変更や委任されたプレフィックスの変更を強制してはなりません。リースの安定性は、長寿命の接続への妨害を回避することを目的としています。
5. Prefix delegation must be supported.
5. プレフィックス委任がサポートされている必要があります。
6. Use of the failover protocol must not introduce significant performance impact on server response times. Therefore, synchronization between partners must be done using some form of lazy updates (see Section 5.2.2).
6. フェイルオーバープロトコルを使用しても、サーバーの応答時間にパフォーマンスの大きな影響を与えてはなりません。したがって、パートナー間の同期は、なんらかの遅延更新を使用して行う必要があります（セクション5.2.2を参照）。
7. The pair of failover servers must be able to recover from a server down failure (see Section 5.1.1).
7. フェールオーバーサーバーのペアは、サーバーダウン障害から回復できる必要があります（セクション5.1.1を参照）。
8. The pair of failover servers must be able to recover from a network partition event (see Section 5.1.2).
8. フェイルオーバーサーバーのペアは、ネットワークパーティションイベントから回復できる必要があります（セクション5.1.2を参照）。
9. The design must allow secure communication between the failover partners.
9. 設計では、フェイルオーバーパートナー間の安全な通信を許可する必要があります。
10. The definition of extensions to this core protocol should be allowed, when possible.
10. 可能な場合、このコアプロトコルの拡張の定義を許可する必要があります。
Depending on the specific nature of the failure, the recovery procedures mentioned in points 7 and 8 may require manual intervention.
障害の特定の性質に応じて、ポイント7および8で説明されている回復手順では、手動による介入が必要になる場合があります。
High availability is a property of the protocol that allows clients to receive DHCPv6 services despite the failure of individual DHCPv6 servers. In particular, it means the server that takes over providing service to clients from its failed partner will continue serving the same addresses and/or prefixes. This property is also called "lease stability".
高可用性は、個々のDHCPv6サーバーに障害が発生してもクライアントがDHCPv6サービスを受信できるようにするプロトコルのプロパティです。特に、障害が発生したパートナーからクライアントへのサービス提供を引き継ぐサーバーは、同じアドレスまたはプレフィックス、あるいはその両方を引き続き提供します。この特性は「リースの安定性」とも呼ばれます。
Although progress on a standardized interoperable DHCPv4 failover protocol has stalled, vendor-specific DHCPv4 failover protocols have been deployed that meet these requirements to a large extent. Accordingly, it would be appropriate to take into account the likely coexistence of DHCPv4 and DHCPv6 failover solutions. In particular, certain features that are common to both IPv4 and IPv6 implementations, such as the DNS Update mechanism, should be taken into consideration to ensure compatible operation.
標準化された相互運用可能なDHCPv4フェールオーバープロトコルの進歩は停滞していますが、これらの要件を大幅に満たすベンダー固有のDHCPv4フェールオーバープロトコルが展開されています。したがって、DHCPv4とDHCPv6のフェイルオーバーソリューションが共存する可能性を考慮することが適切です。特に、DNS更新メカニズムなど、IPv4とIPv6の両方の実装に共通する特定の機能は、互換性のある動作を保証するために考慮する必要があります。
The following features are explicitly out of scope.
次の機能は明らかに範囲外です。
1. Load Balancing - This capability is considered an extension and may be defined in a separate document. It must not be part of the core protocol but rather defined as an extension. The primary reason for this the desire to limit the complexity of the core protocol. See [LOAD-BALANCING].
1. 負荷分散-この機能は拡張と見なされ、別のドキュメントで定義できます。コアプロトコルの一部ではなく、拡張として定義する必要があります。これの主な理由は、コアプロトコルの複雑さを制限することです。 [LOAD-BALANCING]を参照してください。
2. Configuration synchronization - Two failover partners are expected to maintain the same configuration. Mismatched configuration between partners is a frequent problem in failover solutions. Unfortunately, that is an open-ended problem, since different servers have very different configuration data models.
2. 構成の同期-2つのフェールオーバーパートナーが同じ構成を維持することが期待されています。パートナー間の構成の不一致は、フェイルオーバーソリューションで頻繁に発生する問題です。残念ながら、サーバーによって構成データモデルが大きく異なるため、これは制限のない問題です。
3. m-to-n model (see Section 4.4).
3. m-to-nモデル（セクション4.4を参照）。
4. Servers participating in multiple failover relationships for any given prefix or address pool.
4. 特定のプレフィックスまたはアドレスプールの複数のフェイルオーバー関係に参加しているサーバー。
The design must provide a mechanism whereby each peer in a failover relationship can identify the other peer, authenticate that identification, and validate that the identified peer is the one with which communication is intended. This mechanism should also optionally provide support for confidentiality.
設計は、フェイルオーバー関係の各ピアが他のピアを識別し、その識別を認証し、識別されたピアが通信を意図したものであることを検証できるメカニズムを提供する必要があります。このメカニズムは、オプションで機密性のサポートも提供する必要があります。
The protocol specification, when it is written, should provide operational guidelines in the case of authentication mechanisms that require access to network servers that have the potential to be unreachable (e.g., what to do if a partner is reachable but the remote Certificate Authority is unreachable due to a network partition event).
プロトコル仕様は、記述されている場合、到達できない可能性のあるネットワークサーバーへのアクセスを必要とする認証メカニズムの場合の運用ガイドラインを提供する必要があります（たとえば、パートナーは到達可能であるがリモート認証局に到達できない場合の対処法）ネットワークパーティションイベントが原因です）。
The security considerations for the design itself will be discussed in the design document.
デザイン自体のセキュリティに関する考慮事項については、デザインドキュメントで説明します。
This document extensively uses concepts, definitions and other parts of [DHCPV4-FAILOVER]. Thanks to Bernie Volz and Shawn Routhier for their frequent reviews and substantial contributions. The authors would also like to thank Qin Wu, Jean-Francois Tremblay, Frank Sweetser, Jiang Sheng, Yu Fu, Greg Rabil, Vithalprasad Gaitonde, Krzysztof Nowicki, Steinar Haug, Elwyn Davies, Ted Lemon, Benoit Claise, Stephen Farrell, Michal Hoeft, and Krzysztof Gierlowski for their comments and feedback.
このドキュメントでは、[DHCPV4-FAILOVER]の概念、定義、およびその他の部分を広範に使用しています。頻繁なレビューと多大な貢献をしてくれたBernie VolzとShawn Routhierに感謝します。著者はまた、秦呉、ジャン・フランソワ・トランブレ、フランク・スウィートサー、ジャン・シェン、ユ・フー、グレッグ・ラビル、ヴィタルプラサド・ガイトンド、クジストフ・ノビッキ、シュタイナー・ハウグ、エルウィン・デイビス、テッド・レモン、ブノワ・クレイズ、スティーブン・ファレル、ミハルにも感謝したいと思います。 、および彼らのコメントとフィードバックのためのKrzysztof Gierlowski。
This work has been partially supported by the Department of Computer Communications (a division of Gdansk University of Technology) and the National Centre for Research and Development (Poland) under the European Regional Development Fund, Grant No. POIG.01.01.02-00-045 / 09-00 (Future Internet Engineering Project).
この作業は、欧州地域開発基金、助成金番号POIG.01.01.02-00-に基づいて、コンピュータコミュニケーション学科（グダニスク工科大学の一部門）および国立研究開発センター（ポーランド）によって部分的にサポートされています。 045 / 09-00（将来のインターネットエンジニアリングプロジェクト）。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC4704] Volz、B。、「IPv6の動的ホスト構成プロトコル（DHCPv6）クライアントの完全修飾ドメイン名（FQDN）オプション」、RFC 4704、2006年10月。
[DHCPV4-FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil, G., Dooley, M., and A. Kapur, "DHCP Failover Protocol", Work in Progress, March 2003.
[DHCPV4-FAILOVER] Droms、R.、Kinnear、K.、Stapp、M.、Volz、B.、Gonczi、S.、Rabil、G.、Dooley、M。、およびA. Kapur、「DHCPフェイルオーバープロトコル」 、作業中、2003年3月。
[LOAD-BALANCING] Kostur, A., "DHC Load Balancing Algorithm for DHCPv6", Work in Progress, December 2012.
[LOAD-BALANCING] Kostur、A。、「DHCPv6のDHCロードバランシングアルゴリズム」、作業中、2012年12月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメインネームシステムの動的更新（DNS UPDATE）」、RFC 2136、1997年4月。
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 Options for Network Boot", RFC 5970, September 2010.
[RFC5970] Huth、T.、Freimann、J.、Zimmer、V。、およびD. Thaler、「DHCPv6 Options for Network Boot」、RFC 5970、2010年9月。
[RFC6853] Brzozowski, J., Tremblay, J., Chen, J., and T. Mrugalski, "DHCPv6 Redundancy Deployment Considerations", BCP 180, RFC 6853, February 2013.
[RFC6853] Brzozowski、J.、Tremblay、J.、Chen、J。、およびT. Mrugalski、「DHCPv6冗長展開の考慮事項」、BCP 180、RFC 6853、2013年2月。
Authors' Addresses
著者のアドレス
Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
Internet Systems Consortium、Inc.のTomek Mrigalski氏೯೫೦ Charter Street Redwood City、K Kアメリカ合衆国
Phone: +1 650 423 1345
EMail: tomasz.mrugalski@gmail.com
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, Massachusetts 01719 USA
Kim Kinnear Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、Massachusetts 01719 USA
Phone: +1 (978) 936-0000
EMail: kkinnear@cisco.com