[要約] RFC 6853は、DHCPv6の冗長性展開に関する考慮事項を提供する。このRFCの目的は、DHCPv6サーバーの冗長性を確保するためのガイドラインを提供することである。
Internet Engineering Task Force (IETF) J. Brzozowski
Request for Comments: 6853 Comcast Cable Communications
BCP: 180 J. Tremblay
Category: Best Current Practice Videotron G.P.
ISSN: 2070-1721 J. Chen
Time Warner Cable
T. Mrugalski
ISC
February 2013
DHCPv6 Redundancy Deployment Considerations
DHCPv6冗長配置の考慮事項
Abstract
概要
This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services.
このドキュメントでは、IPv6の展開をサポートするためにDHCPv6を使用したいユーザー向けの情報を提供します。特に、半冗長DHCPv6サービスのプロビジョニングについて説明します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化しています。
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 BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc6853.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6853で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 2
2.1. Applicability to Prefix Delegation . . . . . . . . . . . . 3
3. Service Provider Deployment . . . . . . . . . . . . . . . . . 3
4. Enterprise Deployment . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5
5.1. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . 5
5.2. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . 5
5.3. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . 5
6. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . 8
6.3. Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10
7. Challenges and Issues . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Redundancy and high availability for many components of IPv6 infrastructure are desirable and, in some deployments, mandatory. Unfortunately, for DHCPv6 there is currently no standards-based failover or redundancy protocol. An interim solution is to provide semi-redundant services: this document specifies an architecture by which this can be achieved.
IPv6インフラストラクチャの多くのコンポーネントの冗長性と高可用性が望ましく、一部の展開では必須です。残念ながら、DHCPv6には現在、標準ベースのフェイルオーバーまたは冗長プロトコルはありません。暫定的な解決策は、半冗長のサービスを提供することです。このドキュメントでは、これを実現できるアーキテクチャを指定しています。
DHCPv6 redundancy may be useful in a wide range of scenarios. Although the architecture suggested in this document is able to be used in a wide range of networks, just two deployment environments are discussed here: service provider and enterprise network. All other scenarios may be generalized to one of these two cases.
DHCPv6の冗長性は、幅広いシナリオで役立ちます。このドキュメントで提案されているアーキテクチャは幅広いネットワークで使用できますが、ここではサービスプロバイダーとエンタープライズネットワークという2つの展開環境についてのみ説明します。他のすべてのシナリオは、これら2つのケースのいずれかに一般化できます。
In the rest of the document, the following assumptions are made with regards to the existing DHCPv6 infrastructure, regardless of the environment being considered:
このドキュメントの残りの部分では、検討している環境に関係なく、既存のDHCPv6インフラストラクチャに関して次の仮定が行われています。
1. At least two DHCPv6 servers provide a service to the same clients. (The architecture does not limit the number of servers, and more may be provided if required.)
1. 少なくとも2つのDHCPv6サーバーが同じクライアントにサービスを提供します。 （アーキテクチャーはサーバーの数を制限せず、必要に応じてさらに多くのサーバーを提供できます。）
2. The existing DHCPv6 servers will not directly communicate or interact with one another in the assignment of IPv6 addresses and the provision of configuration information to requesting clients.
2. 既存のDHCPv6サーバーは、IPv6アドレスの割り当てと要求クライアントへの構成情報の提供において、直接通信したり相互に作用したりしません。
3. DHCPv6 clients are instructed to run stateful DHCPv6 to request at least one IPv6 address. Configuration information and other options (such as a delegated IPv6 prefix) may also be requested as part of the stateful DHCPv6 operation.
3. DHCPv6クライアントは、ステートフルDHCPv6を実行して少なくとも1つのIPv6アドレスを要求するように指示されます。構成情報およびその他のオプション（委任されたIPv6プレフィックスなど）も、ステートフルDHCPv6操作の一部として要求される場合があります。
4. Clients participating in DHCPv6 configuration have to properly handle the preference option, including the processing of ADVERTISE messages as required by [RFC3315].
4. DHCPv6構成に参加しているクライアントは、[RFC3315]で要求されるADVERTISEメッセージの処理を含む、設定オプションを適切に処理する必要があります。
5. A DHCPv6 server failure does not imply a failure of any other network service or protocol (e.g., TFTP servers). The redundancy of any additional services configured by means of DHCPv6 are outside the scope of this document. (For example, a single DHCPv6 server may configure multiple TFTP servers, with preference for each TFTP server, as specified in [RFC5970].)
5. DHCPv6サーバーの障害は、他のネットワークサービスまたはプロトコル（TFTPサーバーなど）の障害を意味するものではありません。 DHCPv6によって構成された追加サービスの冗長性は、このドキュメントの範囲外です。 （たとえば、単一のDHCPv6サーバーは、[RFC5970]で指定されているように、各TFTPサーバーを優先して複数のTFTPサーバーを構成できます。）
While the techniques described in this document provide some aspects of redundancy, it should be noted that complete redundancy will not be available until a DHCPv6 failover protocol is standardized. The requirements for such a protocol are described in [FAILREQ].
このドキュメントで説明する手法は冗長性のいくつかの側面を提供しますが、DHCPv6フェールオーバープロトコルが標準化されるまで完全な冗長性は利用できないことに注意する必要があります。このようなプロトコルの要件は、[FAILREQ]で説明されています。
The same approaches discussed in this document can potentially be applied to prefix delegation (PD) [RFC3633]. One obvious drawback of using a split prefix model for PD is that use of resources is doubled. It should be noted that such applicability remains theoretical and was not investigated thoroughly during work on this document. As such, the applicability of presented mechanisms to the prefix delegation is outside of the scope of this document.
このドキュメントで説明されている同じアプローチは、プレフィックス委任（PD）[RFC3633]に適用できる可能性があります。 PDに分割プレフィックスモデルを使用する明らかな欠点の1つは、リソースの使用が2倍になることです。そのような適用性は理論的なままであり、このドキュメントの作業中に徹底的に調査されなかったことに注意する必要があります。そのため、プレフィックスの委任に対する提示されたメカニズムの適用性は、このドキュメントの範囲外です。
The service provider model represents cases where the network and end-user devices may be administered by separate entities.
サービスプロバイダーモデルは、ネットワークデバイスとエンドユーザーデバイスが別々のエンティティによって管理される場合を表しています。
The DHCPv6 clients include cable modems, customer gateways or home routers, and end-user devices: these are collectively referred to as Customer Premises Equipment (CPE). In some cases hosts may be configured directly using the service provider DHCPv6 infrastructure; in others, configuration may be via an intermediate router that is being configured by the provider DHCPv6 infrastructure. Either way, the service provider DHCPv6 infrastructure may be semi-redundant.
DHCPv6クライアントには、ケーブルモデム、カスタマーゲートウェイまたはホームルーター、およびエンドユーザーデバイスが含まれます。これらは、総称してCustomer Premises Equipment（CPE）と呼ばれます。場合によっては、サービスプロバイダーのDHCPv6インフラストラクチャを使用してホストを直接構成できます。それ以外の場合は、プロバイダーのDHCPv6インフラストラクチャによって構成されている中間ルーターを介して構成できます。どちらの方法でも、サービスプロバイダーのDHCPv6インフラストラクチャは半冗長になる可能性があります。
In discussing this environment, additional assumptions to those listed in Section 2 have been made:
この環境の説明では、セクション2にリストされているものに追加の仮定が行われています。
1. The service provider edge routers and access routers are IPv6 enabled when required. These routers are, for example, CMTS (Cable Modem Termination System) for cable or DSLAM/BRAS (Digital Subscriber Link Access Multiplexer / Broadband Remote Access Server) for DSL.
1. サービスプロバイダーのエッジルーターとアクセスルーターは、必要に応じてIPv6対応になります。これらのルーターは、たとえば、ケーブルの場合はCMTS（ケーブルモデムターミネーションシステム）、DSLの場合はDSLAM / BRAS（デジタルサブスクライバーリンクアクセスマルチプレクサー/ブロードバンドリモートアクセスサーバー）です。
2. CPE devices are instructed to perform stateful DHCPv6 to request at least one IPv6 address, delegated prefix, and/or configuration information. CPE devices may also be instructed to use stateless DHCPv6 [RFC3736] to acquire configuration information only, a situation that assumes the IPv6 address and prefix information has been acquired using other means.
2. CPEデバイスは、ステートフルDHCPv6を実行して、少なくとも1つのIPv6アドレス、委任されたプレフィックス、構成情報、あるいはその両方を要求するように指示されます。 CPEデバイスは、ステートレスDHCPv6 [RFC3736]を使用して構成情報のみを取得するように指示される場合もあります。この状況では、IPv6アドレスとプレフィックス情報が他の手段を使用して取得されていると想定されます。
3. The primary application of this architecture is for native IPv6 services. (Use and applicability to transition mechanisms are out of scope for this document.)
3. このアーキテクチャの主なアプリケーションは、ネイティブIPv6サービスです。 （移行メカニズムへの使用と適用は、このドキュメントの範囲外です。）
4. The CPE devices must implement a stateful DHCPv6 client [RFC3315]. Support for DHCPv6 prefix delegation [RFC3633] or stateless DHCPv6 [RFC3736] may also be implemented.
4. CPEデバイスは、ステートフルDHCPv6クライアント[RFC3315]を実装する必要があります。 DHCPv6プレフィックス委任のサポート[RFC3633]またはステートレスDHCPv6 [RFC3736]も実装できます。
The enterprise deployment environment covers cases where end-user devices are direct consumers of the configuration provided by the DHCP servers without any intermediate devices (as was the case with home routers used in the service provider environment). Although enterprise IPv6 environments quite often use or require DHCPv6 relay agents, the relays do not influence or process the configuration in any way and merely act as a transport mechanism.
エンタープライズ展開環境は、エンドユーザーデバイスが、中間デバイスなしでDHCPサーバーによって提供される構成の直接のコンシューマーである場合をカバーします（サービスプロバイダー環境で使用されるホームルーターの場合のように）。エンタープライズIPv6環境はDHCPv6リレーエージェントを頻繁に使用または要求しますが、リレーは構成に影響を与えたり処理したりすることはなく、単にトランスポートメカニズムとして機能します。
The additional assumptions made for this model beyond those listed in Section 2 are:
セクション2にリストされているもの以外に、このモデルに対して行われる追加の前提条件は次のとおりです。
1. DHCPv6 clients are hosts and are considered end nodes, i.e., they consume provided configuration and do not use it to provision other devices. Examples of such clients include desktop computers, laptops, printers, other typical office equipment, and some mobile devices.
1. DHCPv6クライアントはホストであり、エンドノードと見なされます。つまり、提供された構成を消費し、それを使用して他のデバイスをプロビジョニングしません。このようなクライアントの例には、デスクトップコンピューター、ラップトップ、プリンター、その他の一般的なオフィス機器、一部のモバイルデバイスなどがあります。
2. The DHCPv6 clients generally do not require the assignment of an IPv6 prefix delegation, and as such they typically do not support DHCPv6 prefix delegation [RFC3633].
2. DHCPv6クライアントは通常、IPv6プレフィックス委任の割り当てを必要としないため、通常、DHCPv6プレフィックス委任をサポートしていません[RFC3633]。
Implementation of the architecture for semi-redundant DHCPv6 services using existing protocols requires the component DHCPv6 clients, relays, and servers to have certain capabilities. The following sections describe the requirements of such devices.
既存のプロトコルを使用して半冗長DHCPv6サービスのアーキテクチャを実装するには、コンポーネントDHCPv6クライアント、リレー、およびサーバーに特定の機能が必要です。次のセクションでは、このようなデバイスの要件について説明します。
This interim architecture requires the DHCPv6 servers that are [RFC3315] compliant and support the necessary options. Support for stateful DHCPv6 and the DHCPv6 preference option [RFC3315] is essential to the architecture. For deployment scenarios where IPv6 prefix delegation is needed, DHCPv6 servers must support DHCPv6 prefix delegation as defined by [RFC3633]. Furthermore, the DHCPv6 servers must support [RFC3736] if stateless DHCPv6 is used.
この暫定アーキテクチャには、[RFC3315]に準拠し、必要なオプションをサポートするDHCPv6サーバーが必要です。アーキテクチャには、ステートフルDHCPv6およびDHCPv6設定オプション[RFC3315]のサポートが不可欠です。 IPv6プレフィックス委任が必要な展開シナリオの場合、DHCPv6サーバーは、[RFC3633]で定義されているDHCPv6プレフィックス委任をサポートする必要があります。さらに、ステートレスDHCPv6が使用される場合、DHCPv6サーバーは[RFC3736]をサポートする必要があります。
DHCPv6 relay agents must be [RFC3315] compliant and must support the ability to relay DHCPv6 messages to more than one destination.
DHCPv6リレーエージェントは[RFC3315]に準拠している必要があり、DHCPv6メッセージを複数の宛先にリレーする機能をサポートしている必要があります。
DHCPv6 clients are required to be compliant with [RFC3315] and support the necessary options required to support the solution depending on the mode of operations and desired behavior:
DHCPv6クライアントは[RFC3315]に準拠している必要があり、操作のモードと望ましい動作に応じて、ソリューションをサポートするために必要なオプションをサポートします。
o If prefix delegation is required, DHCPv6 clients must support DHCPv6 prefix delegation as defined in [RFC3633].
o プレフィックス委任が必要な場合、DHCPv6クライアントは、[RFC3633]で定義されているDHCPv6プレフィックス委任をサポートする必要があります。
o Clients must support the acquisition of at least one IPv6 address and configuration information using stateful DHCPv6 as specified by [RFC3315].
o クライアントは、[RFC3315]で指定されているステートフルDHCPv6を使用して、少なくとも1つのIPv6アドレスと構成情報の取得をサポートする必要があります。
o Stateless DHCPv6 [RFC3736] may also be supported.
o ステートレスDHCPv6 [RFC3736]もサポートされる可能性があります。
o DHCPv6 clients must recognize and adhere to the processing of the advertised DHCPv6 preference option sent by the DHCPv6 servers.
o DHCPv6クライアントは、DHCPv6サーバーによって送信されたアドバタイズされたDHCPv6設定オプションの処理を認識し、それに従う必要があります。
At the time of writing, a standards-based DHCPv6 redundancy protocol is not available. In the interim solution presented here, existing DHCPv6 server implementations are used as-is to provide best effort, semi-redundant DHCPv6 services. The behavior of these services will, in part, be governed by the configuration of each of the servers. Various aspects of the DHCPv6 protocol [RFC3315] are used to yield the desired behavior, although there is no inter-server or inter-process communication to coordinate DHCPv6 events and/or activities.
これを書いている時点では、標準ベースのDHCPv6冗長プロトコルは利用できません。ここで紹介する暫定的なソリューションでは、既存のDHCPv6サーバー実装をそのまま使用して、ベストエフォートの半冗長DHCPv6サービスを提供します。これらのサービスの動作は、一部には、各サーバーの構成によって制御されます。 DHCPv6イベントやアクティビティを調整するためのサーバー間またはプロセス間通信はありませんが、DHCPv6プロトコル[RFC3315]のさまざまな側面を使用して、目的の動作を実現します。
The solution does not impact DHCPv4, so DHCP services for both IPv4 and IPv6 may operate simultaneously on the same physical server(s) or may operate on different ones.
このソリューションはDHCPv4に影響を与えないため、IPv4とIPv6の両方のDHCPサービスは、同じ物理サーバーで同時に動作することも、異なる物理サーバーで動作することもあります。
This section defines three semi-redundant models. Although /64 prefixes are used throughout the following sections as examples, other prefix lengths may be used as well.
このセクションでは、3つの半冗長モデルを定義します。 / 64プレフィックスは例として以降のセクション全体で使用されていますが、他のプレフィックス長も使用できます。
In the split prefixes model, each DHCPv6 server is configured with a unique, non-overlapping pool derived from the /64 prefix deployed for use within an IPv6 network. For example, distributing an allocated /64 such as 2001:db8:1:1::/64 between two servers would require that it be split into two /65 pools, 2001:db8:1:1:0000::/65 and 2001:db8: 1:1:8000::/65.
分割プレフィックスモデルでは、各DHCPv6サーバーは、IPv6ネットワーク内で使用するために展開された/ 64プレフィックスから派生した重複しない一意のプールで構成されます。たとえば、2つのサーバー間で2001：db8：1：1 :: / 64などの割り当てられた/ 64を配布するには、2つの/ 65プールに分割する必要があります。2001：db8：1：1：0000 :: / 65と2001：db8：1：1：8000 :: / 65。
Both DHCPv6 servers are simultaneously active and operational, and each allocates IPv6 addresses from the corresponding pools per device class. The address allocation is governed largely through the use of the DHCPv6 preference option, so the server with the higher preference value is always preferred. Additional proprietary mechanisms can be used to further enforce the favoring of one DHCP server over another. An example of such a scenario is presented in Figure 1.
DHCPv6サーバーは両方とも同時にアクティブで操作可能であり、それぞれが対応するプールからデバイスクラスごとにIPv6アドレスを割り当てます。アドレス割り当ては、主にDHCPv6設定オプションの使用によって管理されるため、より高い設定値を持つサーバーが常に優先されます。追加の独自のメカニズムを使用して、あるDHCPサーバーを別のDHCPサーバーよりも優先させることができます。このようなシナリオの例を図1に示します。
It is important to note that, over time, it is possible that bindings will be unevenly distributed amongst the DHCPv6 servers, and no one server will be authoritative for all of them.
時間の経過とともに、バインディングがDHCPv6サーバー間で不均一に分散される可能性があり、1つのサーバーがそれらすべてに対して権限を持つことはないことに注意することが重要です。
As defined in [RFC3315], a DHCPv6 ADVERTISE message with a preference option of 255 is an indicator to a DHCPv6 client to immediately begin a client-initiated message exchange by transmitting a REQUEST message to the server that sent the ADVERTISE. Alternatively, a DHCPv6 ADVERTISE message with no preference option (or one with a value less than 255) is an indicator to the client that it must wait for subsequent ADVERTISE messages before choosing the server to which is responds, as described in Section 17.1.2 of [RFC3315].
[RFC3315]で定義されているように、優先オプションが255のDHCPv6 ADVERTISEメッセージは、DHCPv6クライアントにとって、アドバタイズを送信したサーバーにREQUESTメッセージを送信することにより、クライアントが開始するメッセージ交換を直ちに開始するためのインジケータです。または、セクション17.1.2で説明されているように、プリファレンスオプションのないDHCPv6 ADVERTISEメッセージ（または値が255未満のメッセージ）は、後続のADVERTISEメッセージを待ってから応答するサーバーを選択する必要があることをクライアントに示すインジケータです。 [RFC3315]の。
In the event of a DHCPv6 server failure, it is desirable (but not essential) for a server other than the server that originally responded to be able to rebind the client's lease. Given the proposed architecture, the remaining active DHCPv6 server will have a different address pool configured, making it technically incorrect to rebind the client in its current state. Ultimately, the rebinding will fail and the client will acquire a new binding from the pool configured in the active server.
DHCPv6サーバーに障害が発生した場合、最初に応答したサーバー以外のサーバーがクライアントのリースを再バインドできることが望ましい（ただし必須ではない）。提案されたアーキテクチャを考えると、残りのアクティブなDHCPv6サーバーには異なるアドレスプールが構成されているため、クライアントを現在の状態で再バインドすることは技術的に正しくありません。最終的に、再バインドは失敗し、クライアントはアクティブサーバーで構成されたプールから新しいバインドを取得します。
To reduce the possibility that a client or some other element on the network will experience a disruption in service or access to relevant binding data, shorter values for T1, T2, valid, and preferred lifetimes can be used. The values for the last three can be adjusted or configured to minimize service disruption. Ideally, setting them equal (or nearly equal) can be used to trigger a DHCPv6 client to reacquire the IPv6 address, prefix, and/or configuration information almost immediately after the rebinding fails. It is important to note, however, that shorter values will create an additional load on the DHCPv6 servers.
クライアントまたはネットワーク上の他の要素がサービスの中断または関連するバインディングデータへのアクセスを経験する可能性を減らすために、T1、T2、有効、および優先ライフタイムの短い値を使用できます。最後の3つの値は、サービスの中断を最小限に抑えるように調整または構成できます。理想的には、それらを等しい（またはほぼ等しい）設定を使用して、DHCPv6クライアントがトリガーされ、再バインドが失敗した直後にIPv6アドレス、プレフィックス、構成情報を再取得できます。ただし、値が短いとDHCPv6サーバーに追加の負荷がかかることに注意してください。
While using a split prefix configuration model, the dynamic updates to DNS [RFC2136] can be coordinated to ensure that the DNS is properly updated with the current binding information. Challenges arise with regards to the update of the PTR resource record for IPv6 addresses since the DNS information may need to be overwritten in a failure condition. The use of split prefixes enables the differentiation of bindings and binding timing to determine which represents the current state. This becomes particularly important when DHCPv6 Leasequery [RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are used to determine lease or binding state.
分割プレフィックス構成モデルを使用している間、DNS [RFC2136]への動的更新を調整して、DNSが現在のバインディング情報で適切に更新されるようにすることができます。障害状態でDNS情報を上書きする必要がある場合があるため、IPv6アドレスのPTRリソースレコードの更新に関して課題が発生します。分割プレフィックスを使用すると、バインディングとバインディングタイミングを区別して、どちらが現在の状態を表しているかを判別できます。これは、DHCPv6 Leasequery [RFC5007]またはDHCPv6 Bulk Leasequery [RFC5460]を使用してリースまたはバインディングの状態を判別する場合に特に重要になります。
Finally, a benefit of this scheme is that the use of separate pools per DHCPv6 server makes failure conditions more obvious and detectable.
最後に、このスキームの利点は、DHCPv6サーバーごとに個別のプールを使用すると、障害状態がより明確になり、検出可能になることです。
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1:0000::/65
Preference = 255
Server 2
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1:8000::/65
Preference = 0
Server n+1
==========
Prefix, pool, and preference would
vary based on prefix definition
Figure 1: Split prefixes approach
図1：分割接頭辞アプローチ
In the multiple prefix model, each DHCPv6 server is configured with a unique, non-overlapping prefix. A /64 pool equal to the prefix is configured on each server. For example, the 2001:db8:1:1::/64 pool would be assigned to a single DHCPv6 server for allocation to clients equal to its parent prefix 2001:db8:1:1::/64. The second DHCPv6 server could use 2001:db8:1:5::/64 as both pool and prefix. This would be repeated for each active DHCP server. An example of this scenario is presented in Figure 2.
複数のプレフィックスモデルでは、各DHCPv6サーバーは一意の重複しないプレフィックスで構成されます。プレフィックスと同じ/ 64プールが各サーバーで構成されます。たとえば、2001：db8：1：1 :: / 64プールは、親プレフィックス2001：db8：1：1 :: / 64と等しいクライアントに割り当てるために、単一のDHCPv6サーバーに割り当てられます。 2番目のDHCPv6サーバーは、プールとプレフィックスの両方として2001：db8：1：5 :: / 64を使用できます。これは、アクティブなDHCPサーバーごとに繰り返されます。このシナリオの例を図2に示します。
The major difference between the split prefixes approach and the multiple unique prefixes approach is that the latter does not require prefixes to be adjacent. In fact, the split prefixes approach can be considered a special case of the multiple unique prefixes approach.
分割接頭辞アプローチと複数の一意の接頭辞アプローチの主な違いは、後者では接頭辞が隣接している必要がないことです。実際、分割接頭辞アプローチは、複数の一意の接頭辞アプローチの特殊なケースと考えることができます。
This approach uses a unique prefix and ultimately a single pool per DHCPv6 server with the corresponding prefixes configured for use in the network. The corresponding network infrastructure must in turn be configured to use multiple prefixes on the interface(s) facing the DHCPv6 clients. The configuration is similar on all the servers, but a different prefix and a different preference are used for each DHCPv6 server.
このアプローチでは、一意のプレフィックスを使用し、最終的にはDHCPv6サーバーごとに1つのプールを使用して、対応するプレフィックスをネットワークで使用するように構成します。次に、対応するネットワークインフラストラクチャを、DHCPv6クライアントに面するインターフェイスで複数のプレフィックスを使用するように構成する必要があります。構成はすべてのサーバーで類似していますが、各DHCPv6サーバーに対して異なるプレフィックスと異なる設定が使用されます。
This approach drastically increases the rate of consumption of IPv6 prefixes and also yields operational and management challenges related to the underlying network since a significantly higher number of prefixes need to be configured and routed. It also does not provide a clean migration path to the desired solution using a standards-based DHCPv6 redundancy or failover protocol (which, of course, has yet to be specified).
このアプローチにより、IPv6プレフィックスの消費率が大幅に増加し、さらに多くのプレフィックスを構成してルーティングする必要があるため、基盤となるネットワークに関連する運用上および管理上の課題が生じます。また、標準ベースのDHCPv6冗長性またはフェイルオーバープロトコル（もちろん、まだ指定されていない）を使用して、目的のソリューションへのクリーンな移行パスを提供しません。
The use of multiple unique prefixes provides benefits related to dynamic updates to DNS similar to those referred to in Section 6.1. The use of multiple unique prefixes enables the differentiation of bindings and binding timing to determine which represents the current state. This becomes particularly important when DHCPv6 Leasequery [RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are used to determine lease or binding state. The use of separate prefixes and pools per DHCPv6 server makes failure conditions more obvious and detectable.
複数の一意のプレフィックスを使用すると、セクション6.1で言及したものと同様のDNSの動的更新に関連する利点が得られます。複数の一意のプレフィックスを使用すると、バインディングとバインディングタイミングを区別して、現在の状態を表すものを決定できます。これは、DHCPv6 Leasequery [RFC5007]またはDHCPv6 Bulk Leasequery [RFC5460]を使用してリースまたはバインディングの状態を判別する場合に特に重要になります。 DHCPv6サーバーごとに別々のプレフィックスとプールを使用すると、障害状態がより明確になり、検出可能になります。
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 255
Server 2
========
Prefix = 2001:db8:1:5::/64
Pool = 2001:db8:1:5::/64
Preference = 0
Server 3
========
Prefix = 2001:db8:1:f::/64
Pool = 2001:db8:1:f::/64
Preference = [1..254]
Figure 2: Multiple unique prefix approach
図2：複数の一意のプレフィックスアプローチ
In the identical prefix model, each DHCPv6 server is configured with the same overlapping prefix and pool deployed for use within an IPv6 network. Distribution between two or more servers, for example, would require that the same /64 prefix and pool be configured on all DHCP servers. For instance, the 2001:db8:1:1::/64 pool would be assigned to all the DHCPv6 servers for allocation to clients derived from the 2001:db8:1:1::/64 prefix. This would be repeated for each active DHCP server. An example of such a scenario is presented in Figure 3.
同一のプレフィックスモデルでは、各DHCPv6サーバーは、IPv6ネットワーク内で使用するためにデプロイされた同じ重複するプレフィックスとプールで構成されます。たとえば、2つ以上のサーバー間の分散では、すべてのDHCPサーバーで同じ/ 64プレフィックスとプールを構成する必要があります。たとえば、2001：db8：1：1 :: / 64プレフィックスから派生したクライアントに割り当てるために、2001：db8：1：1 :: / 64プールがすべてのDHCPv6サーバーに割り当てられます。これは、アクティブなDHCPサーバーごとに繰り返されます。このようなシナリオの例を図3に示します。
This approach uses the same prefix, length, and pool definition across multiple DHCPv6 servers. All other configuration parameters remain the same, with the exception of the DHCPv6 preference. Such an approach conceivably eases the migration of DHCPv6 services to fully support a standards-based redundancy or failover protocol once such solution becomes available. Similar to the split prefix architecture described above, this approach does not place any additional addressing requirements on the network infrastructure.
このアプローチでは、複数のDHCPv6サーバー間で同じプレフィックス、長さ、およびプール定義を使用します。 DHCPv6設定を除いて、他のすべての構成パラメーターは同じままです。このようなアプローチにより、DHCPv6サービスの移行が容易になり、標準ベースの冗長性またはフェイルオーバープロトコルが完全にサポートされるようになると、ソリューションが利用可能になります。上記のスプリットプレフィックスアーキテクチャと同様に、このアプローチではネットワークインフラストラクチャに追加のアドレッシング要件はありません。
The use of identical prefixes provides no benefit or advantage related to dynamic DNS updates, support of DHCPv6 Leasequery [RFC5007] or DHCPv6 Bulk Leasequery [RFC5460]. In this case, all DHCP servers will use the same prefix and pool configurations making it less obvious that a failure condition or event has occurred.
同一のプレフィックスを使用しても、動的DNS更新、DHCPv6 Leasequery [RFC5007]またはDHCPv6 Bulk Leasequery [RFC5460]のサポートに関連する利点や利点はありません。この場合、すべてのDHCPサーバーは同じプレフィックスとプール構成を使用するため、障害状態またはイベントが発生したことが明確にわかりません。
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 255
Server 2
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 0
Server 3
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = [1..254]
Figure 3: Identical prefix approach
図3：同一の接頭辞アプローチ
The lack of interaction between DHCPv6 servers introduces a number of challenges related to the operations of the same service instances in a production environment. The following areas are of particular concern:
DHCPv6サーバー間の相互作用がないため、実稼働環境での同じサービスインスタンスの操作に関連する多くの課題が生じます。次の領域が特に問題になります。
o In the identical prefixes scenario, both servers must follow the same address allocation procedure, i.e., they both must use the same algorithm and the same policy to determine which address is going to be assigned to a specific client. Otherwise, there is a distinct chance that each server will assign the same address to two different clients. It is expected that both servers will receive each incoming REQUEST message. Usually, no special action is required to achieve this as REQUEST messages are sent to a multicast address by clients. Relays are expected to forward incoming client messages to all servers. The client indicates the chosen server by including its DHCP Unique Identifier (DUID) in the Server-ID option. The chosen server assigns the address and other configuration options, while the other server discards the incoming request. In case of a failure of one server, the other server will assign the same address by following the same algorithm and the same policy.
o同じプレフィックスのシナリオでは、両方のサーバーが同じアドレス割り当て手順に従う必要があります。つまり、どちらのサーバーも同じアルゴリズムと同じポリシーを使用して、特定のクライアントに割り当てるアドレスを決定する必要があります。そうしないと、各サーバーが2つの異なるクライアントに同じアドレスを割り当てる可能性がはっきりとあります。両方のサーバーが各着信REQUESTメッセージを受信することが期待されています。通常、REQUESTメッセージはクライアントによってマルチキャストアドレスに送信されるため、特別なアクションは必要ありません。リレーは、着信クライアントメッセージをすべてのサーバーに転送することが期待されています。クライアントは、Server-IDオプションにDHCP一意識別子（DUID）を含めることにより、選択したサーバーを示します。選択されたサーバーはアドレスと他の構成オプションを割り当て、他のサーバーは着信要求を破棄します。一方のサーバーに障害が発生した場合、もう一方のサーバーは同じアルゴリズムと同じポリシーに従って同じアドレスを割り当てます。
o Interactions with DNS server(s) using dynamic update for the same address when one or more DHCPv6 servers have become unavailable. This specifically becomes a challenge when (or if) nodes that were initially granted a lease:
o 1つ以上のDHCPv6サーバーが利用できなくなったときに、同じアドレスに対して動的更新を使用するDNSサーバーとの相互作用。これは、最初にリースを許可されたノード（またはその場合）の場合、特に課題になります。
1. Attempt to renew or rebind the lease originally granted, or
1. 最初に付与されたリースを更新または再バインドする試み、または
2. Attempt to obtain a new lease
2. 新しいリースを取得しようとする
The DHCID resource record [RFC4701] allows identification of the current owner of the specific DNS data that is the target of an update [RFC2136]. [RFC4704] specifies how DHCPv6 servers and/or clients may perform updates. [RFC4703] provides a way to solve conflicts between clients. Although [RFC4703] deals with most cases, it is still possible to leave abandoned resource records. Consider the following scenario: there are two independent servers, A and B. Server A assigns a lease to a client and updates the DNS with an AAAA record for the assigned address. When the client renews, server A is not available and server B assigns a different lease. The DNS is again updated, so now two AAAA resource records are present for the client: there is no indication as to which of the two leases is active. If server A never recovers, its information may never be removed (although it should be noted that this case is somewhat similar to that of a single server crashing and leaving abandoned resource records).
DHCIDリソースレコード[RFC4701]を使用すると、更新の対象である特定のDNSデータの現在の所有者を特定できます[RFC2136]。 [RFC4704]は、DHCPv6サーバーやクライアントが更新を実行する方法を指定します。 [RFC4703]は、クライアント間の競合を解決する方法を提供します。 [RFC4703]はほとんどの場合を扱いますが、破棄されたリソースレコードを残すことは可能です。次のシナリオを考えてみます。AとBの2つの独立したサーバーがあります。サーバーAはクライアントにリースを割り当て、割り当てられたアドレスのAAAAレコードでDNSを更新します。クライアントが更新すると、サーバーAは使用できなくなり、サーバーBは別のリースを割り当てます。 DNSが再度更新されるため、クライアントには2つのAAAAリソースレコードが存在します。2つのリースのどちらがアクティブであるかはわかりません。サーバーAが回復しない場合、その情報は決して削除されない可能性があります（ただし、このケースは、単一サーバーがクラッシュし、破棄されたリソースレコードが残っている場合と多少似ています）。
o Interactions with DHCPv6 servers to facilitate the acquisition of IPv6 lease data by way of the DHCPv6 Leasequery [RFC5007] or DHCPv6 Bulk Leasequery [RFC5460] protocols when one or more DHCPv6 servers have granted leases to DHCPv6 clients and later became unavailable. If the lease data is required and the granting server is unavailable, it will not be possible to obtain any information about leases granted until one of the following has taken place: 1. The granting DHCPv6 server becomes available with all lease information restored.
o 1つ以上のDHCPv6サーバーがDHCPv6クライアントにリースを許可し、後で使用できなくなった場合に、DHCPv6 Leasequery [RFC5007]またはDHCPv6 Bulk Leasequery [RFC5460]プロトコルを介してIPv6リースデータの取得を容易にするDHCPv6サーバーとの相互作用。リースデータが必要であり、許可サーバーが利用できない場合、次のいずれかが行われるまで、許可されたリースに関する情報を取得することはできません。1.すべてのリース情報が復元され、許可DHCPv6サーバーが使用可能になります。
2. The client has renewed or rebound its lease against a different DHCPv6 server.
2. クライアントが別のDHCPv6サーバーに対してリースを更新またはリバウンドしました。
It is important to note that any exchange of available leases and synchronization between DHCPv6 servers is not possible until a redundancy or failover protocol is standardized or proprietary solutions become available.
冗長性またはフェイルオーバープロトコルが標準化されるか、独自のソリューションが利用可能になるまで、利用可能なリースの交換とDHCPv6サーバー間の同期は不可能であることに注意することが重要です。
Additional security considerations are created through the use of this interim architecture beyond what has been cited in Section 23 of [RFC3315]. In particular, the dynamic DNS update using the models defined in this document allows for the possibility of not removing abandoned DNS records even when using the conflict resolution mechanism defined in [RFC4703]. However, this is no worse than a case where a single deployed server crashes and its lease database cannot be recovered.
[RFC3315]のセクション23で引用されているものを超えて、この暫定アーキテクチャを使用することにより、セキュリティに関する追加の考慮事項が作成されます。特に、このドキュメントで定義されているモデルを使用した動的DNS更新では、[RFC4703]で定義されている競合解決メカニズムを使用している場合でも、破棄されたDNSレコードを削除しない可能性があります。ただし、これは、デプロイされた単一のサーバーがクラッシュし、そのリースデータベースを回復できない場合よりも悪くはありません。
When using the identical prefixes model, care must be taken to ensure that all servers use the same lease allocation procedure and are configured with the same policy. If this guidance is not followed, there is a risk of assignment of the same lease to two separate clients. In some cases, that situation can be recovered by using Duplicate Address Detection (Neighbor Discovery) and the DECLINE mechanism (DHCPv6).
同一のプレフィックスモデルを使用する場合は、すべてのサーバーが同じリース割り当て手順を使用し、同じポリシーで構成されていることを確認する必要があります。このガイダンスに従わない場合、同じリースを2つの別々のクライアントに割り当てるリスクがあります。場合によっては、重複アドレス検出（近隣探索）およびDECLINEメカニズム（DHCPv6）を使用することで、この状況を回復できます。
The authors would like to thank Bernie Volz, Kim Kinnear, Ralph Droms, David Hankins, Chuck Anderson, Ted Lemon, Stephen Farrel, Pete McCann, Robert Sparks, Martin Stiemerling, Brian Haberman, and Barry Leiba for their input and review.
著者は、バーニー・ヴォルツ、キム・キニア、ラルフ・ドロムス、デビッド・ハンキンス、チャック・アンダーソン、テッド・レモン、スティーブン・ファレル、ピート・マッキャン、ロバート・スパークス、マーティン・スティーマーリング、ブライアン・ハーバーマン、バリー・レイバに意見とレビューを提供してくれたことに感謝します。
Special thanks to Stephen Morris for his numerous spelling, grammar corrections, and proofreading.
多数のスペル、文法の修正、校正を行ったStephen Morrisに特に感謝します。
This work has been partially supported by 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（将来のインターネットエンジニアリングプロジェクト）。
[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月。
[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月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] Droms、R。、「IPv6用のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)", RFC 4701, October 2006.
[RFC4701] Stapp、M.、Lemon、T。、およびA. Gustafsson、「Dynamic Host Configuration Protocol（DHCP）Information（DHCID RR）をエンコードするためのDNSリソースレコード（RR）」、RFC 4701、2006年10月。
[RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients", RFC 4703, October 2006.
[RFC4703] Stapp、M。およびB. Volz、「動的ホスト構成プロトコル（DHCP）クライアント間の完全修飾ドメイン名（FQDN）競合の解決」、RFC 4703、2006年10月。
[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月。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5007] Brzozowski、J.、Kinnear、K.、Volz、B。、およびS. Zeng、「DHCPv6 Leasequery」、RFC 5007、2007年9月。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.
[RFC5460] Stapp、M。、「DHCPv6 Bulk Leasequery」、RFC 5460、2009年2月。
[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月。
[FAILREQ] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Requirements", Work in Progress, September 2012.
[FAILREQ] Mrugalski、T。およびK. Kinnear、「DHCPv6フェイルオーバー要件」、Work in Progress、2012年9月。
Authors' Addresses
著者のアドレス
John Jason Brzozowski Comcast Cable Communications 1306 Goshen Parkway West Chester, PA 19380 USA
John Jason Brzozowski Comcast Cable Communications 1306 Goshen Parkway West Chester、PA 19380 USA
Phone: +1-609-377-6594
EMail: john_brzozowski@cable.comcast.com
Jean-Francois Tremblay Videotron G.P. 612 Saint-Jacques Montreal, Quebec H3C 4M8 Canada
Jean-Francois Tremblay Videotron G.P. 612 Saint-Jacquesモントリオールケベック州H3C 4M8カナダ
EMail: jf@jftremblay.com
Jack Chen Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 USA
ジャックチェンタイムワーナーケーブル13820 Sunrise Valley Drive Herndon、VA 20171 USA
EMail: jack.chen@twcable.com
Tomasz Mrugalski Internet Systems Consortium, Inc. 950 Charter St. Redwood City, CA 94063 USA
Tomasz Mrugalski Internet Systems Consortium、Inc. 950 Charter St. Redwood City、CA 94063 USA
Phone: +1 650 423 1345
EMail: tomasz.mrugalski@gmail.com