[要約] RFC 8043は、IPv6ホストのためのソースアドレス依存ルーティングとソースアドレス選択の問題領域の概要を提供しています。このRFCの目的は、IPv6ホストが適切なソースアドレスを選択し、効果的なルーティングを行うためのガイドラインを提供することです。
Independent Submission B. Sarikaya
Request for Comments: 8043 Huawei USA
Category: Informational M. Boucadair
ISSN: 2070-1721 Orange
January 2017
Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space
IPv6ホストの送信元アドレス依存ルーティングと送信元アドレス選択：問題空間の概要
Abstract
概要
This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing.
このドキュメントでは、ホストの観点から、送信元アドレス依存ルーティング（SADR）問題空間について説明します。マルチホームホストと複数のインターフェイスを持つホストの両方が考慮されます。送信元アドレスに依存するルーティングの観点から送信元アドレスの選択とネクストホップ解決が必要な理由を説明するために、いくつかのネットワークアーキテクチャが提示されています。
The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations.
このドキュメントは、ホストの観点から送信元アドレス依存ルーティングの一連のシナリオを特定し、発生した問題を軽減するための一連のソリューションを分析することを目的としています。このドキュメントでは、ソリューションに関する推奨事項はありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8043.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8043で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Source-Address-Dependent Routing (SADR) Scenarios . . . . . . 4
2.1. Multi-Prefix Multihoming . . . . . . . . . . . . . . . . 5
2.2. Multi-Prefix Multi-Interface . . . . . . . . . . . . . . 5
2.3. Home Network (Homenet) . . . . . . . . . . . . . . . . . 7
2.4. Service-Specific Egress Routing . . . . . . . . . . . . . 7
3. Analysis of Source-Address-Dependent Routing . . . . . . . . 8
3.1. Scenarios Analysis . . . . . . . . . . . . . . . . . . . 8
3.2. Provisioning Domains and SADR . . . . . . . . . . . . . . 10
4. Discussion of Alternate Solutions . . . . . . . . . . . . . . 11
4.1. Router Advertisement Option . . . . . . . . . . . . . . . 11
4.2. Router Advertisement Option Set . . . . . . . . . . . . . 12
4.3. Rule 5.5 for Source Address Selection . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
BCP 38 recommends ingress traffic filtering to prohibit Denial-of-Service (DoS) attacks. As such, datagrams with source addresses that do not match with the network where the host is attached are discarded [RFC2827]. Preventing packets from being dropped due to ingress filtering is difficult, especially in multihomed networks where the host receives more than one prefix from the networks it is connected to, and consequently may have more than one source address. Based on BCP 38, BCP 84 introduced recommendations on the routing system for multihomed networks [RFC3704].
BCP 38は、サービス拒否（DoS）攻撃を禁止するために入力トラフィックフィルタリングを推奨しています。そのため、ホストが接続されているネットワークと一致しない送信元アドレスを持つデータグラムは破棄されます[RFC2827]。特に、ホストが接続しているネットワークから複数のプレフィックスを受信し、その結果、複数の送信元アドレスが存在する可能性があるマルチホームネットワークでは、入力フィルタリングが原因でパケットがドロップされるのを防ぐことは困難です。 BCP 38に基づいて、BCP 84はマルチホームネットワークのルーティングシステムに関する推奨事項を導入しました[RFC3704]。
Recommendations on the routing system for ingress filtering such as in BCP 84 inevitably involve source address checks. This leads to source-address-dependent-routing (SADR). Source-address-dependent routing can be problematic, especially when the host is connected to a multihomed network and is communicating with another host in another multihomed network. In such a case, the communication can be broken in both directions if Network Providers apply ingress filtering and the datagrams contain the wrong source addresses (see [INGRESS_FIL] for more details).
BCP 84などのイングレスフィルタリングのルーティングシステムに関する推奨事項には、必然的に送信元アドレスのチェックが含まれます。これにより、送信元アドレス依存ルーティング（SADR）が発生します。送信元アドレスに依存するルーティングは、特にホストがマルチホームネットワークに接続されており、別のマルチホームネットワーク内の別のホストと通信している場合に問題になる可能性があります。このような場合、ネットワークプロバイダーが入力フィルタリングを適用し、データグラムに誤った送信元アドレスが含まれていると、通信が双方向で切断される可能性があります（詳細については、[INGRESS_FIL]を参照してください）。
Hosts with simultaneously active interfaces receive multiple prefixes and have multiple source addresses. Datagrams originating from such hosts are likely to be filtered due to ingress filtering policies. The source address selection algorithm needs to carefully avoid ingress filtering on the next-hop router [RFC6724].
同時にアクティブなインターフェイスを持つホストは、複数のプレフィックスを受け取り、複数の送信元アドレスを持っています。このようなホストから発信されたデータグラムは、入力フィルタリングポリシーによりフィルタリングされる可能性があります。送信元アドレス選択アルゴリズムは、ネクストホップルータ[RFC6724]での入力フィルタリングを慎重に回避する必要があります。
Many use cases have been reported for source/destination routing -- see [SD_RTG]. These use cases clearly indicate that the multihomed host or Customer Premises Equipment (CPE) router needs to be configured with the correct source prefixes/addresses so that it can forward packets upstream correctly to prevent the ingress filtering applied by an upstream Network Provider from dropping the packets.
送信元/送信先ルーティングの多くのユースケースが報告されています-[SD_RTG]を参照してください。これらのユースケースは、マルチホームホストまたはCustomer Premises Equipment（CPE）ルーターに正しいソースプレフィックス/アドレスを設定して、上流のネットワークプロバイダーによって適用される入力フィルタリングがパケット。
In multihomed networks, there is a need to enforce source-address-based routing if some providers are performing ingress filtering. This requires that the routers consider the source addresses as well as the destination addresses in determining the packet's next hop.
マルチホームネットワークでは、一部のプロバイダーが入力フィルタリングを実行している場合、送信元アドレスベースのルーティングを適用する必要があります。これには、ルーターがパケットのネクストホップを決定する際に、送信元アドレスと宛先アドレスを考慮する必要があります。
Based on the use cases defined in [SD_RTG], the routers may be informed about the source addresses to use for forwarding using extensions to the routing protocols like IS-IS [ISO.10589.1992] [SD_RTG_ISIS], OSPF [RFC5340] [SD_RTG_OSPF].
[SD_RTG]で定義された使用例に基づいて、ルーターは、IS-IS [ISO.10589.1992] [SD_RTG_ISIS]、OSPF [RFC5340] [SD_RTG_OSPF]などのルーティングプロトコルの拡張を使用して転送に使用するソースアドレスについて通知される場合があります。 。
In this document, we describe the scenarios for source-address-dependent routing from the host's perspective. Two flavors can be considered:
このドキュメントでは、ホストの観点から、送信元アドレスに依存するルーティングのシナリオについて説明します。 2つのフレーバーを検討できます。
1. A host may have a single interface with multiple addresses (from different prefixes or /64s). Each prefix is delegated from different exit routers, and this case can be called "multihomed with multi-prefix" (MHMP). In such case, source address selection is performed by the host while source-dependent routing is enforced by an upstream router.
1. ホストには、（異なるプレフィックスまたは/ 64からの）複数のアドレスを持つ単一のインターフェースがある場合があります。各プレフィックスは異なる出口ルーターから委任されており、この場合は「マルチプレフィックス付きマルチホーム」（MHMP）と呼ばれます。このような場合、送信元アドレス選択はホストによって実行され、送信元依存ルーティングは上流のルーターによって実行されます。
2. A host may have simultaneously connected multiple interfaces where each interface is connected to a different exit router, and this case can be called "multi-prefix multiple interface" (MPMI). For this case, the host is required to support both source address selection and source-dependent routing to avoid the need for an upstream router to rewrite the IPv6 prefix.
2. ホストは複数のインターフェースを同時に接続している場合があります。各インターフェースは異なる出口ルーターに接続されており、この場合は「マルチプレフィックス複数インターフェース」（MPMI）と呼ばれます。この場合、ホストは、上流ルーターがIPv6接頭辞を書き換える必要をなくすために、送信元アドレス選択と送信元依存ルーティングの両方をサポートする必要があります。
Several limitations arise in multihoming contexts based on NAT and IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]; see, for example, [RFC4116]. NPTv6 is out of scope for this document.
NATとIPv6-to-IPv6ネットワークプレフィックス変換（NPTv6）[RFC6296]に基づくマルチホーミングコンテキストでは、いくつかの制限が発生します。たとえば、[RFC4116]を参照してください。 NPTv6はこのドキュメントの範囲外です。
This document was initially written to inform the community about the SADR problem space. It was updated to record the various sets of alternate solutions to address that problem space. The 6man WG consensus is documented in [RFC8028].
このドキュメントは当初、SADR問題空間についてコミュニティに知らせるために作成されました。その問題の領域に対処するための代替ソリューションのさまざまなセットを記録するように更新されました。 6man WGコンセンサスは[RFC8028]に文書化されています。
This section describes a set of scenarios to illustrate the SADR problem. Scenarios are listed in order of increasing complexity.
このセクションでは、SADR問題を説明する一連のシナリオについて説明します。シナリオは、複雑さが増す順にリストされています。
The scenario shown in Figure 1 is a multi-prefix multihoming use case. "rtr" is a CPE router that is connected to two Network Providers, each advertising its own prefixes. In this case, the host may have a single interface, but it receives multiple prefixes from the upstream Network Providers. Assuming that providers apply the ingress filtering policy, the packets for any external communication from the host should follow source-address-dependent routing in order to avoid getting dropped.
図1に示すシナリオは、マルチプレフィックスマルチホーミングの使用例です。 「rtr」は、2つのネットワークプロバイダーに接続されたCPEルーターで、それぞれが独自のプレフィックスをアドバタイズします。この場合、ホストには単一のインターフェースがありますが、上流のネットワークプロバイダーから複数のプレフィックスを受け取ります。プロバイダーが入力フィルタリングポリシーを適用すると想定すると、ホストからの外部通信用のパケットは、ドロップされないように、送信元アドレス依存のルーティングに従う必要があります。
In this scenario, the host does not need to perform source-dependent routing; it only needs to perform source address selection.
このシナリオでは、ホストはソース依存ルーティングを実行する必要はありません。送信元アドレスの選択のみを実行する必要があります。
+------+ |
| | | (Network)
| | |=====|(Provider 1)|=====
| | +------+ |
| | | | |
| |=====| rtr |=====|
| host | | | |
| | +------+ |
| | |
| | | (Network)
| | |=====|(Provider 2)|=====
| | |
+------+ |
Figure 1: Multihomed Host with Multiple CPE Routers
図1：複数のCPEルーターを備えたマルチホームホスト
The scenario shown in Figure 2 is multi-prefix multi-interface, where "rtr1" and "rtr2" represent CPE routers and there are exit routers in both "network 1" and "network 2". If the packets from the host communicating with a remote destination are routed to the wrong exit router, i.e., they carry the wrong source address, they will get dropped due to ingress filtering.
図2に示すシナリオはマルチプレフィックスマルチインターフェイスです。「rtr1」と「rtr2」はCPEルーターを表し、「ネットワーク1」と「ネットワーク2」の両方に出口ルーターがあります。リモート宛先と通信しているホストからのパケットが間違った出口ルーターにルーティングされる場合、つまり、それらが間違った送信元アドレスを運ぶ場合、それらは入力フィルタリングのためにドロップされます。
In order to avoid complications when sending packets and to avoid the need to rewrite the source IPv6 prefix, the host is required to perform both source address selection and source-dependent routing so that the appropriate next hop is selected while taking into account the source address.
パケット送信時の複雑さを回避し、ソースIPv6プレフィックスを書き換える必要を回避するために、ホストはソースアドレス選択とソース依存ルーティングの両方を実行して、ソースアドレスを考慮しながら適切なネクストホップが選択されるようにする必要があります。 。
+------+ +------+ ___________
| | | | / \
| |-----| rtr1 |=====/ network \
| | | | \ 1 /
| | +------+ \___________/
| |
| host |
| |
| | +------+ ___________
| | | | / \
| |=====| rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
Figure 2: Multiple Interfaced Host with Two CPE Routers
図2：2つのCPEルーターを備えた複数のインターフェースホスト
There is a variant of Figure 2 that is often referred to as a corporate VPN, i.e., a secure tunnel from the host to a router attached to a corporate network. In this case, "rtr2" provides access directly to the corporate network, and the link from the host to "rtr2" is a secure tunnel (for example, an IPsec tunnel). Therefore, the interface is a virtual interface with its own IP address/prefix assigned by the corporate network.
図2には、企業VPN、つまりホストから企業ネットワークに接続されたルーターへの安全なトンネルと呼ばれるバリアントがあります。この場合、「rtr2」は企業ネットワークへの直接アクセスを提供し、ホストから「rtr2」へのリンクは安全なトンネル（たとえば、IPsecトンネル）です。したがって、インターフェイスは、企業ネットワークによって割り当てられた独自のIPアドレス/プレフィックスを持つ仮想インターフェイスです。
+------+ +------+ ___________
| |-----| rtr1 | / \
| ==========\\ |=====/ network \
| |-----| || | \ 1 /
| | +--||--+ \___________/
| | ||
| host | ||
| | ||
| | +--||--+ ___________
| | | | / corporate \
| | | rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
Figure 3: VPN Case
図3：VPNケース
There are at least two sub-cases:
少なくとも2つのサブケースがあります。
a. Dedicated forwarding entries are created in the host such that only traffic directed to the corporate network is sent to "rtr2"; everything else is sent to "rtr1".
a. 専用の転送エントリがホストで作成され、企業ネットワークに向けられたトラフィックのみが「rtr2」に送信されます。その他はすべて「rtr1」に送信されます。
b. All traffic is sent to "rtr2" and then routed to the Internet if necessary. This case doesn't need host routes but leads to unnecessary traffic and latency because of the path stretch via "rtr2".
b. すべてのトラフィックは「rtr2」に送信され、必要に応じてインターネットにルーティングされます。この場合、ホストルートは必要ありませんが、「rtr2」を介したパスストレッチにより、不要なトラフィックと遅延が発生します。
In the homenet scenario depicted in Figure 4, representing a simple home network, there is a host connected to a local network that is serviced with two CPEs that are connected to Providers 1 and 2, respectively. Each network delegates a different prefix. Also, each router provides a different prefix to the host. The issue in this scenario is that ingress filtering is used by each provider. This scenario can be considered as a variation of the scenario described in Section 2.2.
単純なホームネットワークを表す図4に示すホームネットシナリオでは、プロバイダー1と2にそれぞれ接続されている2つのCPEでサービスされるローカルネットワークに接続されたホストがあります。各ネットワークは異なるプレフィックスを委任します。また、各ルーターはホストに異なるプレフィックスを提供します。このシナリオの問題は、入力プロバイダーが各プロバイダーによって使用されることです。このシナリオは、セクション2.2で説明されているシナリオのバリエーションと考えることができます。
+------+
| | +------+
| | | | (Network)
| |==+==| rtr1 |====|(Provider 1)|=====
| | | | |
| | | +------+
| host | |
| | |
| | | +------+
| | | | | (Network)
| | +==| rtr2 |====|(Provider 2)|=====
| | | |
+------+ +------+
Figure 4: Simple Home Network with Two CPE Routers
図4：2つのCPEルーターを備えたシンプルなホームネットワーク
The host has to select the source address from the prefixes of Providers 1 or 2 when communicating with other hosts in Provider 1 or 2. The next issue is to select the correct next-hop router, "rtr1" or "rtr2" that can reach the correct provider, Network Provider 1 or 2.
ホストは、プロバイダー1または2の他のホストと通信するときに、プロバイダー1または2のプレフィックスからソースアドレスを選択する必要があります。次の問題は、到達可能な正しいネクストホップルーター「rtr1」または「rtr2」を選択することです。正しいプロバイダー、ネットワークプロバイダー1または2。
A variation of the scenario in Section 2.1 is specialized egress routing. Upstream networks offer different services with specific requirements, e.g., Voice over IP (VoIP) or IPTV. The hosts using this service need to use the service's source and destination addresses. No other service will accept this source address, i.e., those packets will be dropped [SD_RTG].
セクション2.1のシナリオのバリエーションは、特殊な出力ルーティングです。アップストリームネットワークは、Voice over IP（VoIP）やIPTVなど、特定の要件を持つさまざまなサービスを提供します。このサービスを使用するホストは、サービスの送信元アドレスと宛先アドレスを使用する必要があります。他のサービスはこのソースアドレスを受け入れません。つまり、これらのパケットはドロップされます[SD_RTG]。
Both source address selection and source-dependent routing are required to be performed by the host.
送信元アドレスの選択と送信元に依存するルーティングの両方が、ホストによって実行される必要があります。
___________ +------+
/ \ +------+ | |
/ network \ | | | |
\ 1 /--| rtr1 |----| |
\___________/ | | | | +------+ ___________
+------+ | host | | | / \
| |=====| rtr3 |=====/ network \
___________ | | | | \ 3 /
/ \ +------+ | | +------+ \___________/
/ network \ | | | |
\ 2 /--| rtr2 |----| |
\___________/ | | | |
+------+ | |
+------+
Figure 5: Multi-Interfaced Host with Three CPE Routers
図5：3つのCPEルーターを備えたマルチインターフェイスホスト
The scenario shown in Figure 5 is a variation of a multi-prefix multi-interface scenario (Section 2.2). "rtr1", "rtr2", and "rtr3" are CPE routers. The networks apply ingress routing. Source-address-dependent routing should be used to avoid dropping any external communications.
図5に示すシナリオは、マルチプレフィックス、マルチインターフェイスのシナリオ（セクション2.2）のバリエーションです。 「rtr1」、「rtr2」、および「rtr3」はCPEルーターです。ネットワークは入力ルーティングを適用します。送信元アドレスに依存するルーティングを使用して、外部通信のドロップを回避する必要があります。
SADR can be facilitated at the host with proper source address and next-hop selection. For this, each router connected to different interfaces of the host uses Router Advertisements (RAs) [RFC4861] to distribute a default route, the next hop, and the source address/ prefix information to the host. As a reminder, while the Prefix Information Option (PIO) is defined in [RFC4861], the Route Information Option (RIO) is defined in [RFC4191].
適切な送信元アドレスとネクストホップの選択により、ホストでSADRを容易にすることができます。このため、ホストの異なるインターフェイスに接続されている各ルーターは、ルーターアドバタイズ（RA）[RFC4861]を使用して、デフォルトルート、ネクストホップ、ソースアドレス/プレフィックス情報をホストに配布します。注意として、プレフィックス情報オプション（PIO）は[RFC4861]で定義されていますが、ルート情報オプション（RIO）は[RFC4191]で定義されています。
Section 3.1 presents an analysis of the scenarios in Section 2, and Section 3.2 discusses the relevance of SADR to the provisioning domains.
セクション3.1はセクション2のシナリオの分析を示し、セクション3.2はSADRとプロビジョニングドメインの関連性について説明します。
As in [RFC7157], we assume that the routers in Section 2 use RAs to distribute default route and source address prefixes supported in each next hop to the hosts or that the gateway/CPE router relays this information to the hosts.
[RFC7157]と同様に、セクション2のルーターはRAを使用して、各ネクストホップでサポートされるデフォルトのルートとソースアドレスのプレフィックスをホストに配布するか、ゲートウェイ/ CPEルーターがこの情報をホストに中継すると仮定します。
Referring to Section 2.1, source address selection is undertaken by the host while source-dependent routing must be followed by "rtr" to avoid packets being dropped. No particular modification is required for next-hop selection at the host.
セクション2.1を参照すると、送信元アドレスの選択はホストによって行われ、送信元依存ルーティングの後には「rtr」が続く必要があるため、パケットがドロップされません。ホストでのネクストホップの選択に特別な変更は必要ありません。
Referring to the scenario in Figure 2, source-address-dependent routing can present a solution to the problem of when the host wishes to reach a destination in network 2 and the host chooses "rtr1" as the default router. The solution assumes that the host is correctly configured. The host should be configured with the prefixes supported in these next hops. This way the host, having received many prefixes, will have the correct information for selecting the right source address and next hop when sending packets to remote destinations.
図2のシナリオを参照すると、送信元アドレスに依存するルーティングは、ホストがネットワーク2の宛先に到達することを望み、ホストが「rtr1」をデフォルトルーターとして選択する場合の問題に対する解決策を提示できます。ソリューションは、ホストが正しく構成されていることを前提としています。ホストは、これらのネクストホップでサポートされるプレフィックスを使用して構成する必要があります。このようにして、多くのプレフィックスを受信したホストは、パケットをリモート宛先に送信するときに正しい送信元アドレスとネクストホップを選択するための正しい情報を取得します。
Note that similar considerations apply to the scenario in Figure 5.
同様の考慮事項が図5のシナリオに適用されることに注意してください。
In the configuration of the scenario (Figure 1), it is also useful to configure the host with the prefixes and source address prefixes they support. This will enable the host to select the right prefix when sending packets to the right next hop and avoid any issues with ingress filtering.
シナリオの構成（図1）では、ホストがサポートするプレフィックスとソースアドレスプレフィックスをホストに構成することも役立ちます。これにより、ホストはパケットを正しいネクストホップに送信するときに正しいプレフィックスを選択し、入力フィルタリングの問題を回避できます。
Let us analyze the scenario in Section 2.3. If a source-address-dependent routing protocol is used, the two routers ("rtr1" and "rtr2") are both able to route traffic correctly, no matter which next-hop router and source address the host selects. In case the host chooses the wrong next-hop router, e.g., "rtr1" is selected for Provider 2, "rtr1" will forward the traffic to "rtr2" to be sent to Network Provider 2 and no ingress filtering will happen.
セクション2.3のシナリオを分析してみましょう。送信元アドレスに依存するルーティングプロトコルが使用されている場合、2つのルーター（ "rtr1"と "rtr2"）はどちらも、ホストが選択するネクストホップルーターと送信元アドレスに関係なく、トラフィックを正しくルーティングできます。ホストが間違ったネクストホップルーターを選択した場合（たとえば、プロバイダー2に「rtr1」が選択されている場合）、「rtr1」はトラフィックを「rtr2」に転送してネットワークプロバイダー2に送信し、入力フィルタリングは行われません。
Note that home networks are expected to comply with requirements for source-address-dependent routing and that the routers will be configured accordingly no matter which routing protocol is used [RFC7788].
ホームネットワークは送信元アドレスに依存するルーティングの要件に準拠することが期待され、ルーターはどのルーティングプロトコルが使用されるかに関係なくそれに応じて構成されることに注意してください[RFC7788]。
This would work, but with some issues. The host traffic to Provider 2 will have to go over two links instead of one, i.e., the link bandwidth will be halved. Another possibility is that "rtr1" can send an ICMPv6 Redirect message to the host to direct the traffic to "rtr2". The host would then redirect Provider 2 traffic to "rtr2".
これは機能しますが、いくつかの問題があります。プロバイダー2へのホストトラフィックは、1つではなく2つのリンクを経由する必要があります。つまり、リンクの帯域幅が半分になります。別の可能性としては、「rtr1」がICMPv6リダイレクトメッセージをホストに送信して、トラフィックを「rtr2」に転送できる可能性があります。その後、ホストはプロバイダー2トラフィックを「rtr2」にリダイレクトします。
The problem with redirects is that the ICMPv6 Redirect message can only convey two addresses, i.e., in this case the router address, or "rtr2" address and the destination address, or the destination host in Provider 2. That means that the source address will not be communicated. As a result, the host would send packets to the same destination using both source addresses, which causes "rtr2" to send a redirect message to "rtr1", resulting in ping-pong redirects sent by "rtr1" and "rtr2".
リダイレクトに関する問題は、ICMPv6リダイレクトメッセージが2つのアドレスしか伝達できないことです。つまり、この場合、ルーターアドレス、または「rtr2」アドレスと宛先アドレス、またはプロバイダー2の宛先ホストです。つまり、ソースアドレスは連絡することはできません。その結果、ホストは両方の送信元アドレスを使用して同じ宛先にパケットを送信するため、「rtr2」が「rtr1」にリダイレクトメッセージを送信し、「rtr1」と「rtr2」が送信するピンポンリダイレクトが発生します。
A solution to these issues is to configure the host with the source address prefixes that the next hop supports. In a homenet context, each interface of the host can be configured by its next-hop router, so that all that is needed is to add the information about source address prefixes. This results in the hosts selecting the right router, no matter what.
これらの問題の解決策は、ネクストホップがサポートする送信元アドレスプレフィックスを使用してホストを構成することです。ホームネットコンテキストでは、ホストの各インターフェイスをネクストホップルーターで構成できるため、ソースアドレスプレフィックスに関する情報を追加するだけで済みます。これにより、ホストは何があっても適切なルーターを選択します。
Source-address-dependent routing in the use case of specialized egress routing (Section 2.4) may work as follows. The specialized service router advertises one or more specific prefixes with appropriate source prefixes, e.g., to the CPE router, "rtr" in Figure 1. The CPE router in turn advertises the specific service's prefixes and source prefixes to the host. This will allow proper configuration at the host so that the host can use the service by sending the packets with the correct source and destination addresses.
特殊な出力ルーティング（2.4節）の使用例における送信元アドレス依存のルーティングは、次のように機能します。専用サービスルーターは、適切なソースプレフィックスを持つ1つ以上の特定のプレフィックスをアドバタイズします。たとえば、CPEルーター（図1の「rtr」）にアドバタイズします。CPEルーターは、特定のサービスのプレフィックスとソースプレフィックスをホストにアドバタイズします。これにより、ホストで適切な構成が可能になり、ホストは正しい送信元アドレスと宛先アドレスを使用してパケットを送信することでサービスを使用できます。
A consistent set of network configuration information is called a provisioning domain (PvD). In the case of multihomed with multi-prefix (MHMP), more than one provisioning domain is present on a single link. In the case of multi-prefix multiple interface (MPMI) environments, elements of the same domain may be present on multiple links. PvD-aware nodes support association of configuration information into PvDs and use these PvDs to serve requests for network connections, e.g., choosing the right source address for the packets. PvDs can be constructed from one of more DHCP or Router Advertisement (RA) options carrying such information as PvD identity and PvD container [MPvD_NDP] [MPvD_DHCP]. PvDs constructed based on such information are called explicit PvDs [RFC7556].
一貫したネットワーク構成情報のセットは、プロビジョニングドメイン（PvD）と呼ばれます。マルチプレフィックス付きマルチホーム（MHMP）の場合、1つのリンクに複数のプロビジョニングドメインが存在します。マルチプレフィックスマルチインターフェース（MPMI）環境の場合、同じドメインの要素が複数のリンクに存在する可能性があります。 PvD対応ノードは、PvDへの構成情報の関連付けをサポートし、これらのPvDを使用して、ネットワーク接続の要求に対応します（たとえば、パケットに適切なソースアドレスを選択する）。 PvDは、PvD IDやPvDコンテナ[MPvD_NDP] [MPvD_DHCP]などの情報を運ぶ1つ以上のDHCPまたはルーターアドバタイズ（RA）オプションから構築できます。このような情報に基づいて構築されたPvDは、明示的なPvD [RFC7556]と呼ばれます。
Apart from PvD identity, PvD content may be encapsulated in separate RA or DHCP options called the PvD Container Option. These options are placed in the container options of an explicit PvD.
PvD IDとは別に、PvDコンテンツは、PvDコンテナーオプションと呼ばれる個別のRAまたはDHCPオプションにカプセル化できます。これらのオプションは、明示的なPvDのコンテナーオプションに配置されます。
Explicit PvDs may be received from different interfaces. A single PvD may be accessible over one interface or simultaneously accessible over multiple interfaces. Explicit PvDs may be scoped to a configuration related to a particular interface; however, in general, this does not apply. What matters is that the PvD identity is authenticated by the node even in cases where the node has a single connected interface. The authentication of the PvD ID should meet the level required by the node policy. Single PvD information may be received over multiple interfaces as long as the PvD ID is the same.
異なるインターフェイスから明示的なPvDを受信する場合があります。単一のPvDは、1つのインターフェースを介してアクセスできるか、複数のインターフェースを介して同時にアクセスできます。明示的なPvDは、特定のインターフェースに関連する構成にスコープを設定できます。ただし、一般的には、これは当てはまりません。重要なのは、ノードに単一の接続されたインターフェースがある場合でも、PvD IDがノードによって認証されることです。 PvD IDの認証は、ノードポリシーで必要なレベルを満たす必要があります。 PvD IDが同じである限り、複数のインターフェースを介して単一のPvD情報を受信できます。
This applies to the Router Advertisements (RAs) in which case a multihomed host (that is, with multiple interfaces) should trust a message from a router on one interface to install a route to a different router on another interface.
これはルーターアドバタイズ（RA）に適用されます。この場合、マルチホームホスト（つまり、複数のインターフェイスを持つ）は、あるインターフェイスのルーターからのメッセージを信頼して、別のインターフェイスの別のルーターへのルートをインストールする必要があります。
We presented many topologies in which a host with multiple interfaces or a multihomed host is connected to various networks or Network Providers, which in turn may apply ingress routing. The scenario analysis in Section 3.1 shows that in order to prevent packets from being dropped due to ingress routing, source-address-dependent routing is needed. Also, source-address-dependent routing should be supported by routers throughout a site that has multiple egress points.
複数のインターフェースを持つホストまたはマルチホームホストがさまざまなネットワークまたはネットワークプロバイダーに接続されている多くのトポロジを紹介しました。セクション3.1のシナリオ分析は、入力ルーティングが原因でパケットがドロップされるのを防ぐために、送信元アドレス依存のルーティングが必要であることを示しています。また、送信元アドレスに依存するルーティングは、複数の出力ポイントを持つサイト全体のルーターでサポートされる必要があります。
In this section, we provide some alternate solutions vis-a-vis the scenarios presented in Section 2. We start with Rule 5.5 in [RFC6724] for source address selection and the scenarios it solves, and then continue with solutions that state exactly what information hosts need in terms of new Router Advertisement options for correct source address selection in those scenarios. No recommendation is made in this section.
このセクションでは、セクション2で示したシナリオに対していくつかの代替ソリューションを提供します。[RFC6724]のルール5.5から開始して、ソースアドレスの選択とそれが解決するシナリオを示し、次に、どの情報を正確に示すソリューションを続行します。ホストは、これらのシナリオで正しい送信元アドレスを選択するために、新しいルーターアドバタイズメントオプションに関して必要です。このセクションでは推奨事項はありません。
There is a need to configure the host not only with the prefixes, but also with the source prefixes that the next-hop routers support. Such a configuration may prevent the host from getting ingress/egress policy error messages such as ICMP source address failure messages.
プレフィックスだけでなく、ネクストホップルーターがサポートするソースプレフィックスもホストに設定する必要があります。このような構成では、ホストがICMP送信元アドレスエラーメッセージなどの入出力ポリシーエラーメッセージを取得できない場合があります。
If host configuration is done using Router Advertisement messages, then there is a need to define new Router Advertisement options for source-address-dependent routing. These options include the Route Prefix with Source Address/Prefix Option. Other options such as the Next-Hop Address with the Route Prefix Option and the Next-Hop Address with the Source Address and Route Prefix Option will be considered in Section 4.2.
ルーターアドバタイズメッセージを使用してホスト設定を行う場合、送信元アドレス依存型ルーティングの新しいルーターアドバタイズオプションを定義する必要があります。これらのオプションには、送信元アドレス/プレフィックスオプション付きのルートプレフィックスが含まれます。ルートプレフィックスオプション付きのネクストホップアドレス、ソースアドレスとルートプレフィックスオプション付きのネクストホップアドレスなどの他のオプションについては、セクション4.2で検討します。
As discussed in Section 3.1, the scenario in Figure 4 can be solved by defining a new Router Advertisement option.
セクション3.1で説明したように、図4のシナリオは、新しいルーターアドバタイズメントオプションを定義することで解決できます。
If host configuration is done using DHCP, then there is a need to define new DHCP options for Route Prefix with Source Address/Prefix. As mentioned above, DHCP server configuration is interface specific. New DHCP options for source-address-dependent routing such as route prefix and source prefix need to be configured separately for each interface.
ホスト構成がDHCPを使用して行われる場合、ソースアドレス/プレフィックス付きのルートプレフィックスの新しいDHCPオプションを定義する必要があります。上記のように、DHCPサーバーの構成はインターフェイス固有です。ルートプレフィックスやソースプレフィックスなどのソースアドレス依存ルーティングの新しいDHCPオプションは、インターフェイスごとに個別に構成する必要があります。
The scenario in Figure 4 can be solved by defining a new DHCP option.
図4のシナリオは、新しいDHCPオプションを定義することで解決できます。
Rule 5.5 for source address selection may be a solution for selecting the right source addresses for each next hop, but there are cases where the next-hop routers on each interface of the host are not known by the host initially. Such use cases are out of scope. Guidelines for use cases that require the Router Advertisement option set involving third-party next-hop addresses are also out of scope.
送信元アドレスの選択に関するルール5.5は、各ネクストホップに適切な送信元アドレスを選択するためのソリューションである可能性がありますが、ホストの各インターフェイス上のネクストホップルーターがホストによって最初に認識されない場合があります。このようなユースケースは範囲外です。サードパーティのネクストホップアドレスを含むルーターアドバタイズメントオプションセットを必要とする使用例のガイドラインも対象外です。
One possible solution is Rule 5.5 in [RFC6724], the default rule for source address selection, which recommends selecting the source addresses advertised by the next hop. Considering the above scenarios, we can state that this rule can solve the problem in Figures 1, 2, and 5.
考えられる解決策の1つは、[RFC6724]のRule 5.5です。これは、送信元アドレス選択のデフォルトルールであり、ネクストホップによってアドバタイズされる送信元アドレスを選択することを推奨しています。上記のシナリオを考慮すると、このルールは図1、2、および5の問題を解決できると言えます。
Source address selection rules can be distributed by the DHCP server using the DHCP option OPTION_ADDRSEL_TABLE defined in [RFC7078].
送信元アドレス選択ルールは、[RFC7078]で定義されているDHCPオプションOPTION_ADDRSEL_TABLEを使用して、DHCPサーバーによって配布できます。
In case of DHCP-based host configuration, the DHCP server can configure only the interface of the host to which it is directly connected. In order for Rule 5.5 to apply on other interfaces, the option should be sent on those interfaces as well using the DHCPv6 address selection policy option defined in [RFC7078].
DHCPベースのホスト構成の場合、DHCPサーバーは、直接接続されているホストのインターフェースのみを構成できます。ルール5.5が他のインターフェースに適用されるようにするには、[RFC7078]で定義されているDHCPv6アドレス選択ポリシーオプションを使用して、これらのインターフェースでもオプションを送信する必要があります。
Rule 5.5, the default rule for source address selection, solves that problem when an application sends a packet with an unspecified source address. In the presence of two default routes, one route will be chosen, and Rule 5.5 will make sure that the right source address is used.
送信元アドレス選択のデフォルトルールであるRule 5.5は、アプリケーションが送信元アドレスが指定されていないパケットを送信するときの問題を解決します。 2つのデフォルトルートが存在する場合、1つのルートが選択され、Rule 5.5は正しい送信元アドレスが使用されることを確認します。
When the application selects a source address, i.e., the source address is chosen before next-hop selection, even though the source address is a way for the application to select the exit point, in this case, that purpose will not be served. In the presence of multiple default routes, one will be picked, ignoring the source address that was selected by the application because it is known that IPv6 implementations are not required to remember which next hops advertised which prefixes. Therefore, the next-hop router may not be the correct one, and the packets may be filtered.
アプリケーションがソースアドレスを選択する場合、つまり、ソースアドレスはアプリケーションが出口点を選択するための方法である場合でも、ネクストホップの選択前にソースアドレスが選択されますが、この場合、その目的は果たされません。複数のデフォルトルートが存在する場合は、アプリケーションによって選択された送信元アドレスを無視して1つが選択されます。これは、IPv6実装では、どのプレフィックスがアドバタイズされたネクストホップを通知する必要がないことがわかっているためです。したがって、ネクストホップルーターが正しくない場合があり、パケットがフィルター処理される場合があります。
This implies that the hosts should register which next-hop router announced each prefix. It is required that RAs be sent by the routers and that they contain PIO on all links. It is also required that the hosts remember the source addresses of the routers that sent PIOs together with the prefixes advertised. This can be achieved by updating redirect rules specified in [RFC4861]. [RFC8028] further elaborates this to specify to which router a host should present its transmission.
これは、ホストが各ネクストホップルータが各プレフィックスをアナウンスすることを登録する必要があることを意味します。 RAはルーターによって送信され、すべてのリンクにPIOが含まれている必要があります。ホストは、PIOをアドバタイズされたプレフィックスと一緒に送信したルーターのソースアドレスを覚えておく必要もあります。これは、[RFC4861]で指定されているリダイレクトルールを更新することで実現できます。 [RFC8028]は、これをさらに詳しく説明して、ホストが送信を提示するルーターを指定します。
The source-address-dependent routing solution is not complete without support from the edge routers. All routers in edge networks need to be required to support routing based on not only the destination address but also the source address. All edge routers need to be required to satisfy filters as defined in BCP 38.
送信元アドレスに依存するルーティングソリューションは、エッジルーターのサポートなしでは完全ではありません。エッジネットワークのすべてのルーターは、宛先アドレスだけでなく送信元アドレスにも基づくルーティングをサポートする必要があります。すべてのエッジルーターは、BCP 38で定義されているフィルターを満たす必要があります。
This document describes some use cases, and thus brings no additional security risks. Solution documents should further elaborate on specific security considerations.
このドキュメントでは、いくつかの使用例について説明しているため、追加のセキュリティリスクはありません。ソリューションドキュメントでは、特定のセキュリティに関する考慮事項についてさらに詳しく説明する必要があります。
[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>。
[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 >。
[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>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<http：//www.rfc-editor .org / info / rfc5340>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <http://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月、<http://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, <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>。
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy Using DHCPv6", RFC 7078, DOI 10.17487/RFC7078, January 2014, <http://www.rfc-editor.org/info/rfc7078>.
[RFC7078]マツモトA.、藤崎T.、およびT. Chown、「DHCPv6を使用したアドレス選択ポリシーの配布」、RFC 7078、DOI 10.17487 / RFC7078、2014年1月、<http://www.rfc-editor.org / info / rfc7078>。
[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, <http://www.rfc-editor.org/info/rfc8028>.
[RFC8028]ベイカー、F.、B。カーペンター、「マルチプレフィックスネットワーク内のホストによるファーストホップルーターの選択」、RFC 8028、DOI 10.17487 / RFC8028、2016年11月、<http：//www.rfc-editor。 org / info / rfc8028>。
[INGRESS_FIL] Huitema, C., Draves, R., and M. Bagnulo, "Ingress filtering compatibility for IPv6 multihomed sites", Work in Progress, draft-huitema-multi6-ingress-filtering-00, October 2004.
[INGRESS_FIL] Huitema、C.、Draves、R。、およびM. Bagnulo、「IPv6マルチホームサイトのイングレスフィルタリングの互換性」、Work in Progress、draft-huitema-multi6-ingress-filtering-00、2004年10月。
[ISO.10589.1992] International Organization for Standardization, "Intermediate system to intermediate system intra-domain-routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473), ISO Standard 10589", ISO ISO.10589.1992, 1992.
[ISO.10589.1992]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）、ISO標準10589を提供するためのプロトコルと組み合わせて使用するための中間システムから中間システムへのドメイン内ルーティングルーチン情報交換プロトコル」、 ISO ISO.10589.1992、1992。
[MPvD_DHCP] Krishnan, S., Korhonen, J., and S. Bhandari, "Support for multiple provisioning domains in DHCPv6", Work in Progress, draft-ietf-mif-mpvd-dhcp-support-02, October 2015.
[MPvD_DHCP]クリシュナン、S.、Korhonen、J。、およびS. Bhandari、「DHCPv6での複数のプロビジョニングドメインのサポート」、作業中、draft-ietf-mif-mpvd-dhcp-support-02、2015年10月。
[MPvD_NDP] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol", Work in Progress, draft-ietf-mif-mpvd-ndp-support-03, February 2016.
[MPvD_NDP] Korhonen、J.、Krishnan、S。、およびS. Gundavelli、「IPv6近隣探索プロトコルでの複数のプロビジョニングドメインのサポート」、作業中、draft-ietf-mif-mpvd-ndp-support-03、2月2016。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, DOI 10.17487/RFC4116, July 2005, <http://www.rfc-editor.org/info/rfc4116>.
[RFC4116] Abley、J.、Lindqvist、K.、Davies、E.、Black、B。、およびV. Gill、「IPv4マルチホーミングの実践と制限」、RFC 4116、DOI 10.17487 / RFC4116、2005年7月、<http： //www.rfc-editor.org/info/rfc4116>。
[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 >。
[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>。
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, <http://www.rfc-editor.org/info/rfc7556>.
[RFC7556] Anipko、D。、編、「Multiple Provisioning Domain Architecture」、RFC 7556、DOI 10.17487 / RFC7556、2015年6月、<http://www.rfc-editor.org/info/rfc7556>。
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <http://www.rfc-editor.org/info/rfc7788>.
[RFC7788] Stenberg、M.、Barth、S。、およびP. Pfister、「Home Networking Control Protocol」、RFC 7788、DOI 10.17487 / RFC7788、2016年4月、<http://www.rfc-editor.org/info / rfc7788>。
[SD_RTG] Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and Use Cases for Source/Destination Routing", Work in Progress, draft-baker-rtgwg-src-dst-routing-use-cases-02, April 2016.
[SD_RTG] Baker、F.、Xu、M.、Yang、S.、J。Wu、「Source / Destination Routingの要件と使用例」、Work in Progress、draft-baker-rtgwg-src-dst-routing -use-cases-02、2016年4月。
[SD_RTG_ISIS] Baker, F. and D. Lamparter, "IPv6 Source/Destination Routing using IS-IS", Work in Progress, draft-baker-ipv6- isis-dst-src-routing-06, October 2016.
[SD_RTG_ISIS]ベイカー、F。およびD.ランパーター、「IS-ISを使用したIPv6ソース/宛先ルーティング」、作業中、draft-baker-ipv6- isis-dst-src-routing-06、2016年10月。
[SD_RTG_OSPF] Baker, F., "IPv6 Source/Destination Routing using OSPFv3", Work in Progress, draft-baker-ipv6-ospf-dst-src-routing-03, August 2013.
[SD_RTG_OSPF]ベイカー、F。、「OSPFv3を使用したIPv6ソース/宛先ルーティング」、作業中、draft-baker-ipv6-ospf-dst-src-routing-03、2013年8月。
Acknowledgements
謝辞
In writing this document, we benefited from the ideas expressed by the electronic mail discussion participants on 6man Working Group: Brian Carpenter, Ole Troan, Pierre Pfister, Alex Petrescu, Ray Hunter, Lorenzo Colitti, and others.
このドキュメントを書くにあたり、ブライアンカーペンター、オレトローン、ピエールフィスター、アレックスペトレスク、レイハンター、ロレンソコリッティなどの6manワーキンググループの電子メールディスカッション参加者が表明したアイデアを活用しました。
Pierre Pfister proposed the scenario in Figure 4 as well as some text for Rule 5.5.
Pierre Pfisterは、図4のシナリオと、ルール5.5のテキストを提案しました。
The text on corporate VPN in Section 2 was provided by Brian Carpenter.
セクション2の企業VPNに関するテキストは、Brian Carpenterによって提供されました。
Authors' Addresses
著者のアドレス
Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 175 Plano, TX 75024 United States of America
Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 175 Plano、TX 75024アメリカ合衆国
Email: sarikaya@ieee.org
Mohamed Boucadair Orange Rennes 35000 France
Mohamed Boucadair Orange Rennes 35000フランス
Email: mohamed.boucadair@orange.com