[要約] RFC 8028は、マルチプレフィックスネットワークにおけるホストによる最初のホップルーターの選択に関するものです。このRFCの目的は、ホストが最適なルーターを選択するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 8028
Updates: 4861 B. Carpenter
Category: Standards Track Univ. of Auckland
ISSN: 2070-1721 November 2016
First-Hop Router Selection by Hosts in a Multi-Prefix Network
マルチプレフィックスネットワークのホストによるファーストホップルーターの選択
Abstract
概要
This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861.
このドキュメントでは、ホストに複数のルーターを選択できる場合に、BCP 38入力フィルタリングを実装すると想定されるアップストリームネットワークによってそれぞれ割り当てられる複数のプレフィックスがあるシナリオで予想されるIPv6ホストの動作について説明します。また、アドレスベースのフィルターとして効果的に機能するステートフルファイアウォールの使用など、他のシナリオにも適用されます。ファーストホップルーターを選択する際のホストの動作は、特定の実装では送信元アドレスの選択と相互作用する場合があります。ただし、パケットの送信元アドレスの選択は、そのパケットの最初のホップのルーターが選択される前に行われます。ネットワークまたはホストが、プロバイダーが割り当てた複数のアドレスでマルチホーム化されている、またはマルチホーム化されているように見え、ホストが特定のプレフィックスで送信元アドレスを使用することを選択し、すべての隣接ルーターがそのプレフィックスでアドバタイズしているルータアドバタイズメントプレフィックス情報オプション。このドキュメントでは、ホストが送信を提示するルータを指定します。 RFC 4861を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8028.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8028で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction and Applicability . . . . . . . . . . . . . . . 3
1.1. Host Model . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Sending Context Expected by the Host . . . . . . . . . . . . 5
2.1. Expectations the Host Has of the Network . . . . . . . . 5
2.2. Expectations of Multihomed Networks . . . . . . . . . . . 7
3. Reasonable Expectations of the Host . . . . . . . . . . . . . 7
3.1. Interpreting Router Advertisements . . . . . . . . . . . 7
3.2. Default Router Selection . . . . . . . . . . . . . . . . 9
3.3. Source Address Selection . . . . . . . . . . . . . . . . 9
3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Residual Issues . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
This document describes the expected behavior of an IPv6 [RFC2460] host in a network that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 [RFC2827] ingress filtering, and in which the host is presented with a choice of routers. It expects that the network will implement some form of egress routing, so that packets sent to a host outside the local network from a given ISP's prefix will go to that ISP. If the packet is sent to the wrong egress, it is liable to be discarded by the BCP 38 filter. However, the mechanics of egress routing once the packet leaves the host are out of scope. The question here is how the host interacts with that network.
このドキュメントでは、複数のプレフィックスを持つネットワークでIPv6 [RFC2460]ホストの予想される動作について説明します。各プレフィックスは、BCP 38 [RFC2827]入力フィルタリングを実装すると想定される上流ネットワークによって割り当てられ、ホストにはルーターの選択。これは、ネットワークが何らかの形式の出力ルーティングを実装することを想定しているため、特定のISPのプレフィックスからローカルネットワーク外のホストに送信されるパケットは、そのISPに送信されます。パケットが誤った出力に送信されると、BCP 38フィルターによって破棄される可能性があります。ただし、パケットがホストを離れると、出力ルーティングのメカニズムは範囲外になります。ここでの問題は、ホストがそのネットワークとどのように相互作用するかです。
Various aspects of this issue, and possible solution approaches, are discussed in "IPv6 Multihoming without Network Address Translation" [RFC7157].
この問題のさまざまな側面、および考えられる解決策については、「ネットワークアドレス変換のないIPv6マルチホーミング」[RFC7157]で説明されています。
BCP 38 filtering by ISPs is not the only scenario where such behavior is valuable. Implementations that combine existing recommendations, such as [RFC6092] and [RFC7084] can also result in such filtering. Another case is when the connections to the upstream networks include stateful firewalls, such that return packets in a stream will be discarded if they do not return via the firewall that created the state for the outgoing packets. A similar cause of such discards is unicast reverse path forwarding (uRPF) [RFC3704].
ISPによるBCP 38フィルタリングは、そのような動作が重要な唯一のシナリオではありません。 [RFC6092]や[RFC7084]などの既存の推奨事項を組み合わせた実装でも、このようなフィルタリングが行われる可能性があります。もう1つのケースは、アップストリームネットワークへの接続にステートフルファイアウォールが含まれている場合です。これにより、ストリーム内のリターンパケットが、送信パケットの状態を作成したファイアウォール経由で戻らない場合は破棄されます。このような廃棄の同様の原因は、ユニキャストリバースパス転送（uRPF）[RFC3704]です。
In this document, the term "filter" is used for simplicity to cover all such cases. In any case, one cannot assume that the host is aware whether an ingress filter, a stateful firewall, or any other type of filter is in place. Therefore, the only known consistent solution is to implement the features defined in this document.
このドキュメントでは、「フィルタ」という用語は、そのようなすべてのケースをカバーするために簡単にするために使用されています。いずれの場合も、入力フィルター、ステートフルファイアウォール、またはその他の種類のフィルターが配置されているかどうかをホストが認識しているとは想定できません。したがって、唯一知られている一貫した解決策は、このドキュメントで定義されている機能を実装することです。
Note that, apart from ensuring that a message with a given source address is given to a first-hop router that appears to know about the prefix in question, this specification is consistent with [RFC4861]. Nevertheless, implementers of Sections 6.2.3, 6.3.4, 6.3.6, and 8.1 of RFC 4861 should extend their implementations accordingly. This specification is fully consistent with [RFC6724] and depends on support for its Rule 5.5 (see Section 3.3). Hosts that do not support these features may fail to communicate in the presence of filters as described above.
与えられたソースアドレスを持つメッセージが問題のプレフィックスを知っているように見える最初のホップのルーターに確実に与えられることを除いて、この仕様は[RFC4861]と一貫していることに注意してください。それにもかかわらず、RFC 4861のセクション6.2.3、6.3.4、6.3.6、および8.1の実装者は、それに応じて実装を拡張する必要があります。この仕様は[RFC6724]と完全に一貫しており、そのルール5.5のサポートに依存しています（セクション3.3を参照）。これらの機能をサポートしないホストは、上記のようにフィルターが存在すると通信に失敗する場合があります。
It could be argued that the proposal in this document, which is to send messages using a source address in a given prefix to the router that advertised the prefix in its Router Advertisement (RA), is a form of the Strong End System (ES, e.g., Host) model, discussed in Section 3.3.4.2 of [RFC1122]. In short, [RFC1122] identifies two basic models. First, the "strong host" model describes the host as a set of hosts in one chassis, each of which uses a single address on a single interface and always both sends and receives on that interface. Alternatively, the "weak host" model treats the host as one system with zero or more addresses on every interface and is capable of using any interface for any communication. As noted there, neither model is completely satisfactory. For example, a host with a link-local-only interface and a default route pointing to that interface will necessarily send packets using that interface but with a source address derived from some other interface, and will therefore be a de facto weak host. If the router upstream from such a host implements BCP 38 Ingress Filtering [RFC2827], such as by implementing uRPF on each interface, the router might prevent communication by weak hosts.
ルーターアドバタイズ（RA）でプレフィックスをアドバタイズしたルーターに、所定のプレフィックスのソースアドレスを使用してメッセージを送信するというこのドキュメントの提案は、Strong End System（ES、たとえば、[RFC1122]のセクション3.3.4.2で説明されているHost）モデル。要するに、[RFC1122]は2つの基本モデルを識別します。まず、「強力なホスト」モデルは、ホストを1つのシャーシ内のホストのセットとして記述します。各ホストは、単一のインターフェースで単一のアドレスを使用し、常にそのインターフェースで送信と受信の両方を行います。あるいは、「弱いホスト」モデルは、ホストを1つのシステムとして扱い、すべてのインターフェースに0個以上のアドレスがあり、任意の通信に任意のインターフェースを使用できます。そこで述べたように、どちらのモデルも完全に満足できるものではありません。たとえば、リンクローカルのみのインターフェースとそのインターフェースを指すデフォルトルートを持つホストは、必ずそのインターフェースを使用してパケットを送信しますが、他のインターフェースから派生した送信元アドレスを持つため、事実上弱いホストになります。このようなホストの上流にあるルーターがBCP 38 Ingress Filtering [RFC2827]を実装している場合（各インターフェイスにuRPFを実装するなど）、ルーターは弱いホストによる通信を妨げる可能性があります。
+-----------------+
| |
| MIF Router +---/--- Other interfaces
| |
+---+---------+---+
| | Two interfaces with subnets
| | from a common prefix
--+-+-- --+-+--
| |
+--+---------+--+
| MIF Host |
+---------------+
Figure 1: Hypothetical MIF Interconnection
図1：架空のMIF相互接続
The proposal also differs slightly from the language in [RFC1122] for the Strong Host model. The proposal is that the packet will go to a router that advertised a given prefix but that does not specify what interface that might happen on. Hence, if the router is a multi-interface (MIF) router and it is using a common prefix spanning two or more LANs shared by the host (as in Figure 1), the host might use either of those LANs, according to this proposal. The Strong Host model is not stated in those terms, but in terms of the interface used. A strong host would treat such an MIF router as two separate routers when obeying the rules from RFC 1122 as they apply in the Strong case: (A) A host MUST silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received.
また、この提案は、Strong Hostモデルの[RFC1122]の言語とは少し異なります。提案では、パケットは、指定されたプレフィックスをアドバタイズしたルーターに送られますが、どのインターフェースで発生するかは指定されていません。したがって、ルーターがマルチインターフェース（MIF）ルーターであり、ホストが共有する2つ以上のLANにまたがる共通のプレフィックスを使用している場合（図1のように）、ホストはこれらのLANのいずれかを使用する可能性があります（この提案によると）。 。強力なホストモデルは、これらの用語ではなく、使用されるインターフェイスの観点から説明されています。強いホストは、強いケースで適用されるRFC 1122のルールに従う場合、そのようなMIFルーターを2つの別個のルーターとして扱います。（A）ホストは、宛先アドレスが物理インターフェースに対応しない着信データグラムを黙って破棄する必要があります。それを受け取ります。
(B) A host MUST restrict itself to sending (non-source-routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams.
（B）ホストは、データグラムのIP送信元アドレスに対応する物理インターフェースを介してのみ、（非ソースルーティングの）IPデータグラムを送信するように制限する必要があります。
However, when comparing the presumptive route lookup mechanisms in each model, this proposal is indeed most similar to the Strong Host model, as is any source/destination routing paradigm.
ただし、各モデルの推定ルートルックアップメカニズムを比較すると、この提案は確かにストロングホストモデルと最も類似しており、送信元/宛先ルーティングパラダイムも同様です。
Strong: route (src IP addr, dest IP addr, TOS) -> gateway
Weak: route (dest IP addr, TOS) -> gateway, interface
In the hypothetical MIF model suggested in Figure 1, the address fails to identify a single interface, but it does identify a single gateway.
図1で提案されている架空のMIFモデルでは、アドレスは単一のインターフェースを識別できませんが、単一のゲートウェイを識別します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
A host receives prefixes in a Router Advertisement [RFC4861], which goes on to identify whether they are usable by Stateless Address Autoconfiguration (SLAAC) [RFC4862] with any type of interface identifier [RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the Router Advertisement would normally signal the availability of DHCPv6 [RFC3315] and the host would use it to configure its addresses. In the latter case (or if both SLAAC and DHCPv6 are used on the same link for some reason), the configured addresses generally match one of the prefixes advertised in a Router Advertisement that are supposed to be on-link for that link.
ホストは、ルーターアドバタイズメント[RFC4861]でプレフィックスを受信します。これは、任意のタイプのインターフェイス識別子[RFC4941] [RFC7217]でステートレスアドレス自動構成（SLAAC）[RFC4862]が使用できるかどうかを識別します。 SLAACに使用できるプレフィックスがない場合、ルーターアドバタイズは通常DHCPv6 [RFC3315]の可用性を通知し、ホストはそれを使用してアドレスを構成します。後者の場合（または、何らかの理由でSLAACとDHCPv6の両方が同じリンクで使用されている場合）、構成されたアドレスは、一般に、そのリンクのオンリンクであるはずのルーターアドバタイズメントでアドバタイズされるプレフィックスの1つと一致します。
The simplest multihomed network implementation in which a host makes choices among routers might be a LAN with one or more hosts on it and two or more routers, one for each upstream network, or a host that is served by disjoint networks on separate interfaces. In such a network, especially the latter, there is not necessarily a routing protocol, and the two routers may not even know that the other is a router as opposed to a host, or may be configured to ignore its presence. One might expect that the routers may or may not receive each other's RAs and form an address in the other router's prefix (which is not per [RFC4862], but is implemented by some stub router implementations). However, all hosts in such a network might be expected to create an address in each prefix so advertised.
ホストがルーターの中から選択する最も単純なマルチホームネットワークの実装は、1つ以上のホストと2つ以上のルーターを備えたLANであり、各アップストリームネットワークに1つ、または別々のインターフェイス上の互いに素なネットワークによってサービスを提供されるホストです。そのようなネットワーク、特に後者では、ルーティングプロトコルは必ずしも必要ではなく、2つのルーターは、他方がホストではなくルーターであることを認識していないか、その存在を無視するように構成されている場合があります。ルーターがお互いのRAを受信し、他のルーターのプレフィックスにアドレスを形成することを期待するかもしれません（[RFC4862]にはありませんが、一部のスタブルーター実装によって実装されています）。ただし、そのようなネットワーク内のすべてのホストは、アドバタイズされた各プレフィックスにアドレスを作成することが期待される場合があります。
+---------+ +---------+ +---------+ +---------+
| ISP | | ISP | | ISP | | ISP |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
| | | |
+----+----+ +----+----+ +----+----+ +----+----+
| Router | | Router | | Router | | Router |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
+------+------+ | +--------+ |
| +--+ Host +--+
+----+----+ +--------+
| Host |
+---------+
Common LAN Case Disjoint LAN Case
(Multihomed Network) (Multihomed Host)
Figure 2: Two Simple Networks
図2：2つの単純なネットワーク
If there is no routing protocol among those routers, there is no mechanism by which packets can be deterministically forwarded between the routers (as described in BCP 84 [RFC3704]) in order to avoid filters. Even if there was routing, it would result in an indirect route, rather than a direct route originating with the host; this is not "wrong", but can be inefficient. Therefore, the host would do well to select the appropriate router itself.
これらのルーター間にルーティングプロトコルがない場合、フィルターを回避するために、ルーター間でパケットを決定論的に転送できるメカニズムはありません（BCP 84 [RFC3704]で説明されています）。ルーティングがあったとしても、ホストを起点とする直接ルートではなく、間接ルートになります。これは「間違っている」わけではありませんが、非効率的です。したがって、ホストは適切なルーター自体を選択するのに適しています。
Since the host derives fundamental default routing information from the Router Advertisement, this implies that, in any network with hosts using multiple prefixes, each prefix SHOULD be advertised via a Prefix Information Option (PIO) [RFC4861] by one of the attached routers, even if addresses are being assigned using DHCPv6. A router that advertises a prefix indicates that it is able to appropriately route packets with source addresses within that prefix, regardless of the setting of the L and A flags in the PIO.
ホストはルーターアドバタイズから基本的なデフォルトルーティング情報を取得するため、複数のプレフィックスを使用するホストのあるネットワークでは、接続されているルーターのいずれかによって、プレフィックス情報オプション（PIO）[RFC4861]を介して各プレフィックスをアドバタイズする必要があります。 DHCPv6を使用してアドレスが割り当てられている場合。プレフィックスをアドバタイズするルーターは、PIOのLおよびAフラグの設定に関係なく、そのプレフィックス内の送信元アドレスを持つパケットを適切にルーティングできることを示します。
In some circumstances, both L and A might be zero. If SLAAC is not wanted (A=0) and there is no reason to announce an on-link prefix (L=0), a PIO SHOULD be sent to inform hosts that they should use the router in question as the first hop for packets with source addresses in the PIO prefix. An example case is the MIF router in Figure 1, which could send PIOs with A=L=0 for the common prefix. Although this does not violate the existing standard [RFC4861], such a PIO has not previously been common, and it is possible that existing host implementations simply ignore such a PIO or that existing router implementations are not capable of sending such a PIO. Newer implementations that support this mechanism should be updated accordingly:
状況によっては、LとAの両方がゼロになる場合があります。 SLAACが不要（A = 0）で、オンリンクプレフィックス（L = 0）をアナウンスする理由がない場合は、PIOを送信して、問題のルーターをパケットの最初のホップとして使用する必要があることをホストに通知する必要があります。 PIOプレフィックスに送信元アドレスが含まれます。例としては、図1のMIFルーターがあり、共通のプレフィックスにA = L = 0のPIOを送信できます。これは既存の標準[RFC4861]に違反していませんが、そのようなPIOは以前から一般的ではなく、既存のホスト実装がそのようなPIOを単に無視するか、既存のルーター実装がそのようなPIOを送信できない可能性があります。このメカニズムをサポートする新しい実装は、それに応じて更新する必要があります。
o A host SHOULD NOT ignore a PIO simply because both L and A flags are cleared (extending Section 6.3.4 of [RFC4861]).
o ホストは、LフラグとAフラグの両方がクリアされているためにPIOを無視してはなりません（SHOULD NOT）（[RFC4861]のセクション6.3.4を拡張）。
o A router SHOULD be able to send such a PIO (extending Section 6.2.3 of [RFC4861]).
o ルーターはこのようなPIOを送信できる必要があります（SHOULD）（[RFC4861]のセクション6.2.3を拡張）。
Networking equipment needs to support source/destination routing for at least some of the routes in the Forwarding Information Base (FIB), such as default egress routes differentiated by source prefix. Installation of source/destination routes in the FIB might be accomplished using static routes, Software-Defined Networking (SDN) technologies, or dynamic routing protocols.
ネットワーク機器は、ソースプレフィックスで区別されるデフォルトの出力ルートなど、転送情報ベース（FIB）内の少なくともいくつかのルートのソース/宛先ルーティングをサポートする必要があります。 FIBへの送信元/宛先ルートのインストールは、静的ルート、ソフトウェア定義ネットワーク（SDN）テクノロジ、または動的ルーティングプロトコルを使用して実行できます。
As described in [RFC4191] and [RFC4861], a Router Advertisement may contain zero or more Prefix Information Options (PIOs) or zero or more Route Information Options (RIOs). In their original intent, these indicate general information to a host: "the router whose address is found in the source address field of this packet is one of your default routers", "you might create an address in this prefix", or "this router would be a good place to send traffic directed to a given destination prefix". In a multi-prefix network with multiple exits, the host's characterization of each default router SHOULD include the prefixes it has announced (extending Section 6.3.4 of [RFC4861]). In other words, the PIO is reinterpreted to also imply that the advertising router would be a reasonable first hop for any packet using a source address in any advertised prefix, regardless of Default Router Preference.
[RFC4191]と[RFC4861]で説明されているように、ルーターアドバタイズメントには0個以上のプレフィックス情報オプション（PIO）または0個以上のルート情報オプション（RIO）が含まれる場合があります。元の意図では、これらはホストへの一般情報を示しています。「このパケットの送信元アドレスフィールドにアドレスが見つかったルーターは、デフォルトルーターの1つです」、「このプレフィックスにアドレスを作成する可能性があります」、または「これはルーターは、特定の宛先プレフィックスに向けられたトラフィックを送信するのに適した場所です。」複数の出口を持つマルチプレフィックスネットワークでは、各デフォルトルータのホストの特性には、ホストがアナウンスしたプレフィックスを含める必要があります（SHOULD）（[RFC4861]のセクション6.3.4を拡張）。言い換えると、PIOは再解釈され、アドバタイズされたプレフィックスの送信元アドレスを使用するパケットの最初のホップは、デフォルトルーターのプリファレンスに関係なく、アドバタイジングルーターが妥当であることを意味します。
+---------+ |
( ISP A ) - + Bob-A +--+ +-----+
+-------+ / +---------+ +--+ |
| | / | | |
| Alice +--/--( The Internet ) | Bob |
| | \ | | |
+-------+ \ +---------+ +--+ |
( ISP B ) - + Bob-B +--+ +-----+
+---------+ |
Figure 3: PIOs, RIOs, and Default Routes
図3：PIO、RIO、およびデフォルトルート
The implications bear consideration. Imagine, Figure 3, that hosts Alice and Bob are in communication. Bob's network consists of at least Bob (the computer), two routers (Bob-A and Bob-B), and the links between them; it may be much larger, for example, a campus or corporate network. Bob's network is therefore multihomed, and Bob's first-hop routers are Bob-A (to the upstream ISP A advertising prefix PA) and Bob-B (to the upstream network B and advertising prefix PB). We assume that Bob is not applying Rule 5.5 of [RFC6724]. If Bob is responding to a message from Alice, his choice of source address is forced to be the address Alice used as a destination (which we may presume to have been in prefix PA). Hence, Bob either created or was assigned an address in PA, and can only reasonably send traffic using it to Bob-A as a first-hop router. If there are several routers in Bob's network advertising the prefix PA (referred to as "Bob-Ax" routers), then Bob should choose its first-hop router only from among those routers. From among the multiple Bob-Ax routers, Bob should choose the first-hop router based on the criteria specified in Section 3 of [RFC4191]. If none of the Bob-Ax routers has advertised an RA with a non-zero Router Lifetime or an RIO with a non-zero Route Lifetime that includes Alice, but router Bob-B has, it is irrelevant. Bob is using the address allocated in PA and courts a BCP 38 discard if he doesn't send the packet to Bob-A.
その含意には考慮が必要です。アリスとボブをホストしている図3を想像してみてください。ボブのネットワークは、少なくともボブ（コンピューター）、2つのルーター（ボブAとボブB）、およびそれらの間のリンクで構成されます。キャンパスや企業ネットワークなど、はるかに大きい場合があります。したがって、Bobのネットワークはマルチホームであり、Bobの最初のホップのルーターは、Bob-A（アップストリームISP Aへの広告プレフィックスPA）とBob-B（アップストリームネットワークBへの広告プレフィックスPB）です。ボブは[RFC6724]のルール5.5を適用していないと想定します。ボブがアリスからのメッセージに応答している場合、彼の送信元アドレスの選択は、アリスが宛先として使用されるアドレスになるように強制されます（これは、プレフィックスPAにあると推定される場合があります）。したがって、ボブはPAでアドレスを作成するか、アドレスを割り当てられ、それを使用してトラフィックをファーストホップルーターとしてボブAに合理的に送信できます。プレフィックスPAをアドバタイズするBobのネットワークにいくつかのルーター（ "Bob-Ax"ルーターと呼ばれる）がある場合、Bobはそれらのルーターの中からのみ最初のホップルーターを選択する必要があります。複数のBob-Axルーターの中から、Bobは[RFC4191]のセクション3で指定された基準に基づいてファーストホップルーターを選択する必要があります。 Bob-Axルーターのいずれも、ゼロ以外のルーターライフタイムを持つRA、またはAliceを含むゼロ以外のルートライフタイムを持つRIOをアドバタイズしていないが、ルーターBob-Bはそれを持っている場合、それは無関係です。 BobはPAに割り当てられたアドレスを使用しており、Bob-Aにパケットを送信しない場合はBCP 38破棄を求めます。
In the special case that Bob is initiating the conversation, an RIO might, however, influence source address choice. Bob could presumably use any address allocated to him, in this case, his address in PA or PB. If Bob-B has advertised an RIO for Alice's prefix and Bob-A has not, Bob MAY take that fact into account in address selection -- choosing an address that would allow him to make use of the RIO.
ただし、ボブが会話を開始する特殊なケースでは、RIOが送信元アドレスの選択に影響を与える可能性があります。ボブはおそらく自分に割り当てられた任意のアドレス、この場合はPAまたはPBのアドレスを使用できます。ボブBがアリスのプレフィックスのRIOをアドバタイズし、ボブAはアドバタイズしていない場合、ボブはその事実を考慮に入れて、RIOを使用できるアドレスを選択することができます（MAY）。
Default Router Selection (Section 6.3.6 of [RFC4861]) is extended as follows: A host SHOULD select default routers for each prefix it is assigned an address in. Routers that have advertised the prefix in their Router Advertisement message SHOULD be preferred over routers that do not advertise the prefix, regardless of Default Router Preference. Note that this document does not change the way in which default router preferences are communicated [RFC4191].
デフォルトルーターの選択（[RFC4861]のセクション6.3.6）は、次のように拡張されています。ホストは、アドレスが割り当てられているプレフィックスごとにデフォルトルーターを選択する必要があります。ルーターアドバタイズメッセージでプレフィックスをアドバタイズしたルーターは、ルーターよりも優先する必要があります（SHOULD）デフォルトルータプリファレンスに関係なく、プレフィックスをアドバタイズしません。このドキュメントは、デフォルトのルーター設定が通信される方法[RFC4191]を変更しないことに注意してください。
If no router has advertised the prefix in an RA, normal routing metrics will apply. An example is a host connected to the Internet via one router, and at the same time connected by a VPN to a private domain that is also connected to the global Internet.
RAでプレフィックスをアドバタイズしたルーターがない場合、通常のルーティングメトリックが適用されます。たとえば、1つのルーターを介してインターネットに接続されているホストであり、同時にグローバルインターネットにも接続されているプライベートドメインにVPNで接続されているホストです。
As a result of this, when a host sends a packet using a source address in one of those prefixes and has no history directing it otherwise, it SHOULD send it to the indicated default router. In the "simplest" network described in Section 2.1, that would get it to the only router that is directly capable of getting it to the right ISP. This will also apply in more complex networks, even when more than one physical or virtual interface is involved.
この結果、ホストがこれらのプレフィックスの1つにある送信元アドレスを使用してパケットを送信し、それ以外の場合はそれを指示する履歴がない場合、指定されたデフォルトのルーターに送信する必要があります（SHOULD）。セクション2.1で説明した「最も単純な」ネットワークでは、適切なISPに直接到達できる唯一のルーターに到達します。これは、複数の物理または仮想インターフェイスが関係する場合でも、より複雑なネットワークにも適用されます。
In more complex cases, wherein routers advertise RAs for multiple prefixes whether or not they have direct or isolated upstream connectivity, the host is dependent on the routing system already. If the host gives the packet to a router advertising its source prefix, it should be able to depend on the router to do the right thing.
ルーターが直接または分離されたアップストリーム接続を持っているかどうかに関係なく、ルーターが複数のプレフィックスのRAをアドバタイズするより複雑なケースでは、ホストは既にルーティングシステムに依存しています。ホストがパケットをソースプレフィックスをアドバタイズするルーターに渡す場合、ホストはルーターに依存して正しいことを行うことができます。
There is an interaction with Default Address Selection [RFC6724]. A host following the recommendation in the previous section will store information about which next hops advertised which prefixes. Rule 5.5 of RFC 6724 states that the source address used to send to a given destination address should, if possible, be chosen from a prefix known to be advertised by the next-hop router for that destination. Therefore, this selection rule SHOULD be implemented in a host following the recommendation in the previous section.
デフォルトのアドレス選択[RFC6724]との相互作用があります。前のセクションの推奨事項に従うホストは、どのネクストホップがどのプレフィックスをアドバタイズしたかに関する情報を格納します。 RFC 6724のルール5.5は、特定の宛先アドレスへの送信に使用されるソースアドレスは、可能であれば、その宛先のネクストホップルーターによってアドバタイズされることがわかっているプレフィックスから選択する必要があると述べています。したがって、この選択ルールは、前のセクションの推奨事項に従ってホストに実装する必要があります（SHOULD）。
There is potential for adverse interaction with any off-link Redirect (Redirect for a destination that is not on-link) message sent by a router in accordance with Section 8 of [RFC4861]. Hosts SHOULD apply off-link redirects only for the specific pair of source and destination addresses concerned, so the host's Destination Cache might need to contain appropriate source-specific entries. This extends the validity check specified in Section 8.1 of [RFC4861].
[RFC4861]のセクション8に従い、ルーターから送信されたオフリンクリダイレクト（オンリンクではない宛先へのリダイレクト）メッセージとの不利な相互作用の可能性があります。ホストは、関連する送信元アドレスと宛先アドレスの特定のペアにのみオフリンクリダイレクトを適用する必要があるため、ホストの宛先キャッシュに適切な送信元固有のエントリを含める必要がある場合があります。これにより、[RFC4861]のセクション8.1で指定されている有効性チェックが拡張されます。
Some modern hosts maintain history, in terms of what has previously worked or not worked for a given address or prefix and in some cases the effective window and Maximum Segment Size (MSS) values for TCP or other protocols. This might include a next-hop address for use when a packet is sent to the indicated address.
一部の最新のホストは、特定のアドレスまたはプレフィックスに対して以前に機能していた機能または機能しなかった機能、および場合によってはTCPまたはその他のプロトコルの有効ウィンドウと最大セグメントサイズ（MSS）の値に関して履歴を保持します。これには、パケットが指定されたアドレスに送信されるときに使用するネクストホップアドレスが含まれる場合があります。
When such a host makes a successful exchange with a remote destination using a particular address pair, and the host has previously received a PIO that matches the source address, then the host SHOULD include the prefix in such history, whatever the setting of the L and A flags in the PIO. On subsequent attempts to communicate with that destination, if it has an address in that prefix at that time, a host MAY use an address in the remembered prefix for the session.
そのようなホストが特定のアドレスペアを使用してリモート宛先との交換に成功し、ホストが送信元アドレスと一致するPIOを以前に受信した場合、ホストはLの設定にかかわらず、そのような履歴にプレフィックスを含める必要があります（SHOULD）。 PIOのフラグ。その宛先と通信する後続の試行で、その時点でそのプレフィックスにアドレスがある場合、ホストはセッションの記憶されたプレフィックスのアドレスを使用できます。
Consider a network where routers on a link run a routing protocol and are configured with the same information. Thus, on each link, all routers advertise all prefixes on that link. The assumption that packets will be forwarded to the appropriate egress by the local routing system might cause at least one extra hop in the local network (from the host to the wrong router, and from there to another router on the same link).
リンク上のルーターがルーティングプロトコルを実行し、同じ情報で構成されているネットワークを考えてみます。したがって、各リンクでは、すべてのルーターがそのリンク上のすべてのプレフィックスを通知します。パケットがローカルルーティングシステムによって適切な出力に転送されるという想定により、ローカルネットワークで少なくとも1つの余分なホップが発生する可能性があります（ホストから間違ったルーターへ、そしてそこから同じリンク上の別のルーターへ）。
In a slightly more complex situation such as the disjoint LAN case of Figure 2, for example, a home plus corporate home-office configuration, the two upstream routers might be on different LANs and therefore different subnets (e.g., the host is itself multihomed). In that case, there is no way for the "wrong" router to detect the existence of the "right" router, or to route to it.
図2の切り離されたLANのケースなど、やや複雑な状況、たとえば、ホームと企業のホームオフィスの構成では、2つのアップストリームルーターが異なるLANにあるため、異なるサブネットにある場合があります（たとえば、ホスト自体がマルチホームです）。 。その場合、「間違った」ルーターが「正しい」ルーターの存在を検出したり、ルーターにルーティングしたりする方法はありません。
In such a case, it is particularly important that hosts take the responsibility to memorize and select the best first hop as described in Section 3.
このような場合、セクション3で説明されているように、ホストが責任を持って記憶し、最適な最初のホップを選択することが特に重要です。
This document does not request any registry actions.
このドキュメントはレジストリアクションを要求しません。
This document is intended to avoid connectivity issues in the presence of BCP 38 ingress filters or stateful firewalls combined with multihoming. It does not, in itself, create any new security or privacy exposures. However, since the solution is designed to ensure that routing occurs correctly in situations where it previously failed, this might result in unexpected exposure of networks that were previously unreachable.
このドキュメントは、BCP 38入力フィルターまたはマルチホーミングと組み合わせたステートフルファイアウォールが存在する場合の接続の問題を回避することを目的としています。それ自体は、新しいセキュリティやプライバシーの危険性を生み出しません。ただし、このソリューションは以前に失敗した状況でルーティングが正しく行われるように設計されているため、以前は到達できなかったネットワークが予期せず露出する可能性があります。
There might be a small privacy improvement: with the current practice, a multihomed host that sends packets with the wrong address to an upstream router or network discloses the prefix of one upstream to the other upstream network. This practice reduces the probability of that occurrence.
プライバシーが少し改善される可能性があります。現在の慣例では、間違ったアドレスのパケットを上流のルーターまたはネットワークに送信するマルチホームホストが、ある上流のプレフィックスを他の上流ネットワークに公開しています。これにより、その発生の確率が下がります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <http://www.rfc-editor.org/info/rfc4191>.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、DOI 10.17487 / RFC4191、2005年11月、<http://www.rfc-editor.org/info/rfc4191 >。
[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, <http://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月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[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, <http://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月、<http://www.rfc-editor.org/info/rfc6724>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<http：// www .rfc-editor.org / info / rfc2827>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<http://www.rfc-editor.org/info/rfc3704 >。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://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月、<http://www.rfc-editor.org/info / rfc4862>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<http：//www.rfc-editor .org / info / rfc4941>。
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <http://www.rfc-editor.org/info/rfc6092>.
[RFC6092] Woodyatt、J.、Ed。、 "Recommended Simple Security Capability in Customer Premises Equipment（CPE）for Providing Residential IPv6 Internet Service"、RFC 6092、DOI 10.17487 / RFC6092、January 2011、<http：//www.rfc -editor.org/info/rfc6092>。
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルータの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<http：// www .rfc-editor.org / info / rfc7084>。
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, <http://www.rfc-editor.org/info/rfc7157>.
[RFC7157] Troan、O.、Ed。、Miles、D.、Matsushima、S.、Okimoto、T。、およびD. Wing、「ネットワークアドレス変換なしのIPv6マルチホーミング」、RFC 7157、DOI 10.17487 / RFC7157、2014年3月、<http://www.rfc-editor.org/info/rfc7157>。
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成（SLAAC）を使用してセマンティックに不透明なインターフェース識別子を生成する方法」、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、<http://www.rfc-editor.org / info / rfc7217>。
Acknowledgements
謝辞
Comments were received from Jinmei Tatuya and Ole Troan, who have suggested important text, plus Mikael Abrahamsson, Steven Barth, Carlos Bernardos Cano, Chris Bowers, Zhen Cao, Juliusz Chroboczek, Toerless Eckert, David Farmer, Bob Hinden, Ben Laurie, Dusan Mudric, Tadahisa Okimoto, Pierre Pfister, Behcet Sarikaya, Mark Smith, and James Woodyatt.
重要なテキストを提案したJinmei TatuyaとOle Troanからコメントを受け取り、さらにMikael Abrahamsson、Steven Barth、Carlos Bernardos Cano、Chris Bowers、Zhen Cao、Juliusz Chroboczek、Toerless Eckert、David Farmer、Bob Hinden、Ben Laurie、Dusan Mudric 、沖本忠久、ピエール・フィスター、ベーセット・サリカヤ、マーク・スミス、ジェームズ・ウッダット。
Authors' Addresses
著者のアドレス
Fred Baker Santa Barbara, California 93117 United States of America
フレッドベイカーサンタバーバラ、カリフォルニア93117アメリカ合衆国
Email: FredBaker.IETF@gmail.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
ブライアンカーペンターコンピュータサイエンス学部オークランド大学PB 92019オークランド1142ニュージーランド
Email: brian.e.carpenter@gmail.com