[要約] 要約： RFC 8678は、ネットワークプレフィックスの翻訳なしでプロバイダが割り当てたIPv6アドレスを使用してエンタープライズのマルチホーミングを実現するための要件と解決策を提供しています。目的： このRFCの目的は、エンタープライズが複数のネットワークプロバイダを使用してIPv6アドレスを割り当てる際に、ネットワークプレフィックスの翻訳を必要とせずに効果的なマルチホーミングを実現するための要件と解決策を提供することです。
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 8678
Category: Informational C. Bowers
ISSN: 2070-1721 Juniper Networks
J. Linkova
Google
December 2019
Enterprise Multihoming Using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions
ネットワークプレフィックス変換なしでプロバイダーが割り当てたIPv6アドレスを使用したエンタープライズマルチホーミング：要件とソリューション
Abstract
概要
Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs.
プロバイダーが割り当てたアドレスを使用してIPv6経由で複数のISPに企業サイトを接続することは、何らかの形のネットワークアドレス変換（NAT）を使用しないと困難です。このトピックについては過去10〜15年にわたって多くのことが書かれていますが、明確に定義されたソリューションや広く実装されたソリューションがなければ、依然として問題が残っています。 NATを使用しないマルチホーミングソリューションでは、サイトのホストが各ISPからのアドレスを持ち、発信パケットのソースアドレスを選択して出口ISPを選択する必要があります。また、サイトのルーターは、ISPに向けてパケットを転送するときに、これらの送信元アドレスを考慮する必要があります。
This document examines currently available mechanisms for providing a solution to this problem for a broad range of enterprise topologies. It covers the behavior of routers to forward traffic by taking into account source address, and it covers the behavior of hosts to select appropriate default source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this document also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator.
このドキュメントでは、広範なエンタープライズトポロジに対してこの問題の解決策を提供するために現在利用可能なメカニズムを調べます。送信元アドレスを考慮してトラフィックを転送するルーターの動作と、適切なデフォルトの送信元アドレスを選択するホストの動作について説明します。また、ホストが適切な送信元アドレスを選択するのに役立つ情報をホストに提供する際にルーターが果たす可能性のある役割についても説明します。このドキュメントでは、潜在的なソリューションを探索する過程で、エンタープライズサイトのネットワーク管理者の観点からソリューションがどのように動作することが期待されるかについても明示的な要件を示しています。
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/rfc8678.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8678で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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
2. Requirements Language
3. Terminology
4. Enterprise Multihoming Use Cases
4.1. Simple ISP Connectivity with Connected SERs
4.2. Simple ISP Connectivity Where SERs Are Not Directly
Connected
4.3. Enterprise Network Operator Expectations
4.4. More Complex ISP Connectivity
4.5. ISPs and Provider-Assigned Prefixes
4.6. Simplified Topologies
5. Generating Source-Prefix-Scoped Forwarding Tables
6. Mechanisms for Hosts To Choose Good Default Source Addresses in
a Multihomed Site
6.1. Default Source Address Selection Algorithm on Hosts
6.2. Selecting Default Source Address When Both Uplinks Are
Working
6.2.1. Distributing Default Address Selection Policy
Table with DHCPv6
6.2.2. Controlling Default Source Address Selection with
Router Advertisements
6.2.3. Controlling Default Source Address Selection with
ICMPv6
6.2.4. Summary of Methods for Controlling Default Source
Address Selection to Implement Routing Policy
6.3. Selecting Default Source Address When One Uplink Has Failed
6.3.1. Controlling Default Source Address Selection with
DHCPv6
6.3.2. Controlling Default Source Address Selection with
Router Advertisements
6.3.3. Controlling Default Source Address Selection with
ICMPv6
6.3.4. Summary of Methods for Controlling Default Source
Address Selection on the Failure of an Uplink
6.4. Selecting Default Source Address upon Failed Uplink
Recovery
6.4.1. Controlling Default Source Address Selection with
DHCPv6
6.4.2. Controlling Default Source Address Selection with
Router Advertisements
6.4.3. Controlling Default Source Address Selection with ICMP
6.4.4. Summary of Methods for Controlling Default Source
Address Selection upon Failed Uplink Recovery
6.5. Selecting Default Source Address When All Uplinks Have
Failed
6.5.1. Controlling Default Source Address Selection with
DHCPv6
6.5.2. Controlling Default Source Address Selection with
Router Advertisements
6.5.3. Controlling Default Source Address Selection with
ICMPv6
6.5.4. Summary of Methods for Controlling Default Source
Address Selection When All Uplinks Failed
6.6. Summary of Methods for Controlling Default Source Address
Selection
6.7. Solution Limitations
6.7.1. Connections Preservation
6.8. Other Configuration Parameters
6.8.1. DNS Configuration
7. Deployment Considerations
7.1. Deploying SADR Domain
7.2. Hosts-Related Considerations
8. Other Solutions
8.1. Shim6
8.2. IPv6-to-IPv6 Network Prefix Translation
8.3. Multipath Transport
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
Site multihoming, the connection of a subscriber network to multiple upstream networks using redundant uplinks, is a common enterprise architecture for improving the reliability of its Internet connectivity. If the site uses provider-independent (PI) addresses, all traffic originating from the enterprise can use source addresses from the PI address space. Site multihoming with PI addresses is commonly used with both IPv4 and IPv6, and does not present any new technical challenges.
冗長アップリンクを使用してサブスクライバーネットワークを複数のアップストリームネットワークに接続するサイトマルチホーミングは、インターネット接続の信頼性を向上させるための一般的なエンタープライズアーキテクチャです。サイトがプロバイダーに依存しない（PI）アドレスを使用している場合、企業から発信されるすべてのトラフィックは、PIアドレススペースのソースアドレスを使用できます。 PIアドレスによるサイトマルチホーミングは、IPv4とIPv6の両方で一般的に使用されており、新しい技術的な課題はありません。
It may be desirable for an enterprise site to connect to multiple ISPs using provider-assigned (PA) addresses instead of PI addresses. Multihoming with provider-assigned addresses is typically less expensive for the enterprise relative to using provider-independent addresses as it does not require obtaining and maintaining PI address space nor does it require running BGP between the enterprise and the ISPs (for small/medium networks, running BGP might be not only undesirable but also impossible, especially if residential-type ISP connections are used). PA multihoming is also a practice that should be facilitated and encouraged because it does not add to the size of the Internet routing table, whereas PI multihoming does. Note that PA is also used to mean "provider-aggregatable". In this document, we assume that provider-assigned addresses are always provider-aggregatable.
企業サイトが、PIアドレスの代わりにプロバイダー割り当て（PA）アドレスを使用して複数のISPに接続することが望ましい場合があります。プロバイダーが割り当てたアドレスを使用したマルチホーミングは、PIアドレススペースの取得と維持を必要とせず、企業とISPの間でBGPを実行する必要がないため、プロバイダーに依存しないアドレスを使用する場合に比べて、企業にとって一般的に安価です（小規模/中規模ネットワークの場合）。 BGPの実行は、望ましくないだけでなく、特に住宅タイプのISP接続が使用されている場合は不可能である可能性もあります）。 PAマルチホーミングはインターネットルーティングテーブルのサイズに追加しないため、PAマルチホーミングは促進および推奨すべきプラクティスでもありますが、PIマルチホーミングはそうです。 PAは「プロバイダー集約可能」を意味するためにも使用されることに注意してください。このドキュメントでは、プロバイダーによって割り当てられたアドレスは常にプロバイダーによって集約可能であると想定しています。
With PA multihoming, for each ISP connection, the site is assigned a prefix from within an address block allocated to that ISP by its National or Regional Internet Registry. In the simple case of two ISPs (ISP-A and ISP-B), the site will have two different prefixes assigned to it (prefix-A and prefix-B). This arrangement is problematic. First, packets with the "wrong" source address may be dropped by one of the ISPs. In order to limit denial-of-service attacks using spoofed source addresses, [BCP38] recommends that ISPs filter traffic from customer sites to allow only traffic with a source address that has been assigned by that ISP. So a packet sent from a multihomed site on the uplink to ISP-B with a source address in prefix-A may be dropped by ISP-B.
PAマルチホーミングを使用すると、各ISP接続に対して、サイトには、国内または地域のインターネットレジストリによってそのISPに割り当てられたアドレスブロック内からプレフィックスが割り当てられます。 2つのISP（ISP-AとISP-B）の単純なケースでは、サイトには2つの異なるプレフィックスが割り当てられます（プレフィックスAとプレフィックスB）。この配置には問題があります。まず、「間違った」送信元アドレスを持つパケットは、ISPの1つによってドロップされる可能性があります。スプーフィングされた送信元アドレスを使用したサービス拒否攻撃を制限するために、[BCP38]は、ISPが顧客サイトからのトラフィックをフィルタリングして、そのISPによって割り当てられた送信元アドレスを持つトラフィックのみを許可することを推奨します。そのため、アップリンク上のマルチホームサイトからISP-Bへの送信元アドレスがprefix-AであるパケットがISP-Bによってドロップされる可能性があります。
However, even if ISP-B does not implement BCP 38, or ISP-B adds prefix-A to its list of allowed source addresses on the uplink from the multihomed site, two-way communication may still fail. If the packet with a source address in prefix-A was sent to ISP-B because the uplink to ISP-A failed, then if ISP-B does not drop the packet, and the packet reaches its destination somewhere on the Internet, the return packet will be sent back with a destination address in prefix-A. The return packet will be routed over the Internet to ISP-A, but it will not be delivered to the multihomed site because the site uplink with ISP-A has failed. Two-way communication would require some arrangement for ISP-B to advertise prefix-A when the uplink to ISP-A fails.
ただし、ISP-BがBCP 38を実装していない場合や、ISP-Bがマルチホームサイトからのアップリンクで許可されているソースアドレスのリストにプレフィックスAを追加した場合でも、双方向通信は失敗する可能性があります。 ISP-Aへのアップリンクが失敗したためにprefix-Aに送信元アドレスが含まれるパケットがISP-Bに送信された場合、ISP-Bがパケットをドロップせず、パケットがインターネット上のどこかに宛先に到達すると、リターンパケットは、プレフィックスAの宛先アドレスで返送されます。リターンパケットはインターネット経由でISP-Aにルーティングされますが、ISP-Aを使用したサイトのアップリンクが失敗したため、マルチホームサイトには配信されません。双方向通信では、ISP-Aへのアップリンクが失敗したときに、ISP-Bがprefix-Aをアドバタイズするための何らかの調整が必要になります。
Note that the same may be true of a provider that does not implement BCP 38, even if his upstream provider does, or of a provider that has no corresponding route to deliver the ingress traffic to the multihomed site. The issue is not that the immediate provider implements ingress filtering; it is that someone upstream does (so egress traffic is blocked) or lacks a route (causing blackholing of the ingress traffic).
アップストリームプロバイダーが実装している場合でもBCP 38を実装していないプロバイダー、またはマルチホームサイトに入力トラフィックを配信するための対応するルートがないプロバイダーについても同様です。問題は、直接のプロバイダーが入力フィルタリングを実装することではありません。それは、上流の誰かがそうしている（そのため、出力トラフィックがブロックされている）か、ルートがない（入力トラフィックのブラックホールを引き起こす）ことです。
Another issue with asymmetric traffic flow (when the egress traffic leaves the site via one ISP, but the return traffic enters the site via another uplink) is related to stateful firewalls/middleboxes. Keeping state in that case might be problematic, even impossible.
非対称トラフィックフローに関するもう1つの問題（下りトラフィックが1つのISP経由でサイトを離れるが、戻りトラフィックが別のアップリンク経由でサイトに入る）は、ステートフルファイアウォール/ミドルボックスに関連しています。その場合に状態を維持することは、問題さえあり、不可能でさえあります。
With IPv4, this problem is commonly solved by using private address space described in [RFC1918] within the multihomed site and Network Address Translation (NAT) or Network Address/Port Translation (NAPT) [RFC2663] on the uplinks to the ISPs. However, one of the goals of IPv6 is to eliminate the need for and the use of NAT or NAPT. Therefore, requiring the use of NAT or NAPT for an enterprise site to multihome with provider-assigned addresses is not an attractive solution.
IPv4では、この問題は通常、マルチホームサイト内の[RFC1918]で説明されているプライベートアドレススペースと、ISPへのアップリンクのネットワークアドレス変換（NAT）またはネットワークアドレス/ポート変換（NAPT）[RFC2663]を使用することで解決されます。ただし、IPv6の目標の1つは、NATまたはNAPTの必要性と使用を排除することです。したがって、プロバイダーが割り当てたアドレスを使用してエンタープライズサイトをマルチホーム化するためにNATまたはNAPTの使用を要求することは、魅力的なソリューションではありません。
[RFC6296] describes a translation solution specifically tailored to meet the requirements of multihoming with provider-assigned IPv6 addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6) solution, an enterprise can use either Unique Local Addresses [RFC4193] or the prefix assigned by one of the ISPs within its site. As traffic leaves the site on an uplink to an ISP, the source address is translated in a predictable and reversible manner to an address within the prefix assigned by the ISP on that uplink. [RFC6296] is currently classified as Experimental, and it has been implemented by several vendors. See Section 8.2 for more discussion of NPTv6.
[RFC6296]は、プロバイダーが割り当てたIPv6アドレスによるマルチホーミングの要件を満たすように特別に調整された変換ソリューションについて説明しています。 IPv6-to-IPv6ネットワークプレフィックス変換（NPTv6）ソリューションを使用すると、企業は一意のローカルアドレス[RFC4193]またはサイト内のISPの1つによって割り当てられたプレフィックスを使用できます。トラフィックがISPへのアップリンクでサイトを離れると、送信元アドレスは予測可能かつ可逆的な方法で、そのアップリンク上のISPによって割り当てられたプレフィックス内のアドレスに変換されます。 [RFC6296]は現在実験的として分類されており、いくつかのベンダーによって実装されています。 NPTv6の詳細については、セクション8.2を参照してください。
This document defines routing requirements for enterprise multihoming. This document focuses on the following general class of solutions.
このドキュメントでは、エンタープライズマルチホーミングのルーティング要件を定義します。このドキュメントでは、次の一般的なクラスのソリューションに焦点を当てています。
Each host at the enterprise has multiple addresses, at least one from each ISP-assigned prefix. As discussed in Section 6.1 and in [RFC6724], each host is responsible for choosing the source address that is applied to each packet it sends. A host is expected to be able to respond dynamically to the failure of an uplink to a given ISP by no longer sending packets with the source address corresponding to that ISP. Potential mechanisms for communicating network changes to the host are Neighbor Discovery Router Advertisements [RFC4861], DHCPv6 [RFC8415], and ICMPv6 [RFC4443].
企業の各ホストには複数のアドレスがあり、少なくとも1つのISPが割り当てたプレフィックスからのアドレスです。セクション6.1と[RFC6724]で説明されているように、各ホストは、送信する各パケットに適用される送信元アドレスを選択する責任があります。ホストは、そのISPに対応するソースアドレスを持つパケットを送信しないことにより、特定のISPへのアップリンクの障害に動的に応答できることが期待されます。ホストにネットワーク変更を伝達するための潜在的なメカニズムは、近隣探索ルーターアドバタイズメント[RFC4861]、DHCPv6 [RFC8415]、およびICMPv6 [RFC4443]です。
The routers in the enterprise network are responsible for ensuring that packets are delivered to the "correct" ISP uplink based on source address. This requires that at least some routers in the site network are able to take into account the source address of a packet when deciding how to route it. That is, some routers must be capable of some form of Source Address Dependent Routing (SADR), if only as described in Section 4.3 of [RFC3704]. At a minimum, the routers connected to the ISP uplinks (the site exit routers or SERs) must be capable of Source Address Dependent Routing. Expanding the connected domain of routers capable of SADR from the site exit routers deeper into the site network will generally result in more efficient routing of traffic with external destinations.
エンタープライズネットワーク内のルーターは、パケットが送信元アドレスに基づいて「正しい」ISPアップリンクに配信されるようにする責任があります。これには、サイトネットワークの少なくとも一部のルーターが、パケットのルーティング方法を決定するときに、パケットの送信元アドレスを考慮に入れることが必要です。つまり、一部のルーターは、[RFC3704]のセクション4.3で説明されている場合に限り、なんらかの形式の送信元アドレス依存ルーティング（SADR）に対応できる必要があります。少なくとも、ISPアップリンクに接続されているルーター（サイト出口ルーターまたはSER）は、送信元アドレス依存型ルーティングに対応している必要があります。 SADRに対応したルーターの接続ドメインをサイト出口ルーターからサイトネットワークのより深い場所に拡張すると、通常、外部宛先を持つトラフィックのルーティングがより効率的になります。
This document is organized as follows. Section 4 looks in more detail at the enterprise networking environments in which this solution is expected to operate. The discussion of Section 4 uses the concepts of Source-Prefix-Scoped Routing advertisements and forwarding tables and describes how Source-Prefix-Scoped Routing advertisements are used to generate source-prefix-scoped forwarding tables. A detailed description of generating source-prefix-scoped forwarding tables is provided in Section 5. Section 6 discusses existing and proposed mechanisms for hosts to select the default source address to be used by applications. It also discusses the requirements for routing that are needed to support these enterprise network scenarios and the mechanisms by which hosts are expected to update default source addresses based on network state. Section 7 discusses deployment considerations, while Section 8 discusses other solutions.
このドキュメントは次のように構成されています。セクション4では、このソリューションの運用が期待されるエンタープライズネットワーキング環境について詳しく説明します。セクション4の説明では、ソースプレフィックススコープのルーティングアドバタイズメントと転送テーブルの概念を使用し、ソースプレフィックススコープのルーティングアドバタイズメントを使用してソースプレフィックススコープの転送テーブルを生成する方法について説明します。ソースプレフィックススコープの転送テーブルの生成の詳細については、セクション5を参照してください。セクション6では、アプリケーションが使用するデフォルトのソースアドレスをホストが選択するための既存のメカニズムおよび提案されたメカニズムについて説明します。また、これらのエンタープライズネットワークシナリオをサポートするために必要なルーティングの要件と、ホストがネットワーク状態に基づいてデフォルトの送信元アドレスを更新するメカニズムを説明します。セクション7では導入に関する考慮事項について説明し、セクション8では他のソリューションについて説明します。
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]で説明されているように解釈されます。
PA (provider-assigned or provider-aggregatable) address space: a block of IP addresses assigned by a Regional Internet Registry (RIR) to a Local Internet Registry (LIR), used to create allocations to end sites. Can be aggregated and present in the routing table as one route.
PA（プロバイダー割り当てまたはプロバイダー集約可能）アドレススペース：リージョナルインターネットレジストリ（RIR）からローカルインターネットレジストリ（LIR）に割り当てられたIPアドレスのブロック。エンドサイトへの割り当てを作成するために使用されます。集約して、ルーティングテーブルに1つのルートとして表示できます。
PI (provider-independent) address space: a block of IP addresses assigned by a Regional Internet Registry (RIR) directly to end site / end customer.
PI（プロバイダーに依存しない）アドレススペース：リージョナルインターネットレジストリ（RIR）によってエンドサイト/エンドカスタマーに直接割り当てられたIPアドレスのブロック。
ISP: Internet Service Provider
ISP：インターネットサービスプロバイダー
LIR (Local Internet Registry): an organization (usually an ISP or an enterprise/academic) that receives its allocation of IP addresses from its Regional Internet Registry, then assigns parts of that allocation to its customers.
LIR（ローカルインターネットレジストリ）：地域のインターネットレジストリからIPアドレスの割り当てを受け取り、その割り当ての一部を顧客に割り当てる組織（通常はISPまたは企業/学術機関）。
RIR (Regional Internet Registry): an organization that manages the Internet number resources (such as IP addresses and autonomous system (AS) numbers) within a geographical region of the world.
RIR（Regional Internet Registry）：世界の地理的領域内のインターネット番号リソース（IPアドレスや自律システム（AS）番号など）を管理する組織。
SADR (Source Address Dependent Routing): routing that takes into account the source address of a packet in addition to the packet destination address.
SADR（送信元アドレス依存ルーティング）：パケットの宛先アドレスに加えて、パケットの送信元アドレスを考慮するルーティング。
SADR domain: a routing domain in which some (or all) routers exchange source-dependent routing information.
SADRドメイン：一部（またはすべて）のルーターがソース依存のルーティング情報を交換するルーティングドメイン。
Source-Prefix-Scoped Routing/Forwarding Table: a routing (or forwarding) table that contains routing (or forwarding) information only applicable to packets with source addresses from the specific prefix.
Source-Prefix-Scoped Routing / Forwarding Table：特定のプレフィックスからの送信元アドレスを持つパケットにのみ適用されるルーティング（または転送）情報を含むルーティング（または転送）テーブル。
Unscoped Routing/Forwarding Table: a routing (or forwarding) table that can be used to route/forward packets with any source address.
対象範囲外のルーティング/転送テーブル：任意の送信元アドレスでパケットをルーティング/転送するために使用できるルーティング（または転送）テーブル。
SER (Site Edge Router): a router that connects the site to an ISP (terminates an ISP uplink).
SER（サイトエッジルーター）：サイトをISPに接続する（ISPアップリンクを終端する）ルーター。
LLA (Link-Local Address): an IPv6 unicast address from the fe80::/10 prefix [RFC4291].
LLA（リンクローカルアドレス）：fe80 :: / 10プレフィックスからのIPv6ユニキャストアドレス[RFC4291]。
ULA (Unique Local IPv6 Unicast Address): an IPv6 unicast address from the FC00::/7 prefix. They are globally unique and intended for local communications [RFC4193].
ULA（一意のローカルIPv6ユニキャストアドレス）：FC00 :: / 7プレフィックスからのIPv6ユニキャストアドレス。これらはグローバルに一意であり、ローカル通信[RFC4193]を対象としています。
GUA (Global Unicast Address): a globally routable IPv6 address of the global scope [RFC4291].
GUA（グローバルユニキャストアドレス）：グローバルスコープのグローバルにルーティング可能なIPv6アドレス[RFC4291]。
SLAAC (IPv6 Stateless Address Autoconfiguration): a stateless process of configuring the network stack on IPv6 hosts [RFC4862].
SLAAC（IPv6ステートレスアドレス自動構成）：IPv6ホストでネットワークスタックを構成するステートレスプロセス[RFC4862]。
RA (Router Advertisement): a message sent by an IPv6 router to advertise its presence to hosts together with various network-related parameters required for hosts to perform SLAAC [RFC4861].
RA（ルーターアドバタイズメント）：ホストがSLAAC [RFC4861]を実行するために必要なさまざまなネットワーク関連パラメーターと共に、その存在をホストにアドバタイズするためにIPv6ルーターによって送信されるメッセージ。
PIO (Prefix Information Option): a part of an RA message containing information about IPv6 prefixes that could be used by hosts to generate global IPv6 addresses [RFC4862].
PIO（プレフィックス情報オプション）：ホストがグローバルIPv6アドレスを生成するために使用できるIPv6プレフィックスに関する情報を含むRAメッセージの一部[RFC4862]。
RIO (Route Information Option): a part of an RA message containing information about more specific IPv6 prefixes reachable via the advertising router [RFC4191].
RIO（ルート情報オプション）：アドバタイジングルーター[RFC4191]を介して到達可能な、より具体的なIPv6プレフィックスに関する情報を含むRAメッセージの一部。
We start by looking at a scenario in which a site has connections to two ISPs, as shown in Figure 1. The site is assigned the prefix 2001:db8:0:a000::/52 by ISP-A and prefix 2001:db8:0:b000::/52 by ISP-B. We consider three hosts in the site. H31 and H32 are on a LAN that has been assigned subnets 2001:db8:0:a010::/64 and 2001:db8:0:b010::/64. H31 has been assigned the addresses 2001:db8:0:a010::31 and 2001:db8:0:b010::31. H32 has been assigned 2001:db8:0:a010::32 and 2001:db8:0:b010::32. H41 is on a different subnet that has been assigned 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64.
図1に示すように、サイトが2つのISPに接続しているシナリオから始めます。サイトには、ISP-Aによってプレフィックス2001：db8：0：a000 :: / 52が割り当てられ、プレフィックス2001：db8：が割り当てられます。 ISP-Bによる0：b000 :: / 52。サイト内の3つのホストを検討します。 H31およびH32は、サブネット2001：db8：0：a010 :: / 64および2001：db8：0：b010 :: / 64が割り当てられているLAN上にあります。 H31には、アドレス2001：db8：0：a010 :: 31および2001：db8：0：b010 :: 31が割り当てられています。 H32には2001：db8：0：a010 :: 32および2001：db8：0：b010 :: 32が割り当てられています。 H41は、2001：db8：0：a020 :: / 64および2001：db8：0：b020 :: / 64が割り当てられている別のサブネット上にあります。
2001:db8:0:1234::101 H101
|
|
2001:db8:0:a010::31 --------
2001:db8:0:b010::31 ,-----. / \
+--+ +--+ +----+ ,' `. : :
+---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- :
H31--+ +--+ +--+ | +----+ `. ,' : :
| | `-----' : Internet :
| | : :
| | : :
| | : :
| | ,-----. : :
H32--+ +--+ | +----+ ,' `. : :
+---|R2|----------+---|SERb|-+ ISP-B +--+-- :
+--+ | +----+ `. ,' : :
| `-----' : :
| : :
+--+ +--+ +--+ \ /
H41------|R3|--|R5|--|R6| --------
+--+ +--+ +--+
2001:db8:0:a020::41
2001:db8:0:b020::41
Figure 1: Simple ISP Connectivity with Connected SERs
図1：接続されたSERによる単純なISP接続
We refer to a router that connects the site to an ISP as a site edge router (SER). Several other routers provide connectivity among the internal hosts (H31, H32, and H41), as well as connect the internal hosts to the Internet through SERa and SERb. In this example, SERa and SERb share a direct connection to each other. In Section 4.2, we consider a scenario in which this is not the case.
サイトをISPに接続するルーターをサイトエッジルーター（SER）と呼びます。他のいくつかのルーターは、内部ホスト（H31、H32、およびH41）間の接続を提供し、内部ホストをSERaおよびSERbを介してインターネットに接続します。この例では、SERaとSERbは互いに直接接続を共有しています。セクション4.2では、これが当てはまらないシナリオを検討します。
For the moment, we assume that the hosts are able to select suitable source addresses through some mechanism that doesn't involve the routers in the site network. Here, we focus on the primary task of the routed site network, which is to get packets efficiently to their destinations, while sending a packet to the ISP that assigned the prefix that matches the source address of the packet. In Section 6, we examine what role the routed network may play in helping hosts select suitable source addresses for packets.
現時点では、ホストはサイトネットワーク内のルーターを含まないメカニズムを介して適切な送信元アドレスを選択できると想定しています。ここでは、ルーティングされたサイトネットワークの主要なタスクに焦点を当てます。これは、パケットの送信元アドレスと一致するプレフィックスを割り当てたISPにパケットを送信しながら、宛先にパケットを効率的に送信することです。セクション6では、ホストがパケットに適した送信元アドレスを選択するのを助ける上で、ルーティングされたネットワークがどのような役割を果たす可能性があるかを調べます。
With this solution, routers will need some form of Source Address Dependent Routing, which will be new functionality. It would be useful if an enterprise site does not need to upgrade all routers to support the new SADR functionality in order to support PA multihoming. We consider whether this is possible and examine the trade-offs of not having all routers in the site support SADR functionality.
このソリューションでは、ルーターは何らかの形の送信元アドレス依存ルーティングを必要としますが、これは新しい機能です。エンタープライズサイトがPAマルチホーミングをサポートするために新しいSADR機能をサポートするためにすべてのルーターをアップグレードする必要がない場合に役立ちます。これが可能かどうかを検討し、サイト内のすべてのルーターがSADR機能をサポートしていない場合のトレードオフを調べます。
In the topology in Figure 1, it is possible to support PA multihoming with only SERa and SERb being capable of SADR. The other routers can continue to forward based only on destination address, and exchange routes that only consider destination address. In this scenario, SERa and SERb communicate source-scoped routing information across their shared connection. When SERa receives a packet with a source address matching prefix 2001:db8:0:b000::/52, it forwards the packet to SERb, which forwards it on the uplink to ISP-B. The analogous behavior holds for traffic that SERb receives with a source address matching prefix 2001:db8:0:a000::/52.
図1のトポロジでは、SARaが可能なSERaとSERbのみでPAマルチホーミングをサポートできます。他のルーターは、宛先アドレスのみに基づいて転送を続行し、宛先アドレスのみを考慮するルートを交換できます。このシナリオでは、SERaとSERbは、共有接続を介してソーススコープのルーティング情報を通信します。プレフィックス2001：db8：0：b000 :: / 52に一致するソースアドレスを持つパケットを受信すると、SERaはパケットをSERbに転送し、SERbはアップリンクでISP-Bに転送します。 SERbが送信元アドレスと一致するプレフィックス2001：db8：0：a000 :: / 52と一致するトラフィックについても、同様の動作が保持されます。
In Figure 1, when only SERa and SERb are capable of source address dependent routing, PA multihoming will work. However, the paths over which the packets are sent will generally not be the shortest paths. The forwarding paths will generally be more efficient when more routers are capable of SADR. For example, if R4, R2, and R6 are upgraded to support SADR, then they can exchange source-scoped routes with SERa and SERb. They will then know to send traffic with a source address matching prefix 2001:db8:0:b000::/52 directly to SERb, without sending it to SERa first.
図1では、SERaとSERbのみがソースアドレス依存ルーティングを実行できる場合、PAマルチホーミングが機能します。ただし、パケットが送信されるパスは通常、最短パスではありません。転送パスは、一般的に、より多くのルーターがSADRに対応している場合により効率的です。たとえば、R4、R2、およびR6がSADRをサポートするようにアップグレードされている場合、ソーススコープのルートをSERaおよびSERbと交換できます。次に、プレフィックス2001：db8：0：b000 :: / 52に一致するソースアドレスを持つトラフィックを、最初にSERaに送信することなく、直接SERbに送信することを認識します。
In Figure 2, we modify the topology slightly by inserting R7, so that SERa and SERb are no longer directly connected. With this topology, it is not enough to just enable SADR routing on SERa and SERb to support PA multihoming. There are two solutions to enable PA multihoming in this topology.
図2では、R7を挿入してトポロジーをわずかに変更しているため、SERaとSERbが直接接続されなくなりました。このトポロジでは、SERaおよびSERbでSADRルーティングを有効にしてPAマルチホーミングをサポートするだけでは不十分です。このトポロジでPAマルチホーミングを有効にする2つのソリューションがあります。
2001:db8:0:1234::101 H101
|
|
2001:db8:0:a010::31 --------
2001:db8:0:b010::31 ,-----. / \
+--+ +--+ +----+ ,' `. : :
+---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- :
H31--+ +--+ +--+ | +----+ `. ,' : :
| | `-----' : Internet :
| +--+ : :
| |R7| : :
| +--+ : :
| | ,-----. : :
H32--+ +--+ | +----+ ,' `. : :
+---|R2|----------+---|SERb|-+ ISP-B +--+-- :
+--+ | +----+ `. ,' : :
| `-----' : :
| : :
+--+ +--+ +--+ \ /
H41------|R3|--|R5|--|R6| --------
+--+ +--+ +--+ |
|
2001:db8:0:a020::41 2001:db8:0:5678::501 H501
2001:db8:0:b020::41
Figure 2: Simple ISP Connectivity Where SERs Are Not Directly Connected
図2：SERが直接接続されていない単純なISP接続
One option is to effectively modify the topology by creating a logical tunnel between SERa and SERb by using Generic Routing Encapsulation (GRE) [RFC7676], for example. Although SERa and SERb are not directly connected physically in this topology, they can be directly connected logically by a tunnel.
1つのオプションは、たとえばGeneric Routing Encapsulation（GRE）[RFC7676]を使用してSERaとSERbの間に論理トンネルを作成することにより、トポロジを効果的に変更することです。このトポロジでは、SERaとSERbは物理的に直接接続されていませんが、トンネルを介して論理的に直接接続できます。
The other option is to enable SADR functionality on R7. In this way, R7 will exchange source-scoped routes with SERa and SERb, making the three routers act as a single SADR domain. This illustrates the basic principle that the minimum requirement for the routed site network to support PA multihoming is having all of the site exit routers be part of a connected SADR domain. Extending the connected SADR domain beyond that point can produce more efficient forwarding paths.
もう1つのオプションは、R7でSADR機能を有効にすることです。このようにして、R7はソーススコープのルートをSERaおよびSERbと交換し、3つのルーターが単一のSADRドメインとして機能するようにします。これは、ルーティングされたサイトネットワークがPAマルチホーミングをサポートするための最小要件が、すべてのサイト出口ルーターを接続されたSADRドメインの一部にすることの基本原則を示しています。接続されたSADRドメインをそのポイントを超えて拡張すると、より効率的な転送パスを作成できます。
Before considering a more complex scenario, let's look in more detail at the reasonably simple multihoming scenario in Figure 2 to understand what can reasonably be expected from this solution. As a general guiding principle, we assume an enterprise network operator will expect a multihomed network to behave as close to a single-homed network as possible. So a solution that meets those expectations where possible is a good thing.
より複雑なシナリオを検討する前に、図2のかなりシンプルなマルチホーミングシナリオを詳しく見て、このソリューションから合理的に何が期待できるかを理解しましょう。一般的な指針として、エンタープライズネットワークオペレーターは、マルチホームネットワークがシングルホームネットワークにできるだけ近い動作をすることを期待していると想定しています。したがって、可能な場合はそれらの期待に応えるソリューションは良いことです。
For traffic between internal hosts and for traffic from outside the site to internal hosts, an enterprise network operator would expect there to be no visible change in the path taken by this traffic, since this traffic does not need to be routed in a way that depends on source address. It is also reasonable to expect that internal hosts should be able to communicate with each other using either of their source addresses without restriction. For example, H31 should be able to communicate with H41 using a packet with S=2001:db8:0:a010::31, D=2001:db8:0:b020::41, regardless of the state of uplink to ISP-B.
内部ホスト間のトラフィック、およびサイトの外部から内部ホストへのトラフィックの場合、エンタープライズネットワークオペレーターは、このトラフィックが依存する方法でルーティングされる必要がないため、このトラフィックがたどるパスに目に見える変化がないことを期待します。送信元アドレス。また、内部ホストが制限なしにソースアドレスのいずれかを使用して相互に通信できることを期待することも妥当です。たとえば、H31は、ISPへのアップリンクの状態に関係なく、S = 2001：db8：0：a010 :: 31、D = 2001：db8：0：b020 :: 41のパケットを使用してH41と通信できるはずです。 Ｂ．
These goals can be accomplished by having all of the routers in the network continue to originate normal unscoped destination routes for their connected networks. If we can arrange it so that these unscoped destination routes are used for forwarding this traffic, then we will have accomplished multihoming's goal of not affecting the forwarding of traffic destined for internal hosts.
これらの目標は、ネットワーク内のすべてのルーターに、接続されているネットワークの通常の対象範囲外の宛先ルートを継続して発信させることで達成できます。これらの対象範囲外の宛先ルートがこのトラフィックの転送に使用されるように調整できれば、内部ホスト宛てのトラフィックの転送に影響を与えないというマルチホーミングの目標を達成できます。
For traffic destined for external hosts, it is reasonable to expect that traffic with a source address from the prefix assigned by ISP-A to follow the path that the traffic would follow if there were no connection to ISP-B. This can be accomplished by having SERa originate a source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0). If all of the routers in the site support SADR, then the path of traffic exiting via ISP-A can match that expectation. If some routers don't support SADR, then it is reasonable to expect that the path for traffic exiting via ISP-A may be different within the site. This is a trade-off that the enterprise network operator may decide to make.
外部ホスト宛てのトラフィックの場合、ISP-Aによって割り当てられたプレフィックスからの送信元アドレスを持つトラフィックが、ISP-Bへの接続がなかった場合にトラフィックがたどるパスをたどると期待するのは妥当です。これは、SERaに形式（S = 2001：db8：0：a000 :: / 52、D = :: / 0）のソーススコープのルートを発信させることで実現できます。サイト内のすべてのルーターがSADRをサポートしている場合、ISP-Aを経由して出るトラフィックのパスはその期待に一致できます。一部のルーターがSADRをサポートしていない場合は、ISP-Aを経由して出るトラフィックのパスがサイト内で異なる可能性があると予想するのが妥当です。これは、企業のネットワークオペレータが決定する可能性のあるトレードオフです。
It is important to understand the behavior of this multihoming solution when an uplink to one of the ISPs fails. To simplify this discussion, we assume that all routers in the site support SADR. We start by looking at the operation of the network when the uplinks to both ISP-A and ISP-B are functioning properly. SERa originates a source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0), and SERb originates a source-scoped route of the form (S=2001:db8:0:b000::/52, D=::/0). These routes are distributed through the routers in the site, and they establish within the routers two sets of forwarding paths for traffic leaving the site. One set of forwarding paths is for packets with source addresses in 2001:db8:0:a000::/52. The other set of forwarding paths is for packets with source addresses in 2001:db8:0:b000::/52. The normal destination routes, which are not scoped to these two source prefixes, play no role in the forwarding. Whether a packet exits the site via SERa or via SERb is completely determined by the source address applied to the packet by the host. So for example, when host H31 sends a packet to host H101 with (S=2001:db8:0:a010::31, D=2001:db8:0:1234::101), the packet will only be sent out the link from SERa to ISP-A.
いずれかのISPへのアップリンクが失敗した場合のこのマルチホーミングソリューションの動作を理解することが重要です。この説明を簡単にするために、サイト内のすべてのルーターがSADRをサポートしていると仮定します。まず、ISP-AとISP-Bの両方へのアップリンクが適切に機能しているときのネットワークの動作について説明します。 SERaはフォームのソーススコープのルート（S = 2001：db8：0：a000 :: / 52、D = :: / 0）を発信し、SERbはフォームのソーススコープのルート（S = 2001：db8）を発信します。 ：0：b000 :: / 52、D = :: / 0）。これらのルートはサイト内のルーターを介して配信され、ルーター内でサイトを離れるトラフィック用に2セットの転送パスを確立します。転送パスの1つのセットは、2001：db8：0：a000 :: / 52の送信元アドレスを持つパケット用です。転送パスのもう1つのセットは、2001：db8：0：b000 :: / 52の送信元アドレスを持つパケット用です。これらの2つのソースプレフィックスにスコープされていない通常の宛先ルートは、転送に役割を果たしません。パケットがSERa経由でサイトを出るか、SERb経由でサイトを出るかは、ホストによってパケットに適用される送信元アドレスによって完全に決定されます。たとえば、ホストH31がホストH101に（S = 2001：db8：0：a010 :: 31、D = 2001：db8：0：1234 :: 101）でパケットを送信すると、パケットはSERaからISP-Aへのリンク。
Now consider what happens when the uplink from SERa to ISP-A fails. The only way for the packets from H31 to reach H101 is for H31 to start using the source address for ISP-B. H31 needs to send the following packet: (S=2001:db8:0:b010::31, D=2001:db8:0:1234::101).
次に、SERaからISP-Aへのアップリンクが失敗したときに何が起こるかを考えます。 H31からH101にパケットが到達する唯一の方法は、H31がISP-Bのソースアドレスの使用を開始することです。 H31は次のパケットを送信する必要があります：（S = 2001：db8：0：b010 :: 31、D = 2001：db8：0：1234 :: 101）。
This behavior is very different from the behavior that occurs with site multihoming using PI addresses or with PA addresses using NAT. In these other multihoming solutions, hosts do not need to react to network failures several hops away in order to regain Internet access. Instead, a host can be largely unaware of the failure of an uplink to an ISP. When multihoming with PA addresses and NAT, existing sessions generally need to be reestablished after a failure since the external host will receive packets from the internal host with a new source address. However, new sessions can be established without any action on the part of the hosts. Multihoming with PA addresses and NAT has created the expectation of a fairly quick and simple recovery from network failures. Alternatives should to be evaluated in terms of the speed and complexity of the recovery mechanism.
この動作は、PIアドレスを使用したサイトマルチホーミングやNATを使用したPAアドレスで発生する動作とは大きく異なります。これらの他のマルチホーミングソリューションでは、インターネットアクセスを回復するために、ホストは数ホップ先のネットワーク障害に反応する必要はありません。代わりに、ホストはISPへのアップリンクの障害にほとんど気付かない可能性があります。外部ホストは新しい送信元アドレスで内部ホストからパケットを受信するため、PAアドレスとNATを使用してマルチホーミングする場合、通常、障害発生後に既存のセッションを再確立する必要があります。ただし、ホスト側のアクションなしで新しいセッションを確立できます。 PAアドレスとNATを使用したマルチホーミングにより、ネットワーク障害からのかなり迅速かつ単純な回復が期待されています。代替手段は、回復メカニズムの速度と複雑さの観点から評価する必要があります。
Another significant difference between this multihoming solution and multihoming with either PI addresses or with PA addresses using NAT is the ability of the enterprise network operator to route traffic over different ISPs based on destination address. We still consider the fairly simple network of Figure 2 and assume that uplinks to both ISPs are functioning. Assume that the site is multihomed using PA addresses and NAT, and that SERa and SERb each originate a normal destination route for D=::/0, with the route origination dependent on the state of the uplink to the respective ISP.
このマルチホーミングソリューションと、PIアドレスまたはNATを使用したPAアドレスを使用したマルチホーミングとのもう1つの大きな違いは、エンタープライズネットワークオペレーターが宛先アドレスに基づいて異なるISPにトラフィックをルーティングできることです。ここでも、図2のかなり単純なネットワークを検討し、両方のISPへのアップリンクが機能していると想定しています。サイトがPAアドレスとNATを使用してマルチホーム化されており、SERaとSERbがそれぞれD = :: / 0の通常の宛先ルートを発信し、ルートの発信元がそれぞれのISPへのアップリンクの状態に依存するとします。
Now suppose it is observed that an important application running between internal hosts and external host H101 experiences much better performance when the traffic passes through ISP-A (perhaps because ISP-A provides lower latency to H101). When multihoming this site with PI addresses or with PA addresses and NAT, the enterprise network operator can configure SERa to originate into the site network a normal destination route for D=2001:db8:0:1234::/64 (the destination prefix to reach H101) that depends on the state of the uplink to ISP-A. When the link to ISP-A is functioning, the destination route D=2001:db8:0:1234::/64 will be originated by SERa, so traffic from all hosts will use ISP-A to reach H101 based on the longest destination prefix match in the route lookup.
次に、トラフィックがISP-Aを通過するときに、内部ホストと外部ホストH101の間で実行される重要なアプリケーションのパフォーマンスが大幅に向上するとします（おそらく、ISP-AがH101へのレイテンシを低くするため）。このサイトをPIアドレスまたはPAアドレスとNATでマルチホーミングする場合、エンタープライズネットワークオペレーターは、SERaをサイトネットワークにD = 2001：db8：0：1234 :: / 64（宛先プレフィックスISP-Aへのアップリンクの状態に依存するH101に到達します。 ISP-Aへのリンクが機能している場合、宛先ルートD = 2001：db8：0：1234 :: / 64はSERaによって発信されるため、すべてのホストからのトラフィックはISP-Aを使用して、最長の宛先に基づいてH101に到達しますルート検索でのプレフィックスの一致。
Implementing the same routing policy is more difficult with the PA multihoming solution described in this document since it doesn't use NAT. By design, the only way to control where a packet exits this network is by setting the source address of the packet. Since the network cannot modify the source address without NAT, the host must set it. To implement this routing policy, each host needs to use the source address from the prefix assigned by ISP-A to send traffic destined for H101. Mechanisms have been proposed to allow hosts to choose the source address for packets in a fine-grained manner. We will discuss these proposals in Section 6. However, an enterprise network administrator would not expect to interact with host operating systems to ensure that a particular source address is chosen for a particular destination prefix in order to implement this routing policy.
このルーティングポリシーはNATを使用しないため、このドキュメントで説明するPAマルチホーミングソリューションを使用すると、同じルーティングポリシーを実装することがより困難になります。設計上、パケットがこのネットワークを出る場所を制御する唯一の方法は、パケットの送信元アドレスを設定することです。ネットワークはNATなしでは送信元アドレスを変更できないため、ホストが設定する必要があります。このルーティングポリシーを実装するには、各ホストは、ISP-Aによって割り当てられたプレフィックスのソースアドレスを使用して、H101宛てのトラフィックを送信する必要があります。ホストがパケットの送信元アドレスをきめ細かく選択できるメカニズムが提案されています。これらの提案については、セクション6で説明します。ただし、エンタープライズネットワーク管理者は、このルーティングポリシーを実装するために、特定の送信元アドレスが特定の宛先プレフィックスに確実に選択されるようにホストオペレーティングシステムと対話することを期待しません。
The previous sections considered two variations of a simple multihoming scenario in which the site is connected to two ISPs offering only Internet connectivity. It is likely that many actual enterprise multihoming scenarios will be similar to this simple example. However, there are more complex multihoming scenarios that we would like this solution to address as well.
前のセクションでは、サイトがインターネット接続のみを提供する2つのISPに接続されている単純なマルチホーミングシナリオの2つのバリエーションを検討しました。多くの実際のエンタープライズマルチホーミングシナリオは、この単純な例に類似している可能性があります。ただし、このソリューションで対処したいより複雑なマルチホーミングシナリオもあります。
It is fairly common for an ISP to offer a service in addition to Internet access over the same uplink. Two variations of this are reflected in Figure 3. In addition to Internet access, ISP-A offers a service that requires the site to access host H51 at 2001:db8:0:5555::51. The site has a single physical and logical connection with ISP-A, and ISP-A only allows access to H51 over that connection. So when H32 needs to access the service at H51, it needs to send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51), and those packets need to be forwarded out the link from SERa to ISP-A.
ISPが同じアップリンクを介したインターネットアクセスに加えてサービスを提供することはかなり一般的です。これの2つのバリエーションが図3に反映されています。インターネットアクセスに加えて、ISP-Aはサイトが2001：db8：0：5555 :: 51でホストH51にアクセスすることを必要とするサービスを提供しています。サイトにはISP-Aとの物理的および論理的接続が1つあり、ISP-Aはその接続を介したH51へのアクセスのみを許可します。したがって、H32がH51のサービスにアクセスする必要がある場合、（S = 2001：db8：0：a010 :: 32、D = 2001：db8：0：5555 :: 51）でパケットを送信する必要があり、これらのパケットはSERaからISP-Aへのリンクから転送されます。
2001:db8:0:1234::101 H101
|
|
2001:db8:0:a010::31 --------
2001:db8:0:b010::31 ,-----. / \
+--+ +--+ +----+ ,' `. : :
+---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- :
H31--+ +--+ +--+ | +----+ `. ,' : :
| | `-----' : Internet :
| | | : :
| | H51 : :
| | 2001:db8:0:5555::51 : :
| +--+ : :
| |R7| : :
| +--+ : :
| | : :
| | ,-----. : :
H32--+ +--+ | +-----+ ,' `. : :
+---|R2|-----+----+--|SERb1|-+ ISP-B +--+-- :
+--+ | +-----+ `. ,' : :
+--+ `--|--' : :
2001:db8:0:a010::32 |R8| | \ /
+--+ ,--|--. --------
| +-----+ ,' `. |
+-------|SERb2|-+ ISP-B | |
| +-----+ `. ,' H501
| `-----' 2001:db8:0:5678
| | ::501
+--+ +--+ H61
H41------|R3|--|R5| 2001:db8:0:6666::61
+--+ +--+
2001:db8:0:a020::41
2001:db8:0:b020::41
Figure 3: Internet Access and Services Offered by ISP-A and ISP-B
図3：ISP-AおよびISP-Bが提供するインターネットアクセスとサービス
ISP-B illustrates a variation on this scenario. In addition to Internet access, ISP-B also offers a service that requires the site to access host H61. The site has two connections to two different parts of ISP-B (shown as SERb1 and SERb2 in Figure 3). ISP-B expects Internet traffic to use the uplink from SERb1, while it expects traffic destined for the service at H61 to use the uplink from SERb2. For either uplink, ISP-B expects the ingress traffic to have a source address matching the prefix that it assigned to the site, 2001:db8:0:b000::/52.
ISP-Bは、このシナリオのバリエーションを示しています。インターネットアクセスに加えて、ISP-Bは、サイトがホストH61にアクセスすることを必要とするサービスも提供します。サイトには、ISP-Bの2つの異なる部分への2つの接続があります（図3ではSERb1およびSERb2として示されています）。 ISP-Bは、インターネットトラフィックがSERb1からのアップリンクを使用することを期待し、H61のサービス宛てのトラフィックがSERb2からのアップリンクを使用することを期待します。どちらのアップリンクでも、ISP-Bは、サイトに割り当てたプレフィックス2001：db8：0：b000 :: / 52に一致するソースアドレスが入力トラフィックにあることを期待します。
As discussed before, we rely completely on the internal host to set the source address of the packet properly. In the case of a packet sent by H31 to access the service in ISP-B at H61, we expect the packet to have the following addresses: (S=2001:db8:0:b010::31, D=2001:db8:0:6666::61). The routed network has two potential ways of distributing routes so that this packet exits the site on the uplink at SERb2.
前に説明したように、パケットの送信元アドレスを正しく設定するには、内部ホストに完全に依存しています。 H61のISP-BのサービスにアクセスするためにH31から送信されたパケットの場合、パケットには次のアドレスが含まれていることが予想されます：（S = 2001：db8：0：b010 :: 31、D = 2001：db8： 0：6666 :: 61）。ルーティングされたネットワークには、このパケットがSERb2のアップリンク上のサイトから出るように、ルートを配布する2つの潜在的な方法があります。
We could just rely on normal destination routes, without using source-prefix-scoped routes. If we have SERb2 originate a normal unscoped destination route for D=2001:db8:0:6666::/64, the packets from H31 to H61 will exit the site at SERb2 as desired. We should not have to worry about SERa needing to originate the same route, because ISP-B should choose a globally unique prefix for the service at H61.
ソースプレフィックススコープのルートを使用せずに、通常の宛先ルートに依存することもできます。 SERb2がD = 2001：db8：0：6666 :: / 64の通常の対象範囲外の宛先ルートを発信している場合、H31からH61へのパケットは、必要に応じてSERb2のサイトから出ます。 ISP-BはH61のサービスに対してグローバルに一意のプレフィックスを選択する必要があるため、同じルートを発信する必要があるSERaについて心配する必要はありません。
The alternative is to have SERb2 originate a source-prefix-scoped destination route of the form (S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64). From a forwarding point of view, the use of the source-prefix-scoped destination route would result in traffic with source addresses corresponding only to ISP-B being sent to SERb2. Instead, the use of the unscoped destination route would result in traffic with source addresses corresponding to ISP-A and ISP-B being sent to SERb2, as long as the destination address matches the destination prefix. It seems like either forwarding behavior would be acceptable.
代わりの方法は、SERb2にソースプレフィックススコープの宛先ルート（S = 2001：db8：0：b000 :: / 52、D = 2001：db8：0：6666 :: / 64）の形式で送信させることです。転送の観点から見ると、送信元プレフィックススコープの宛先ルートを使用すると、ISP-Bにのみ対応する送信元アドレスを持つトラフィックがSERb2に送信されます。代わりに、対象範囲外の宛先ルートを使用すると、宛先アドレスが宛先プレフィックスと一致する限り、ISP-AおよびISP-Bに対応するソースアドレスを持つトラフィックがSERb2に送信されます。どちらの転送動作も許容できるようです。
However, from the point of view of the enterprise network administrator trying to configure, maintain, and troubleshoot this multihoming solution, it seems much clearer to have SERb2 originate the source-prefix-scoped destination route corresponding to the service offered by ISP-B. In this way, all of the traffic leaving the site is determined by the source-prefix-scoped routes, and all of the traffic within the site or arriving from external hosts is determined by the unscoped destination routes. Therefore, for this multihoming solution we choose to originate source-prefix-scoped routes for all traffic leaving the site.
ただし、このマルチホーミングソリューションを構成、保守、およびトラブルシューティングしようとする企業ネットワーク管理者の観点からは、SERb2がISP-Bによって提供されるサービスに対応するソースプレフィックススコープの宛先ルートを発信することははるかに明確に思われます。このようにして、サイトを出るすべてのトラフィックはソースプレフィックススコープのルートによって決定され、サイト内または外部ホストから到着するすべてのトラフィックはスコープのない宛先ルートによって決定されます。したがって、このマルチホーミングソリューションでは、サイトを出るすべてのトラフィックに対してソースプレフィックススコープのルートを発信することを選択します。
While we expect that most site multihoming involves connecting to only two ISPs, this solution allows for connections to an arbitrary number of ISPs. However, when evaluating scalable implementations of the solution, it would be reasonable to assume that the maximum number of ISPs that a site would connect to is five (topologies with two redundant routers, each having two uplinks to different ISPs, plus a tunnel to a head office acting as fifth one are not unheard of).
ほとんどのサイトマルチホーミングには2つのISPへの接続のみが含まれると想定していますが、このソリューションでは、任意の数のISPへの接続が可能です。ただし、ソリューションのスケーラブルな実装を評価する場合、サイトが接続するISPの最大数は5（それぞれが異なるISPへの2つのアップリンクと、 5番目の本社として機能する本社は前代未聞ではありません）。
It is also useful to note that the prefixes assigned to the site by different ISPs will not overlap. This must be the case, since the provider-assigned addresses have to be globally unique.
異なるISPによってサイトに割り当てられたプレフィックスが重複しないことにも注意してください。プロバイダーが割り当てるアドレスはグローバルに一意である必要があるため、これは当てはまります。
The topologies of many enterprise sites using this multihoming solution may in practice be simpler than the examples that we have used. The topology in Figure 1 could be further simplified by directly connecting all hosts to the LAN that connects the two site exit routers, SERa and SERb. The topology could also be simplified by connecting both uplinks to ISP-A and ISP-B to the same site exit router. However, it is the aim of this document to provide a solution that applies to a broad range of enterprise site network topologies, so this document focuses on providing a solution to the more general case. The simplified cases will also be supported by this solution, and there may even be optimizations that can be made for simplified cases. This solution, however, needs to support more complex topologies.
このマルチホーミングソリューションを使用する多くの企業サイトのトポロジは、実際に使用した例よりも単純な場合があります。図1のトポロジは、すべてのホストを2つのサイト出口ルーターであるSERaとSERbを接続するLANに直接接続することで、さらに簡略化できます。トポロジは、ISP-AとISP-Bの両方のアップリンクを同じサイト出口ルーターに接続することによっても簡略化できます。ただし、このドキュメントの目的は、広範なエンタープライズサイトネットワークトポロジに適用されるソリューションを提供することなので、このドキュメントでは、より一般的なケースに対するソリューションの提供に焦点を当てています。簡略化されたケースもこのソリューションでサポートされ、簡略化されたケースに対して最適化を行うこともできます。ただし、このソリューションでは、より複雑なトポロジをサポートする必要があります。
We are starting with the basic assumption that enterprise site networks can be quite complex from a routing perspective. However, even a complex site network can be multihomed to different ISPs with PA addresses using IPv4 and NAT. It is not reasonable to expect an enterprise network operator to change the routing topology of the site in order to deploy IPv6.
エンタープライズサイトネットワークはルーティングの観点からはかなり複雑になる可能性があるという基本的な前提から始めます。ただし、複雑なサイトネットワークでも、IPv4とNATを使用してPAアドレスを持つ異なるISPにマルチホーム化できます。エンタープライズネットワークオペレーターがIPv6を展開するためにサイトのルーティングトポロジを変更することを期待するのは合理的ではありません。
So far, we have described in general terms how the SADR-capable routers in this solution forward traffic by using both normal unscoped destination routes and source-prefix-scoped destination routes. Here we give a precise method for generating a source-prefix-scoped forwarding table on a router that supports SADR.
ここまでは、このソリューションのSADR対応ルーターが、通常の対象範囲外の宛先ルートと送信元プレフィックス範囲の宛先ルートの両方を使用してトラフィックを転送する方法を一般的な用語で説明しました。ここでは、SADRをサポートするルーターでソースプレフィックススコープの転送テーブルを生成するための正確な方法を示します。
1. Compute the next-hops for the source-prefix-scoped destination prefixes using only routers in the connected SADR domain. These are the initial source-prefix-scoped forwarding table entries.
1. 接続されたSADRドメイン内のルーターのみを使用して、送信元プレフィックススコープの宛先プレフィックスのネクストホップを計算します。これらは、最初のソースプレフィックススコープの転送テーブルエントリです。
2. Compute the next-hops for the unscoped destination prefixes using all routers in the IGP. This is the unscoped forwarding table.
2. IGPのすべてのルーターを使用して、対象範囲外の宛先プレフィックスのネクストホップを計算します。これは対象範囲外の転送テーブルです。
3. For a given source-prefix-scoped forwarding table T (scoped to source prefix P), consider a source-prefix-scoped forwarding table T', whose source prefix P' contains P. We call T the more specific source-prefix-scoped forwarding table, and T' the less specific source-prefix-scoped forwarding table. We select entries in forwarding table T' to augment forwarding table T based on the following rules. If a destination prefix of an entry in forwarding table T' exactly matches the destination prefix of an existing entry in forwarding table T (including destination prefix length), then do not add the entry to forwarding table T. If the destination prefix does NOT match an existing entry, then add the entry to forwarding table T. As the unscoped forwarding table is considered to be scoped to ::/0, this process will propagate routes from the unscoped forwarding table to forwarding table T. If there exist multiple source-prefix-scoped forwarding tables whose source prefixes contain P, these source-prefix-scoped forwarding tables should be processed in order from most specific to least specific.
3. 特定のソースプレフィックススコープの転送テーブルT（スコープはソースプレフィックスP）について、ソースプレフィックススコープの転送テーブルT 'について考えます。そのソースプレフィックスP'にはPが含まれています。Tをより具体的なソースプレフィックススコープと呼びます転送テーブル、およびT 'は、ソースプレフィックススコープの転送テーブルです。転送テーブルT 'のエントリを選択して、次のルールに基づいて転送テーブルTを拡張します。転送テーブルT 'のエントリの宛先プレフィックスが転送テーブルTの既存のエントリの宛先プレフィックス（宛先プレフィックス長を含む）と完全に一致する場合は、エントリを転送テーブルTに追加しないでください。宛先プレフィックスが一致しない場合既存のエントリ、次にエントリを転送テーブルTに追加します。スコープ外の転送テーブルは:: / 0にスコープされていると見なされるため、このプロセスはルートをスコープ外の転送テーブルから転送テーブルTに伝達します。複数のソースが存在する場合は、ソースプレフィックスにPが含まれるプレフィックススコープの転送テーブル。これらのソースプレフィックススコープの転送テーブルは、最も具体的なものから最も具体的でないものの順に処理する必要があります。
The forwarding tables produced by this process are used in the following way to forward packets.
このプロセスで作成された転送テーブルは、パケットを転送するために次のように使用されます。
1. Select the most specific (longest prefix match) source-prefix-scoped forwarding table that matches the source address of the packet (again, the unscoped forwarding table is considered to be scoped to ::/0).
1. パケットの送信元アドレスと一致する最も具体的な（最長のプレフィックス一致）source-prefix-scoped転送テーブルを選択します（ここでも、対象範囲外の転送テーブルはスコープが:: / 0と見なされます）。
2. Look up the destination address of the packet in the selected forwarding table to determine the next-hop for the packet.
2. 選択した転送テーブルでパケットの宛先アドレスを検索して、パケットのネクストホップを決定します。
The following example illustrates how this process is used to create a forwarding table for each provider-assigned source prefix. We consider the multihomed site network in Figure 3. Initially we assume that all of the routers in the site network support SADR. Figure 4 shows the routes that are originated by the routers in the site network.
次の例は、このプロセスを使用して、プロバイダーが割り当てたソースプレフィックスごとに転送テーブルを作成する方法を示しています。図3のマルチホームサイトネットワークを検討します。最初に、サイトネットワーク内のすべてのルーターがSADRをサポートすると想定します。図4は、サイトネットワーク内のルーターから発信されたルートを示しています。
Routes originated by SERa:
(S=2001:db8:0:a000::/52, D=2001:db8:0:5555/64)
(S=2001:db8:0:a000::/52, D=::/0)
(D=2001:db8:0:5555::/64)
(D=::/0)
Routes originated by SERb1:
(S=2001:db8:0:b000::/52, D=::/0)
(D=::/0)
Routes originated by SERb2:
(S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64)
(D=2001:db8:0:6666::/64)
Routes originated by R1:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)
Routes originated by R2:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)
Routes originated by R3:
(D=2001:db8:0:a020::/64)
(D=2001:db8:0:b020::/64)
Figure 4: Routes Originated by Routers in the Site Network
図4：サイトネットワークのルーターから発信されたルート
Each SER originates destination routes that are scoped to the source prefix assigned by the ISP to which the SER connects. Note that the SERs also originate the corresponding unscoped destination route. This is not needed when all of the routers in the site support SADR. However, it is required when some routers do not support SADR. This will be discussed in more detail later.
各SERは、SERが接続するISPによって割り当てられたソースプレフィックスにスコープされた宛先ルートを発信します。 SERも対応する対象範囲外の宛先ルートを発信することに注意してください。サイト内のすべてのルーターがSADRをサポートしている場合、これは必要ありません。ただし、一部のルーターがSADRをサポートしていない場合に必要です。これについては、後で詳しく説明します。
We focus on how R8 constructs its source-prefix-scoped forwarding tables from these route advertisements. R8 computes the next hops for destination routes that are scoped to the source prefix 2001:db8:0:a000::/52. The results are shown in the first table in Figure 5. (In this example, the next hops are computed assuming that all links have the same metric.) Then, R8 computes the next hops for destination routes that are scoped to the source prefix 2001:db8:0:b000::/52. The results are shown in the second table in Figure 5. Finally, R8 computes the next hops for the unscoped destination prefixes. The results are shown in the third table in Figure 5.
R8がこれらのルートアドバタイズからソースプレフィックススコープの転送テーブルを構築する方法に焦点を当てます。 R8は、送信元プレフィックス2001：db8：0：a000 :: / 52をスコープとする宛先ルートのネクストホップを計算します。結果を図5の最初の表に示します（この例では、すべてのリンクが同じメトリックを持つと想定してネクストホップが計算されます）。次に、R8は、送信元プレフィックス2001をスコープとする宛先ルートのネクストホップを計算します。 ：db8：0：b000 :: / 52。結果は、図5の2番目の表に示されています。最後に、R8は対象範囲外の宛先プレフィックスのネクストホップを計算します。結果を図5の3番目の表に示します。
forwarding entries scoped to
source prefix = 2001:db8:0:a000::/52
============================================
D=2001:db8:0:5555/64 NH=R7
D=::/0 NH=R7
forwarding entries scoped to
source prefix = 2001:db8:0:b000::/52
============================================
D=2001:db8:0:6666/64 NH=SERb2
D=::/0 NH=SERb1
unscoped forwarding entries
============================================
D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=SERb1
Figure 5: Forwarding Entries Computed at R8
図5：R8で計算された転送エントリ
The final step is for R8 to augment the more specific source-prefix-scoped forwarding tables with entries from less specific source-prefix-scoped forwarding tables. The unscoped forwarding table is considered as being scoped to ::/0, so both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52 are more specific prefixes of ::/0. Therefore, entries in the unscoped forwarding table will be evaluated to be added to these two more specific source-prefix-scoped forwarding tables. If a forwarding entry from the less specific source-prefix-scoped forwarding table has the exact same destination prefix (including destination prefix length) as the forwarding entry from the more specific source-prefix-scoped forwarding table, then the existing forwarding entry in the more specific source-prefix-scoped forwarding table wins.
最後のステップは、R8が、より具体的なソースプレフィックススコープの転送テーブルからのエントリで、より具体的なソースプレフィックススコープの転送テーブルを拡張することです。スコープ外の転送テーブルは、スコープが:: / 0であると見なされるため、2001：db8：0：a000 :: / 52と2001：db8：0：b000 :: / 52の両方が:: / 0のより具体的なプレフィックスです。したがって、対象範囲外の転送テーブルのエントリは、これら2つの特定の送信元プレフィックス範囲の転送テーブルに追加されると評価されます。より具体的でない送信元プレフィックススコープの転送テーブルからの転送エントリが、より具体的な送信元プレフィックススコープの転送テーブルからの転送エントリとまったく同じ宛先プレフィックス（宛先プレフィックス長を含む）を持っている場合、より具体的な送信元プレフィックススコープの転送テーブルが優先されます。
As an example of how the source-prefix-scoped forwarding entries are augmented, we consider how the two entries in the first table in Figure 5 (the table for source prefix = 2001:db8:0:a000::/52) are augmented with entries from the third table in Figure 5 (the table of unscoped or scoped to ::/0 forwarding entries). The first four unscoped forwarding entries (D=2001:db8:0:a010::/64, D=2001:db8:0:b010::/64, D=2001:db8:0:a020::/64, and D=2001:db8:0:b020::/64) are not an exact match for any of the existing entries in the forwarding table for source prefix 2001:db8:0:a000::/52. Therefore, these four entries are added to the final forwarding table for source prefix 2001:db8:0:a000::/52. The result of adding these entries is reflected in the first four entries the first table in Figure 6.
source-prefix-scoped転送エントリがどのように拡張されるかの例として、図5の最初のテーブル（source prefix = 2001：db8：0：a000 :: / 52のテーブル）の2つのエントリがどのように拡張されるかを考えます。図5の3番目のテーブルからのエントリ（スコープなしまたはスコープが:: / 0の転送エントリのテーブル）。最初の4つの対象範囲外の転送エントリ（D = 2001：db8：0：a010 :: / 64、D = 2001：db8：0：b010 :: / 64、D = 2001：db8：0：a020 :: / 64、およびD = 2001：db8：0：b020 :: / 64）は、ソースプレフィックス2001：db8：0：a000 :: / 52の転送テーブル内の既存のエントリのいずれとも完全には一致しません。したがって、これらの4つのエントリは、ソースプレフィックス2001：db8：0：a000 :: / 52の最終的な転送テーブルに追加されます。これらのエントリを追加した結果は、図6の最初のテーブルの最初の4つのエントリに反映されています。
The next less specific source-prefix-scoped (scope is ::/0) forwarding table entry is for D=2001:db8:0:5555::/64. This entry is an exact match for the existing entry in the forwarding table for the more specific source prefix 2001:db8:0:a000::/52. Therefore, we do not replace the existing entry with the entry from the unscoped forwarding table. This is reflected in the fifth entry in the first table in Figure 6. (Note that since both scoped and unscoped entries have R7 as the next hop, the result of applying this rule is not visible.)
次に限定的なソースプレフィックススコープ（スコープは:: / 0）の転送テーブルエントリは、D = 2001：db8：0：5555 :: / 64です。このエントリは、より具体的なソースプレフィックス2001：db8：0：a000 :: / 52の転送テーブルの既存のエントリと完全に一致します。したがって、既存のエントリを対象範囲外の転送テーブルのエントリで置き換えません。これは、図6の最初の表の5番目のエントリに反映されています（スコープエントリとスコープなしエントリの両方にネクストホップとしてR7があるため、このルールを適用した結果は表示されません）。
The next less specific source-prefix-scoped (scope is ::/0) forwarding table entry is for D=2001:db8:0:6666::/64. This entry is not an exact match for any existing entries in the forwarding table for source prefix 2001:db8:0:a000::/52. Therefore, we add this entry. This is reflected in the sixth entry in the first table in Figure 6.
次に限定的なソースプレフィックススコープ（スコープは:: / 0）の転送テーブルエントリは、D = 2001：db8：0：6666 :: / 64用です。このエントリは、転送元テーブルのソースプレフィックス2001：db8：0：a000 :: / 52の既存のエントリと完全には一致しません。したがって、このエントリを追加します。これは、図6の最初の表の6番目のエントリに反映されています。
The next less specific source-prefix-scoped (scope is ::/0) forwarding table entry is for D=::/0. This entry is an exact match for the existing entry in the forwarding table for the more specific source prefix 2001:db8:0:a000::/52. Therefore, we do not overwrite the existing source-prefix-scoped entry, as can be seen in the last entry in the first table in Figure 6.
次に限定的なソースプレフィックススコープ（スコープは:: / 0）の転送テーブルエントリは、D = :: / 0用です。このエントリは、より具体的なソースプレフィックス2001：db8：0：a000 :: / 52の転送テーブルの既存のエントリと完全に一致します。したがって、図6の最初の表の最後のエントリにあるように、既存のsource-prefix-scopedエントリを上書きしません。
if source address matches 2001:db8:0:a000::/52
then use this forwarding table
============================================
D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=R7
else if source address matches 2001:db8:0:b000::/52
then use this forwarding table
============================================
D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=SERb1
else if source address matches ::/0 use this forwarding table
============================================
D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=SERb1
Figure 6: Complete Forwarding Tables Computed at R8
図6：R8で計算された完全な転送テーブル
The forwarding tables produced by this process at R8 have the desired properties. A packet with a source address in 2001:db8:0:a000::/52 will be forwarded based on the first table in Figure 6. If the packet is destined for the Internet at large or the service at D=2001:db8:0:5555/64, it will be sent to R7 in the direction of SERa. If the packet is destined for an internal host, then the first four entries will send it to R2 or R5 as expected. Note that if this packet has a destination address corresponding to the service offered by ISP-B (D=2001:db8:0:5555::/64), then it will get forwarded to SERb2. It will be dropped by SERb2 or by ISP-B, since the packet has a source address that was not assigned by ISP-B. However, this is expected behavior. In order to use the service offered by ISP-B, the host needs to originate the packet with a source address assigned by ISP-B.
R8でこのプロセスによって作成された転送テーブルには、必要なプロパティがあります。 2001：db8：0：a000 :: / 52の送信元アドレスを持つパケットは、図6の最初のテーブルに基づいて転送されます。パケットがインターネット全体またはD = 2001：db8のサービス宛ての場合： 0：5555/64、SERaの方向でR7に送信されます。パケットの宛先が内部ホストである場合、最初の4つのエントリは、期待どおりにR2またはR5に送信します。このパケットに、ISP-Bが提供するサービス（D = 2001：db8：0：5555 :: / 64）に対応する宛先アドレスがある場合、SERb2に転送されることに注意してください。パケットにはISP-Bによって割り当てられなかった送信元アドレスがあるため、SERb2またはISP-Bによってドロップされます。ただし、これは予想される動作です。 ISP-Bが提供するサービスを使用するには、ホストがISP-Bによって割り当てられた送信元アドレスでパケットを発信する必要があります。
In this example, a packet with a source address that doesn't match 2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated from an external host. Such a packet will use the unscoped forwarding table (the last table in Figure 6). These packets will flow exactly as they would in absence of multihoming.
この例では、2001：db8：0：a000 :: / 52または2001：db8：0：b000 :: / 52と一致しない送信元アドレスを持つパケットは、外部ホストから発信されたものでなければなりません。このようなパケットは、対象範囲外の転送テーブル（図6の最後のテーブル）を使用します。これらのパケットは、マルチホーミングがない場合とまったく同じように流れます。
We can also modify this example to illustrate how it supports deployments in which not all routers in the site support SADR. Continuing with the topology shown in Figure 3, suppose that R3 and R5 do not support SADR. Instead they are only capable of understanding unscoped route advertisements. The SADR routers in the network will still originate the routes shown in Figure 4. However, R3 and R5 will only understand the unscoped routes as shown in Figure 7.
この例を変更して、サイト内のすべてのルーターがSADRをサポートするわけではない展開をサポートする方法を示すこともできます。図3に示すトポロジーを続けて、R3とR5がSADRをサポートしていないとします。代わりに、対象範囲外のルートアドバタイズを理解することしかできません。ネットワーク内のSADRルーターは、引き続き図4に示すルートを発信します。ただし、R3とR5は、図7に示すように、対象範囲外のルートのみを認識します。
Routes originated by SERa:
(D=2001:db8:0:5555::/64)
(D=::/0)
Routes originated by SERb1:
(D=::/0)
Routes originated by SERb2:
(D=2001:db8:0:6666::/64)
Routes originated by R1:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)
Routes originated by R2:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)
Routes originated by R3:
(D=2001:db8:0:a020::/64)
(D=2001:db8:0:b020::/64)
Figure 7: Route Advertisements Understood by Routers That Do Not Support SADR
図7：SADRをサポートしないルーターによって認識されるルートアドバタイズメント
With these unscoped route advertisements, R5 will produce the forwarding table shown in Figure 8.
これらの対象範囲外のルートアドバタイズを使用すると、R5は図8に示す転送テーブルを生成します。
forwarding table
============================================
D=2001:db8:0:a010::/64 NH=R8
D=2001:db8:0:b010::/64 NH=R8
D=2001:db8:0:a020::/64 NH=R3
D=2001:db8:0:b020::/64 NH=R3
D=2001:db8:0:5555::/64 NH=R8
D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=R8
Figure 8: Forwarding Table for R5, Which Doesn't Understand Source-Prefix- Scoped Routes
図8：ソースプレフィックススコープのルートを理解しないR5の転送テーブル
As all SERs belong to the SADR domain, any traffic that needs to exit the site will eventually hit a SADR-capable router. To prevent routing loops involving SADR-capable and non-SADR-capable routers, traffic that enters the SADR-capable domain does not leave the domain until it exits the site. Therefore all SADR-capable routers within the domain MUST be logically connected.
すべてのSERはSADRドメインに属しているため、サイトを出る必要のあるトラフィックは最終的にSADR対応ルーターに到達します。 SADR対応およびSADR非対応のルーターが関与するルーティングループを防止するために、SADR対応ドメインに入るトラフィックは、サイトを出るまでドメインを離れません。したがって、ドメイン内のすべてのSADR対応ルーターは論理的に接続されている必要があります。
Note that the mechanism described here for converting source-prefix-scoped destination prefix routing advertisements into forwarding state is somewhat different from that proposed in [DST-SRC-RTG]. The method described in this document is functionally equivalent, but it is based on application of existing mechanisms for the described scenarios.
ソースプレフィックススコープの宛先プレフィックスルーティングアドバタイズメントを転送状態に変換するためにここで説明されているメカニズムは、[DST-SRC-RTG]で提案されているメカニズムとは多少異なることに注意してください。このドキュメントで説明されている方法は機能的に同等ですが、説明されているシナリオに対する既存のメカニズムの適用に基づいています。
6. Mechanisms for Hosts To Choose Good Default Source Addresses in a Multihomed Site
6. ホストがマルチホームサイトで適切なデフォルトの送信元アドレスを選択するためのメカニズム
Until this point, we have made the assumption that hosts are able to choose the correct source address using some unspecified mechanism. This has allowed us to focus on what the routers in a multihomed site network need to do in order to forward packets to the correct ISP based on source address. Now we look at possible mechanisms for hosts to choose the correct source address. We also look at what role, if any, the routers may play in providing information that helps hosts to choose source addresses.
ここまでは、ホストが特定されていないメカニズムを使用して正しい送信元アドレスを選択できると仮定してきました。これにより、送信元アドレスに基づいてパケットを正しいISPに転送するために、マルチホームサイトネットワークのルーターが何をする必要があるかに焦点を当てることができました。次に、ホストが正しい送信元アドレスを選択するための考えられるメカニズムを調べます。ホストがソースアドレスを選択するのに役立つ情報を提供する際にルーターが果たす役割についても検討します。
It should be noted that this section discusses how hosts could select the default source address for new connections. Any connection that already exists on a host is bound to a specific source address that cannot be changed. Section 6.7 discusses the connections preservation issue in more detail.
このセクションでは、ホストが新しい接続のデフォルトの送信元アドレスを選択する方法について説明していることに注意してください。ホストにすでに存在する接続は、変更できない特定の送信元アドレスにバインドされます。セクション6.7では、接続の保存の問題について詳しく説明します。
Any host that needs to be able to send traffic using the uplinks to a given ISP is expected to be configured with an address from the prefix assigned by that ISP. The host will control which ISP is used for its traffic by selecting one of the addresses configured on the host as the source address for outgoing traffic. It is the responsibility of the site network to ensure that a packet with the source address from an ISP is now sent on an uplink to that ISP.
特定のISPへのアップリンクを使用してトラフィックを送信できる必要があるすべてのホストは、そのISPによって割り当てられたプレフィックスからのアドレスで構成されていることが期待されます。ホストは、発信トラフィックのソースアドレスとしてホストに設定されたアドレスの1つを選択することにより、トラフィックに使用されるISPを制御します。 ISPからの送信元アドレスを含むパケットがアップリンクでそのISPに送信されるようにするのは、サイトネットワークの責任です。
If all of the ISP uplinks are working, then the host's choice of source address may be driven by the desire to load share across ISP uplinks, or it may be driven by the desire to take advantage of certain properties of a particular uplink or ISP (if some information about various path properties has been made available to the host somehow. See [PROV-DOMAINS] as an example). If any of the ISP uplinks is not working, then the choice of source address by the host can cause packets to get dropped.
すべてのISPアップリンクが機能している場合、ホストのソースアドレスの選択は、ISPアップリンク間で負荷を共有したいという欲求によって促進されるか、特定のアップリンクまたはISPの特定のプロパティを利用したいという欲求によって促進されます（さまざまなパスプロパティに関する情報が何らかの形でホストに提供されている場合（例として[PROV-DOMAINS]を参照）。いずれかのISPアップリンクが機能していない場合、ホストが送信元アドレスを選択すると、パケットがドロップされる可能性があります。
How a host selects a suitable source address in a multihomed site is not a solved problem. We do not attempt to solve this problem in this document. Instead we discuss the current state of affairs with respect to standardized solutions and the implementation of those solutions. We also look at proposed solutions for this problem.
ホストがマルチホームサイトで適切な送信元アドレスを選択する方法は、解決された問題ではありません。このドキュメントでは、この問題の解決を試みていません。代わりに、標準化されたソリューションとそれらのソリューションの実装に関する現状について説明します。また、この問題に対する提案された解決策も検討します。
An external host initiating communication with a host internal to a PA-multihomed site will need to know multiple addresses for that host in order to communicate with it using different ISPs to the multihomed site (knowing just one address would undermine all benefits of redundant connectivity provided by multihoming). These addresses are typically learned through DNS. (For simplicity, we assume that the external host is single-homed.) The external host chooses the ISP that will be used at the remote multihomed site by setting the destination address on the packets it transmits. For a session originated from an external host to an internal host, the choice of source address used by the internal host is simple. The internal host has no choice but to use the destination address in the received packet as the source address of the transmitted packet.
PAマルチホームサイトの内部のホストとの通信を開始する外部ホストは、マルチホームサイトと異なるISPを使用してホストと通信するために、そのホストの複数のアドレスを知る必要があります（1つのアドレスだけを知っていれば、提供される冗長接続のすべての利点が損なわれます）マルチホーミングによる）。これらのアドレスは通常、DNSを通じて学習されます。 （簡単にするために、外部ホストはシングルホームであると想定しています。）外部ホストは、送信するパケットに宛先アドレスを設定することにより、リモートマルチホームサイトで使用されるISPを選択します。外部ホストから内部ホストへのセッションの場合、内部ホストが使用する送信元アドレスの選択は簡単です。内部ホストは、受信パケットの宛先アドレスを送信パケットの送信元アドレスとして使用する以外に選択肢はありません。
For a session originated by a host inside the multihomed site, the decision of which source address to select is more complicated. We consider three main methods for hosts to get information about the network. The two proactive methods are Neighbor Discovery Router Advertisements and DHCPv6. The one reactive method we consider is ICMPv6. Note that we are explicitly excluding the possibility of having hosts participate in, or even listen directly to, routing protocol advertisements.
マルチホームサイト内のホストによって開始されたセッションの場合、選択する送信元アドレスの決定はより複雑です。ホストがネットワークに関する情報を取得するための3つの主要な方法を検討します。 2つのプロアクティブな方法は、近隣探索ルーターアドバタイズメントとDHCPv6です。私たちが検討する反応的な方法の1つは、ICMPv6です。ホストがルーティングプロトコルアドバタイズメントに参加する、または直接リッスンする可能性を明示的に除外していることに注意してください。
First we look at how a host is currently expected to select the default source and destination addresses to be used for a new connection.
最初に、新しい接続に使用するデフォルトの送信元アドレスと宛先アドレスをホストが現在どのように選択することが期待されているかを確認します。
[RFC6724] defines the algorithms that hosts are expected to use to select source and destination addresses for packets. It defines an algorithm for selecting a source address and a separate algorithm for selecting a destination address. Both of these algorithms depend on a policy table. [RFC6724] defines a default policy that produces certain behavior.
[RFC6724]は、ホストがパケットの送信元アドレスと宛先アドレスを選択するために使用すると予想されるアルゴリズムを定義しています。送信元アドレスを選択するためのアルゴリズムと宛先アドレスを選択するための別のアルゴリズムを定義します。これらのアルゴリズムはどちらもポリシーテーブルに依存しています。 [RFC6724]は、特定の動作を生成するデフォルトのポリシーを定義しています。
The rules in the two algorithms in [RFC6724] depend on many different properties of addresses. While these are needed for understanding how a host should choose addresses in an arbitrary environment, most of the rules are not relevant for understanding how a host should choose among multiple source addresses in a multihomed environment when sending a packet to a remote host. Returning to the example in Figure 3, we look at what the default algorithms in [RFC6724] say about the source address that internal host H31 should use to send traffic to external host H101, somewhere on the Internet.
[RFC6724]の2つのアルゴリズムのルールは、アドレスのさまざまなプロパティに依存します。これらは、ホストが任意の環境でアドレスを選択する方法を理解するために必要ですが、ほとんどの規則は、リモートホストにパケットを送信するときに、ホストがマルチホーム環境で複数の送信元アドレスから選択する方法を理解するためには関係ありません。図3の例に戻り、インターネット上のどこかにある外部ホストH101にトラフィックを送信するために内部ホストH31が使用する必要があるソースアドレスについて、[RFC6724]のデフォルトアルゴリズムがどのように言っているかを調べます。
There is no choice to be made with respect to destination address. H31 needs to send a packet with D=2001:db8:0:1234::101 in order to reach H101. So H31 has to choose between using S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 as the source address for this packet. We go through the rules for source address selection in Section 5 of [RFC6724].
宛先アドレスに関して行われる選択はありません。 H31は、H101に到達するために、D = 2001：db8：0：1234 :: 101のパケットを送信する必要があります。したがって、H31は、このパケットのソースアドレスとしてS = 2001：db8：0：a010 :: 31またはS = 2001：db8：0：b010 :: 31を使用することを選択する必要があります。 [RFC6724]のセクション5で送信元アドレスの選択に関するルールを確認します。
Rule 1 (Prefer same address) is not useful to break the tie between source addresses because neither one of the candidate source addresses equals the destination address.
ルール1（同じアドレスを優先する）は、送信元アドレスの候補のいずれも宛先アドレスと等しくないため、送信元アドレス間のつながりを断ち切るのに役立ちません。
Rule 2 (Prefer appropriate scope) is also not useful in this scenario because both source addresses and the destination address have global scope.
ルール2（適切なスコープを優先する）もこのシナリオでは役に立ちません。送信元アドレスと宛先アドレスの両方にグローバルスコープがあるためです。
Rule 3 (Avoid deprecated addresses) applies to an address that has been autoconfigured by a host using stateless address autoconfiguration as defined in [RFC4862]. An address autoconfigured by a host has a preferred lifetime and a valid lifetime. The address is preferred until the preferred lifetime expires, after which it becomes deprecated. A deprecated address is not used if there is a preferred address of the appropriate scope available. When the valid lifetime expires, the address cannot be used at all. The preferred and valid lifetimes for an autoconfigured address are set based on the corresponding lifetimes in the Prefix Information Option in Neighbor Discovery Router Advertisements. In this scenario, a possible tool to control source address selection in this scenario would be for a host to deprecate an address by having routers on that link, R1 and R2 in Figure 3, send Router Advertisement messages containing PIOs with the Preferred Lifetime value for the deprecated source prefix set to zero. This is a rather blunt tool, because it discourages or prohibits the use of that source prefix for all destinations. However, it may be useful in some scenarios. For example, if all uplinks to a particular ISP fail, it is desirable to prevent hosts from using source addresses from that ISP address space.
ルール3（非推奨のアドレスを回避する）は、[RFC4862]で定義されているステートレスアドレス自動構成を使用してホストによって自動構成されたアドレスに適用されます。ホストによって自動構成されたアドレスには、優先ライフタイムと有効ライフタイムがあります。アドレスは、優先ライフタイムが期限切れになるまで優先され、その後、非推奨になります。使用可能な適切なスコープの優先アドレスがある場合、非推奨のアドレスは使用されません。有効期限が切れると、アドレスはまったく使用できなくなります。自動構成されたアドレスの優先有効期間は、近隣探索ルーターアドバタイズメントのプレフィックス情報オプションの対応する有効期間に基づいて設定されます。このシナリオでは、このシナリオでソースアドレスの選択を制御するための可能なツールは、ホストがそのリンク上のルーター（図3のR1およびR2）を使用してアドレスを非推奨にすることです。廃止されたソースプレフィックスはゼロに設定されます。これは、すべての宛先に対してそのソースプレフィックスの使用を推奨または禁止するため、かなり率直なツールです。ただし、一部のシナリオでは役立ちます。たとえば、特定のISPへのすべてのアップリンクに障害が発生した場合、ホストがそのISPアドレス空間のソースアドレスを使用しないようにすることが望ましいです。
Rule 4 (Avoid home addresses) does not apply here because we are not considering Mobile IP.
ルール4（ホームアドレスを使用しない）は、モバイルIPを考慮していないため、ここでは適用されません。
Rule 5 (Prefer outgoing interface) is not useful in this scenario because both source addresses are assigned to the same interface.
両方のソースアドレスが同じインターフェイスに割り当てられているため、ルール5（発信インターフェイスを優先）はこのシナリオでは役立ちません。
Rule 5.5 (Prefer addresses in a prefix advertised by the next-hop) is not useful in the scenario when both R1 and R2 will advertise both source prefixes. However, this rule may potentially allow a host to select the correct source prefix by selecting a next-hop. The most obvious way would be to make R1 advertise itself as a default router and send PIO for 2001:db8:0:a010::/64, while R2 advertises itself as a default router and sends PIO for 2001:db8:0:b010::/64. We'll discuss later how Rule 5.5 can be used to influence a source address selection in single-router topologies (e.g., when H41 is sending traffic using R3 as a default gateway).
ルール5.5（ネクストホップによってアドバタイズされるプレフィックスのアドレスを優先する）は、R1とR2の両方が両方のソースプレフィックスをアドバタイズするシナリオでは役立ちません。ただし、このルールでは、ネクストホップを選択することにより、ホストが正しいソースプレフィックスを選択できる可能性があります。最も明白な方法は、R1をデフォルトルーターとしてアドバタイズしてPIOを2001：db8：0：a010 :: / 64に送信し、R2をデフォルトルーターとしてアドバタイズして2001：db8：0：b010にPIOを送信することです。 :: / 64。ルール5.5を使用して単一ルータートポロジでソースアドレスの選択に影響を与える方法については後で説明します（たとえば、H41がR3をデフォルトゲートウェイとして使用してトラフィックを送信している場合）。
Rule 6 (Prefer matching label) refers to the label value determined for each source and destination prefix as a result of applying the policy table to the prefix. With the default policy table defined in Section 2.1 of [RFC6724], Label(2001:db8:0:a010::31) = 5, Label(2001:db8:0:b010::31) = 5, and Label(2001:db8:0:1234::101) = 5. So with the default policy, Rule 6 does not break the tie. However, the algorithms in [RFC6724] are defined in such a way that non-default address selection policy tables can be used. [RFC7078] defines a way to distribute a non-default address selection policy table to hosts using DHCPv6. So even though the application of Rule 6 to this scenario using the default policy table is not useful, Rule 6 may still be a useful tool.
ルール6（一致するラベルを優先する）は、ポリシーテーブルをプレフィックスに適用した結果、各送信元プレフィックスと宛先プレフィックスに対して決定されたラベル値を参照します。 [RFC6724]のセクション2.1で定義されているデフォルトのポリシーテーブルでは、Label（2001：db8：0：a010 :: 31）= 5、Label（2001：db8：0：b010 :: 31）= 5、Label（2001 ：db8：0：1234 :: 101）= 5.したがって、デフォルトのポリシーでは、ルール6はタイを壊しません。ただし、[RFC6724]のアルゴリズムは、デフォルト以外のアドレス選択ポリシーテーブルを使用できるように定義されています。 [RFC7078]は、デフォルト以外のアドレス選択ポリシーテーブルをDHCPv6を使用してホストに配布する方法を定義しています。したがって、デフォルトのポリシーテーブルを使用したこのシナリオへのルール6の適用は有用ではありませんが、ルール6は依然として有用なツールである可能性があります。
Rule 7 (Prefer temporary addresses) has to do with the technique described in [RFC4941] to periodically randomize the interface portion of an IPv6 address that has been generated using stateless address autoconfiguration. In general, if H31 were using this technique, it would use it for both source addresses, for example, creating temporary addresses 2001:db8:0:a010:2839:9938:ab58:830f and 2001:db8:0:b010:4838:f483:8384:3208, in addition to 2001:db8:0:a010::31 and 2001:db8:0:b010::31. So this rule would prefer the two temporary addresses, but it would not break the tie between the two source prefixes from ISP-A and ISP-B.
ルール7（一時アドレスを優先）は、[RFC4941]で説明されている手法と関係があり、ステートレスアドレス自動構成を使用して生成されたIPv6アドレスのインターフェース部分を定期的にランダム化します。一般的に、H31がこの手法を使用している場合、両方の送信元アドレスにそれを使用します。たとえば、一時アドレス2001：db8：0：a010：2839：9938：ab58：830fおよび2001：db8：0：b010：4838を作成します。 ：f483：8384：3208、2001：db8：0：a010 :: 31および2001：db8：0：b010 :: 31に加えて。したがって、このルールは2つの一時アドレスを優先しますが、ISP-AとISP-Bからの2つのソースプレフィックス間のつながりを壊しません。
Rule 8 (Use longest matching prefix) dictates that, between two candidate source addresses, the host selects the one that has longest common prefix length with the destination address. For example, if H31 were selecting the source address for sending packets to H101, this rule would not break the tie between candidate source addresses 2001:db8:0:a101::31 and 2001:db8:0:b101::31 since the common prefix length with the destination is 48. However, if H31 were selecting the source address for sending packets to H41 address 2001:db8:0:a020::41, then this rule would result in using 2001:db8:0:a101::31 as a source (2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix 2001:db8:0:a000::/58, while for 2001:db8:0:b101::31 and 2001:db8:0:a020::41, the common prefix is 2001:db8:0:a000::/51). Therefore Rule 8 might be useful for selecting the correct source address in some, but not all, scenarios (for example if ISP-B services belong to 2001:db8:0:b000::/59, then H31 would always use 2001:db8:0:b010::31 to access those destinations).
ルール8（一致する最長のプレフィックスを使用）は、2つの候補送信元アドレス間で、ホストが宛先アドレスと共通のプレフィックス長が最も長いアドレスを選択することを指示します。たとえば、H31がH101にパケットを送信するための送信元アドレスを選択していた場合、このルールは候補送信元アドレス2001：db8：0：a101 :: 31と2001：db8：0：b101 :: 31の間の関係を壊しません。宛先との共通のプレフィックス長は48です。ただし、H31がH41アドレス2001：db8：0：a020 :: 41にパケットを送信するためのソースアドレスを選択している場合、このルールでは2001：db8：0：a101：が使用されます。 ：31をソースとして（2001：db8：0：a101 :: 31および2001：db8：0：a020 :: 41は、共通のプレフィックス2001：db8：0：a000 :: / 58を共有しますが、2001：db8：0 ：b101 :: 31および2001：db8：0：a020 :: 41、一般的なプレフィックスは2001：db8：0：a000 :: / 51です）。したがって、ルール8は、すべてではなく一部のシナリオで正しい送信元アドレスを選択するのに役立ちます（たとえば、ISP-Bサービスが2001：db8：0：b000 :: / 59に属している場合、H31は常に2001：db8を使用します。 ：0：b010 :: 31（これらの宛先にアクセスするため）。
So we can see that of the eight source address selection rules from [RFC6724], four actually apply to our basic site multihoming scenario. The rules that are relevant to this scenario are summarized below.
したがって、[RFC6724]の8つの送信元アドレス選択ルールのうち、4つが基本的なサイトマルチホーミングシナリオに実際に適用されることがわかります。このシナリオに関連するルールを以下にまとめます。
* Rule 3: Avoid deprecated addresses.
* ルール3：非推奨のアドレスを避けます。
* Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
* ルール5.5：ネクストホップによってアドバタイズされるプレフィックスのアドレスを優先します。
* Rule 6: Prefer matching label.
* ルール6：一致するラベルを優先します。
* Rule 8: Prefer longest matching prefix.
* ルール8：一致する最長のプレフィックスを優先します。
The two methods that we discuss for controlling the source address selection through the four relevant rules above are SLAAC Router Advertisement messages and DHCPv6.
上記の4つの関連ルールを通じて送信元アドレスの選択を制御するために説明する2つの方法は、SLAACルーターアドバタイズメッセージとDHCPv6です。
We also consider a possible role for ICMPv6 for getting traffic-driven feedback from the network. With the source address selection algorithm discussed above, the goal is to choose the correct source address on the first try, before any traffic is sent. However, another strategy is to choose a source address, send the packet, get feedback from the network about whether or not the source address is correct, and try another source address if it is not.
また、ネットワークからトラフィック主導のフィードバックを取得するためのICMPv6の可能な役割についても検討します。上記の送信元アドレス選択アルゴリズムの目的は、トラフィックが送信される前に、最初の試行で正しい送信元アドレスを選択することです。ただし、別の戦略は、送信元アドレスを選択し、パケットを送信し、送信元アドレスが正しいかどうかについてネットワークからフィードバックを取得し、正しくない場合は別の送信元アドレスを試すことです。
We consider four scenarios in which a host needs to select the correct source address. In the first scenario, both uplinks are working. In the second scenario, one uplink has failed. The third scenario is a situation in which one failed uplink has recovered. The last scenario is failure of both (all) uplinks.
ホストが正しい送信元アドレスを選択する必要がある4つのシナリオを検討します。最初のシナリオでは、両方のアップリンクが機能しています。 2番目のシナリオでは、1つのアップリンクが失敗しました。 3番目のシナリオは、1つの失敗したアップリンクが回復した状況です。最後のシナリオは、両方（すべて）のアップリンクの障害です。
It should be noted that [RFC6724] only defines the behavior of IPv6 hosts to select default addresses that applications and upper-layer protocols can use. Applications and upper-layer protocols can make their own choices on selecting source addresses. The mechanism proposed in this document attempts to ensure that the subset of source addresses available for applications and upper-layer protocols is selected with the up-to-date network state in mind. The rest of the document discusses various aspects of the default source address selection defined in [RFC6724], calling it for the sake of brevity "the source address selection".
[RFC6724]は、アプリケーションと上位層プロトコルが使用できるデフォルトアドレスを選択するためのIPv6ホストの動作のみを定義していることに注意してください。アプリケーションと上位層プロトコルは、送信元アドレスを選択する際に独自の選択を行うことができます。このドキュメントで提案されているメカニズムは、アプリケーションと上位層プロトコルで使用可能な送信元アドレスのサブセットが、最新のネットワーク状態を考慮して選択されるようにすることを目的としています。この文書の残りの部分では、[RFC6724]で定義されているデフォルトの送信元アドレス選択のさまざまな側面について説明し、簡潔にするために「送信元アドレス選択」と呼んでいます。
Again we return to the topology in Figure 3. Suppose that the site administrator wants to implement a policy by which all hosts need to use ISP-A to reach H101 at D=2001:db8:0:1234::101. So for example, H31 needs to select S=2001:db8:0:a010::31.
再び図3のトポロジに戻ります。サイト管理者が、すべてのホストがISP-Aを使用してD = 2001：db8：0：1234 :: 101のH101に到達する必要があるポリシーを実装したいとします。たとえば、H31はS = 2001：db8：0：a010 :: 31を選択する必要があります。
This policy can be implemented by using DHCPv6 to distribute an address selection policy table that assigns the same label to destination addresses that match 2001:db8:0:1234::/64 as it does to source addresses that match 2001:db8:0:a000::/52. The following two entries accomplish this.
このポリシーを実装するには、DHCPv6を使用して、2001：db8：0：1に一致する送信元アドレスと同じように2001：db8：0：1234 :: / 64に一致する宛先アドレスに同じラベルを割り当てるアドレス選択ポリシーテーブルを配布します。 a000 :: / 52。次の2つのエントリはこれを実現します。
Prefix Precedence Label
2001:db8:0:1234::/64 50 33
2001:db8:0:a000::/52 50 33
Figure 9: Policy Table Entries to Implement a Routing Policy
図9：ルーティングポリシーを実装するためのポリシーテーブルエントリ
This requires that the hosts implement [RFC6724], the basic source and destination address framework, along with [RFC7078], the DHCPv6 extension for distributing a non-default policy table. Note that it does NOT require that the hosts use DHCPv6 for address assignment. The hosts could still use stateless address autoconfiguration for address configuration, while using DHCPv6 only for policy table distribution (see [RFC8415]). However this method has a number of disadvantages:
これには、ホストが、デフォルト以外のポリシーテーブルを配布するためのDHCPv6拡張である[RFC7078]とともに、基本的な送信元および宛先アドレスフレームワークである[RFC6724]を実装する必要があります。ホストがアドレス割り当てにDHCPv6を使用する必要がないことに注意してください。ホストはアドレス構成にステートレスアドレス自動構成を使用できますが、DHCPv6はポリシーテーブル配布にのみ使用できます（[RFC8415]を参照）。ただし、この方法にはいくつかの欠点があります。
* DHCPv6 support is not a mandatory requirement for IPv6 hosts [RFC8504], so this method might not work for all devices.
* DHCPv6サポートはIPv6ホスト[RFC8504]の必須要件ではないため、この方法はすべてのデバイスで機能しない場合があります。
* Network administrators are required to explicitly configure the desired network access policies on DHCPv6 servers. While it might be feasible in the scenario of a single multihomed network, such approach might have some scalability issues, especially if the centralized DHCPv6 solution is deployed to serve a large number of multihomed sites.
* ネットワーク管理者は、DHCPv6サーバーで目的のネットワークアクセスポリシーを明示的に構成する必要があります。単一のマルチホームネットワークのシナリオでは実現可能かもしれませんが、特に集中型DHCPv6ソリューションが多数のマルチホームサイトにサービスを提供するために展開されている場合、このようなアプローチにはスケーラビリティの問題があるかもしれません。
6.2.2. Controlling Default Source Address Selection with Router Advertisements
6.2.2. ルータアドバタイズメントによるデフォルトの送信元アドレス選択の制御
Neighbor Discovery currently has two mechanisms to communicate prefix information to hosts. The base specification for Neighbor Discovery (see [RFC4861]) defines the Prefix Information Option (PIO) in the Router Advertisement (RA) message. When a host receives a PIO with the A-flag [RFC8425] set, it can use the prefix in the PIO as the source prefix from which it assigns itself an IP address using stateless address autoconfiguration (SLAAC) procedures described in [RFC4862]. In the example of Figure 3, if the site network is using SLAAC, we would expect both R1 and R2 to send RA messages with PIOs with the A-flag set for both source prefixes 2001:db8:0:a010::/64 and 2001:db8:0:b010::/64. H31 would then use the SLAAC procedure to configure itself with 2001:db8:0:a010::31 and 2001:db8:0:b010::31.
近隣探索には現在、プレフィックス情報をホストに伝達するための2つのメカニズムがあります。近隣探索（[RFC4861]を参照）の基本仕様では、ルーターアドバタイズ（RA）メッセージのプレフィックス情報オプション（PIO）を定義しています。ホストは、Aフラグ[RFC8425]が設定されたPIOを受信すると、PIO内のプレフィックスをソースプレフィックスとして使用し、[RFC4862]で説明されているステートレスアドレス自動構成（SLAAC）プロシージャを使用してIPアドレスを自身に割り当てます。図3の例では、サイトネットワークがSLAACを使用している場合、R1とR2の両方が、両方のソースプレフィックス2001：db8：0：a010 :: / 64および2001：db8：0：b010 :: / 64。次に、H31はSLAACプロシージャを使用して、2001：db8：0：a010 :: 31および2001：db8：0：b010 :: 31で自身を構成します。
Whereas a host learns about source prefixes from PIO messages, hosts can learn about a destination prefix from a Router Advertisement containing a Route Information Option (RIO), as specified in [RFC4191]. The destination prefixes in RIOs are intended to allow a host to choose the router that it uses as its first hop to reach a particular destination prefix.
ホストはPIOメッセージからソースプレフィックスについて学習するのに対し、ホストは[RFC4191]で指定されているように、Route Information Option（RIO）を含むルーターアドバタイズメントから宛先プレフィックスについて学習できます。 RIOの宛先プレフィックスは、ホストが特定の宛先プレフィックスに到達するための最初のホップとして使用するルーターを選択できるようにすることを目的としています。
As currently standardized, neither PIO nor RIO options contained in Neighbor Discovery Router Advertisements can communicate the information needed to implement the desired routing policy. PIOs communicate source prefixes, and RIOs communicate destination prefixes. However, there is currently no standardized way to directly associate a particular destination prefix with a particular source prefix.
現在標準化されているように、近隣探索ルーターアドバタイズメントに含まれているPIOオプションもRIOオプションも、目的のルーティングポリシーを実装するために必要な情報を伝達できません。 PIOはソースプレフィックスを伝達し、RIOは宛先プレフィックスを伝達します。ただし、現在のところ、特定の宛先プレフィックスを特定のソースプレフィックスに直接関連付ける標準化された方法はありません。
[SADR-RA] proposes a Source Address Dependent Route Information option for Neighbor Discovery Router Advertisements that would associate a source prefix with a destination prefix. The details of [SADR-RA] might need tweaking to address this use case. However, in order to be able to use Neighbor Discovery Router Advertisements to implement this routing policy, an extension is needed that would allow R1 and R2 to explicitly communicate to H31 an association between S=2001:db8:0:a000::/52 and D=2001:db8:0:1234::/64.
[SADR-RA]は、ソースプレフィックスを宛先プレフィックスに関連付ける近隣探索ルーターアドバタイズメントのソースアドレス依存ルート情報オプションを提案します。 [SADR-RA]の詳細は、この使用例に対処するために微調整が必要になる場合があります。ただし、近隣探索ルーターアドバタイズメントを使用してこのルーティングポリシーを実装できるようにするには、R1とR2がS = 2001：db8：0：a000 :: / 52間の関連付けをH31に明示的に通信できるようにする拡張が必要です。およびD = 2001：db8：0：1234 :: / 64。
However, Rule 5.5 of the default source address selection algorithm (discussed in Section 6.1), together with default router preference (specified in [RFC4191]) and RIO, can be used to influence a source address selection on a host as described below. Let's look at source address selection on the host H41. It receives RAs from R3 with PIOs for 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. At that point, all traffic would use the same next-hop (R3 link-local address) so Rule 5.5 does not apply. Now let's assume that R3 supports SADR and has two scoped forwarding tables, one scoped to S=2001:db8:0:a000::/52 and another scoped to S=2001:db8:0:b000::/52. If R3 generates two different link-local addresses for its interface facing H41 (one for each scoped forwarding table, LLA_A and LLA_B), R3 will send two different RAs: one from LLA_A that includes a PIO for 2001:db8:0:a020::/64, and another from LLA_B that includes a PIO for 2001:db8:0:b020::/64. Now it is possible to influence H41 source address selection for destinations that follow the default route by setting the default router preference in RAs. If it is desired that H41 reaches H101 (or any destination in the Internet) via ISP-A, then RAs sent from LLA_A should have the default router preference set to 01 (high priority), while RAs sent from LLA_B should have the preference set to 11 (low). LLA_A would then be chosen as a next-hop for H101, and therefore (per Rule 5.5) 2001:db8:0:a020::41 would be selected as the source address. If, at the same time, it is desired that H61 is accessible via ISP-B, then R3 should include a RIO for 2001:db8:0:6666::/64 in its RA sent from LLA_B. H41 would choose LLA_B as a next-hop for all traffic to H61, and then per Rule 5.5, 2001:db8:0:b020::41 would be selected as a source address.
ただし、デフォルトの送信元アドレス選択アルゴリズム（セクション6.1で説明）のルール5.5は、デフォルトのルーター設定（[RFC4191]で指定）とRIOとともに、以下で説明するようにホスト上の送信元アドレス選択に影響を与えるために使用できます。ホストH41での送信元アドレスの選択を見てみましょう。 2001：db8：0：a020 :: / 64および2001：db8：0：b020 :: / 64のPIOを持つR3からRAを受信します。その時点で、すべてのトラフィックは同じネクストホップ（R3リンクローカルアドレス）を使用するため、ルール5.5は適用されません。次に、R3がSADRをサポートし、2つのスコープ付き転送テーブルがあり、1つはS = 2001：db8：0：a000 :: / 52にスコープし、もう1つはS = 2001：db8：0：b000 :: / 52にスコープしていると仮定します。 R3がH41に面するインターフェース用に2つの異なるリンクローカルアドレスを生成する場合（スコープ付き転送テーブル、LLA_AおよびLLA_Bごとに1つ）、R3は2つの異なるRAを送信します。 ：/ 64、および2001：db8：0：b020 :: / 64のPIOを含むLLA_Bからのもう1つ。 RAでデフォルトのルータープリファレンスを設定することにより、デフォルトルートをたどる宛先のH41ソースアドレス選択に影響を与えることができるようになりました。 H41がISP-Aを介してH101（またはインターネットの任意の宛先）に到達することが望ましい場合、LLA_Aから送信されたRAはデフォルトのルーター優先順位を01（高優先度）に設定し、LLA_Bから送信されたRAは優先順位セットを設定する必要があります。 〜11（低）。次に、LLA_AがH101のネクストホップとして選択されるため、（ルール5.5に従って）2001：db8：0：a020 :: 41がソースアドレスとして選択されます。同時に、ISP-Bを介してH61にアクセスできることが望ましい場合、R3は、LLA_Bから送信されたRAに2001：db8：0：6666 :: / 64のRIOを含める必要があります。 H41はLLA_BをH61へのすべてのトラフィックのネクストホップとして選択し、ルール5.5に従って2001：db8：0：b020 :: 41がソースアドレスとして選択されます。
If in the above-mentioned scenario it is desirable that all Internet traffic leaves the network via ISP-A, and the link to ISP-B is used for accessing ISP-B services only (not as an ISP-A link backup), then RAs sent by R3 from LLA_B should have their Router Lifetime values set to zero and should include RIOs for ISP-B address space. It would instruct H41 to use LLA_A for all Internet traffic but to use LLA_B as a next-hop while sending traffic to ISP-B addresses.
上記のシナリオで、すべてのインターネットトラフィックがISP-A経由でネットワークを離れ、ISP-BへのリンクがISP-Bサービスへのアクセスのみに使用される場合（ISP-Aリンクバックアップとしてではない）、次にLLA_BからR3によって送信されたRAは、ルーターのライフタイム値をゼロに設定し、ISP-Bアドレス空間のRIOを含める必要があります。これは、すべてのインターネットトラフィックにLLA_Aを使用し、トラフィックをISP-Bアドレスに送信するときにLLA_Bをネクストホップとして使用するようにH41に指示します。
The description of the mechanism above assumes SADR support by the first-hop routers as well as SERs. However, a first-hop router can still provide a less flexible version of this mechanism even without implementing SADR. This could be done by providing configuration knobs on the first-hop router that allow it to generate different link-local addresses and to send individual RAs for each prefix.
上記のメカニズムの説明では、ファーストホップルーターとSERによるSADRサポートを前提としています。ただし、ファーストホップルーターは、SADRを実装しなくても、このメカニズムの柔軟性の低いバージョンを提供できます。これは、最初のホップのルーターに、異なるリンクローカルアドレスを生成し、プレフィックスごとに個別のRAを送信できるようにする構成ノブを提供することで実行できます。
The mechanism described above relies on Rule 5.5 of the default source address selection algorithm defined in [RFC6724]. [RFC8028] states that "A host SHOULD select default routers for each prefix it is assigned an address in." It also recommends that hosts should implement Rule 5.5. of [RFC6724]. Hosts following the recommendations specified in [RFC8028] therefore should be able to benefit from the solution described in this document. No standards need to be updated in regards to host behavior.
上記のメカニズムは、[RFC6724]で定義されているデフォルトの送信元アドレス選択アルゴリズムのルール5.5に依存しています。 [RFC8028]は、「ホストは、アドレスが割り当てられているプレフィックスごとにデフォルトルーターを選択する必要がある（SHOULD）」と述べています。また、ホストがルール5.5を実装することを推奨します。 [RFC6724]の。したがって、[RFC8028]で指定された推奨事項に従うホストは、このドキュメントで説明されているソリューションから利益を得ることができるはずです。ホストの動作に関して標準を更新する必要はありません。
We now discuss how one might use ICMPv6 to implement the routing policy to send traffic destined for H101 out the uplink to ISP-A, even when uplinks to both ISPs are working. If H31 started sending traffic to H101 with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, it would be routed through SER-b1 and out the uplink to ISP-B. SERb1 could recognize that this traffic is not following the desired routing policy and react by sending an ICMPv6 message back to H31.
次に、両方のISPへのアップリンクが機能している場合でも、ICMPv6を使用してルーティングポリシーを実装し、H101宛てのトラフィックをアップリンクからISP-Aに送信する方法について説明します。 H31がS = 2001：db8：0：b010 :: 31およびD = 2001：db8：0：1234 :: 101でトラフィックをH101に送信し始めた場合、SER-b1を介してルーティングされ、アップリンクからISP-Bに送信されます。 。 SERb1は、このトラフィックが目的のルーティングポリシーに従っていないことを認識し、ICMPv6メッセージをH31に送信することで対応できます。
In this example, we could arrange things so that SERb1 drops the packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and then sends to H31 an ICMPv6 Destination Unreachable message with Code 5 (Source address failed ingress/egress policy). When H31 receives this packet, it would then be expected to try another source address to reach the destination. In this example, H31 would then send a packet with S=2001:db8:0:a010::31 and D=2001:db8:0:1234::101, which will reach SERa and be forwarded out the uplink to ISP-A.
この例では、SERb1がS = 2001：db8：0：b010 :: 31およびD = 2001：db8：0：1234 :: 101のパケットをドロップし、ICMPv6宛先到達不能をH31に送信するように配置できます。コード5のメッセージ（送信元アドレスが入力/出力ポリシーに失敗しました）。 H31がこのパケットを受信すると、宛先に到達するために別の送信元アドレスを試すことが期待されます。この例では、H31はS = 2001：db8：0：a010 :: 31およびD = 2001：db8：0：1234 :: 101のパケットを送信し、SERaに到達してアップリンクからISP-に転送されます。 A.
However, we would also want it to be the case that SERb1 does not enforce this routing policy when the uplink from SERa to ISP-A has failed. This could be accomplished by having SERa originate a source-prefix-scoped route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64), and have SERb1 monitor the presence of that route. If that route is not present (because SERa has stopped originating it), then SERb1 will not enforce the routing policy, and it will forward packets with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101 out its uplink to ISP-B.
ただし、SERaからISP-Aへのアップリンクが失敗したときに、SERb1がこのルーティングポリシーを適用しない場合も同様です。これは、SERaが（S = 2001：db8：0：a000 :: / 52、D = 2001：db8：0：1234 :: / 64）のソースプレフィックススコープのルートを発信し、SERb1モニターを使用することで実現できます。そのルートの存在。そのルートが存在しない場合（SERaがルートの作成を停止したため）、SERb1はルーティングポリシーを適用せず、S = 2001：db8：0：b010 :: 31およびD = 2001：db8：0のパケットを転送します。 ：1234 :: 101がアップリンクからISP-Bに送信されます。
We can also use this source-prefix-scoped route originated by SERa to communicate the desired routing policy to SERb1. We can define an EXCLUSIVE flag to be advertised together with the IGP route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This would allow SERa to communicate to SERb that SERb should reject traffic for D=2001:db8:0:1234::/64 and respond with an ICMPv6 Destination Unreachable Code 5 message, as long as the route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. The definition of an EXCLUSIVE flag for SADR advertisements in IGPs would require future standardization work.
また、SERaから発信されたこのソースプレフィックススコープのルートを使用して、目的のルーティングポリシーをSERb1に伝達することもできます。 （S = 2001：db8：0：a000 :: / 52、D = 2001：db8：0：1234 :: / 64）のIGPルートと共にアドバタイズされるEXCLUSIVEフラグを定義できます。これにより、SERaはSERbと通信し、SERbはD = 2001：db8：0：1234 :: / 64のトラフィックを拒否し、（S = 2001：db8のルートである限り）ICMPv6宛先到達不能コード5メッセージで応答する必要があります：0：a000 :: / 52、D = 2001：db8：0：1234 :: / 64）が存在します。 IGPでのSADRアドバタイズメントのEXCLUSIVEフラグの定義には、将来の標準化作業が必要になります。
Finally, if we are willing to extend ICMPv6 to support this solution, then we could create a mechanism for SERb1 to tell the host which source address it should be using to successfully forward packets that meet the policy. In its current form, when SERb1 sends an ICMPv6 Destination Unreachable Code 5 message, it is basically saying, "This source address is wrong. Try another source address." In the absence of a clear indication which address to try next, the host will iterate over all addresses assigned to the interface (e.g., various privacy addresses), which would lead to significant delays and degraded user experience. It would be better if the ICMPv6 message could say, "This source address is wrong. Instead use a source address in S=2001:db8:0:a000::/52".
最後に、ICMPv6を拡張してこのソリューションをサポートする場合は、SERb1のメカニズムを作成して、ポリシーを満たすパケットを正常に転送するために使用する送信元アドレスをホストに通知することができます。現在の形式では、SERb1がICMPv6 Destination Unreachable Code 5メッセージを送信するとき、基本的には「このソースアドレスは間違っています。別のソースアドレスを試してください」と言っています。次に試行するアドレスが明確に示されていない場合、ホストはインターフェースに割り当てられたすべてのアドレス（たとえば、さまざまなプライバシーアドレス）を反復します。これにより、大幅な遅延が発生し、ユーザーエクスペリエンスが低下します。 ICMPv6メッセージで「この送信元アドレスは間違っています。代わりにS = 2001：db8：0：a000 :: / 52の送信元アドレスを使用してください」と言ったほうがよいでしょう。
However, using ICMPv6 for signaling source address information back to hosts introduces new challenges. Most routers currently have software or hardware limits on generating ICMP messages. A site administrator deploying a solution that relies on the SERs generating ICMP messages could try to improve the performance of SERs for generating ICMP messages. However, in a large network, it is still likely that ICMP message generation limits will be reached. As a result, hosts would not receive ICMPv6 back, which in turn leads to traffic blackholing and poor user experience. To improve the scalability of ICMPv6-based signaling, hosts SHOULD cache the preferred source address (or prefix) for the given destination (which in turn might cause issues in the case of the corresponding ISP uplink failure - see Section 6.3). In addition, the same source prefix SHOULD be used for other destinations in the same /64 as the original destination address. The source prefix to the destination mapping SHOULD have a specific lifetime. Expiration of the lifetime SHOULD trigger the source address selection algorithm again.
ただし、送信元アドレス情報をホストにシグナリングするためにICMPv6を使用すると、新しい課題が生じます。現在、ほとんどのルーターには、ICMPメッセージの生成に関するソフトウェアまたはハードウェアの制限があります。 ICMPメッセージを生成するSERに依存するソリューションを展開するサイト管理者は、ICMPメッセージを生成するためのSERのパフォーマンスを改善しようとする可能性があります。ただし、大規模なネットワークでは、ICMPメッセージ生成の制限に達する可能性があります。その結果、ホストはICMPv6を受信しないため、トラフィックがブラックホール化し、ユーザーエクスペリエンスが低下します。 ICMPv6ベースのシグナリングのスケーラビリティを向上させるために、ホストは指定された宛先の優先送信元アドレス（またはプレフィックス）をキャッシュする必要があります（対応するISPアップリンク障害の場合に問題が発生する可能性があります-6.3を参照）。さらに、元の宛先アドレスと同じ/ 64の他の宛先には、同じソースプレフィックスを使用する必要があります（SHOULD）。送信元プレフィックスから送信先へのマッピングには、特定の有効期間が必要です（SHOULD）。ライフタイムの満了は、送信元アドレス選択アルゴリズムを再度トリガーする必要があります（SHOULD）。
Using ICMPv6 Destination Unreachable Messages with Code 5 to influence source address selection introduces some security challenges, which are discussed in Section 10.
コード5でICMPv6宛先到達不能メッセージを使用して送信元アドレスの選択に影響を与えると、セキュリティ上の課題が生じます。これについては、セクション10で説明します。
As currently standardized in [RFC4443], the ICMPv6 Destination Unreachable Message with Code 5 would allow for the iterative approach to retransmitting packets using different source addresses. As currently defined, the ICMPv6 message does not provide a mechanism to communicate information about which source prefix should be used for a retransmitted packet. The current document does not define such a mechanism, but it might be a useful extension to define in a different document. However, this approach has some security implications, such as an ability for an attacker to send spoofed ICMPv6 messages to signal an invalid/unreachable source prefix, causing a DoS-type attack.
[RFC4443]で現在標準化されているように、コード5のICMPv6宛先到達不能メッセージは、異なる送信元アドレスを使用してパケットを再送信する反復アプローチを可能にします。現在定義されているように、ICMPv6メッセージは、再送信されたパケットにどのソースプレフィックスを使用する必要があるかに関する情報を伝達するメカニズムを提供しません。現在のドキュメントはそのようなメカニズムを定義していませんが、別のドキュメントで定義するのに役立つ拡張機能かもしれません。ただし、このアプローチには、攻撃者がスプーフィングされたICMPv6メッセージを送信して無効または到達不可能なソースプレフィックスを信号で送信し、DoSタイプの攻撃を引き起こすなど、セキュリティ上の影響があります。
6.2.4. Summary of Methods for Controlling Default Source Address Selection to Implement Routing Policy
6.2.4. ルーティングポリシーを実装するためのデフォルトの送信元アドレス選択を制御する方法の概要
So to summarize this section, we have looked at three methods for implementing a simple routing policy where all traffic for a given destination on the Internet needs to use a particular ISP, even when the uplinks to both ISPs are working.
したがって、このセクションを要約するために、両方のISPへのアップリンクが機能している場合でも、インターネット上の特定の宛先のすべてのトラフィックが特定のISPを使用する必要がある単純なルーティングポリシーを実装する3つの方法を検討しました。
The default source address selection policy cannot distinguish between the source addresses needed to enforce this policy, so a non-default policy table using associating source and destination prefixes using label values would need to be installed on each host. A mechanism exists for DHCPv6 to distribute a non-default policy table, but such solution would heavily rely on DHCPv6 support by the host operating system. Moreover, there is no mechanism to translate desired routing/traffic engineering policies into policy tables on DHCPv6 servers. Therefore using DHCPv6 for controlling the address selection policy table is not recommended and SHOULD NOT be used.
デフォルトの送信元アドレス選択ポリシーでは、このポリシーを適用するために必要な送信元アドレスを区別できないため、ラベル値を使用して送信元プレフィックスと宛先プレフィックスを関連付けるデフォルト以外のポリシーテーブルを各ホストにインストールする必要があります。 DHCPv6がデフォルト以外のポリシーテーブルを配布するためのメカニズムは存在しますが、そのようなソリューションはホストオペレーティングシステムによるDHCPv6サポートに大きく依存します。さらに、望ましいルーティング/トラフィックエンジニアリングポリシーをDHCPv6サーバー上のポリシーテーブルに変換するメカニズムはありません。したがって、アドレス選択ポリシーテーブルの制御にDHCPv6を使用することはお勧めできません。使用しないでください。
At the same time, Router Advertisements provide a reliable mechanism to influence the source address selection process via PIO, RIO, and default router preferences. As all those options have been standardized by the IETF and are supported by various operating systems, no changes are required on hosts. First-hop routers in the enterprise network need to be capable of sending different RAs for different SLAAC prefixes (either based on scoped forwarding tables or based on preconfigured policies).
同時に、ルーターアドバタイズメントは、PIO、RIO、およびデフォルトのルーター設定を介してソースアドレス選択プロセスに影響を与える信頼できるメカニズムを提供します。これらのオプションはすべてIETFによって標準化されており、さまざまなオペレーティングシステムでサポートされているため、ホストでの変更は必要ありません。エンタープライズネットワークのファーストホップルーターは、（スコープ指定された転送テーブルまたは事前構成されたポリシーに基づいて）異なるSLAACプレフィックスに対して異なるRAを送信できる必要があります。
SERs can enforce the routing policy by sending ICMPv6 Destination Unreachable messages with Code 5 (Source address failed ingress/ egress policy) for traffic sent with the wrong source address. The policy distribution could be automated by defining an EXCLUSIVE flag for the source-prefix-scoped route, which could then be set on the SER that originates the route. As ICMPv6 message generation can be rate limited on routers, it SHOULD NOT be used as the only mechanism to influence source address selection on hosts. While hosts SHOULD select the correct source address for a given destination, the network SHOULD signal any source address issues back to hosts using ICMPv6 error messages.
SERは、不正な送信元アドレスで送信されたトラフィックに対して、コード5（送信元アドレスが失敗した入力/出力ポリシー）のICMPv6宛先到達不能メッセージを送信することにより、ルーティングポリシーを適用できます。 source-prefix-scopedルートのEXCLUSIVEフラグを定義することにより、ポリシーの配布を自動化できます。これは、ルートを発信するSERで設定できます。 ICMPv6メッセージ生成はルーターでレート制限される可能性があるため、ホストでのソースアドレス選択に影響を与える唯一のメカニズムとして使用すべきではありません（SHOULD NOT）。ホストは与えられた宛先に対して正しい送信元アドレスを選択する必要があります（SHOULD）が、ネットワークはICMPv6エラーメッセージを使用して送信元アドレスの問題をホストに通知する必要があります（SHOULD）。
Now we discuss whether DHCPv6, Neighbor Discovery Router Advertisements, and ICMPv6 can help a host choose the right source address when an uplink to one of the ISPs has failed. Again we look at the scenario in Figure 3. This time we look at traffic from H31 destined for external host H501 at D=2001:db8:0:5678::501. We initially assume that the uplink from SERa to ISP-A is working and that the uplink from SERb1 to ISP-B is working.
次に、DHCPv6、近隣探索ルーターアドバタイズメント、およびICMPv6が、ISPの1つへのアップリンクが失敗したときにホストが正しい送信元アドレスを選択できるようにするかどうかについて説明します。再び図3のシナリオを見てみましょう。今度は、D = 2001：db8：0：5678 :: 501の外部ホストH501を宛先とするH31からのトラフィックを調べます。最初に、SERaからISP-Aへのアップリンクが機能し、SERb1からISP-Bへのアップリンクが機能していると想定します。
We assume there is no particular routing policy desired, so H31 is free to send packets with S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 and have them delivered to H501. For this example, we assume that H31 has chosen S=2001:db8:0:b010::31 so that the packets exit via SERb to ISP-B. Now we see what happens when the link from SERb1 to ISP-B fails. How should H31 learn that it needs to start sending packets to H501 with S=2001:db8:0:a010::31 in order to start using the uplink to ISP-A? We need to do this in a way that doesn't prevent H31 from still sending packets with S=2001:db8:0:b010::31 in order to reach H61 at D=2001:db8:0:6666::61.
特定のルーティングポリシーは必要ないため、H31はS = 2001：db8：0：a010 :: 31またはS = 2001：db8：0：b010 :: 31のパケットを自由に送信し、H501に配信できます。この例では、H31がS = 2001：db8：0：b010 :: 31を選択し、パケットがSERb経由でISP-Bに送信されると想定しています。これで、SERb1からISP-Bへのリンクが失敗したときに何が起こるかがわかります。 H31は、ISP-Aへのアップリンクの使用を開始するために、S = 2001：db8：0：a010 :: 31でH501へのパケットの送信を開始する必要があることをどのように知る必要がありますか？ D = 2001：db8：0：6666 :: 61でH61に到達するために、H31がS = 2001：db8：0：b010 :: 31のパケットを送信することを妨げない方法でこれを行う必要があります。
For this example, we assume that the site network in Figure 3 has a centralized DHCP server and that all routers act as DHCP relay agents. We assume that both of the addresses assigned to H31 were assigned via DHCP.
この例では、図3のサイトネットワークに一元化されたDHCPサーバーがあり、すべてのルーターがDHCPリレーエージェントとして機能することを前提としています。 H31に割り当てられたアドレスは両方ともDHCP経由で割り当てられたと想定しています。
We could try to have the DHCP server monitor the state of the uplink from SERb1 to ISP-B in some manner and then tell H31 that it can no longer use S=2001:db8:0:b010::31 by setting its valid lifetime to zero. The DHCP server could initiate this process by sending a Reconfigure message to H31 as described in Section 18.3 of [RFC8415]. Or the DHCP server can assign addresses with short lifetimes in order to force clients to renew them often.
DHCPサーバーに何らかの方法でSERb1からISP-Bへのアップリンクの状態を監視させ、有効期間を設定することにより、H31にS = 2001：db8：0：b010 :: 31を使用できなくなったことを通知することができます。ゼロに。 [RFC8415]のセクション18.3で説明されているように、DHCPサーバーはH31に再構成メッセージを送信することでこのプロセスを開始できます。または、DHCPサーバーは、クライアントに頻繁にアドレスを更新させるために、有効期間が短いアドレスを割り当てることができます。
This approach would prevent H31 from using S=2001:db8:0:b010::31 to reach a host on the Internet. However, it would also prevent H31 from using S=2001:db8:0:b010::31 to reach H61 at D=2001:db8:0:6666::61, which is not desirable.
このアプローチは、H31がS = 2001：db8：0：b010 :: 31を使用してインターネット上のホストに到達するのを防ぎます。ただし、これは、H31がS = 2001：db8：0：b010 :: 31を使用してD = 2001：db8：0：6666 :: 61でH61に到達することも防止するため、望ましくありません。
Another potential approach is to have the DHCP server monitor the uplink from SERb1 to ISP-B and control the choice of source address on H31 by updating its address selection policy table via the mechanism in [RFC7078]. The DHCP server could initiate this process by sending a Reconfigure message to H31. Note that [RFC8415] requires that Reconfigure messages use DHCP authentication. DHCP authentication could be avoided by using short address lifetimes to force clients to send Renew messages to the server often. If the host does not obtain its IP addresses from the DHCP server, then it would need to use the Information Refresh Time option defined in [RFC8415].
別の潜在的なアプローチは、DHCPサーバーにSERb1からISP-Bへのアップリンクを監視させ、[RFC7078]のメカニズムを介してアドレス選択ポリシーテーブルを更新することにより、H31上のソースアドレスの選択を制御することです。 DHCPサーバーは、H31に再構成メッセージを送信することにより、このプロセスを開始できます。 [RFC8415]では、ReconfigureメッセージがDHCP認証を使用する必要があることに注意してください。 DHCP認証は、短いアドレスライフタイムを使用してクライアントにサーバーに更新メッセージを頻繁に送信させることで回避できます。ホストがDHCPサーバーからIPアドレスを取得しない場合、[RFC8415]で定義されている情報更新時間オプションを使用する必要があります。
If the following policy table can be installed on H31 after the failure of the uplink from SERb1, then the desired routing behavior should be achieved based on source and destination prefix being matched with label values.
SERb1からのアップリンクに障害が発生した後、次のポリシーテーブルをH31にインストールできる場合、送信元と宛先のプレフィックスがラベル値と一致することに基づいて、望ましいルーティング動作を実現する必要があります。
Prefix Precedence Label
::/0 50 44
2001:db8:0:a000::/52 50 44
2001:db8:0:6666::/64 50 55
2001:db8:0:b000::/52 50 55
Figure 10: Policy Table Needed on Failure of Uplink from SERb1
図10：SERb1からのアップリンクの障害時に必要なポリシーテーブル
The described solution has a number of significant drawbacks, some of them already discussed in Section 6.2.1.
説明されているソリューションには、いくつかの重大な欠点があり、そのうちのいくつかはセクション6.2.1ですでに説明されています。
* DHCPv6 support is not required for an IPv6 host, and there are operating systems that do not support DHCPv6. Besides that, it does not appear that [RFC7078] has been widely implemented on host operating systems.
* IPv6ホストにはDHCPv6サポートは必要ありません。DHCPv6をサポートしないオペレーティングシステムがあります。さらに、[RFC7078]がホストオペレーティングシステムに広く実装されているようには見えません。
* [RFC7078] does not clearly specify this kind of a dynamic use case in which the address selection policy needs to be updated quickly in response to the failure of a link. In a large network, it would present scalability issues as many hosts need to be reconfigured in a very short period of time.
* [RFC7078]は、リンクの障害に応答してアドレス選択ポリシーを迅速に更新する必要があるこの種の動的な使用例を明確に指定していません。大規模なネットワークでは、非常に短い時間で多くのホストを再構成する必要があるため、スケーラビリティの問題が発生します。
* Updating DHCPv6 server configuration each time an ISP's uplink changes its state introduces some scalability issues, especially for mid/large distributed-scale enterprise networks. In addition to that, the policy table needs to be manually configured by administrators, which makes that solution prone to human error.
* ISPのアップリンクの状態が変化するたびにDHCPv6サーバー構成を更新すると、特に中規模/大規模の分散規模エンタープライズネットワークでは、スケーラビリティの問題が発生します。それに加えて、ポリシーテーブルは管理者が手動で構成する必要があるため、そのソリューションでは人的ミスが発生しやすくなります。
* No mechanism exists for making DHCPv6 servers aware of network topology/routing changes in the network. In general, having DHCPv6 servers monitor network-related events sounds like a bad idea as it requires completely new functionality beyond the scope of the DHCPv6 role.
* DHCPv6サーバーにネットワークトポロジ/ネットワーク内のルーティングの変更を認識させるメカニズムはありません。一般に、DHCPv6サーバーにネットワーク関連のイベントを監視させることは、DHCPv6の役割の範囲を超えた完全に新しい機能を必要とするため、悪い考えのように思えます。
6.3.2. Controlling Default Source Address Selection with Router Advertisements
6.3.2. ルータアドバタイズメントによるデフォルトの送信元アドレス選択の制御
The same mechanism as discussed in Section 6.2.2 can be used to control the source address selection in the case of an uplink failure. If a particular prefix should not be used as a source for any destination, then the router needs to send an RA with the Preferred Lifetime field for that prefix set to zero.
セクション6.2.2で説明したのと同じメカニズムを使用して、アップリンク障害が発生した場合の送信元アドレスの選択を制御できます。特定のプレフィックスを宛先のソースとして使用しない場合、ルーターはそのプレフィックスの優先ライフタイムフィールドをゼロに設定してRAを送信する必要があります。
Let's consider a scenario in which all uplinks are operational, and H41 receives two different RAs from R3: one from LLA_A with a PIO for 2001:db8:0:a020::/64 and the default router preference set to 11 (low), and another one from LLA_B with a PIO for 2001:db8:0:a020::/64, the default router preference set to 01 (high), and a RIO for 2001:db8:0:6666::/64. As a result, H41 uses 2001:db8:0:b020::41 as a source address for all Internet traffic, and those packets are sent by SERs to ISP-B. If SERb1's uplink to ISP-B fails, the desired behavior is that H41 stops using 2001:db8:0:b020::41 as a source address for all destinations but H61. To achieve that, R3 should react to SERb1's uplink failure (which could be detected as the disappearance of scoped route (S=2001:db8:0:b000::/52, D=::/0)) by withdrawing itself as a default router. R3 sends a new RA from LLA_B with the Router Lifetime value set to zero (which means that it should not be used as the default router). That RA still contains a PIO for 2001:db8:0:b020::/64 (for SLAAC purposes) and a RIO for 2001:db8:0:6666::/64 so that H41 can reach H61 using LLA_B as a next-hop and 2001:db8:0:b020::41 as a source address. For all traffic following the default route, LLA_A will be used as a next-hop and 2001:db8:0:a020::41 as a source address.
すべてのアップリンクが動作しており、H41がR3から2つの異なるRAを受信するシナリオを考えてみましょう。1つはLLA_Aから、2001：db8：0：a020 :: / 64のPIOとデフォルトのルーター設定は11（低）に設定されています。そして、2001：db8：0：a020 :: / 64のPIO、デフォルトのルーター設定が01（高）、および2001：db8：0：6666 :: / 64のRIOを持つLLA_Bからのもう1つ。その結果、H41はすべてのインターネットトラフィックのソースアドレスとして2001：db8：0：b020 :: 41を使用し、これらのパケットはSERによってISP-Bに送信されます。 ISP-BへのSERb1のアップリンクが失敗した場合、望ましい動作は、H41が2001：db8：0：b020 :: 41をH61以外のすべての宛先のソースアドレスとして使用を停止することです。これを実現するには、R3をSERb1のアップリンク障害（スコープ付きルート（S = 2001：db8：0：b000 :: / 52、D = :: / 0）の消失として検出される可能性があります）に自身をデフォルトルーター。 R3は、ルーターライフタイム値をゼロに設定して（デフォルトのルーターとして使用しないでください）、LLA_Bから新しいRAを送信します。そのRAには、2001：db8：0：b020 :: / 64（SLAACの目的）のPIOと2001：db8：0：6666 :: / 64のRIOがまだ含まれているため、H41はLLA_Bを使用してH61に到達できます。ホップおよび2001：db8：0：b020 :: 41をソースアドレスとして。デフォルトルートに続くすべてのトラフィックでは、LLA_Aがネクストホップとして使用され、2001：db8：0：a020 :: 41が送信元アドレスとして使用されます。
If all of the uplinks to ISP-B have failed, source addresses from ISP-B address space should not be used. In such a failure scenario, the forwarding table scoped S=2001:db8:0:b000::/52 contains no entries, indicating that R3 can instruct hosts to stop using source addresses from 2001:db8:0:b000::/52 by sending RAs containing PIOs with Preferred Lifetime values set to zero.
ISP-Bへのすべてのアップリンクに障害が発生した場合、ISP-Bアドレス空間からのソースアドレスは使用しないでください。このような障害シナリオでは、スコープがS = 2001：db8：0：b000 :: / 52の転送テーブルにエントリが含まれておらず、R3がホストに2001：db8：0：b000 :: / 52からのソースアドレスの使用を停止するように指示できることを示しています。 Preferred Lifetime値がゼロに設定されたPIOを含むRAを送信する。
Now we look at how ICMPv6 messages can provide information back to H31. We assume again that, at the time of the failure, H31 is sending packets to H501 using (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501). When the uplink from SERb1 to ISP-B fails, SERb1 would stop originating its source-prefix-scoped route for the default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its unscoped default destination route. With these routes no longer in the IGP, traffic with (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501) would end up at SERa based on the unscoped default destination route being originated by SERa. Since that traffic has the wrong source address to be forwarded to ISP-A, SERa would drop it and send a Destination Unreachable message with Code 5 (Source address failed ingress/egress policy) back to H31. H31 would then know to use another source address for that destination and would try with (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This would be forwarded to SERa based on the source-prefix-scoped default destination route still being originated by SERa, and SERa would forward it to ISP-A. As discussed above, if we are willing to extend ICMPv6, SERa can even tell H31 what source address it should use to reach that destination. The expected host behavior has been discussed in Section 6.2.3. Using ICMPv6 would have the same scalability/rate limiting issues that are discussed in Section 6.2.3. An ISP-B uplink failure immediately makes source addresses from 2001:db8:0:b000::/52 unsuitable for external communication and might trigger a large number of ICMPv6 packets being sent to hosts in that subnet.
ここで、ICMPv6メッセージがH31に情報を返す方法を見てみましょう。ここでも、障害発生時に、H31は（S = 2001：db8：0：b010 :: 31、D = 2001：db8：0：5678 :: 501）を使用してH501にパケットを送信していると想定します。 SERb1からISP-Bへのアップリンクが失敗すると、SERb1はデフォルトの宛先（S = 2001：db8：0：b000 :: / 52、D = :: / 0）のソースプレフィックススコープのルートの発信も停止します対象範囲外のデフォルトの宛先ルートとして。これらのルートがIGPに存在しない場合、（S = 2001：db8：0：b010 :: 31、D = 2001：db8：0：5678 :: 501）のトラフィックは、対象範囲外のデフォルトの宛先ルートに基づいてSERaで終了しますSERaによって作成されました。そのトラフィックはISP-Aに転送される間違ったソースアドレスを持っているので、SERaはそれをドロップし、コード5（ソースアドレスが失敗した入力/出力ポリシー）の宛先到達不能メッセージをH31に送り返します。次に、H31はその宛先に別のソースアドレスを使用することを認識し、（S = 2001：db8：0：a010 :: 31、D = 2001：db8：0：5678 :: 501）で試行します。これは、まだSERaによって発信されているsource-prefixスコープのデフォルトの宛先ルートに基づいてSERaに転送され、SERaはそれをISP-Aに転送します。上記で説明したように、ICMPv6を拡張する用意がある場合、SERaはH31に、その宛先に到達するために使用する必要がある送信元アドレスを通知することもできます。予想されるホストの動作については、セクション6.2.3で説明しています。 ICMPv6を使用すると、セクション6.2.3で説明したスケーラビリティ/レート制限の問題と同じになります。 ISP-Bアップリンク障害が発生すると、2001：db8：0：b000 :: / 52からの送信元アドレスが外部通信に不適切になり、そのサブネット内のホストに送信される多数のICMPv6パケットがトリガーされる可能性があります。
6.3.4. Summary of Methods for Controlling Default Source Address Selection on the Failure of an Uplink
6.3.4. アップリンクの障害時にデフォルトの送信元アドレス選択を制御する方法の要約
It appears that DHCPv6 is not particularly well suited to quickly changing the source address used by a host when an uplink fails, which eliminates DHCPv6 from the list of potential solutions. On the other hand, Router Advertisements provide a reliable mechanism to dynamically provide hosts with a list of valid prefixes to use as source addresses as well as to prevent the use of particular prefixes. While no additional new features are required to be implemented on hosts, routers need to be able to send RAs based on the state of scoped forwarding table entries and to react to network topology changes by sending RAs with particular parameters set.
DHCPv6は、アップリンクに障害が発生したときにホストが使用する送信元アドレスをすばやく変更するのに特に適していないと思われます。これにより、DHCPv6が潜在的なソリューションのリストから削除されます。一方、ルーターアドバタイズは、送信元アドレスとして使用する有効なプレフィックスのリストを動的にホストに提供し、特定のプレフィックスの使用を防止するための信頼できるメカニズムを提供します。ホストに追加の新機能を実装する必要はありませんが、ルーターは、スコープ指定された転送テーブルエントリの状態に基づいてRAを送信し、特定のパラメータセットを使用してRAを送信することにより、ネットワークトポロジの変更に対応できる必要があります。
It seems that the use of ICMPv6 Destination Unreachable messages generated by the SER (or any SADR-capable) routers, together with the use of RAs to signal source address selection errors back to hosts, has the potential to provide a support mechanism. However, scalability issues may arise in large networks when topology suddenly changes. Therefore, it is highly desirable that hosts are able to select the correct source address in the case of uplink failure, with ICMPv6 being an additional mechanism to signal unexpected failures back to hosts.
SER（またはSADR対応）ルーターによって生成されたICMPv6 Destination Unreachableメッセージを使用し、RAを使用して送信元アドレス選択エラーをホストに通知すると、サポートメカニズムが提供される可能性があるようです。ただし、トポロジが突然変化すると、大規模なネットワークでスケーラビリティの問題が発生する可能性があります。したがって、アップリンク障害が発生した場合にホストが正しい送信元アドレスを選択できることが強く望まれます。ICMPv6は、予期しない障害をホストに通知する追加のメカニズムです。
The current behaviors of different host operating systems upon receipt of an ICMPv6 Destination Unreachable message with Code 5 (Source address failed ingress/egress policy) is not clear to the authors. Information from implementers, users, and testing would be quite helpful in evaluating this approach.
ICMPv6 Destination Unreachableメッセージとコード5（送信元アドレスの失敗した入力/出力ポリシー）を受信したときのさまざまなホストオペレーティングシステムの現在の動作は、作成者には明らかではありません。実装者、ユーザー、およびテストからの情報は、このアプローチの評価に非常に役立ちます。
The next logical step is to look at the scenario when a failed uplink on SERb1 to ISP-B comes back up, so the hosts can start using source addresses belonging to 2001:db8:0:b000::/52 again.
次の論理的な手順は、SERb1でISP-Bへの失敗したアップリンクが復旧した場合のシナリオを確認することです。これにより、ホストは2001：db8：0：b000 :: / 52に属するソースアドレスを再び使用できるようになります。
The mechanism to use DHCPv6 to instruct the hosts (H31 in our example) to start using prefixes from ISP-B space (e.g., S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is quite similar to one discussed in Section 6.3.1 and shares the same drawbacks.
DHCPv6を使用してホスト（この例ではH31）にISP-Bスペースからのプレフィックス（たとえば、H31の場合はS = 2001：db8：0：b010 :: 31）を使用してインターネット上のホストに到達するように指示するメカニズムは、かなりセクション6.3.1で説明したものと同様であり、同じ欠点を共有します。
6.4.2. Controlling Default Source Address Selection with Router Advertisements
6.4.2. ルータアドバタイズメントによるデフォルトの送信元アドレス選択の制御
Let's look at the scenario discussed in Section 6.3.2. If the uplink(s) failure caused the complete withdrawal of prefixes from the 2001:db8:0:b000::/52 address space by setting the Preferred Lifetime value to zero, then the recovery of the link should just trigger the sending of a new RA with a non-zero Preferred Lifetime. In another scenario discussed in Section 6.3.2, the failure of the SERb1 uplink to ISP-B leads to the disappearance of the (S=2001:db8:0:b000::/52, D=::/0) entry from the forwarding table scoped to S=2001:db8:0:b000::/52 and, in turn, causes R3 to send RAs with the Router Lifetime set to zero from LLA_B. The recovery of the SERb1 uplink to ISP-B leads to the reappearance of the scoped forwarding entry (S=2001:db8:0:b000::/52, D=::/0). That reappearance acts as a signal for R3 to advertise itself as a default router for ISP-B address space domain (to send RAs from LLA_B with non-zero Router Lifetime).
セクション6.3.2で説明したシナリオを見てみましょう。アップリンクの障害により、Preferred Lifetime値をゼロに設定することにより、2001：db8：0：b000 :: / 52アドレススペースからのプレフィックスが完全に取り消された場合、リンクの回復により、ゼロ以外の優先ライフタイムを持つ新しいRA。セクション6.3.2で説明した別のシナリオでは、ISP-BへのSERb1アップリンクの障害により、（S = 2001：db8：0：b000 :: / 52、D = :: / 0）エントリが表示されなくなります。転送テーブルのスコープはS = 2001：db8：0：b000 :: / 52になり、R3はルーターのライフタイムがLLA_Bからゼロに設定されたRAを送信します。 ISP-BへのSERb1アップリンクが回復すると、スコープ指定された転送エントリが再び表示されます（S = 2001：db8：0：b000 :: / 52、D = :: / 0）。その再出現は、R3がそれ自体をISP-Bアドレス空間ドメインのデフォルトルーターとしてアドバタイズするためのシグナルとして機能します（ゼロ以外のルーターライフタイムでLLA_BからRAを送信するため）。
It looks like ICMPv6 provides a rather limited functionality to signal back to hosts that particular source addresses have become valid again. Unless the changes in the uplink specify a particular (S,D) pair, hosts can keep using the same source address even after an ISP uplink has come back up. For example, after the uplink from SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as described in Section 6.3.3) and allegedly started using (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) to reach H501. Now when the SERb1 uplink comes back up, the packets with that (S,D) pair are still routed to SERa1 and sent to the Internet. Therefore, H31 is not informed that it should stop using 2001:db8:0:a010::31 and start using 2001:db8:0:b010::31 again. Unless SERa has a policy configured to drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and send ICMPv6 back if the SERb1 uplink to ISP-B is up, H31 will be unaware of the network topology change and keep using S=2001:db8:0:a010::31 for Internet destinations, including H51.
ICMPv6は、特定の送信元アドレスが再び有効になったことをホストに通知するかなり限定された機能を提供しているようです。アップリンクの変更で特定の（S、D）ペアが指定されていない限り、ISPアップリンクが復旧した後でも、ホストは同じ送信元アドレスを使用し続けることができます。たとえば、SERb1からISP-Bへのアップリンクが失敗した後、H31はICMPv6コード5メッセージ（セクション6.3.3で説明）を受信し、（S = 2001：db8：0：a010 :: 31、D = 2001：db8：0：5678 :: 501）H501に到達します。これで、SERb1アップリンクが復旧しても、その（S、D）ペアのパケットは引き続きSERa1にルーティングされ、インターネットに送信されます。したがって、H31は2001：db8：0：a010 :: 31の使用を停止し、2001：db8：0：b010 :: 31の使用を再開する必要があることを知らされていません。 SERaにパケットをドロップするように構成されたポリシー（S = 2001：db8：0：a010 :: 31、D = 2001：db8：0：5678 :: 501）があり、ISP-BへのSERb1アップリンクが稼働している場合にICMPv6を送信しない限り、H31はネットワークトポロジの変更を認識せず、H51を含むインターネット宛先にS = 2001：db8：0：a010 :: 31を使用し続けます。
One of the possible options may be using a scoped route with an EXCLUSIVE flag as described in Section 6.2.3. SERa1 uplink recovery would cause the (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to reappear in the routing table. In the absence of that, route packets to H101 are sent to ISP-B (as ISP-A uplink was down) with source addresses from 2001:db8:0:b000::/52. When the route reappears, SERb1 rejects those packets and sends ICMPv6 back as discussed in Section 6.2.3. Practically, it might lead to scalability issues, which have been already discussed in 6.2.3 and 6.4.3.
可能なオプションの1つは、セクション6.2.3で説明されているように、EXCLUSIVEフラグを指定したスコープ付きルートを使用することです。 SERa1アップリンク回復により、（S = 2001：db8：0：a000 :: / 52、D = 2001：db8：0：1234 :: / 64）ルートがルーティングテーブルに再表示されます。それがない場合、H101へのルートパケットは、2001：db8：0：b000 :: / 52からの送信元アドレスでISP-Bに送信されます（ISP-Aアップリンクがダウンしたため）。ルートが再び現れると、SERb1はそれらのパケットを拒否し、セクション6.2.3で説明されているようにICMPv6を送り返します。実際には、6.2.3および6.4.3ですでに説明されているスケーラビリティの問題につながる可能性があります。
6.4.4. Summary of Methods for Controlling Default Source Address Selection upon Failed Uplink Recovery
6.4.4. 失敗したアップリンク回復時のデフォルトの送信元アドレス選択を制御する方法の要約
Once again, DHCPv6 does not look like a reasonable choice to manipulate the source address selection process on a host in the case of network topology changes. Using Router Advertisement provides the flexible mechanism to dynamically react to network topology changes (if routers are able to use routing changes as a trigger for sending out RAs with specific parameters). ICMPv6 could be considered as a supporting mechanism to signal incorrect source address back to hosts, but it should not be considered as the only mechanism to control the address selection in multihomed environments.
ここでも、DHCPv6は、ネットワークトポロジが変更された場合に、ホスト上のソースアドレス選択プロセスを操作するための適切な選択のようには見えません。ルーターアドバタイズメントを使用すると、ネットワークトポロジの変更に動的に対応する柔軟なメカニズムが提供されます（ルーターがルーティングの変更を特定のパラメーターのRAを送信するトリガーとして使用できる場合）。 ICMPv6は、誤ったソースアドレスをホストに通知するサポートメカニズムと見なすことができますが、マルチホーム環境でアドレス選択を制御する唯一のメカニズムと見なすべきではありません。
One particular tricky case is a scenario when all uplinks have failed. In that case, there is no valid source address to be used for any external destinations when it might be desirable to have intra-site connectivity.
1つの特定のトリッキーなケースは、すべてのアップリンクが失敗したシナリオです。その場合、サイト内接続が必要な場合に、外部宛先に使用できる有効な送信元アドレスがありません。
From the DHCPv6 perspective, uplinks failure should be treated as two independent failures and processed as described in Section 6.3.1. At this stage, it is quite obvious that it would result in a quite complicated policy table that would need to be explicitly configured by administrators and therefore seems to be impractical.
DHCPv6の観点からは、アップリンクの障害は2つの独立した障害として扱われ、セクション6.3.1で説明されているように処理されます。この段階では、管理者が明示的に構成する必要がある非常に複雑なポリシーテーブルが作成されるため、実用的ではないように思われます。
6.5.2. Controlling Default Source Address Selection with Router Advertisements
6.5.2. ルータアドバタイズメントによるデフォルトの送信元アドレス選択の制御
As discussed in Section 6.3.2, an uplink failure causes the scoped default entry to disappear from the scoped forwarding table and triggers RAs with zero Router Lifetimes. Complete disappearance of all scoped entries for a given source prefix would cause the prefix to be withdrawn from hosts by setting the Preferred Lifetime value to zero in the PIO. If all uplinks (SERa, SERb1 and SERb2) fail, hosts either lose their default routers and/or have no global IPv6 addresses to use as a source. (Note that 'uplink failure' might mean 'IPv6 connectivity failure with IPv4 still being reachable', in which case, hosts might fall back to IPv4 if there is IPv4 connectivity to destinations). As a result, intra-site connectivity is broken. One of the possible ways to solve it is to use ULAs.
セクション6.3.2で説明したように、アップリンク障害により、スコープのデフォルトエントリがスコープの転送テーブルから消え、ルーターのライフタイムがゼロのRAがトリガーされます。特定のソースプレフィックスのすべてのスコープエントリが完全に消えると、PIOの優先ライフタイム値をゼロに設定することにより、プレフィックスがホストから削除されます。すべてのアップリンク（SERa、SERb1、およびSERb2）に障害が発生した場合、ホストはデフォルトルーターを失うか、ソースとして使用するグローバルIPv6アドレスを持たないか、あるいはその両方を持っています。 （「アップリンク障害」は、「IPv4がまだ到達可能であり、IPv6接続障害」を意味する場合があることに注意してください。この場合、宛先へのIPv4接続がある場合、ホストはIPv4にフォールバックする可能性があります）。その結果、サイト内の接続が切断されます。それを解決する可能な方法の1つはULAを使用することです。
In addition to GUAs, all hosts have ULA addresses assigned, and these addresses are used for intra-site communication even if there is no GUA assigned to a host. To avoid accidental leaking of packets with ULA sources, SADR-capable routers SHOULD have a scoped forwarding table for ULA source for internal routes but MUST NOT have an entry for D=::/0 in that table. In the absence of (S=ULA_Prefix; D=::/0), first-hop routers will send dedicated RAs from a unique link-local source LLA_ULA with a PIO from ULA address space, a RIO for the ULA prefix, and Router Lifetime set to zero. The behavior is consistent with the situation when SERb1 lost the uplink to ISP-B (so there is no Internet connectivity from 2001:db8:0:b000::/52 sources), but those sources can be used to reach some specific destinations. In the case of ULA, there is no Internet connectivity from ULA sources, but they can be used to reach other ULA destinations. Note that ULA usage could be particularly useful if all ISPs assign prefixes via DHCP prefix delegation. In the absence of ULAs, upon the failure of all uplinks, hosts would lose all their GUAs upon prefix-lifetime expiration, which again makes intra-site communication impossible.
GUAに加えて、すべてのホストにはULAアドレスが割り当てられています。これらのアドレスは、GUAがホストに割り当てられていない場合でも、サイト内通信に使用されます。 ULAソースを使用したパケットの偶発的なリークを回避するために、SADR対応ルーターは、内部ルートのULAソースのスコープ付き転送テーブルを持つ必要がありますが、そのテーブルにD = :: / 0のエントリを含めることはできません。 （S = ULA_Prefix; D = :: / 0）がない場合、ファーストホップルーターは、ULAアドレス空間からのPIO、ULAプレフィックスのRIO、およびルーターを使用して、一意のリンクローカルソースLLA_ULAから専用RAを送信しますライフタイムはゼロに設定されています。この動作は、SERb1がISP-Bへのアップリンクを失った場合と同じです（したがって、2001：db8：0：b000 :: / 52ソースからのインターネット接続はありません）。ただし、これらのソースを使用して、特定の宛先に到達できます。 ULAの場合、ULAソースからのインターネット接続はありませんが、他のULA宛先に到達するために使用できます。 ULAの使用は、すべてのISPがDHCPプレフィックス委任を介してプレフィックスを割り当てる場合に特に役立つことに注意してください。 ULAがない場合、すべてのアップリンクに障害が発生すると、ホストはプレフィックスの有効期限が切れるとすべてのGUAを失い、サイト内通信が再び不可能になります。
It should be noted that Rule 5.5 (prefer a prefix advertised by the selected next-hop) takes precedence over the Rule 6 (prefer matching label, which ensures that GUA source addresses are preferred over ULAs for GUA destinations). Therefore if ULAs are used, the network administrator needs to ensure that, while the site has Internet connectivity, hosts do not select a router that advertises ULA prefixes as their default router.
ルール5.5（選択したネクストホップでアドバタイズされるプレフィックスを優先する）はルール6（一致するラベルを優先する）に優先します。これにより、GUA送信元アドレスがGUA宛先のULAよりも優先されることが保証されます。したがって、ULAを使用する場合、ネットワーク管理者は、サイトがインターネットに接続している間、ホストがULAプレフィックスをデフォルトルーターとしてアドバタイズするルーターを選択しないようにする必要があります。
In the case of the failure of all uplinks, all SERs will drop outgoing IPv6 traffic and respond with ICMPv6 error messages. In a large network in which many hosts attempt to reach Internet destinations, the SERs need to generate an ICMPv6 error for every packet they receive from hosts, which presents the same scalability issues discussed in Section 6.3.3.
すべてのアップリンクに障害が発生した場合、すべてのSERが発信IPv6トラフィックをドロップし、ICMPv6エラーメッセージで応答します。多くのホストがインターネットの宛先に到達しようとする大規模なネットワークでは、SERは、ホストから受信するすべてのパケットに対してICMPv6エラーを生成する必要があります。これは、セクション6.3.3で説明した同じスケーラビリティの問題を示します。
6.5.4. Summary of Methods for Controlling Default Source Address Selection When All Uplinks Failed
6.5.4. すべてのアップリンクが失敗したときにデフォルトの送信元アドレス選択を制御する方法の要約
Again, combining SADR with Router Advertisements seems to be the most flexible and scalable way to control the source address selection on hosts.
繰り返しになりますが、SADRとルーターアドバタイズメントを組み合わせることは、ホスト上のソースアドレスの選択を制御する最も柔軟でスケーラブルな方法のようです。
6.6. Summary of Methods for Controlling Default Source Address Selection
6.6. デフォルトの送信元アドレス選択を制御する方法の要約
This section summarizes the scenarios and options discussed above.
このセクションでは、上記で説明したシナリオとオプションをまとめています。
While DHCPv6 allows administrators to manipulate source address selection policy tables, this method has a number of significant disadvantages that eliminate DHCPv6 from a list of potential solutions:
DHCPv6を使用すると、管理者は送信元アドレス選択ポリシーテーブルを操作できますが、この方法には、潜在的なソリューションのリストからDHCPv6を排除する多くの重大な欠点があります。
1. It requires hosts to support DHCPv6 and its extension [RFC7078].
1. DHCPv6とその拡張[RFC7078]をサポートするホストが必要です。
2. A DHCPv6 server needs to monitor network state and detect routing changes.
2. DHCPv6サーバーは、ネットワークの状態を監視し、ルーティングの変更を検出する必要があります。
3. The use of policy tables requires manual configuration and might be extremely complicated, especially in the case of a distributed network in which a large number of remote sites are being served by centralized DHCPv6 servers.
3. ポリシーテーブルを使用するには手動での構成が必要であり、特に集中型DHCPv6サーバーによって多数のリモートサイトが提供されている分散ネットワークの場合は、非常に複雑になる可能性があります。
4. Network topology/routing policy changes could trigger simultaneous reconfiguration of large number of hosts, which presents serious scalability issues.
4. ネットワークトポロジ/ルーティングポリシーの変更は、多数のホストの同時再構成をトリガーする可能性があり、深刻なスケーラビリティの問題が発生します。
The use of Router Advertisements to influence the source address selection on hosts seem to be the most reliable, flexible, and scalable solution. It has the following benefits:
ホスト上のソースアドレスの選択に影響を与えるルーターアドバタイズメントの使用は、最も信頼性が高く、柔軟で、スケーラブルなソリューションのようです。次のような利点があります。
1. No new (non-standard) functionality needs to be implemented on hosts (except for RIO support [RFC4191], which is not widely implemented at the time of this writing).
1. ホストに新しい（非標準の）機能を実装する必要はありません（RIOサポート[RFC4191]を除き、これはこの記事の執筆時点ではあまり実装されていません）。
2. No changes in RA format.
2. RA形式の変更はありません。
3. Routers can react to routing table changes by sending RAs, which would minimize the failover time in the case of network topology changes.
3. ルーターはRAを送信することでルーティングテーブルの変更に対応できます。これにより、ネットワークトポロジが変更された場合のフェイルオーバー時間が最小限になります。
4. Information required for source address selection is broadcast to all affected hosts in the case of a topology change event, which improves the scalability of the solution (compared to DHCPv6 reconfiguration or ICMPv6 error messages).
4. 送信元アドレスの選択に必要な情報は、トポロジ変更イベントの場合に影響を受けるすべてのホストにブロードキャストされ、ソリューションのスケーラビリティが向上します（DHCPv6再構成またはICMPv6エラーメッセージと比較して）。
To fully benefit from the RA-based solution, first-hop routers need to implement SADR, belong to the SADR domain, and be able to send dedicated RAs per scoped forwarding table as discussed above, reacting to network changes by sending new RAs. It should be noted that the proposed solution would work even if first-hop routers are not SADR-capable but still able to send individual RAs for each ISP prefix and react to topology changes as discussed above (e.g., via configuration knobs).
RAベースのソリューションを十分に活用するには、ファーストホップルーターはSADRを実装し、SADRドメインに属し、上記のようにスコープ指定転送テーブルごとに専用RAを送信し、新しいRAを送信することでネットワークの変更に対応できる必要があります。提案されたソリューションは、ファーストホップルーターがSADR対応ではなくても、各ISPプレフィックスの個別のRAを送信し、上記のように（構成ノブなどを介して）トポロジの変更に対応できる場合でも機能することに注意してください。
The RA-based solution relies heavily on hosts correctly implementing the default address selection algorithm as defined in [RFC6724]. While the basic, and the most common, multihoming scenario (two or more Internet uplinks, no 'walled gardens') would work for any host supporting the minimal implementation of [RFC6724], more complex use cases (such as 'walled garden' and other scenarios when some ISP resources can only be reached from that ISP address space) require that hosts support Rule 5.5 of the default address selection algorithm. There is some evidence that not all host OSes have that rule implemented currently. However, it should be noted that [RFC8028] states that Rule 5.5 should be implemented.
RAベースのソリューションは、[RFC6724]で定義されているデフォルトのアドレス選択アルゴリズムを正しく実装するホストに大きく依存しています。基本的で最も一般的なマルチホーミングシナリオ（2つ以上のインターネットアップリンク、「ウォールドガーデン」なし）は、[RFC6724]の最小限の実装、より複雑な使用例（「ウォールドガーデン」、一部のISPリソースがそのISPアドレス空間からしか到達できない他のシナリオでは、ホストがデフォルトのアドレス選択アルゴリズムのルール5.5をサポートする必要があります。現在、すべてのホストOSにそのルールが実装されているわけではないという証拠がいくつかあります。ただし、[RFC8028]には、ルール5.5を実装する必要があると記載されていることに注意してください。
The ICMPv6 Code 5 error message SHOULD be used to complement an RA-based solution to signal incorrect source address selection back to hosts, but it SHOULD NOT be considered as the standalone solution. To prevent scenarios when hosts in multihomed environments incorrectly identify on-link/off-link destinations, hosts SHOULD treat ICMPv6 Redirects as discussed in [RFC8028].
ICMPv6コード5エラーメッセージを使用して、RAベースのソリューションを補完し、不正な送信元アドレスの選択をホストに通知する必要がありますが、スタンドアロンソリューションと見なしてはいけません（SHOULD NOT）。マルチホーム環境のホストがオンリンク/オフリンクの宛先を誤って識別するシナリオを防ぐために、ホストは[RFC8028]で説明されているようにICMPv6リダイレクトを扱う必要があります（SHOULD）。
The proposed solution is not designed to preserve connection state in the case of an uplink failure. When all uplinks to an ISP go down, all transport connections established to/from that ISP address space will be interrupted (unless the transport protocol has specific multihoming support). That behavior is similar to the scenario of IPv4 multihoming with NAT when an uplink failure causes all connections to be NATed to completely different public IPv4 addresses. While it does sound suboptimal, it is determined by the nature of PA address space: if all uplinks to the particular ISP have failed, there is no path for the ingress traffic to reach the site, and the egress traffic is supposed to be dropped by the ingress filters [BCP38]. The only potential way to overcome this limitation would be to run BGP with all ISPs and to advertise all site prefixes to all uplinks - a solution that shares all the drawbacks of using the PI address space without sharing its benefits. Networks willing and capable of running BGP and using PI are out of scope of this document.
提案されたソリューションは、アップリンク障害が発生した場合に接続状態を維持するようには設計されていません。 ISPへのすべてのアップリンクがダウンすると、そのISPアドレススペースとの間で確立されたすべてのトランスポート接続が中断されます（トランスポートプロトコルに特定のマルチホーミングサポートがない場合）。この動作は、アップリンク障害によりすべての接続が完全に異なるパブリックIPv4アドレスにNAT変換される場合の、NATを使用したIPv4マルチホーミングのシナリオに似ています。最適とは言えませんが、PAアドレススペースの性質によって決定されます。特定のISPへのすべてのアップリンクが失敗した場合、入力トラフィックがサイトに到達するためのパスはなく、出力トラフィックは入力フィルタ[BCP38]。この制限を克服する唯一の潜在的な方法は、すべてのISPでBGPを実行し、すべてのサイトプレフィックスをすべてのアップリンクにアドバタイズすることです。これは、その利点を共有せずにPIアドレススペースを使用することのすべての欠点を共有するソリューションです。 BGPを実行してPIを使用できるネットワークは、このドキュメントの範囲外です。
It should be noted that in the case of IPv4 NAT-based multihoming, uplink recovery could cause connection interruptions as well (unless packet forwarding is integrated with the tracking of existing NAT sessions so that the egress interface for the existing sessions is not changed). However, the proposed solution has the benefit of preserving the existing sessions during and after the restoration of the failed uplink. Unlike the uplink failure event, which causes all addresses from the affected prefix to be deprecated, the recovery would just add new, preferred addresses to a host without making any addresses unavailable. Therefore, connections established to and from those addresses do not have to be interrupted.
IPv4 NATベースのマルチホーミングの場合、アップリンクの回復が接続の中断を引き起こす可能性があることに注意する必要があります（既存のセッションの出力インターフェイスが変更されないように、パケット転送が既存のNATセッションの追跡と統合されている場合を除く）。ただし、提案されたソリューションには、失敗したアップリンクの復元中および復元後に既存のセッションを保持するという利点があります。影響を受けるプレフィックスのすべてのアドレスが廃止される原因となるアップリンク障害イベントとは異なり、リカバリでは、アドレスを使用不可にすることなく、新しい優先アドレスをホストに追加するだけです。したがって、これらのアドレスとの間で確立された接続を中断する必要はありません。
While it's desirable for active connections to survive ISP failover events, such events affect the reachability of IP addresses assigned to hosts in sites using PA address space. Unless the transport (or higher-level protocols) is capable of surviving the host renumbering, the active connections will be broken. The proposed solution focuses on minimizing the impact of failover on new connections and on multipath-aware protocols.
アクティブな接続がISPフェイルオーバーイベントに耐えることが望ましいですが、そのようなイベントは、PAアドレススペースを使用するサイトのホストに割り当てられたIPアドレスの到達可能性に影響します。トランスポート（またはより高レベルのプロトコル）がホストの再番号付けに耐えることができない場合、アクティブな接続は切断されます。提案されたソリューションは、新しい接続とマルチパス対応プロトコルへのフェイルオーバーの影響を最小限に抑えることに重点を置いています。
Another way to preserve connection state is to use multipath transport as discussed in Section 8.3.
接続状態を維持する別の方法は、8.3で説明したマルチパス転送を使用することです。
In a multihomed environment, each ISP might provide their own list of DNS servers. For example, in the topology shown in Figure 3, ISP-A might provide H51 2001:db8:0:5555::51 as a recursive DNS server, while ISP-B might provide H61 2001:db8:0:6666::61 as a recursive DNS server (RDNSS). [RFC8106] defines IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of RDNSS addresses and a DNS Search List (DNSSL) to IPv6 hosts. Using RDNSS together with 'scoped' RAs as described above would allow a first-hop router (R3 in Figure 3) to send DNS server addresses and search lists provided by each ISP (or the corporate DNS server addresses if the enterprise is running its own DNS servers. As discussed below, the DNS split-horizon problem is too hard to solve without running a local DNS server).
マルチホーム環境では、各ISPが独自のDNSサーバーのリストを提供する場合があります。たとえば、図3に示すトポロジでは、ISP-AがH51 2001：db8：0：5555 :: 51を再帰DNSサーバーとして提供し、ISP-BがH61 2001：db8：0：6666 :: 61を提供する場合があります。再帰DNSサーバー（RDNSS）として。 [RFC8106]は、IPv6ルーターがIPv6ホストにRDNSSアドレスのリストとDNS検索リスト（DNSSL）を通知できるようにするIPv6ルーター通知オプションを定義します。上記のようにRDNSSを「スコープ」RAと一緒に使用すると、ファーストホップルーター（図3のR3）は、各ISPが提供するDNSサーバーアドレスと検索リスト（または企業が独自のDNSサーバーアドレスを実行している場合）を送信できますDNSサーバー：以下で説明するように、DNSスプリットホライズンの問題は、ローカルDNSサーバーを実行しないと解決するのが困難です。
As discussed in Section 6.5.2, failure of all ISP uplinks would cause deprecation of all addresses assigned to a host from the address space of all ISPs. If any intra-site IPv6 connectivity is still desirable (most likely to be the case for any mid/large-scale network), then ULAs should be used as discussed in Section 6.5.2. In such a scenario, the enterprise network should run its own recursive DNS server(s) and provide its ULA addresses to hosts via RDNSS in RAs sent for ULA-scoped forwarding table as described in Section 6.5.2.
セクション6.5.2で説明したように、すべてのISPアップリンクに障害が発生すると、すべてのISPのアドレス空間からホストに割り当てられたすべてのアドレスが非推奨になります。サイト内IPv6接続が依然として望ましい場合（中規模/大規模ネットワークの場合が最も当てはまる可能性が高い）、セクション6.5.2で説明されているようにULAを使用する必要があります。このようなシナリオでは、エンタープライズネットワークは独自の再帰DNSサーバーを実行し、セクション6.5.2で説明するように、ULAスコープの転送テーブルに送信されるRAのRDNSSを介してホストにULAアドレスを提供する必要があります。
There are some scenarios in which the final outcome of the name resolution might be different depending on:
名前解決の最終結果が以下に応じて異なる場合があるいくつかのシナリオがあります。
* which DNS server is used;
* 使用されているDNSサーバー。
* which source address the client uses to send a DNS query to the server (DNS split horizon).
* クライアントがDNSクエリをサーバーに送信するために使用するソースアドレス（DNSスプリットホライズン）。
There is no way currently to instruct a host to use a particular DNS server from the configured servers list for resolving a particular name. Therefore, it does not seem feasible to solve the problem of DNS server selection on the host (it should be noted that this particular issue is protocol-agnostic and happens for IPv4 as well). In such a scenario, it is recommended that the enterprise run its own local recursive DNS server.
現在のところ、特定の名前を解決するために、構成済みサーバーリストから特定のDNSサーバーを使用するようにホストに指示する方法はありません。したがって、ホスト上のDNSサーバー選択の問題を解決することは現実的ではないようです（この特定の問題はプロトコルに依存せず、IPv4でも発生することに注意してください）。このようなシナリオでは、企業が独自のローカル再帰DNSサーバーを実行することをお勧めします。
To influence host source address selection for packets sent to a particular DNS server, the following requirements must be met:
特定のDNSサーバーに送信されるパケットのホストソースアドレスの選択に影響を与えるには、次の要件を満たす必要があります。
* The host supports RIO as defined in [RFC4191].
* ホストは、[RFC4191]で定義されているRIOをサポートします。
* The routers send RIOs for routes to DNS server addresses.
* ルーターは、ルートのRIOをDNSサーバーアドレスに送信します。
For example, if it is desirable that host H31 reaches the ISP-A DNS server H51 2001:db8:0:5555::51 using its source address 2001:db8:0:a010::31, then both R1 and R2 should send RIOs containing the route to 2001:db8:0:5555::51 (or covering route) in their 'scoped' RAs, containing LLA_A as the default router address and the PIO for SLAAC prefix 2001:db8:0:a010::/64. In that case, host H31 (if it supports Rule 5.5) would select LLA_A as a next-hop and then choose 2001:db8:0:a010::31 as the source address for packets to the DNS server.
たとえば、ホストH31がそのソースアドレス2001：db8：0：a010 :: 31を使用してISP-A DNSサーバーH51 2001：db8：0：5555 :: 51に到達することが望ましい場合、R1とR2の両方が送信する必要があります。 「スコープ」RAに2001：db8：0：5555 :: 51（またはカバールート）へのルートを含むRIO。デフォルトのルーターアドレスとしてLLA_Aを含み、SLAACプレフィックス2001：db8：0：a010 :: /のPIOを含みます。 64。その場合、ホストH31（ルール5.5をサポートしている場合）はLLA_Aをネクストホップとして選択し、2001：db8：0：a010 :: 31をDNSサーバーへのパケットのソースアドレスとして選択します。
It should be noted that [RFC6106] explicitly prohibits using DNS information if the RA Router Lifetime has expired:
[RFC6106]は、RAルーターの有効期限が切れている場合、DNS情報の使用を明示的に禁止していることに注意してください。
| An RDNSS address or a DNSSL domain name MUST be used only as long
| as both the RA router Lifetime (advertised by a Router
| Advertisement message) and the corresponding option Lifetime have
| not expired.
Therefore, hosts might ignore RDNSS information provided in ULA-scoped RAs, as those RAs would have Router Lifetime values set to zero. However, [RFC8106], which obsoletes RFC 6106, has removed that requirement.
したがって、ホストはULAスコープのRAで提供されるRDNSS情報を無視する可能性があります。これらのRAではルーターのライフタイム値がゼロに設定されるためです。ただし、RFC 6106を廃止した[RFC8106]により、この要件は削除されました。
As discussed above, the DNS split-horizon problem and the selection of the correct DNS server in a multihomed environment are not easy problems to solve. The proper solution would require hosts to support the concept of multiple provisioning domains (PvD, a set of configuration information associated with a network, [RFC7556]).
上記のように、DNSスプリットホライズンの問題とマルチホーム環境での正しいDNSサーバーの選択は、解決するのが難しい問題です。適切なソリューションでは、ホストが複数のプロビジョニングドメインの概念（PvD、ネットワークに関連付けられた一連の構成情報[RFC7556]）をサポートする必要があります。
The solution described in this document requires certain mechanisms to be supported by the network infrastructure and hosts. It requires some routers in the enterprise site to support some form of SADR. It also requires hosts to be able to learn when the uplink to an ISP changes its state so that the hosts can use appropriate source addresses. Ongoing work to create mechanisms to accomplish this are discussed in this document, but they are still works in progress.
このドキュメントで説明するソリューションでは、ネットワークインフラストラクチャとホストによってサポートされる特定のメカニズムが必要です。エンタープライズサイトの一部のルーターは、なんらかの形式のSADRをサポートする必要があります。また、ホストが適切な送信元アドレスを使用できるように、ISPへのアップリンクがその状態を変更したときにホストが学習できる必要があります。これを達成するためのメカニズムを作成するための進行中の作業は、このドキュメントで説明されていますが、それらはまだ進行中の作業です。
The proposed solution does not prescribe particular details regarding deploying an SADR domain within a multihomed enterprise network. However the following guidelines could be applied:
提案されたソリューションは、マルチホームエンタープライズネットワーク内でのSADRドメインの展開に関する特定の詳細を規定していません。ただし、次のガイドラインを適用できます。
* The SADR domain is usually limited by the multihomed site border.
* SADRドメインは通常、マルチホームサイトの境界によって制限されます。
* The minimal deployable scenario requires enabling SADR on all SERs and including them into a single SADR domain.
* 最小限の展開可能なシナリオでは、すべてのSERでSADRを有効にし、それらを単一のSADRドメインに含める必要があります。
* As discussed in Section 4.2, extending the connected SADR domain beyond the SERs to the first-hop routers can produce more efficient forwarding paths and allow the network to fully benefit from SADR. It would also simplify the operation of the SADR domain.
* セクション4.2で説明したように、接続されたSADRドメインをSERを超えてファーストホップルーターに拡張すると、より効率的な転送パスを生成し、ネットワークでSADRのメリットを十分に活用できます。また、SADRドメインの操作も簡素化されます。
* During the incremental SADR domain expansion from the SERs down towards first-hop routers, it's important to ensure that, at any given moment, all SADR-capable routers within the domain are logically connected (see Section 5).
* SERからファーストホップルーターに向かってSADRドメインが段階的に拡張されている間、常に、ドメイン内のすべてのSADR対応ルーターが論理的に接続されていることを確認することが重要です（セクション5を参照）。
The solution discussed in this document relies on the default address selection algorithm, Rule 5.5 [RFC6724]. While [RFC6724] considers this rule as optional, the more recent [RFC8028] states that "A host SHOULD select default routers for each prefix it is assigned an address in." It also recommends that hosts should implement Rule 5.5. of [RFC6724]. Therefore, while hosts compliant with RFC 8028 already have a mechanism to learn about state changes to ISP uplinks and to select the source addresses accordingly, many hosts do not support such a mechanism yet.
このドキュメントで説明されているソリューションは、デフォルトのアドレス選択アルゴリズムであるRule 5.5 [RFC6724]に依存しています。 [RFC6724]はこのルールをオプションと見なしていますが、最近の[RFC8028]は、「ホストは、アドレスが割り当てられている各プレフィックスにデフォルトルーターを選択する必要があります（SHOULD）」と述べています。また、ホストがルール5.5を実装することを推奨します。 [RFC6724]の。したがって、RFC 8028に準拠するホストには、ISPアップリンクの状態変更について学習し、それに応じて送信元アドレスを選択するメカニズムがすでにありますが、多くのホストはまだそのようなメカニズムをサポートしていません。
It should be noted that a multihomed enterprise network utilizing multiple ISP prefixes can be considered as a typical multiple provisioning domain (mPvD) scenario, as described in [RFC7556]. This document defines a way for the network to provide the PvD information to hosts indirectly, using the existing mechanisms. At the same time, [PROV-DOMAINS] takes one step further and describes a comprehensive mechanism for hosts to discover the whole set of configuration information associated with different PvDs/ISPs. [PROV-DOMAINS] complements this document in terms of enabling hosts to learn about ISP uplink states and to select the corresponding source addresses.
[RFC7556]で説明されているように、複数のISPプレフィックスを利用するマルチホームエンタープライズネットワークは、典型的な複数プロビジョニングドメイン（mPvD）シナリオと見なすことができることに注意してください。このドキュメントでは、既存のメカニズムを使用して、ネットワークがホストにPvD情報を間接的に提供する方法を定義します。同時に、[PROV-DOMAINS]はさらに一歩進んで、ホストがさまざまなPvD / ISPに関連付けられた構成情報のセット全体を発見するための包括的なメカニズムについて説明します。 [PROV-DOMAINS]は、ホストがISPアップリンク状態について学習し、対応するソースアドレスを選択できるようにするという点で、このドキュメントを補足します。
The Shim6 protocol [RFC5533], specified by the Shim6 working group, allows a host at a multihomed site to communicate with an external host and to exchange information about possible source and destination address pairs that they can use to communicate. The Shim6 working group also specified the REAchability Protocol (REAP) [RFC5534] to detect failures in the path between working address pairs and to find new working address pairs. A fundamental requirement for Shim6 is that both internal and external hosts need to support Shim6. That is, both the host internal to the multihomed site and the host external to the multihomed site need to support Shim6 in order for there to be any benefit for the internal host to run Shim6. The Shim6 protocol specification was published in 2009, but it has not been widely implemented. Therefore Shim6 is not considered as a viable solution for enterprise multihoming.
Shim6ワーキンググループによって指定されたShim6プロトコル[RFC5533]を使用すると、マルチホームサイトのホストが外部ホストと通信し、通信に使用できる可能な送信元および宛先アドレスのペアに関する情報を交換できます。 Shim6ワーキンググループは、REAchability Protocol（REAP）[RFC5534]も指定して、ワーキングアドレスペア間のパスの障害を検出し、新しいワーキングアドレスペアを見つけました。 Shim6の基本的な要件は、内部ホストと外部ホストの両方がShim6をサポートする必要があることです。つまり、マルチホームサイトの内部のホストとマルチホームサイトの外部のホストの両方がShim6をサポートして、内部ホストがShim6を実行できるようにする必要があります。 Shim6プロトコル仕様は2009年に公開されましたが、広く実装されていません。したがって、Shim6はエンタープライズマルチホーミングの実行可能なソリューションとは見なされません。
IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the focus of this document. NPTv6 suffers from the same fundamental issue as any other approaches to address translation: it breaks end-to-end connectivity. Therefore NPTv6 is not considered as a desirable solution, and this document intentionally focuses on solving the enterprise multihoming problem without any form of address translation.
IPv6-to-IPv6ネットワークプレフィックス変換（NPTv6）[RFC6296]は、このドキュメントの焦点ではありません。 NPTv6には、変換に対処する他のアプローチと同じ基本的な問題があり、エンドツーエンドの接続が切断されます。したがって、NPTv6は望ましいソリューションとは見なされず、このドキュメントでは、いかなる形式のアドレス変換も行わずにエンタープライズマルチホーミング問題の解決に焦点を当てています。
With increasing interest and ongoing work in bringing path awareness to transport- and application-layer protocols, hosts might be able to determine the properties of the various network paths and choose among the paths that are available to them. As selecting the correct source address is one of the possible mechanisms that path-aware hosts may utilize, address translation negatively affects hosts' path-awareness, which makes NTPv6 an even more undesirable solution.
トランスポート層およびアプリケーション層のプロトコルにパス認識をもたらすことへの関心と継続的な作業の増加により、ホストはさまざまなネットワークパスのプロパティを決定し、それらに利用可能なパスの中から選択できるようになる可能性があります。正しい送信元アドレスを選択することは、パス認識ホストが利用できるメカニズムの1つであるため、アドレス変換はホストのパス認識に悪影響を及ぼすため、NTPv6はさらに望ましくないソリューションになります。
Using multipath transport (such as Multipath TCP (MPTCP) [RFC6824] or multipath capabilities in QUIC) might solve the problems discussed in Section 6 since a multipath transport would allow hosts to use multiple source addresses for a single connection and to switch between those source addresses when a particular address becomes unavailable or a new address is assigned to the host interface. Therefore, if all hosts in the enterprise network use only multipath transport for all connections, the signaling solution described in Section 6 might not be needed (it should be noted that Source Address Dependent Routing would still be required to deliver packets to the correct uplinks). At the time this document was written, multipath transport alone could not be considered a solution for the problem of selecting the source address in a multihomed environment. There are a significant number of hosts that do not use multipath transport currently, and it seems unlikely that the situation will change in the foreseeable future (even if new releases of operating systems support multipath protocols, there will be a long tail of legacy hosts). The solution for enterprise multihoming needs to work for the least common denominator: hosts without multipath transport support. In addition, not all protocols are using multipath transport. While multipath transport would complement the solution described in Section 6, it could not be considered as a sole solution to the problem of source address selection in multihomed environments.
マルチパストランスポート（マルチパスTCP（MPTCP）[RFC6824]またはQUICのマルチパス機能など）を使用すると、ホストが単一の接続に複数の送信元アドレスを使用し、それらの送信元を切り替えることができるため、セクション6で説明した問題を解決できる場合があります。特定のアドレスが使用できなくなったとき、または新しいアドレスがホストインターフェイスに割り当てられたときのアドレス。したがって、エンタープライズネットワークのすべてのホストがすべての接続にマルチパストランスポートのみを使用する場合、セクション6で説明されているシグナリングソリューションは必要ない可能性があります（正しいアップリンクにパケットを配信するには、ソースアドレス依存ルーティングが依然として必要であることに注意してください）。 。このドキュメントが作成された時点では、マルチパストランスポートだけでは、マルチホーム環境で送信元アドレスを選択する問題の解決策とは考えられませんでした。現在、マルチパストランスポートを使用していないホストは多数あり、近い将来に状況が変わる可能性は低いと思われます（オペレーティングシステムの新しいリリースがマルチパスプロトコルをサポートしている場合でも、レガシーホストのテールが長くなります）。 。エンタープライズマルチホーミングのソリューションは、最も一般的な分母であるマルチパストランスポートサポートのないホストで機能する必要があります。さらに、すべてのプロトコルがマルチパス転送を使用しているわけではありません。マルチパストランスポートは、セクション6で説明したソリューションを補完するものですが、マルチホーム環境での送信元アドレス選択の問題に対する唯一のソリューションとは言えません。
On the other hand, PA-based multihoming could provide additional benefits to multipath protocols, should those protocols be deployed in the network. Multipath protocols could leverage source address selection to achieve maximum path diversity (and potentially improved performance).
一方、PAベースのマルチホーミングは、マルチパスプロトコルがネットワークに導入されている場合、マルチパスプロトコルに追加の利点をもたらす可能性があります。マルチパスプロトコルは、ソースアドレスの選択を活用して、最大のパスダイバーシティを実現できます（パフォーマンスが向上する可能性もあります）。
Therefore, the deployment of multipath protocols should not be considered as an alternative to the approach proposed in this document. Instead, both solutions complement each other, so deploying multipath protocols in a PA-based multihomed network proves mutually beneficial.
したがって、マルチパスプロトコルの展開は、このドキュメントで提案されているアプローチの代替として考えるべきではありません。代わりに、両方のソリューションが互いに補完し合うため、PAベースのマルチホームネットワークにマルチパスプロトコルを展開すると、相互にメリットがあることがわかります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
Section 6.2.3 discusses a mechanism for controlling source address selection on hosts using ICMPv6 messages. Using ICMPv6 to influence source address selection allows an attacker to exhaust the list of candidate source addresses on the host by sending spoofed ICMPv6 Code 5 for all prefixes known on the network (therefore preventing a victim from establishing communication with the destination host). Another possible attack vector is using ICMPv6 Destination Unreachable Messages with Code 5 to steer the egress traffic towards the particular ISP, so the attacker can benefit from their ability doing traffic sniffing/interception in that ISP network.
セクション6.2.3では、ICMPv6メッセージを使用してホスト上の送信元アドレス選択を制御するメカニズムについて説明します。 ICMPv6を使用して送信元アドレスの選択に影響を与えると、攻撃者はネットワーク上で既知のすべてのプレフィックスに対して偽装されたICMPv6コード5を送信することにより、ホスト上の候補送信元アドレスのリストを使い果たすことができます（したがって、被害者が宛先ホストとの通信を確立できないようにします）。別の可能な攻撃ベクトルは、ICMPv6宛先到達不能メッセージとコード5を使用して、特定のISPに向けて出力トラフィックを誘導することです。これにより、攻撃者は、そのISPネットワークでトラフィックスニッフィング/傍受を行う能力から利益を得ることができます。
To prevent those attacks, hosts SHOULD verify that the original packet header included in the ICMPv6 error message was actually sent by the host (to ensure that the ICMPv6 message was triggered by a packet sent by the host).
これらの攻撃を防ぐために、ホストはICMPv6エラーメッセージに含まれる元のパケットヘッダーが実際にホストによって送信されたことを確認する必要があります（ホストによって送信されたパケットによってICMPv6メッセージがトリガーされたことを確認するため）。
As ICMPv6 Destination Unreachable Messages with Code 5 could be originated by any SADR-capable router within the domain (or even come from the Internet), the Generalized TTL Security Mechanism (GTSM) [RFC5082] cannot be applied. Filtering such ICMPv6 messages at the site border cannot be recommended as it would break the legitimate end-to-end error signaling mechanism for which ICMPv6 was designed.
コード5のICMPv6宛先到達不能メッセージは、ドメイン内の（またはインターネットからの）SADR対応ルーターによって発信される可能性があるため、一般化TTLセキュリティメカニズム（GTSM）[RFC5082]は適用できません。このようなICMPv6メッセージをサイト境界でフィルタリングすると、ICMPv6が設計された正当なエンドツーエンドのエラーシグナリングメカニズムが機能しなくなるため、お勧めできません。
The security considerations of using stateless address autoconfiguration are discussed in [RFC4862].
ステートレスアドレス自動構成を使用する際のセキュリティに関する考慮事項は、[RFC4862]で説明されています。
[BCP38] 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>.
[BCP38]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<https：// www .rfc-editor.org / info / rfc2827>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., 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、GJ、および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>。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、DOI 10.17487 / RFC4191、2005年11月、<https://www.rfc-editor.org/info/rfc4191 >。
[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>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6）」、STD 89、RFC 4443、DOI 10.17487 / RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[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>。
[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>。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, DOI 10.17487/RFC6106, November 2010, <https://www.rfc-editor.org/info/rfc6106>.
[RFC6106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 6106、DOI 10.17487 / RFC6106、2010年11月、<https：// www .rfc-editor.org / info / rfc6106>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <https://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、DOI 10.17487 / RFC6296、2011年6月、<https://www.rfc-editor.org/info/rfc6296 >。
[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>。
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy Using DHCPv6", RFC 7078, DOI 10.17487/RFC7078, January 2014, <https://www.rfc-editor.org/info/rfc7078>.
[RFC7078]マツモトA.、藤崎T.、およびT. Chown、「DHCPv6を使用したアドレス選択ポリシーの配布」、RFC 7078、DOI 10.17487 / RFC7078、2014年1月、<https://www.rfc-editor.org / info / rfc7078>。
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, <https://www.rfc-editor.org/info/rfc7556>.
[RFC7556] Anipko、D。、編、「Multiple Provisioning Domain Architecture」、RFC 7556、DOI 10.17487 / RFC7556、2015年6月、<https://www.rfc-editor.org/info/rfc7556>。
[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>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Siodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T。、およびT. Winters、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https://www.rfc-editor.org/info/rfc8415>。
[DST-SRC-RTG] Lamparter, D. and A. Smirnov, "Destination/Source Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-dst-src-routing-07, 10 March 2019, <https://tools.ietf.org/html/draft-ietf-rtgwg-dst-src-routing-07>.
[DST-SRC-RTG]ランパーター、D。およびA.スミルノフ、「宛先/ソースルーティング」、作業中、インターネットドラフト、draft-ietf-rtgwg-dst-src-routing-07、2019年3月10日、< https://tools.ietf.org/html/draft-ietf-rtgwg-dst-src-routing-07>。
[PROV-DOMAINS] Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", Work in Progress, Internet-Draft, draft-ietf-intarea-provisioning-domains-09, 6 December 2019, <https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-09>.
[PROV-DOMAINS] Pfister、P.、Vyncke、E.、Pauly、T.、Schinazi、D。、およびW. Shao、「Discovering Provisioning Domain Names and Data」、Work in Progress、Internet-Draft、draft-ietf -intarea-provisioning-domains-09、2019年12月6日、<https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-09>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<https://www.rfc-editor.org/info / rfc2663>。
[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 >。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<https：//www.rfc-editor .org / info / rfc4941>。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、DOI 10.17487 / RFC5082、 2007年10月、<https://www.rfc-editor.org/info/rfc5082>。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5533] Nordmark、E。およびM. Bagnulo、「Shim6：Level 3 Multihoming Shim Protocol for IPv6」、RFC 5533、DOI 10.17487 / RFC5533、2009年6月、<https://www.rfc-editor.org/info/ rfc5533>。
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, DOI 10.17487/RFC5534, June 2009, <https://www.rfc-editor.org/info/rfc5534>.
[RFC5534] Arkko、J。およびI. van Beijnum、「IPv6マルチホーミングの障害検出およびロケータペア探索プロトコル」、RFC 5534、DOI 10.17487 / RFC5534、2009年6月、<https://www.rfc-editor.org/ info / rfc5534>。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスによるマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<https：// www.rfc-editor.org/info/rfc6824>。
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, <https://www.rfc-editor.org/info/rfc7676>.
[RFC7676] Pignataro、C.、Bonica、R。、およびS. Krishnan、「IPv6 Support for Generic Routing Encapsulation（GRE）」、RFC 7676、DOI 10.17487 / RFC7676、2015年10月、<https：//www.rfc- editor.org/info/rfc7676>。
[RFC8425] Troan, O., "IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags", RFC 8425, DOI 10.17487/RFC8425, July 2018, <https://www.rfc-editor.org/info/rfc8425>.
[RFC8425]トローン、O。、「IPv6近隣探索プレフィックス情報オプションフラグに関するIANAの考慮事項」、RFC 8425、DOI 10.17487 / RFC8425、2018年7月、<https://www.rfc-editor.org/info/rfc8425>。
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC8504] Chown、T.、Loughney、J。、およびT. Winters、「IPv6ノード要件」、BCP 220、RFC 8504、DOI 10.17487 / RFC8504、2019年1月、<https://www.rfc-editor.org / info / rfc8504>。
[SADR-RA] Pfister, P., "Source Address Dependent Route Information Option for Router Advertisements", Work in Progress, Internet-Draft, draft-pfister-6man-sadr-ra-01, 22 June 2015, <https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01>.
[SADR-RA] Pfister、P。、「ルータアドバタイズメントのソースアドレス依存ルート情報オプション」、進行中の作業、インターネットドラフト、draft-pfister-6man-sadr-ra-01、2015年6月22日、<https：/ /tools.ietf.org/html/draft-pfister-6man-sadr-ra-01>。
Acknowledgements
謝辞
The original outline was suggested by Ole Trøan.
元の概要はOleTrøanによって提案されました。
The authors would like to thank the following people (in alphabetical order) for their review and feedback: Olivier Bonaventure, Deborah Brungard, Brian E. Carpenter, Lorenzo Colitti, Roman Danyliw, Benjamin Kaduk, Suresh Krishnan, Mirja Kühlewind, David Lamparter, Nicolai Leymann, Acee Lindem, Philip Matthews, Robert Raszuk, Pete Resnick, Alvaro Retana, Dave Thaler, Michael Tüxen, Martin Vigoureux, Éric Vyncke, Magnus Westerlund.
著者は、レビューとフィードバックを提供してくれた次の人々（アルファベット順）に感謝します。 Leymann、Acee Lindem、Philip Matthews、Robert Raszuk、Pete Resnick、Alvaro Retana、Dave Thaler、MichaelTüxen、Martin Vigoureux、ÉricVyncke、Magnus Westerlund。
Authors' Addresses
著者のアドレス
Fred Baker Santa Barbara, California 93117 United States of America
フレッドベイカーサンタバーバラ、カリフォルニア93117アメリカ合衆国
Email: FredBaker.IETF@gmail.com
Chris Bowers Juniper Networks Sunnyvale, California 94089 United States of America
クリスバウアーズジュニパーネットワークスサニーベール、カリフォルニア州94089アメリカ合衆国
Email: cbowers@juniper.net
Jen Linkova Google 1 Darling Island Rd Pyrmont NSW 2009 Australia
Jen Linkova Google 1ダーリングアイランドロードピルモントNSW 2009オーストラリア
Email: furry@google.com