[要約] RFC 8475は、企業のマルチホーミングにおける条件付きルータ広告の使用に関するものであり、要約すると以下のようになります。1. マルチホーミング環境での効果的なネットワーク接続を実現するために、条件付きルータ広告の使用方法を提案している。 2. このRFCの目的は、企業のネットワーク環境におけるマルチホーミングの実装をサポートし、ネットワークの冗長性と可用性を向上させることである。 3. 条件付きルータ広告を使用することで、ネットワークトラフィックの効率化やフェールオーバーの改善など、マルチホーミング環境でのネットワーク管理の柔軟性を向上させることが期待される。
Internet Engineering Task Force (IETF) J. Linkova
Request for Comments: 8475 Google
Category: Informational M. Stucchi
ISSN: 2070-1721 RIPE NCC
October 2018
Using Conditional Router Advertisements for Enterprise Multihoming
エンタープライズマルチホーミングでの条件付きルーターアドバタイズの使用
Abstract
概要
This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028.
このドキュメントでは、ISPによって割り当てられたアドレススペースを使用してエンタープライズネットワークを複数のISPに接続する最も一般的なシナリオと、「ネットワークプレフィックス変換なしのプロバイダー割り当てアドレスを使用したエンタープライズマルチホーミング：要件とソリューション」で提案されたアプローチをどのように適用できるかについて説明しますそれらのシナリオ。ネットワークがパケットの送信元アドレスに基づいて正しい出力ISPを選択する必要があり、ホストがそのために目的の出力ISPに基づいて正しい送信元アドレスを選択する必要があるため、どの形式のアドレス変換もないエンタープライズマルチホーミングの問題はまだ解決されていませんトラフィック。前述のドキュメントは、アップリンク選択の問題を解決するための新しいルーティング機能（Source Address Dependent Routing）を導入することにより、この問題の解決策を提案しています。また、ルーターアドバタイズメントを使用して、ホストの送信元アドレスの選択に影響を与えることも提案しています。一般的な問題の解決とさまざまな複雑なユースケースのカバーに重点を置いており、このドキュメントでは、提案されたアプローチを採用して、限られた数の一般的なユースケースのソリューションを提供します。特に、このドキュメントでは、エンタープライズネットワークにプライマリ/バックアップモードまたは同時に使用される2つのインターネットアップリンクがあり、そのネットワーク内のホストがRFC 8028で説明されているマルチホーミングをまだ適切にサポートしていないシナリオに焦点を当てています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 https://www.rfc-editor.org/info/rfc8475.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8475で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 4
2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 4
2.2. Two ISP Uplinks, Used for Load-Balancing . . . . . . . . 5
3. Conditional Router Advertisements . . . . . . . . . . . . . . 5
3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 5
3.1.2. Source Address Selection and Conditional RAs . . . . 5
3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 8
3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 9
3.2.3. Single Router, Load-Balancing between Uplinks . . . . 12
3.2.4. Two Routers, Load-Balancing between Uplinks . . . . . 12
3.2.5. Topologies with Dedicated Border Routers . . . . . . 13
3.2.6. Intrasite Communication during Simultaneous Uplinks
Outage . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 15
3.2.8. Routing Packets When the Corresponding Uplink Is
Unavailable . . . . . . . . . . . . . . . . . . . . . 16
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 16
3.3.1. Connections Preservation . . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Multihoming is an obvious requirement for many enterprise networks to ensure the desired level of network reliability. However, using more than one ISP (and address space assigned by those ISPs) introduces the problem of assigning IP addresses to hosts. In IPv4, there is no choice but using address space [RFC1918] and NAT [RFC3022] at the network edge [RFC4116]. Using Provider Independent (PI) address space is not always an option, since it requires running BGP between the enterprise network and the ISPs. The administrative overhead of obtaining and managing PI address space can also be a concern. As IPv6 hosts can, by design, have multiple addresses of the global scope [RFC4291], multihoming using provider addresses looks even easier for IPv6: each ISP assigns an IPv6 block (usually /48), and hosts in the enterprise network have addresses assigned from each ISP block. However, using IPv6 provider-assigned (PA) blocks in a multihoming scenario introduces some challenges, including, but not limited to:
マルチホーミングは、望ましいレベルのネットワーク信頼性を確保するために、多くの企業ネットワークにとって明白な要件です。ただし、複数のISP（およびそれらのISPによって割り当てられたアドレススペース）を使用すると、ホストにIPアドレスを割り当てる際に問題が発生します。 IPv4では、ネットワークエッジ[RFC4116]でアドレススペース[RFC1918]とNAT [RFC3022]を使用する以外に選択肢はありません。エンタープライズネットワークとISPの間でBGPを実行する必要があるため、プロバイダーに依存しない（PI）アドレススペースを使用することは必ずしも選択肢ではありません。 PIアドレス空間の取得と管理の管理オーバーヘッドも問題になる可能性があります。 IPv6ホストは、設計により、グローバルスコープ[RFC4291]の複数のアドレスを持つことができるため、プロバイダーアドレスを使用したマルチホーミングは、IPv6の場合はさらに簡単に見えます。各ISPはIPv6ブロック（通常は/ 48）を割り当て、エンタープライズネットワーク内のホストにはアドレスが割り当てられます各ISPブロックから。ただし、IPv6プロバイダー割り当て（PA）ブロックをマルチホーミングシナリオで使用すると、次のようないくつかの課題が生じます。
o Selecting the correct uplink based on the packet source address;
o パケットの送信元アドレスに基づいて正しいアップリンクを選択します。
o Signaling to hosts that some source addresses should or should not be used (e.g., an uplink to the ISP went down or became available again).
o 一部の送信元アドレスを使用する必要があるかどうかをホストに通知する（たとえば、ISPへのアップリンクがダウンしたか、再び使用可能になった）。
[PROVIDER-ASSIGNED] discusses these and other related challenges in detail in relation to the general multihoming scenario for enterprise networks. It proposes a solution that relies heavily on Rule 5.5 of the default address selection algorithm [RFC6724]. Rule 5.5 makes hosts prefer source addresses in a prefix advertised by the next hop and, therefore, is very useful in multihomed scenarios when different routers may advertise different prefixes. While [RFC6724] defines Rule 5.5 as optional, the recent [RFC8028] recommends that multihomed hosts SHOULD support it. Unfortunately, that rule has not been widely implemented at the time of writing. Therefore, network administrators in enterprise networks can't yet assume that all devices in their network support Rule 5.5, especially in the quite common BYOD ("Bring Your Own Device") scenario. However, while it does not seem feasible to solve all the possible multihoming scenarios without relying on Rule 5.5, it is possible to provide IPv6 multihoming using PA address space for the most common use cases. This document discusses how the general approach described in [PROVIDER-ASSIGNED] can be applied to solve multihoming scenarios when:
[PROVIDER-ASSIGNED]は、エンタープライズネットワークの一般的なマルチホーミングシナリオに関連して、これらおよびその他の関連する課題について詳細に説明しています。デフォルトのアドレス選択アルゴリズム[RFC6724]のルール5.5に大きく依存するソリューションを提案します。ルール5.5は、ホストにネクストホップによってアドバタイズされるプレフィックスの送信元アドレスを優先させるため、異なるルーターが異なるプレフィックスをアドバタイズする可能性があるマルチホームのシナリオで非常に役立ちます。 [RFC6724]はルール5.5をオプションとして定義していますが、最近の[RFC8028]はマルチホームホストがそれをサポートする必要があることを推奨しています。残念ながら、このルールは執筆時点では広く実装されていません。したがって、エンタープライズネットワークのネットワーク管理者は、ネットワーク内のすべてのデバイスが、特に非常に一般的なBYOD（「独自のデバイスの持ち込み」）シナリオで、ルール5.5をサポートするとはまだ想定できません。ただし、ルール5.5に依存せずにすべての可能なマルチホーミングシナリオを解決することは現実的ではないように思われますが、最も一般的なユースケースでPAアドレススペースを使用してIPv6マルチホーミングを提供することは可能です。このドキュメントでは、[PROVIDER-ASSIGNED]で説明されている一般的なアプローチを適用して、マルチホーミングシナリオを解決する方法について説明します。
o An enterprise network has two or more ISP uplinks;
o 企業ネットワークには2つ以上のISPアップリンクがあります。
o Those uplinks are used for Internet access in active/backup or load-sharing mode without any sophisticated traffic engineering requirements;
o これらのアップリンクは、高度なトラフィックエンジニアリング要件なしに、アクティブ/バックアップまたは負荷共有モードでインターネットアクセスに使用されます。
o Each ISP assigns the network a subnet from its own PA address space; and
o 各ISPは、独自のPAアドレス空間からサブネットをネットワークに割り当てます。そして
o Hosts in the enterprise network are not expected to support Rule 5.5 of the default address selection algorithm [RFC6724].
o 企業ネットワークのホストは、デフォルトのアドレス選択アルゴリズム[RFC6724]のルール5.5をサポートすることは想定されていません。
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 scenario has the following key characteristics:
このシナリオには、次の主要な特徴があります。
o The enterprise network uses uplinks to two (or more) ISPs for Internet access;
o エンタープライズネットワークでは、インターネットアクセスに2つ（またはそれ以上）のISPへのアップリンクを使用します。
o Each ISP assigns IPv6 PA address space for the network;
o 各ISPは、ネットワークにIPv6 PAアドレススペースを割り当てます。
o Uplink(s) to one ISP is a primary (preferred) one. All other uplinks are backup and are not expected to be used while the primary one is operational;
o 1つのISPへのアップリンクがプライマリ（推奨）です。他のすべてのアップリンクはバックアップであり、プライマリのアップリンクが動作している間は使用しないでください。
o If the primary uplink is operational, all Internet traffic should flow via that uplink;
o プライマリアップリンクが機能している場合、すべてのインターネットトラフィックはそのアップリンクを経由する必要があります。
o When the primary uplink fails, the Internet traffic needs to flow via the backup uplinks;
o プライマリアップリンクに障害が発生した場合、インターネットトラフィックはバックアップアップリンクを経由する必要があります。
o Recovery of the primary uplink needs to trigger the traffic switchover from the backup uplinks back to the primary one;
o プライマリアップリンクの復旧は、バックアップアップリンクからプライマリアップリンクへのトラフィックスイッチオーバーをトリガーする必要があります。
o Hosts in the enterprise network are not expected to support Rule 5.5 of the default address selection algorithm [RFC6724].
o 企業ネットワークのホストは、デフォルトのアドレス選択アルゴリズム[RFC6724]のルール5.5をサポートすることは想定されていません。
This scenario has the following key characteristics:
このシナリオには、次の主要な特徴があります。
o The enterprise network is using uplinks to two (or more) ISPs for Internet access;
o エンタープライズネットワークは、インターネットアクセスに2つ（またはそれ以上）のISPへのアップリンクを使用しています。
o Each ISP assigns an IPv6 PA address space;
o 各ISPはIPv6 PAアドレス空間を割り当てます。
o All the uplinks may be used simultaneously, with the traffic flows being randomly (not necessarily equally) distributed between them;
o すべてのアップリンクを同時に使用でき、トラフィックフローはそれらの間でランダムに（必ずしも等しくはありません）分散されます。
o Hosts in the enterprise network are not expected to support Rule 5.5 of the default address selection algorithm [RFC6724].
o 企業ネットワークのホストは、デフォルトのアドレス選択アルゴリズム[RFC6724]のルール5.5をサポートすることは想定されていません。
As discussed in [PROVIDER-ASSIGNED], one of the two main problems to be solved in the enterprise multihoming scenario is the problem of the next-hop (uplink) selection based on the packet source address. For example, if the enterprise network has two uplinks, to ISP_A and ISP_B, and hosts have addresses from subnet_A and subnet_B (belonging to ISP_A and ISP_B, respectively), then packets sourced from subnet_A must be sent to the ISP_A uplink while packets sourced from subnet_B must be sent to the ISP_B uplink. Sending packets with source addresses belonging to one ISP address space to another ISP might cause those packets to be filtered out if those ISPs or their uplinks implement antispoofing ingress filtering [RFC2827][RFC3704].
[PROVIDER-ASSIGNED]で説明したように、エンタープライズマルチホーミングシナリオで解決すべき2つの主な問題の1つは、パケットの送信元アドレスに基づくネクストホップ（アップリンク）選択の問題です。たとえば、企業ネットワークにISP_AとISP_Bへの2つのアップリンクがあり、ホストにそれぞれsubnet_Aとsubnet_Bからのアドレス（それぞれISP_AとISP_Bに属している）がある場合、subnet_Aから送信されたパケットはISP_Aアップリンクに送信され、パケットはsubnet_BはISP_Bアップリンクに送信する必要があります。 1つのISPアドレススペースに属するソースアドレスを持つパケットを別のISPに送信すると、それらのISPまたはそのアップリンクがスプーフィング防止フィルタリング[RFC2827] [RFC3704]を実装している場合、これらのパケットがフィルターで除外される可能性があります。
While some work is being done in the Source Address Dependent Routing (SADR) (such as [DESTINATION]), the simplest way to implement the desired functionality currently is to apply a policy that selects a next hop or an egress interface based on the packet source address. Currently, most SMB/Enterprise-grade routers have such functionality available.
送信元アドレス依存ルーティング（SADR）（[DESTINATION]など）でいくつかの作業が行われていますが、現在必要な機能を実装する最も簡単な方法は、パケットに基づいてネクストホップまたは出力インターフェイスを選択するポリシーを適用することです送信元アドレス。現在、ほとんどのSMB /エンタープライズグレードのルーターには、このような機能があります。
Another problem to be solved in the multihoming scenario is the source address selection on hosts. In the normal situation (all uplinks are up/operational), hosts have multiple global unique addresses and can rely on the default address selection algorithm [RFC6724] to pick up a source address, while the network is responsible for choosing the correct uplink based on the source address selected by a host, as described in Section 3.1.1. However, some network topology changes (i.e., changing uplink status) might affect the global reachability for packets sourced from particular prefixes; therefore, such changes have to be signaled back to the hosts. For example:
マルチホーミングシナリオで解決すべきもう1つの問題は、ホストでの送信元アドレスの選択です。通常の状況（すべてのアップリンクがアップ/操作可能）では、ホストに複数のグローバル一意アドレスがあり、デフォルトのアドレス選択アルゴリズム[RFC6724]に基づいてソースアドレスを取得できますが、ネットワークは、セクション3.1.1で説明されているように、ホストによって選択された送信元アドレス。ただし、一部のネットワークトポロジの変更（つまり、アップリンクステータスの変更）は、特定のプレフィックスをソースとするパケットのグローバルな到達可能性に影響を与える可能性があります。したがって、このような変更はホストに通知する必要があります。例えば：
o An uplink to ISP_A went down. Hosts should not use addresses from an ISP_A prefix;
o ISP_Aへのアップリンクがダウンしました。ホストはISP_Aプレフィックスのアドレスを使用しないでください。
o A primary uplink to ISP_A that was not operational has come back up. Hosts should start using the source addresses from an ISP_A prefix.
o 動作していなかったISP_Aへのプライマリアップリンクが復旧しました。ホストは、ISP_Aプレフィックスからのソースアドレスの使用を開始する必要があります。
[PROVIDER-ASSIGNED] provides a detailed explanation of why Stateless Address Autoconfiguration (SLAAC) [RFC4862] and Router Advertisements (RAs) [RFC4861] are the most suitable mechanisms for signaling network topology changes to hosts, thereby influencing the source address selection. Sending an RA to change the preferred lifetime for a given prefix provides the following functionality:
[PROVIDER-ASSIGNED]は、ステートレスアドレス自動構成（SLAAC）[RFC4862]とルーターアドバタイズメント（RA）[RFC4861]がホストへのネットワークトポロジ変更のシグナリングに最も適したメカニズムであり、それによって送信元アドレスの選択に影響を与える理由を詳しく説明しています。特定のプレフィックスの優先ライフタイムを変更するためにRAを送信すると、次の機能が提供されます。
o Deprecating addresses by sending an RA with preferred_lifetime set to 0 in the corresponding Prefix Information option (PIO) [RFC4861]. This indicates to hosts that addresses from that prefix should not be used;
o 対応するプレフィックス情報オプション（PIO）[RFC4861]で、preferred_lifetimeを0に設定してRAを送信することにより、アドレスを非推奨にします。これは、そのプレフィックスからのアドレスを使用してはならないことをホストに示します。
o Making a previously unused (deprecated) prefix usable again by sending an RA containing a PIO with nonzero preferred lifetime. This indicates to hosts that addresses from that prefix can be used again.
o ゼロ以外の推奨存続期間を持つPIOを含むRAを送信することにより、以前に使用されていない（非推奨）プレフィックスを再び使用可能にします。これは、そのプレフィックスからのアドレスを再び使用できることをホストに示します。
It should be noted that only the preferred lifetime for the affected prefix needs to be changed. As the goal is to influence the source address selection algorithm on hosts rather than prevent them from forming addresses from a specific prefix, the valid lifetime should not be changed. Actually, changing the valid lifetime would not even be possible for unauthenticated RAs (which is the most common deployment scenario), because Section 5.5.3 of [RFC4862] prevents hosts from setting the valid lifetime for addresses to zero unless RAs are authenticated.
影響を受けるプレフィックスの優先ライフタイムのみを変更する必要があることに注意してください。目標は、ホストが特定のプレフィックスからアドレスを形成しないようにするのではなく、ホスト上のソースアドレス選択アルゴリズムに影響を与えることなので、有効期間を変更しないでください。 [RFC4862]のセクション5.5.3は、ホストがRAが認証されていない限り、アドレスの有効期間をゼロに設定できないため、実際には、認証されていないRAでも有効期間を変更することはできません（これは最も一般的な導入シナリオです）。
To provide the desired functionality, first-hop routers are required to:
必要な機能を提供するには、ファーストホップルーターが次のことを行う必要があります。
o Send RAs triggered by defined event policies in response to an uplink status change event; and
o アップリンクステータス変更イベントに応答して、定義されたイベントポリシーによってトリガーされたRAを送信します。そして
o While sending periodic or solicited RAs, set the value in the given RA field (e.g., PIO preferred lifetime) based on the uplink status.
o 定期的または要請されたRAを送信する際に、アップリンクステータスに基づいて、所定のRAフィールドに値を設定します（たとえば、PIO優先ライフタイム）。
The exact definition of the "uplink status" depends on the network topology and may include conditions like:
「アップリンクステータス」の正確な定義はネットワークトポロジによって異なり、次のような条件が含まれる場合があります。
o Uplink interface status change;
o アップリンクインターフェイスステータスの変更。
o Presence of a particular route in the routing table;
o ルーティングテーブル内の特定のルートの存在。
o Presence of a particular route with a particular attribute (next hop, tag, etc.) in the routing table;
o ルーティングテーブルに特定の属性（ネクストホップ、タグなど）を持つ特定のルートが存在する。
o Protocol adjacency change.
o プロトコル隣接関係の変更。
In some scenarios, when two routers are providing first-hop redundancy via Virtual Router Redundancy Protocol (VRRP) [RFC5798], the master-backup status can be considered to be a condition for sending RAs and changing the preferred lifetime value. See Section 3.2.2 for more details.
一部のシナリオでは、2台のルーターが仮想ルーター冗長プロトコル（VRRP）[RFC5798]を介してファーストホップ冗長性を提供している場合、マスターバックアップステータスは、RAを送信し、優先ライフタイム値を変更するための条件と見なすことができます。詳細については、セクション3.2.2を参照してください。
If hosts are provided with the IPv6 addresses of ISP DNS servers via a Recursive DNS Server (RDNSS) (see "IPv6 Router Advertisement Options for DNS Configuration" [RFC8106]), it might be desirable for the conditional RAs to update the Lifetime field of the RDNSS option as well.
ホストに、再帰DNSサーバー（RDNSS）を介してISP DNSサーバーのIPv6アドレスが提供されている場合（「DNS構成のIPv6ルーターアドバタイズメントオプション」[RFC8106]を参照）、条件付きRAのライフタイムフィールドを更新することが望ましい場合があります。 RDNSSオプションも同様です。
The trigger is not only forcing the router to send an unsolicited RA to propagate the topology changes to all hosts. Obviously, the values of the RA fields (like PIO Preferred Lifetime or DNS Server Lifetime) changed by the particular trigger need to stay the same until another event causes the value to be updated. For example, if an ISP_A uplink failure causes the prefix to be deprecated, all solicited and unsolicited RAs sent by the router need to have the preferred lifetime for that PIO set to 0 until the uplink comes back up.
トリガーは、ルーターに非送信請求RAを送信してトポロジーの変更をすべてのホストに伝搬させることだけではありません。明らかに、特定のトリガーによって変更されたRAフィールドの値（PIO Preferred LifetimeやDNS Server Lifetimeなど）は、別のイベントによって値が更新されるまで同じままである必要があります。たとえば、ISP_Aアップリンクの障害によりプレフィックスが廃止される場合、ルーターによって送信されるすべての要請された非送信請求RAは、アップリンクが復旧するまで、そのPIOの優先ライフタイムを0に設定する必要があります。
It should be noted that the proposed solution is quite similar to the existing requirement L-13 for IPv6 Customer Edge Routers [RFC7084] and the documented behavior of homenet devices [RFC7788]. It is using the same mechanism of deprecating a prefix when the corresponding uplink is not operational, applying it to an enterprise-network scenario.
提案されたソリューションは、IPv6カスタマーエッジルーターの既存の要件L-13 [RFC7084]およびホームネットデバイスの文書化された動作[RFC7788]と非常に似ていることに注意してください。対応するアップリンクが動作していないときにプレフィックスを廃止するのと同じメカニズムを使用して、エンタープライズネットワークシナリオに適用します。
This section illustrates how the conditional RAs solution can be applied to the most common enterprise multihoming scenarios, described in Section 2.
このセクションでは、セクション2で説明する最も一般的なエンタープライズマルチホーミングシナリオに条件付きRAソリューションを適用する方法を示します。
--------
,-------, / \
+----+ 2001:db8:1::/48 ,' ', : :
| |-----------------+ ISP_A +--+: :
2001:db8:1:1::/64 | | ', ,' : :
| | '-------' : :
H1-----------------| R1 | : INTERNET :
| | ,-------, : :
2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : :
| |-----------------+ ISP_B +--+: :
+----+ ', ,' : :
'-------' \ /
--------
Figure 1: Single Router, Primary/Backup Uplinks
図1：単一ルーター、プライマリ/バックアップアップリンク
Let's look at a simple network topology where a single router acts as a border router to terminate two ISP uplinks and as a first-hop router for hosts. Each ISP assigns a /48 to the network, and the ISP_A uplink is a primary one, to be used for all Internet traffic, while the ISP_B uplink is a backup, to be used only when the primary uplink is not operational.
1つのルーターが2つのISPアップリンクを終端する境界ルーターとして機能し、ホストのファーストホップルーターとして機能する単純なネットワークトポロジを見てみましょう。各ISPはネットワークに/ 48を割り当て、ISP_Aアップリンクはすべてのインターネットトラフィックに使用されるプライマリリンクですが、ISP_Bアップリンクはバックアップであり、プライマリアップリンクが動作していないときにのみ使用されます。
To ensure that packets with source addresses from ISP_A and ISP_B are only routed to ISP_A and ISP_B uplinks, respectively, the network administrator needs to configure a policy on R1:
ISP_AおよびISP_Bからの送信元アドレスを持つパケットがそれぞれISP_AおよびISP_Bアップリンクにのみルーティングされるようにするには、ネットワーク管理者がR1にポリシーを構成する必要があります。
IF (packet_source_address is in 2001:db8:1::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_A_uplink
IF (packet_source_address is in 2001:db8:2::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_B_uplink
Under normal circumstances, it is desirable that all traffic be sent via the ISP_A uplink; therefore, hosts (the host H1 in the example topology figure) should be using source addresses from 2001:db8:1:1::/64. When or if the ISP_A uplink fails, hosts should stop using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 until the ISP_A uplink comes back up. To achieve this, the RA configuration on the R1 device for the interface facing H1 needs to have the following policy:
通常の状況では、すべてのトラフィックがISP_Aアップリンクを介して送信されることが望ましいです。したがって、ホスト（トポロジ図の例ではホストH1）は2001：db8：1：1 :: / 64のソースアドレスを使用する必要があります。 ISP_Aアップリンクが失敗した場合、または失敗した場合、ホストは2001：db8：1：1 :: / 64プレフィックスの使用を停止し、ISP_Aアップリンクが復旧するまで2001：db8：2：1 :: / 64の使用を開始する必要があります。これを実現するには、H1に面するインターフェイスのR1デバイスのRA構成に次のポリシーが必要です。
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_A_Uplink is up)
THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
}
A similar policy needs to be applied to the RDNSS lifetime if ISP_A and ISP_B DNS servers are used.
ISP_AおよびISP_B DNSサーバーが使用されている場合、同様のポリシーをRDNSSライフタイムに適用する必要があります。
Let's look at a more complex scenario where two border routers are terminating two ISP uplinks (one each), acting as redundant first-hop routers for hosts. The topology is shown in Figure 2.
2つの境界ルーターが2つのISPアップリンク（それぞれ1つ）を終端し、ホストの冗長ファーストホップルーターとして機能する、より複雑なシナリオを見てみましょう。トポロジーを図2に示します。
--------
,-------, / \
2001:db8:1:1::/64 +----+ 2001:db8:1::/48 ,' ', : :
_| |----------------+ ISP_A +--+: :
| | R1 | ', ,' : :
| +----+ '-------' : :
H1----------------| : INTERNET :
| +----+ ,-------, : :
|_| | 2001:db8:2::/48 ,' ', : :
| R2 |----------------+ ISP_B +--+: :
2001:db8:2:1::/64 +----+ ', ,' : :
'-------' \ /
--------
Figure 2: Two Routers, Primary/Backup Uplinks
図2：2つのルーター、プライマリ/バックアップアップリンク
In this scenario, R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A address space), and R2 sends RAs with PIO for 2001:db8:2:1::/64 (ISP_B address space). Each router needs to have a forwarding policy configured for packets received on its hosts-facing interface:
このシナリオでは、R1はPIOを使用してRAを2001：db8：1：1 :: / 64（ISP_Aアドレス空間）に送信し、R2はPIOを使用してRAを2001：db8：2：1 :: / 64（ISP_Bアドレス空間）に送信します。 。各ルーターには、ホストに面するインターフェースで受信したパケット用に構成された転送ポリシーが必要です。
IF (packet_source_address is in 2001:db8:1::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_A_uplink
IF (packet_source_address is in 2001:db8:2::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_B_uplink
In this case, there is more than one way to ensure that hosts are selecting the correct source address based on the uplink status. If VRRP is used to provide first-hop redundancy, and the master router is the one with the active uplink, then the simplest way is to use the VRRP mastership as a condition for RA. So, if ISP_A is the primary uplink, the routers R1 and R2 need to be configured in the following way:
この場合、ホストがアップリンクステータスに基づいて正しい送信元アドレスを選択していることを確認する方法は複数あります。 VRRPを使用してファーストホップ冗長性を提供し、マスタールータがアクティブなアップリンクを備えている場合、最も簡単な方法は、RAの条件としてVRRPマスターシップを使用することです。したがって、ISP_Aがプライマリアップリンクである場合、ルータR1およびR2は次のように設定する必要があります。
R1 is the VRRP master by default (when the ISP_A uplink is up). If the ISP_A uplink is down, then R1 becomes a backup (the VRRP interface-status tracking is expected to be used to automatically modify the VRRP priorities and trigger the mastership switchover). RAs on R1's interface facing H1 needs to have the following policy applied:
R1はデフォルトでVRRPマスターです（ISP_Aアップリンクがアップの場合）。 ISP_Aアップリンクがダウンしている場合、R1がバックアップになります（VRRPインターフェイスステータストラッキングを使用して、VRRP優先度を自動的に変更し、マスターシップスイッチオーバーをトリガーすることが期待されます）。 H1に面するR1のインターフェイス上のRAには、次のポリシーを適用する必要があります。
prefix 2001:db8:1:1::/64 {
IF (vrrp_master)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
R2 is VRRP backup by default. RA on R2's interface facing H1 needs to have the following policy applied:
R2はデフォルトでVRRPバックアップです。 H1に面するR2のインターフェイスのRAには、次のポリシーを適用する必要があります。
prefix 2001:db8:2:1::/64 {
IF(vrrp_master)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
If VRRP is not used or interface status tracking is not used for mastership switchover, then each router needs to be able to detect the uplink failure/recovery on the neighboring router, so that RAs with updated preferred lifetime values are triggered. Depending on the network setup, various triggers can be used, such as a route to the uplink interface subnet or a default route received from the uplink. The obvious drawback of using the routing table to trigger the conditional RAs is that some additional configuration is required. For example, if a route to the prefix assigned to the ISP uplink is used as a trigger, then the conditional RA policy would have the following logic:
VRRPが使用されていない場合、またはマスターシップスイッチオーバーにインターフェースステータストラッキングが使用されていない場合は、各ルーターが隣接ルーターのアップリンク障害/回復を検出できるようにする必要があります。これにより、優先ライフタイム値が更新されたRAがトリガーされます。ネットワーク設定に応じて、アップリンクインターフェイスサブネットへのルートやアップリンクから受信したデフォルトルートなど、さまざまなトリガーを使用できます。ルーティングテーブルを使用して条件付きRAをトリガーする明らかな欠点は、追加の構成が必要になることです。たとえば、ISPアップリンクに割り当てられたプレフィックスへのルートがトリガーとして使用される場合、条件付きRAポリシーには次のロジックがあります。
R1:
R1：
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
R2:
prefix 2001:db8:2:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
}
Let's look at the example topology shown in Figure 1, but with both uplinks used simultaneously. In this case, R1 would send RAs containing PIOs for both prefixes, 2001:db8:1:1::/64 and 2001:db8:2:1::/64, changing the preferred lifetime based on particular uplink availability. If the interface status is used as an uplink availability indicator, then the policy logic would look like the following:
図1に示すトポロジの例を見てみましょう。ただし、両方のアップリンクが同時に使用されています。この場合、R1は、2001：db8：1：1 :: / 64と2001：db8：2：1 :: / 64の両方のプレフィックスのPIOを含むRAを送信し、特定のアップリンクの可用性に基づいて優先ライフタイムを変更します。インターフェイスステータスがアップリンクの可用性インジケータとして使用される場合、ポリシーロジックは次のようになります。
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
R1 needs a forwarding policy to be applied to forward packets to the correct uplink based on the source address, similar to the policy described in Section 3.2.1.
R1では、セクション3.2.1で説明したポリシーと同様に、送信元アドレスに基づいて正しいアップリンクにパケットを転送するために適用する転送ポリシーが必要です。
In this scenario, the example topology is similar to the one shown in Figure 2, but both uplinks can be used at the same time. This means that both R1 and R2 need to have the corresponding forwarding policy to forward packets based on their source addresses.
このシナリオでは、トポロジの例は図2に示すものと似ていますが、両方のアップリンクを同時に使用できます。つまり、送信元アドレスに基づいてパケットを転送するには、R1とR2の両方に対応する転送ポリシーが必要です。
Each router would send RAs with PIO for the corresponding prefix, setting preferred_lifetime to a nonzero value when the ISP uplink is up and deprecating the prefix by setting preferred_lifetime to 0 in the case of uplink failure. The uplink recovery would trigger another RA with a nonzero preferred lifetime to make the addresses from the prefix preferred again. The example RA policy on R1 and R2 would look like:
各ルーターは、対応するプレフィックスのPIOを含むRAを送信します。ISPアップリンクが稼働している場合は、preferred_lifetimeをゼロ以外の値に設定し、アップリンク障害が発生した場合は、preferred_lifetimeを0に設定してプレフィックスを非推奨にします。アップリンクの回復により、ゼロ以外の推奨存続期間を持つ別のRAがトリガーされ、プレフィックスからのアドレスが再び優先されます。 R1とR2のRAポリシーの例は次のようになります。
R1:
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
R2:
R2：
prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
For simplicity, all topologies above show the ISP uplinks terminated on the first-hop routers. Obviously, the proposed approach can be used in more complex topologies when dedicated devices are used for terminating ISP uplinks. In that case, VRRP mastership or interface status cannot be used as a trigger for conditional RAs. Route presence as described in Section 3.2.2 should be used instead.
簡単にするために、上記のすべてのトポロジは、ファーストホップルーターで終端されたISPアップリンクを示しています。明らかに、ISPアップリンクの終端に専用デバイスが使用されている場合、提案されたアプローチはより複雑なトポロジで使用できます。その場合、VRRPマスターシップまたはインターフェイスステータスは、条件付きRAのトリガーとして使用できません。代わりに、セクション3.2.2で説明されているルートプレゼンスを使用する必要があります。
Let's look at the example topology shown in Figure 3:
図3に示すトポロジーの例を見てみましょう。
2001:db8:1::/48 --------
2001:db8:1:1::/64 ,-------, ,' ',
+----+ +---+ +----+ ,' ', : :
_| |--| |--| R3 |----+ ISP_A +---+: :
| | R1 | | | +----+ ', ,' : :
| +----+ | | '-------' : :
H1--------| |LAN| : INTERNET :
| +----+ | | ,-------, : :
|_| | | | +----+ ,' ', : :
| R2 |--| |--| R4 |----+ ISP_B +---+: :
+----+ +---+ +----+ ', ,' : :
2001:db8:2:1::/64 '-------' ', ,'
2001:db8:2::/48 --------
Figure 3: Dedicated Border Routers
図3：専用ボーダールーター
For example, if ISP_A is a primary uplink and ISP_B is a backup, then the following policy might be used to achieve the desired behavior (H1 is using ISP_A address space, 2001:db8:1:1::/64, while the ISP_A uplink is up and only using the ISP_B 2001:db8:2:1::/64 prefix if the uplink is non-operational):
たとえば、ISP_AがプライマリアップリンクでISP_Bがバックアップの場合、次のポリシーを使用して目的の動作を実現できます（H1はISP_Aアドレススペース2001：db8：1：1 :: / 64を使用していますが、ISP_Aアップリンクがアップしていて、アップリンクが動作していない場合は、ISP_B 2001：db8：2：1 :: / 64プレフィックスのみを使用しています）：
R1 and R2 policy:
R1およびR2ポリシー：
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
}
For the load-balancing case, the policy would look slightly
different: each prefix has a nonzero preferred_lifetime only if the
corresponding ISP uplink route is present:
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink_route is present)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
Prefix deprecation as a result of an uplink status change might lead to a situation in which all global prefixes are deprecated (all ISP uplinks are not operational for some reason). Even when there is no Internet connectivity, it might be still desirable to have intrasite IPv6 connectivity (especially when the network in question is an IPv6-only one). However, while an address is in a deprecated state, its use is discouraged, but not strictly forbidden [RFC4862]. In such a scenario, all IPv6 source addresses in the candidate set [RFC6724] are deprecated, which means that they still can be used (as there are no preferred addresses available), and the source address selection algorithm can pick up one of them, allowing intrasite communication. However, some operating systems might just fall back to IPv4 if the network interface has no preferred IPv6 global addresses. Therefore, if intrasite connectivity is vital during simultaneous outages of multiple uplinks, administrators might consider using Unique Local Addresses (ULAs) [RFC4193] or provisioning additional backup uplinks to protect the network from double-failure cases.
アップリンクのステータス変更の結果としてのプレフィックスの廃止は、すべてのグローバルプレフィックスが廃止される状況につながる可能性があります（すべてのISPアップリンクが何らかの理由で動作していない）。インターネット接続がない場合でも、サイト内IPv6接続が望ましい場合があります（特に、問題のネットワークがIPv6のみの場合）。しかし、アドレスが非推奨の状態にある間、その使用は推奨されませんが、厳密に禁止されていません[RFC4862]。このようなシナリオでは、候補セット[RFC6724]のすべてのIPv6送信元アドレスが非推奨になりました。つまり、それらは引き続き使用でき（使用可能な優先アドレスがないため）、送信元アドレス選択アルゴリズムはそれらの1つを取得できます。サイト内通信を可能にします。ただし、ネットワークインターフェイスに優先IPv6グローバルアドレスがない場合、一部のオペレーティングシステムはIPv4にフォールバックするだけかもしれません。したがって、複数のアップリンクが同時に停止しているときにサイト内接続が不可欠な場合、管理者は、Unique Local Addresses（ULA）[RFC4193]を使用するか、追加のバックアップアップリンクをプロビジョニングしてネットワークを二重障害から保護することを検討します。
If an actively used uplink (a primary one or one used in a load-balancing scenario) starts flapping, it might lead to the undesirable situation of flapping addresses on hosts: every time the uplink goes up, hosts receive an RA with a nonzero preferred PIO lifetime, and every time the uplink goes down, all addresses in the affected prefix become deprecated. This would, undoubtedly, negatively impact the user experience, not to mention the impact of spikes of duplicate address detection traffic every time an uplink comes back up. Therefore, it's recommended that router vendors implement some form of damping policy for conditional RAs and either postpone sending an RA with a nonzero lifetime for a PIO when the uplink comes up for a number of seconds or (even) introduce accumulated penalties/ exponential backoff algorithm for such delays. (In the case of multiple simultaneous uplink failure, when all but one of the uplinks are down and the last remaining one is flapping, it might result in all addresses being deprecated for a while after the flapping uplink recovers.)
アクティブに使用されているアップリンク（プライマリまたはロードバランシングシナリオで使用されているもの）がフラッピングを開始すると、ホストのアドレスがフラッピングするという望ましくない状況が発生する可能性があります。 PIOの有効期間。アップリンクがダウンするたびに、影響を受けるプレフィックスのすべてのアドレスが非推奨になります。これは間違いなく、ユーザーエクスペリエンスに悪影響を及ぼします。アップリンクが復旧するたびに、重複するアドレス検出トラフィックのスパイクの影響は言うまでもありません。したがって、ルーターベンダーは、条件付きRAに何らかの形式のダンピングポリシーを実装し、アップリンクが数秒間アップしたときにPIOのゼロ以外のライフタイムでRAの送信を延期するか、または（さらに）累積ペナルティ/指数バックオフアルゴリズムを導入することをお勧めしますそのような遅延のため。 （複数の同時アップリンク障害の場合、1つを除くすべてのアップリンクがダウンしており、最後の1つがフラッピングしている場合、フラッピングアップリンクが回復した後、しばらくの間すべてのアドレスが非推奨になる可能性があります。）
Deprecating IPv6 addresses by setting the preferred lifetime to 0 discourages but does not strictly forbid its usage in new communications. A deprecated address may still be used for existing connections [RFC4862]. Therefore, when an ISP uplink goes down, the corresponding border router might still receive packets with source addresses belonging to that ISP address space while there is no available uplink to send those packets to.
優先ライフタイムを0に設定してIPv6アドレスを廃止することは推奨されませんが、新しい通信での使用を厳密に禁止するものではありません。廃止されたアドレスは、既存の接続に引き続き使用できます[RFC4862]。したがって、ISPアップリンクがダウンしても、対応する境界ルーターは、そのISPアドレススペースに属する送信元アドレスを持つパケットを受信する可能性がありますが、それらのパケットの送信先となる利用可能なアップリンクはありません。
The expected router behavior would depend on the uplink selection mechanism. For example, if some form of SADR is used, then such packets will be dropped as there is no route to the destination. If policy-based routing is used to set a next hop, then the behavior would be implementation dependent and may vary from dropping the packets to forwarding them based on the routing table entries. It should be noted that there is no return path to the packet source (as the ISP uplink is not operational). Therefore, even if the outgoing packets are sent to another ISP, the return traffic might not be delivered.
予想されるルーターの動作は、アップリンク選択メカニズムによって異なります。たとえば、何らかの形式のSADRが使用されている場合、宛先へのルートがないため、そのようなパケットはドロップされます。ポリシーベースのルーティングを使用してネクストホップを設定する場合、動作は実装に依存し、パケットのドロップからルーティングテーブルエントリに基づいた転送までさまざまです。パケットソースへのリターンパスがないことに注意してください（ISPアップリンクが動作していないため）。したがって、発信パケットが別のISPに送信されても、リターントラフィックが配信されない場合があります。
It should be noted that the proposed approach is not a "silver bullet" for all possible multihoming scenarios. It would work very well for networks with relatively simple topologies and straightforward routing policies. The more complex the network topology and the corresponding routing policies, the more configuration would be required to implement the solution.
提案されたアプローチは、考えられるすべてのマルチホーミングシナリオの「特効薬」ではないことに注意してください。これは、比較的単純なトポロジーと単純なルーティングポリシーを持つネットワークに非常に適しています。ネットワークトポロジと対応するルーティングポリシーが複雑になるほど、ソリューションの実装に必要な構成も多くなります。
Another limitation is related to the load-balancing between the uplinks. In the scenario in which both uplinks are active, hosts would select the source prefix using the Default Address Selection algorithm [RFC6724]; therefore, the load between two uplinks most likely would not be evenly distributed. (However, the proposed mechanism does allow a creative way of controlling uplinks load in software-defined networks where controllers might selectively deprecate prefixes on some hosts but not others to move egress traffic between uplinks). Also, the prefix selection does not take into account any other properties of uplinks (such as latency), so egress traffic might not be sent to the nearest uplink if the corresponding prefix is selected as a source. In general, if not all uplinks are equal, and some uplinks are expected to be preferred over others, then the network administrator should ensure that prefixes from non-preferred ISP(s) are kept deprecated (so primary/backup setup is used).
別の制限は、アップリンク間のロードバランシングに関連しています。両方のアップリンクがアクティブであるシナリオでは、ホストはデフォルトアドレス選択アルゴリズム[RFC6724]を使用してソースプレフィックスを選択します。したがって、2つのアップリンク間の負荷は、おそらく均等に分散されません。 （ただし、提案されたメカニズムでは、コントローラが一部のホストではプレフィックスを選択的に非推奨にし、他のホストではプレフィックスを非推奨にせずに、アップリンク間で下りトラフィックを移動するソフトウェア定義のネットワークで、アップリンクの負荷を制御する独創的な方法が可能になります）。また、プレフィックスの選択ではアップリンクの他のプロパティ（レイテンシなど）が考慮されないため、対応するプレフィックスがソースとして選択されている場合、出力トラフィックは最も近いアップリンクに送信されない可能性があります。一般に、すべてのアップリンクが等しいわけではなく、一部のアップリンクが他よりも優先されることが予想される場合、ネットワーク管理者は、優先されないISPからのプレフィックスが非推奨のままであることを確認する必要があります（したがって、プライマリ/バックアップ設定が使用されます）。
The proposed solution is not designed to preserve connection state after an uplink failure. If all uplinks to an ISP go down, all sessions to/from addresses from that ISP address space are interrupted as there is no egress path for those packets and there is no return path from the Internet to the corresponding prefix. In this regard, it is similar to IPv4 multihoming using NAT, where an uplink failure and failover to another uplink means that a public IPv4 address changes and all existing connections are interrupted.
提案されたソリューションは、アップリンク障害後の接続状態を保持するようには設計されていません。 ISPへのすべてのアップリンクがダウンした場合、それらのパケットの出力パスがなく、インターネットから対応するプレフィックスへの戻りパスがないため、そのISPアドレススペースからのアドレスへ/からのすべてのセッションが中断されます。この点で、NATを使用したIPv4マルチホーミングに似ています。アップリンクの障害と別のアップリンクへのフェイルオーバーは、パブリックIPv4アドレスが変更され、既存のすべての接続が中断されることを意味します。
However, an uplink recovery does not necessarily lead to connections interruption. In the load-sharing/balancing scenario, an uplink recovery does not affect any existing connections at all. In the active/backup topology, when the primary uplink recovers from the failure and the backup prefix is deprecated, the existing sessions (established to/from the backup ISP addresses) can be preserved if the routers are configured as described in Section 3.2.1 and send packets with the backup ISP source addresses to the backup uplink, even when the primary one is operational. As a result, the primary uplink recovery makes the usage of the backup ISP addresses discouraged but still possible.
ただし、アップリンクの回復が接続の中断につながるとは限りません。負荷分散/負荷分散のシナリオでは、アップリンクの回復は既存の接続にまったく影響を与えません。アクティブ/バックアップトポロジで、プライマリアップリンクが障害から回復し、バックアッププレフィックスが廃止された場合、セクション3.2.1で説明されているようにルーターが構成されていれば、既存のセッション（バックアップISPアドレスとの間で確立）を保持できます。また、プライマリISPが動作している場合でも、バックアップISP送信元アドレスを持つパケットをバックアップアップリンクに送信します。その結果、プライマリアップリンクの復旧により、バックアップISPアドレスの使用は推奨されなくなりましたが、依然として可能です。
It should be noted that in IPv4 multihoming with NAT, when the egress interface is chosen without taking packet source address into account (as internal hosts usually have addresses from [RFC1918] space), sessions might not be preserved after an uplink recovery unless packet forwarding is integrated with existing NAT sessions tracking.
NATを使用したIPv4マルチホーミングでは、パケットの送信元アドレスを考慮せずに出力インターフェイスを選択すると（内部ホストは通常[RFC1918]スペースのアドレスを持っているため）、パケット転送を行わない限り、アップリンクの回復後にセッションが保持されない場合があることに注意してください。既存のNATセッション追跡と統合されています。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This memo introduces no new security considerations. It relies on RAs [RFC4861] and the SLAAC [RFC4862] mechanism and inherits their security properties. If an attacker is able to send a rogue RA, they could deprecate IPv6 addresses on hosts or influence source-address-selection processes on hosts.
このメモでは、セキュリティに関する新しい考慮事項は紹介されていません。 RA [RFC4861]とSLAAC [RFC4862]メカニズムに依存し、それらのセキュリティプロパティを継承します。攻撃者が不正なRAを送信できる場合、攻撃者はホストのIPv6アドレスを廃止するか、ホストの送信元アドレス選択プロセスに影響を与える可能性があります。
The potential attack vectors include, but are not limited to:
潜在的な攻撃ベクトルには、以下が含まれますが、これらに限定されません。
o An attacker sends a rogue RA deprecating IPv6 addresses on hosts;
o 攻撃者は、ホストでIPv6アドレスを非推奨にする不正なRAを送信します。
o An attacker sends a rogue RA making addresses preferred while the corresponding ISP uplink is not operational;
o 攻撃者は不正なRAを送信し、対応するISPアップリンクが動作していないときにアドレスを優先します。
o An attacker sends a rogue RA making addresses preferred for a backup ISP, steering traffic to an undesirable (e.g., more expensive) uplink.
o 攻撃者は不正なRAを送信してバックアップISPにアドレスを優先させ、トラフィックを望ましくない（たとえば、より高価な）アップリンクに誘導します。
Therefore, the network administrators SHOULD secure RAs, e.g., by deploying an RA guard [RFC6105].
したがって、ネットワーク管理者は、RAガードを配備するなどして、RAを保護する必要があります[RFC6105]。
This memo introduces no new privacy considerations.
このメモでは、プライバシーに関する新しい考慮事項は紹介されていません。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IPソースアドレススプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<https：// www .rfc-editor.org / info / rfc2827>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<https://www.rfc-editor.org/info/ rfc3022>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<https://www.rfc-editor.org/info/rfc3704 >。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, DOI 10.17487/RFC4116, July 2005, <https://www.rfc-editor.org/info/rfc4116>.
[RFC4116] Abley、J.、Lindqvist、K.、Davies、E.、Black、B。、およびV. Gill、「IPv4マルチホーミングのプラクティスと制限」、RFC 4116、DOI 10.17487 / RFC4116、2005年7月、<https： //www.rfc-editor.org/info/rfc4116>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https://www.rfc-editor.org/info/rfc4193>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://www.rfc-editor.org/info/rfc4291>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https://www.rfc-editor.org/info / rfc4862>。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, <https://www.rfc-editor.org/info/rfc6105>.
[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C。、およびJ. Mohacsi、「IPv6 Router Advertisement Guard」、RFC 6105、DOI 10.17487 / RFC6105、2011年2月、<https：// www.rfc-editor.org/info/rfc6105>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<https://www.rfc-editor.org/info/rfc6724>。
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, <https://www.rfc-editor.org/info/rfc8028>.
[RFC8028]ベイカー、F.、B。カーペンター、「マルチプレフィックスネットワーク内のホストによるファーストホップルーターの選択」、RFC 8028、DOI 10.17487 / RFC8028、2016年11月、<https：//www.rfc-editor。 org / info / rfc8028>。
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 8106、DOI 10.17487 / RFC8106、2017年3月、<https：// www .rfc-editor.org / info / rfc8106>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[DESTINATION] Lamparter, D. and A. Smirnov, "Destination/Source Routing", Work in Progress, draft-ietf-rtgwg-dst-src-routing-06, October 2017.
[DESTINATION] Lamparter、D。およびA. Smirnov、「Destination / Source Routing」、Work in Progress、draft-ietf-rtgwg-dst-src-routing-06、2017年10月。
[PROVIDER-ASSIGNED] Baker, F., Bowers, C., and J. Linkova, "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution", Work in Progress, draft-ietf-rtgwg-enterprise-pa-multihoming-07, June 2018.
[PROVIDER-ASSIGNED] Baker、F.、Bowers、C。、およびJ. Linkova、「ネットワークプレフィックス変換なしでプロバイダーが割り当てたアドレスを使用したエンタープライズマルチホーミング：要件とソリューション」、Work in Progress、draft-ietf-rtgwg-enterprise- pa-multihoming-07、2018年6月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：/ /www.rfc-editor.org/info/rfc4861>。
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.
[RFC5798] Nadas、S。、編、「IPv4およびIPv6の仮想ルーター冗長プロトコル（VRRP）バージョン3」、RFC 5798、DOI 10.17487 / RFC5798、2010年3月、<https://www.rfc-editor.org / info / rfc5798>。
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルーターの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<https：// www .rfc-editor.org / info / rfc7084>。
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC7788] Stenberg、M.、Barth、S。、およびP. Pfister、「Home Networking Control Protocol」、RFC 7788、DOI 10.17487 / RFC7788、2016年4月、<https://www.rfc-editor.org/info / rfc7788>。
Acknowledgements
謝辞
Thanks to the following people (in alphabetical order) for their review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, and Dave Thaler.
レビューとフィードバックをありがとう（アルファベット順）：Mikael Abrahamsson、Lorenzo Colitti、Marcus Keane、Erik Kline、David Lamparter、Dusan Mudric、Erik Nordmark、Dave Thaler。
Authors' Addresses
著者のアドレス
Jen Linkova Google Mountain View, California 94043 United States of America
Jen Linkova Googleマウンテンビュー、カリフォルニア州94043アメリカ合衆国
Email: furry@google.com
Massimiliano Stucchi RIPE NCC Stationsplein, 11 Amsterdam 1012 AB The Netherlands
Massimiliano Stucchi RIPE NCC Stationsplein、11アムステルダム1012 ABオランダ
Email: mstucchi@ripe.net