[要約] RFC 9079は、Babelルーティングプロトコルにおけるソース固有ルーティングの拡張を定義します。この文書の目的は、特定のソースからのトラフィックに対して特定の経路を選択する能力をBabelに追加することです。これは、マルチホーム接続や特定のトラフィックフローの最適化など、複数のインターネット接続がある環境で特に有用です。
Internet Engineering Task Force (IETF) M. Boutier
Request for Comments: 9079 J. Chroboczek
Category: Standards Track IRIF, University of Paris
ISSN: 2070-1721 August 2021
Source-Specific Routing in the Babel Routing Protocol
Babelルーティングプロトコルにおけるソース固有のルーティング
Abstract
概要
Source-specific routing, also known as Source Address Dependent Routing (SADR), is an extension to traditional next-hop routing where packets are forwarded according to both their destination address and their source address. This document describes an extension for source-specific routing to the Babel routing protocol.
ソースアドレス依存ルーティング（SADR）とも呼ばれるソース固有のルーティングは、パケットがそれらの宛先アドレスとその送信元アドレスの両方に従って転送される従来のネクストホップルーティングの拡張です。このドキュメントでは、Babelルーティングプロトコルへのソース固有のルーティングの拡張機能について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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）の製品です。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 https://www.rfc-editor.org/info/rfc9079.
この文書の現在のステータスに関する情報、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9079で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction and Background
1.1. Application to Multihoming
1.2. Other Applications
1.3. Specificity of Prefix Pairs
2. Specification of Requirements
3. Data Structures
3.1. The Source Table
3.2. The Route Table
3.3. The Table of Pending Seqno Requests
4. Data Forwarding
5. Protocol Operation
5.1. Protocol Messages
5.2. Wildcard Messages
6. Compatibility with the Base Protocol
6.1. Starvation and Blackholes
7. Protocol Encoding
7.1. Source Prefix Sub-TLV
7.2. Source-Specific Update
7.3. Source-Specific Route Request
7.4. Source-Specific Seqno Request
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
The Babel routing protocol [RFC8966] is a distance vector routing protocol for next-hop routing. In next-hop routing, each node maintains a forwarding table that maps destination prefixes to next hops. The forwarding decision is a per-packet operation that depends on the destination address of the packets and on the entries of the forwarding table. When a packet is about to be routed, its destination address is compared to the prefixes of the routing table: the entry with the most specific prefix containing the destination address of the packet is chosen, and the packet is forwarded to the associated next hop. Next-hop routing is a simple, well-understood paradigm that works satisfactorily in a large number of cases.
Babelルーティングプロトコル[RFC8966]は、ネクストホップルーティング用の距離ベクトルルーティングプロトコルです。ネクストホップルーティングでは、各ノードは宛先プレフィックスを次のホップにマッピングする転送テーブルを維持します。転送決定は、パケットの宛先アドレスと転送テーブルのエントリに依存するパケットごとの操作です。パケットがルーティングされようとしている場合、その宛先アドレスはルーティングテーブルの接頭辞と比較されます。パケットの宛先アドレスを含む最も特有のプレフィックスを持つエントリが選択され、パケットは関連する次のホップに転送されます。ネクストホップルーティングは、多数の場合に満足のいくように機能する単純でよく理解されているパラダイムです。
The use of next-hop routing limits the flexibility of the routing system in two ways. First, since the routing decision is local to each router, a router A can only select a route ABC...Z if its neighbouring router B has selected the route BC...Z. Second, the only criterion used by a router to choose a route is the destination address: two packets with the same destination follow the same route. Yet, there are other data in the IP header that could conceivably be used to guide the routing decision -- the Type of Service (ToS) octet and, of course, the source address.
NEXTホップルーティングの使用は、ルーティングシステムの柔軟性を2つの方法で制限します。まず、ルーティング判定は各ルータに対してローカルであるため、隣接ルータBがルートBC ... Zを選択した場合にのみルータABC ... Zを選択できます。第二に、ルータがルータを選択するためにルータが使用する唯一の基準は宛先アドレスです。同じ宛先の2つのパケットが同じルートに従います。それでも、IPヘッダーには、ルーティング決定を導くために考えられる可能性がある他のデータがあります - サービスの種類（TOS）オクテット、およびもちろん送信元アドレス。
Source-specific routing [SS-ROUTING], or Source Address Dependent Routing (SADR), is a modest extension to next-hop routing where the forwarding decision depends not only on the destination address but also on the source address of the packet being routed, which makes it possible for two packets with the same destination but different source addresses to be routed following different paths.
ソース固有のルーティング[SS-routing]、または送信元アドレス依存ルーティング（SADR）は、転送決定が宛先アドレスだけでなく、ルーティングされているパケットの送信元アドレスにも依存するネクストホップルーティングへの適度な拡張です。これにより、同じ宛先を持つ2つのパケットが異なるパスに従ってルーティングされる可能性があります。
This document describes a source-specific routing extension for the Babel routing protocol [RFC8966]. This involves minor changes to the data structures, which must include a source prefix in addition to the destination prefix already present, and some changes to the Update, Route Request, and Seqno Request TLVs, which are extended with a source prefix. The source prefix is encoded using a mandatory sub-TLV ([RFC8966], Section 4.4).
このドキュメントでは、Babelルーティングプロトコル[RFC8966]のソース固有のルーティング拡張機能について説明します。これはデータ構造に対するマイナーな変更を含みます。これは、既に存在する宛先プレフィックスに加えてソースプレフィックスを含める必要があります。これは、ソースプレフィックスで拡張された更新、ルートリクエスト、およびSEQNOリクエストTLVSに変更されます。ソースプレフィックスは、必須サブTLVを使用してエンコードされます（[RFC8966]、セクション4.4）。
Multihoming is the practice of connecting a single network to two or more transit networks. The main application of source-specific routing is a form of multihoming known as "multihoming with multiple addresses".
マルチホーム化は、単一のネットワークを2つ以上のトランジットネットワークに接続する習慣です。ソース固有のルーティングの主な適用は、「複数のアドレスを持つマルチホーム」として知られるマルチホームの形式です。
Classical multihoming consists of assigning a provider-independent range of addresses to the multihomed network and announcing it to all transit providers. While classical multihoming works well for large networks, the cost of obtaining a provider-independent address range and announcing it globally in the Internet is prohibitive for small networks. Unfortunately, it is not possible to implement classical multihoming with ordinary provider-dependent addresses: in a network connected to two providers A and B, a packet with a source address allocated by A needs to be routed through the edge router connected to A. If it is routed through the edge router connected to B, it will most likely be filtered (dropped), in accordance with [BCP84].
Classical Multihomingは、プロバイダに依存しないアドレスの範囲をマルチホームネットワークに割り当て、それをすべてのトランジットプロバイダにアナウンスします。クラシックマルチホーム化は大規模ネットワークにうまく機能しますが、プロバイダに依存しない住所範囲を入手し、インターネットでグローバルに発表するコストは、小規模ネットワークでは法外です。残念ながら、通常のプロバイダ依存アドレスを使用して古典的なマルチホームを実装することはできません.2つのプロバイダAとBに接続されているネットワークでは、Aに接続されているエッジルーターを介して割り当てられたソースアドレスを持つパケットを使用する必要があります。それはBに接続されているエッジルータを介してルーティングされます、[BCP84]に従って、それは最も可能性が高いでしょう（ドロップ）。
In multihoming with multiple addresses, every host in the multihomed network is assigned multiple addresses, one for each transit provider. Additional mechanisms are needed in order (i) to choose, for each packet, a source address that is associated with a provider that is currently up, and (ii) to route each packet towards the router connected to the provider associated with its source address. One might argue that multihoming with multiple addresses splits the difficult problem of multihoming into two simpler sub-problems.
複数のアドレスを持つマルチホームでは、マルチホームネットワーク内のすべてのホストには、各トランジットプロバイダに対して1つずつ複数のアドレスが割り当てられています。（i）各パケットについて、現在アップしているプロバイダに関連付けられている送信元アドレス、およびその送信元アドレスに関連付けられているプロバイダに接続されているルータに関連する送信元アドレスを選択する。。複数のアドレスによるマルチホーム化は、マルチホームの困難な問題を2つのより単純なサブ問題に分割すると主張するかもしれません。
The issue of choosing a suitable source address is a decision local to the sending host and is an area of active research. The simplest solution is to use a traditional transport-layer protocol, such as TCP, and to probe all available source addresses at connection time, analogously to what is already done with destination addresses, either sequentially [RFC6724] or in parallel [RFC8305]. Since the transport-layer protocol is not aware of the multiple available addresses, flows are interrupted when the selected provider goes down (from the point of view of the user, all TCP connections are dropped when the network environment changes). A better user experience can be provided by making all of the potential source and destination addresses available to higher-layer protocols, either at the transport layer [RFC8684] [RFC4960] or at the application layer [RFC8445].
適切な送信元アドレスを選択するという問題は、送信側のホストに対する地域の決定であり、活発な研究の分野です。最も簡単な解決策は、TCPなどの従来のトランスポート層プロトコルを使用し、接続時にすべての利用可能な送信元アドレスを使用して、宛先アドレスを使用しているものと同様に、順次[RFC6724]または並行して[RFC8305]。トランスポート層プロトコルは複数の利用可能なアドレスを認識していないので、選択されたプロバイダがダウンしたときにフローが中断されます（ユーザーのビューの点から、ネットワーク環境が変更されたときにすべてのTCP接続が削除されます）。トランスポート層[RFC8684] [RFC4960]またはアプリケーション層[RFC8445]のいずれかで、潜在的なソースアドレスと宛先アドレスをすべての潜在的なプロトコルに使用できるようにすることで、より良いユーザーエクスペリエンスを提供できます。
Source-specific routing solves the problem of routing a packet to the edge router indicated by its source address. Every edge router announces into the routing domain a default route specific to the prefix associated with the provider it is connected to. This route is propagated all the way to the routers on the access link, which are therefore able to route every packet to the correct router. Hosts simply send packets to their default router -- no host changes are necessary at the network layer.
ソース固有のルーティングは、その送信元アドレスによって示されたエッジルータにパケットをルーティングするという問題を解決します。すべてのエッジルーターは、接続されているプロバイダーに関連付けられているプレフィックスに固有のデフォルトルートをルーティングドメインにアナウンスします。このルートはアクセスリンク上のルータまでずっと伝播されます。したがって、すべてのパケットを正しいルータにルーティングすることができます。ホストは単に自分のデフォルトルータにパケットを送信するだけです - ネットワーク層でホストの変更は不要です。
In addition to multihoming with multiple addresses, we are aware of two applications of source-specific routing. Tunnels and VPNs are packet encapsulation techniques that are commonly used in the Internet to establish a network-layer topology that is different from the physical topology. In some deployments, the default route points at the tunnel; this causes the network stack to attempt to send encapsulated packets through the tunnel, which causes it to break. Various solutions to this problem are possible, the most common of which is to point a host route at the tunnel endpoint.
複数のアドレスを持つマルチホームに加えて、ソース固有のルーティングの2つのアプリケーションを認識しています。トンネルとVPNSは、物理的トポロジとは異なるネットワーク層トポロジを確立するためにインターネットで一般的に使用されているパケットカプセル化技術です。展開によっては、デフォルトのルートがトンネルで点を指します。これにより、ネットワークスタックはトンネルを介してカプセル化されたパケットを送信しようとします。この問題に対するさまざまな解決策が可能です。最も一般的なものは、トンネルエンドポイントでホストルートを指すことです。
When source-specific routing is available, it becomes possible to announce through the tunnel a default route that is specific to the prefix served by the tunnel. Since the encapsulated packets have a source address that is not within that prefix, they are not routed through the tunnel.
ソース固有のルーティングが利用可能な場合は、トンネルが提供するプレフィックスに固有のデフォルトルートがトンネルを通過することが可能になります。カプセル化されたパケットにはその接頭辞内にない送信元アドレスがあるため、トンネルを介してルーティングされません。
The third application of source-specific routing is controlled anycast. Anycast is a technique in which a single destination address is used to represent multiple network endpoints, collectively called an "anycast group". A packet destined to the anycast group is routed to an arbitrary member of the group, typically the one that is nearest according to the routing protocol.
ソース固有のルーティングの3番目のアプリケーションは、エネルギーキャスト制御されます。Anycastは、単一の宛先アドレスが複数のネットワークエンドポイントを表すために使用され、まとめて「Anycast Group」と呼びます。Anycastグループ宛てのパケットは、グループの任意のメンバーにルーティングされ、通常はルーティングプロトコルに従って最も近いものです。
In many applications of anycast, such as DNS root servers, the nondeterminism of anycast is acceptable; some applications, however, require finer control. For example, in some Content Distribution Networks (CDNs), every endpoint is expected to handle a well-defined subset of the client population. With source-specific routing, it is possible for each member of the anycast group to announce a route specific to its client population, a technique that is both simpler and more robust than manually tweaking the routing protocol's metric ("prepending" in BGP).
DNSルートサーバーなどのAnycastの多くのアプリケーションでは、エニーキャストの非証明主義は受け入れられます。ただし、いくつかのアプリケーションはより細かい制御を必要とします。たとえば、一部のコンテンツ配信ネットワーク（CDNS）では、すべてのエンドポイントがクライアント数の明確に定義されたサブセットを処理することが期待されています。ソース固有のルーティングでは、Anycastグループの各メンバーは、クライアントの人口に固有のルートをアナウンスすることができます。これは、ルーティングプロトコルのメトリックを手動で微調整するよりも簡単で堅牢なテクニックです（BGPの「先頭」）。
In ordinary next-hop routing, when multiple routing table entries match the destination of a packet, the "longest prefix rule" mandates that the most specific entry applies. The reason why this rule makes sense is that the set of prefixes has the following "tree property":
通常のネクストホップルーティングでは、複数のルーティングテーブルエントリがパケットの宛先と一致する場合、「最長プレフィックスルール」は、最も特定のエントリが適用されることを必須です。この規則が理にかなっている理由は、プレフィックスのセットに次の「ツリープロパティ」があることです。
For any prefixes P and P', either P and P' are disjoint, or one is more specific than the other.
PおよびP 'は、p'およびp 'のいずれかが互いに素であるか、または他方のものよりも具体的である。
It would be a natural proposition to order pairs of prefixes pointwise: to define that (D,S) is more specific than (D',S') when D is more specific than D and S is more specific than S'. Unfortunately, the set of pairs of prefixes with the pointwise ordering doesn't satisfy the tree property. Indeed, consider the following two pairs:
Dを定義するために（D、S）がDよりも具体的な（D、S '）よりも具体的ではありません。残念ながら、PointWide Orderingを持つプレフィックスのペアのセットはツリープロパティを満たしていません。確かに、次の2つのペアを考えます。
(2001:db8:0:1::/64, ::/0) and (::/0, 2001:db8:0:2::/64)
These two pairs are not disjoint (a packet with destination 2001:db8:0:1::1 and source 2001:db8:0:2::1 is matched by both), but neither is more specific than the other. The effect is that there is no natural, unambiguous way to interpret a routing table such as the following:
これら2つのペアは互いに素ではありません（宛先2001のパケット：DB8：0：1 :: 1とSource 2001：DB8：0：2 :: 1）は両方で一致しませんが、もう一方の具体的ではありません。その効果は、次のようなルーティングテーブルを解釈する自然で明確な方法がないということです。
destination source next-hop
2001:db8:0:1::/64 ::/0 A
::/0 2001:db8:0:2::/64 B
A finer ordering of pairs of prefixes is required in order to avoid all ambiguities. There are two natural choices: destination-first ordering, where (D,S) is more specific than (D',S') when
すべてのあいまいさを回避するためには、プレフィックスのペアの微調並びが必要です。2つの自然な選択があります。宛先最初の注文、ここで（D、S）は（D '、S）より具体的です（D'、S '）。
* D is strictly more specific than D', or
* DはD 'よりも厳密に具体的です、または
* D = D', and S is more specific than S'
* D = D '、SはS'より具体的です
and, symmetrically, source-first ordering, in which sources are compared first and destinations second.
そして、ソースが最初に2番目と目的地を比較した、対称的に、ソースの最初の順序付け。
Expedient as it would be to leave the choice to the implementation, this is not possible: all routers in a routing domain must use the same ordering lest persistent routing loops occur. Indeed, consider the following topology:
適用を選択することはできませんので、これは不可能です。ルーティングドメイン内のすべてのルータは同じ順序付けLestの永続ルーティングループが発生する必要があります。確かに、次のトポロジを検討してください。
A --- B --- C --- D
Suppose that A announces a route for (::/0, 2001:db8:0:2::/64), while D announces a route for (2001:db8:0:1::/64, ::/0). Suppose further that B uses destination-first ordering while C uses source-first ordering. Then a packet that matches both routes, say, with destination 2001:db8:0:1::1 and source 2001:db8:0:2::1, would be sent by B towards D and by C towards A and would therefore loop indefinitely between B and C.
aのルートを発表したとします(:: / 0,2001：DB8：0：2 :: / 64）、D（2001：DB8：0：1 :: / 64、:: / 0）のルートを発表します。。さらに、Cはソース - 最初の順序付けを使用している間に宛先 - 最初の順序を使用するとします。次に、両方のルートに一致するパケット、つまり宛先2001：DB8：0：1 :: 1およびSource 2001：DB8：0：2 :: 1は、Dに向かってDおよびCに向かってCに向かって送信されます。BとCの間で無期限にループ
This document mandates (Section 4) that all routers use destination-first ordering, which is generally believed to be more useful than source-first ordering. Consider the following topology, where A is an edge router connected to the Internet and B is an internal router connected to an access network N:
この文書は、すべてのルータが宛先の最初の順序を使用することを義務付けます（セクション4）。これは一般的にソースの最初の順序よりも有用であると考えられています。次のトポロジを考えてください。ここで、Aはインターネットに接続されているエッジルーターであり、BはアクセスネットワークNに接続されている内部ルータです。
(::/0, S) (D, ::/0)
Internet --- A --- B --- N
A announces a source-specific default route with source S (::/0, S), while B announces a nonspecific route to prefix D. Consider what happens to a packet with a destination in D and a source in S. With destination-first ordering, the packet is routed towards the network N, which is the only way it can possibly reach its destination. With source-first ordering, on the other hand, the packet is sent towards the Internet, with no hope of ever reaching its destination in N.
aは、ソースS (:: / 0、s）を持つソース固有のデフォルトルートを発表しますが、BはPREFIX Dへの非特異的なルートを発表しました。D.宛先の宛先とS.のソースのパケットに何が起こるかを検討します。最初の順序付け、パケットはネットワークNに向かってルーティングされます。これはおそらくその宛先に到達できる唯一の方法です。一方、ソースの最初の順序付けでは、パケットはインターネットに向かって送信され、Nの宛先に到達することは望みません。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A number of the conceptual data structures described in Section 3.2 of [RFC8966] contain a destination prefix. This specification extends these data structures with a source prefix. Data from the original protocol, which do not specify a source prefix, are stored with a zero-length source prefix, which matches the exact same set of packets as the original, non-source-specific data.
[RFC8966]のセクション3.2に記載されている概念データ構造のいくつかは、宛先プレフィックスを含みます。この仕様はこれらのデータ構造をソースプレフィックスで拡張します。ソースプレフィックスを指定しない元のプロトコルからのデータは、正確なソース固有のデータとしての正確なパケットのセットと一致するゼロ長のソースプレフィックスが格納されています。
Every Babel node maintains a source table, as described in [RFC8966], Section 3.2.5. A source-specific Babel node extends this table with the following field:
[RFC8966]、3.2.5の[RFC8966]で説明されているように、すべてのBableノードがソース表を維持します。ソース固有のBabelノードは、次の項目を使用してこのテーブルを拡張します。
* The source prefix (sprefix, splen) specifying the source address of packets to which this entry applies.
* このエントリが適用されるパケットの送信元アドレスを指定するソースプレフィックス（Sprefix、Splen）。
The source table is now indexed by 5-tuples of the form (prefix, plen, sprefix, splen, router-id).
ソース表は、フォームの5タプル（プレフィックス、PLEN、Sprefix、Splen、Router-ID）によってインデックスされています。
Note that the route entry contains a source (see Sections 2 and 3.2.5 of [RFC8966]) that itself contains both destination and source prefixes. These are two different concepts and must not be confused.
ルートエントリにはソースが含まれています（[RFC8966のセクション2と3.2.5）自体が宛先プレフィックスとソースの両方のプレフィックスが含まれていることに注意してください。これらは2つの異なる概念であり、混同してはいけません。
Every Babel node maintains a route table, as described in [RFC8966], Section 3.2.6. Each route table entry contains, among other data, a source, which this specification extends with a source prefix as described above. The route table is now indexed by 5-tuples of the form (prefix, plen, sprefix, splen, neighbour), where the first four components are obtained from the source.
[RFC8966]、3.2.6の[RFC8966]で説明されているように、すべてのBableノードがルートテーブルを維持します。各ルートテーブルエントリは、他のデータの中で、この仕様が上述のようにソースプレフィックスで拡張されたソースを含む。ルートテーブルは現在、フォームの5タプル（プレフィックス、プレス、スプレフィックス、スプレン、ネイバー）によってインデックスされています。ここで、最初の4つのコンポーネントがソースから取得されます。
Every Babel node maintains a table of pending seqno requests, as described in [RFC8966], Section 3.2.7. A source-specific Babel node extends this table with the following entry:
[RFC8966]、セクション3.2.7で説明されているように、すべてのBabelノードは保留中のSEQNO要求の表を維持しています。ソース固有のBabelノードは、次のエントリでこのテーブルを拡張します。
* The source prefix (sprefix, splen) being requested.
* 要求されているソースプレフィックス（プレフィックス、スプレン）。
The table of pending seqno requests is now indexed by 5-tuples of the form (prefix, plen, sprefix, splen, router-id).
保留中のSEQNO要求の表は、フォームの5タプル（プレフィックス、PLEN、Sprefix、Splen、Router-ID）によってインデックスされています。
As noted in Section 1.3, source-specific tables can, in general, be ambiguous, and all routers in a routing domain must use the same algorithm for choosing applicable routes. An implementation of the extension described in this document MUST choose routing table entries by using destination-first ordering, where routing table entry R1 is preferred to routing table entry R2 when either R1's destination prefix is more specific than R2's or the destination prefixes are equal and R1's source prefix is more specific than R2's.
セクション1.3で述べたように、ソース固有のテーブルは、一般に、曖昧であり、ルーティングドメイン内のすべてのルータは該当するルートを選択するために同じアルゴリズムを使用する必要があります。このドキュメントに記載されている拡張機能の実装は、宛先ファースト順序を使用してルーティングテーブルエントリを選択する必要があります。ここで、ルーティングテーブルエントリR1は、R1の宛先プレフィックスがR2以降または宛先接頭辞が等しくなっているときにルーティングテーブルエントリR2がルーティングテーブルエントリR2に優先されます。R1のソースプレフィックスはR2よりも具体的です。
In practice, this means that a source-specific Babel implementation must take care that any lower layer that performs packet forwarding obey these semantics. More precisely:
実際には、これはソース固有のBabel実装がパケット転送を実行する下位レイヤーがこれらのセマンティクスに従うことを注意しなければならないことを意味します。より正確に：
* if the lower layers implement destination-first ordering, then the Babel implementation SHOULD use them directly;
* 下位層が宛先の最初の注文を実装する場合、Babelの実装はそれらを直接使用する必要があります。
* if the lower layers can hold source-specific routes but not with the right semantics, then the Babel implementation MUST either silently ignore any source-specific routes or disambiguate the routing table by using a suitable disambiguation algorithm (see Section V.B of [SS-ROUTING] for such an algorithm);
* 下位レイヤーが正しい意味論を使用しないでくださいが、Babelの実装は、適切な曖昧な解消アルゴリズムを使用して、任意のソース固有のルートを静的に無視するか、ルーティングテーブルを曖昧させる必要があります（[SSルーティングのセクションVB]を参照）。]そのようなアルゴリズムの場合）。
* if the lower layers cannot hold source-specific routes, then a Babel implementation MUST silently ignore any source-specific routes.
* 下位レイヤーがソース固有のルートを保持できない場合、Babel実装はソース固有のルートを静的に無視する必要があります。
This extension does not fundamentally change the operation of the Babel protocol, and we therefore only describe differences between the original protocol and the extended protocol.
この拡張は、Babelプロトコルの動作を根本的に変更していないため、元のプロトコルと拡張プロトコルの違いのみを説明します。
In the original protocol, three TLVs carry a destination prefix: Update, Route Request, and Seqno Request TLVs. This specification extends these messages so that they may carry a Source Prefix sub-TLV, as described in Section 7. The sub-TLV is marked as mandatory so that an unextended implementation will silently ignore the whole enclosing TLV. A node obeying this specification MUST NOT send a TLV with a zero-length source prefix; instead, it sends a TLV with no Source Prefix sub-TLV. Conversely, an extended implementation MUST interpret an unextended TLV as carrying a source prefix of zero length. Taken together, these properties ensure interoperability between the original and extended protocols (see Section 6).
元のプロトコルでは、3つのTLVSが宛先プレフィックスを搭載しています。アップデート、ルート要求、およびSEQNO要求TLVS。この仕様は、セクション7で説明されているように、ソースプレフィックスサブTLVを搬送することができるようにこれらのメッセージを拡張します。サブTLVは必須としてマークされています。これは、拡張されていない実装が絶えず囲むTLV全体を無視します。この仕様に従うノードは、長さゼロのソースプレフィックスを持つTLVを送信してはなりません。代わりに、ソースプレフィックスサブTLVのないTLVを送信します。逆に、拡張された実装は、ゼロの長さのソースプレフィックスを伝送するときに、非拡張TLVを解釈する必要があります。まとめると、これらのプロパティは、元のプロトコルと拡張プロトコルとの間の相互運用性を保証します（セクション6を参照）。
This extension allows three TLVs of the original Babel protocol to carry a source prefix: Update TLVs, Route Request TLVs, and Seqno Request TLVs.
この拡張機能により、元のBabelプロトコルの3つのTLVがソースプレフィックスを搭載しています。更新TLV、ルートリクエストTLVS、およびSEQNOリクエストTLVSを使用できます。
In order to advertise a route with a non-zero length source prefix, a node sends a source-specific update, i.e., an update with a Source Prefix sub-TLV. When a node receives a source-specific update (prefix, source prefix, router-id, seqno, metric) from a neighbour neigh, it behaves as described in [RFC8966], Section 3.5.3, except that the entry under consideration is indexed by (prefix, plen, sprefix, splen, neigh) rather than just (prefix, plen, neigh).
ゼロ以外のソースプレフィックスを持つルートをアドバタイズするために、ノードはソース固有の更新、すなわちソースプレフィックスサブTLVを使用して更新を送信します。ノードが隣接ネイからのソース固有の更新プログラム（プレフィックス、ソースプレフィックス、ルータID、SEQNO、メトリック）を受信すると、検討中のエントリがインデックスされていることを除いて、[RFC8966]、3.5.3で説明されているように動作します。（接頭辞、プレーン、スプレフィックス、スプレン、ネイ）だけではなく（プレフィックス、プレス、ネイ）。
Similarly, when a node needs to send a request of either kind that applies to a route with a non-zero length source prefix, it sends a source-specific request, i.e., a request with a Source Prefix sub-TLV. When a node receives a source-specific request, it behaves as described in Section 3.8 of [RFC8966], except that the request applies to the route table entry carrying the source prefix indicated by the Source Prefix sub-TLV.
同様に、ノードがゼロ以外の長さのソースプレフィックスを持つルートに適用されるどちらの種類の要求を送信する必要がある場合、ソース固有の要求、すなわちソースプレフィックスサブTLVを含む要求を送信する。ノードがソース固有の要求を受信すると、要求がソースプレフィックスサブTLVで示されるソースプレフィックスを搬送するルートテーブルエントリに要求が適用されることを除いて、[RFC8966]のセクション3.8で説明されているように動作します。
In the original protocol, the address encoding (AE) value 0 is used for wildcard messages: messages that apply to all routes of any address family and with any destination prefix. Wildcard messages are allowed in two places in the protocol: wildcard retractions are used to retract all of the routes previously advertised by a node on a given interface, and wildcard route requests are used to request a full dump of the route table from a given node. Wildcard messages are intended to apply to all routes, including routes decorated with additional data and AE values to be defined by future extensions; hence, this specification extends wildcard operations to apply to all routes, whatever the value of the source prefix.
元のプロトコルでは、アドレスエンコード（AE）値0がワイルドカードメッセージに使用されます。アドレスファミリのすべてのルートに適用されるメッセージと宛先プレフィックスとのメッセージが使用されます。ワイルドカードメッセージはプロトコル内の2つの場所で許可されています。ワイルドカードの後退は、特定のインタフェース上のノードによって以前にアドバタイズされたすべてのルートをリトークするために使用され、ワイルドカードルート要求は特定のノードからルートテーブルのフルダンプを要求するために使用されます。。ワイルドカードメッセージは、将来の拡張によって定義されるべき追加のデータとAE値で装飾されたルートを含む、すべてのルートに適用することを目的としています。したがって、この仕様は、ソースプレフィックスの値が任意のすべてのルートに適用するためにワイルドカード操作を拡張します。
More precisely, a node receiving an update with the AE field set to 0 and the Metric field set to infinity (a wildcard retraction) MUST apply the route acquisition procedure described in Section 3.5.3 of [RFC8966] to all of the routes that it has learned from the sending node, whatever the value of the source prefix. A node MUST NOT send a wildcard retraction with an attached source prefix, and a node that receives a wildcard retraction with a source prefix MUST ignore the retraction.
より正確には、AEフィールドが0に設定された更新を0と無限大に設定されたメトリックフィールド（ワイルドカードの後退）で更新を受信するノード（WIRDCARD RETRACTION）は、[RFC8966]のセクション3.5.3に記載されているルート取得手順を適用する必要があります。ソースプレフィックスの値は何でも送信ノードから学んだ。ノードはワイルドカードの退避を添付のソースプレフィックスに送信してはならず、ソースプレフィックスを使用してワイルドカードの退避を受信するノードは後退を無視する必要があります。
Similarly, a node that receives a route request with the AE field set to 0 (a wildcard route request) SHOULD send a full routing table dump, including routes with a non-zero length source prefix. A node MUST NOT send a wildcard request that carries a source prefix, and a node receiving a wildcard request with a source prefix MUST ignore the request.
同様に、AEフィールドを0に設定して経路要求を0に受信するノード（ワイルドカードルート要求）は、ゼロ以外のソースプレフィックスを持つルートを含む、フルルーティングテーブルダンプを送信する必要があります。ノードは、ソースプレフィックスを搭載したワイルドカード要求を送信してはいけません。ソースプレフィックスを使用してワイルドカード要求を受信したノードはリクエストを無視する必要があります。
The protocol extension defined in this document is, to a great extent, interoperable with the base protocol defined in [RFC8966] (and all previously standardised extensions). More precisely, if non-source-specific routers and source-specific routers are mixed in a single routing domain, Babel's loop-avoidance properties are preserved, and, in particular, no persistent routing loops will occur.
このドキュメントで定義されているプロトコル拡張は、[RFC8966]（および以前に標準化されたすべての拡張機能）で定義されているベースプロトコルと相互運用可能です。より正確には、単一のルーティングドメインで非ソース固有のルータおよびソース固有のルータが混在する場合、Babelのループ回避プロパティは保持され、特に持続的なルーティングループは発生しません。
However, this extension is encoded using mandatory sub-TLVs, introduced in [RFC8966], and therefore is not compatible with the older version of the Babel routing protocol [RFC6126], which does not support mandatory sub-TLVs. Consequently, this extension MUST NOT be used in a routing domain in which some routers implement [RFC6126]; otherwise, persistent routing loops may occur.
ただし、この拡張は[RFC8966]で導入された必須のSUB-TLVを使用してエンコードされているため、必須のサブTLVをサポートしていない、古いバージョンのBabelルーティングプロトコル[RFC6126]と互換性がありません。その結果、この拡張子は、いくつかのルータが実装されているルーティングドメインで使用してはいけません[RFC6126]。それ以外の場合は、持続的なルーティングループが発生する可能性があります。
In general, the discarding of source-specific routes by non-source-specific routers will cause route starvation. Intuitively, unless there are enough non-source-specific routes in the network, non-source-specific routers will suffer starvation and discard packets for destinations that are only announced by source-specific routers.
一般に、非ソース固有のルータによるソース固有のルートを破棄すると、ルートの飢餓が発生します。直感的に、ネットワーク内に十分なソース固有のルートが十分にない限り、ソース固有のルータは、ソース固有のルータによってのみ発表されている宛先の順応器と破棄されます。
In the common case where all source-specific routes are originated at one of a small set of edge routers, a simple yet sufficient condition for avoiding starvation is to build a connected source-specific backbone that includes all of the edge routers and announce a non-source-specific default route towards the backbone.
一般的なソース固有のルートがすべてのエッジルータのうちの1つで発信された一般的な場合では、飢餓を回避するための単純な未だ十分な条件は、すべてのエッジルーターを含む接続元固有のバックボーンを構築し、非以外をアナウンスすることです。-Source固有のデフォルトルートをバックボーンに向けてください。
This extension defines a new sub-TLV used to carry a source prefix: the Source Prefix sub-TLV. It can be used within an Update, Route Request, or Seqno Request TLV to match a source-specific entry of the route table in conjunction with the destination prefix natively carried by these TLVs.
この拡張子は、ソースプレフィックスを伝送するために使用される新しいサブTLVを定義します。ソースプレフィックスサブTLV。これらのTLVによってネイティブに運ばれた宛先プレフィックスと組み合わせて、ルートテーブルのソース固有のエントリと一致するように、更新、ルート要求、またはSEQNO要求TLV内で使用できます。
Since a source-specific routing entry is characterised by a single destination prefix and a single source prefix, a source-specific message contains exactly one Source Prefix sub-TLV. A node MUST NOT send more than one Source Prefix sub-TLV in a TLV, and a node receiving more than one Source Prefix sub-TLV in a single TLV MUST ignore the TLV. It MAY ignore the whole packet.
ソース固有のルーティングエントリは単一の宛先プレフィックスと単一のソースプレフィックスによって特徴付けられているため、ソース固有のメッセージには正確に1つのソースプレフィックスサブTLVが含まれています。ノードはTLVに複数のソースプレフィックスサブTLVを送信してはならず、単一のTLVで複数のソースプレフィックスサブTLVを受信したノードはTLVを無視する必要があります。パケット全体を無視することができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 128 | Length | Source Plen | Source Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
田畑：
Type Set to 128 to indicate a Source Prefix sub-TLV.
ソースプレフィックスサブTLVを示すには、128に設定します。
Length The length of the body, in octets, exclusive of the Type and Length fields.
体の長さは、オクテットで、タイプフィールドと長さのフィールドを除く。
Source Plen The length of the advertised source prefix, in bits. This MUST NOT be 0.
ソースプレス宣伝されているソースプレフィックスの長さ（ビット）。これは0にする必要があります。
Source Prefix The source prefix being advertised. This field's size is (Source Plen)/8 octets rounded upwards.
送信元プレフィックスアドバタイズされているソースプレフィックス。このフィールドのサイズは（ソースプレーン）/ 8オクテットが上向きに切り上げられました。
The length of the body TLV is normally of size 1+(Source Plen)/8 rounded upwards. If the Length field indicates a length smaller than that, then the sub-TLV is corrupt, and the whole enclosing TLV must be ignored; if the Length field indicates a length that is larger, then the extra octets contained in the sub-TLV MUST be silently ignored.
ボディTLVの長さは通常1（ソースプレーン）/ 8を丸みを帯びています。長さフィールドがそれより小さい長さを示す場合、SUB-TLVは破損し、囲むTLV全体は無視されなければなりません。長さフィールドが大きい長さを示す場合は、SUB-TLVに含まれている余分なオクテットは黙って無視されなければなりません。
The contents of the Source Prefix sub-TLV are interpreted according to the AE of the enclosing TLV. If a TLV with AE equal to 0 contains a Source Prefix sub-TLV, then the whole enclosing TLV MUST be ignored. If a TLV contains multiple Source Prefix sub-TLVs, then the whole TLV MUST be ignored.
ソースプレフィックスサブTLVの内容は、囲むTLVのAEに従って解釈されます。AEを持つTLVがソースプレフィックスサブTLVを含む場合、囲むTLV全体は無視されなければなりません。TLVに複数のソースプレフィックスサブTLVが含まれている場合は、TLV全体を無視する必要があります。
Note that this sub-TLV is a mandatory sub-TLV. Therefore, as described in Section 4.4 of [RFC8966], the whole TLV MUST be ignored if that sub-TLV is not understood (or malformed).
このサブTLVは必須のサブTLVです。したがって、[RFC8966]のセクション4.4で説明されているように、そのサブTLVが理解されていない（または不正行為）されていない場合、TLV全体は無視されなければなりません。
The source-specific update is an Update TLV with a Source Prefix sub-TLV. It advertises or retracts source-specific routes in the same manner as routes with non-source-specific updates (see [RFC8966]). A wildcard retraction (update with AE equal to 0) MUST NOT carry a Source Prefix sub-TLV.
ソース固有のアップデートは、ソースプレフィックスサブTLVを持つアップデートTLVです。ソース固有のアップデートを使用しているルートと同じ方法で、ソース固有のルートをアドバタイズまたはリートします（[RFC8966]を参照）。ワイルドカードの後退（0に等しいAEの更新）は、ソースプレフィックスサブTLVを持ちません。
Babel uses a stateful compression scheme to reduce the size taken by destination prefixes in Update TLVs (see Section 4.5 of [RFC8966]). The source prefix defined by this extension is not compressed. On the other hand, compression is allowed for the destination prefixes carried by source-specific updates. As described in Section 4.5 of [RFC8966], unextended implementations will correctly update their parser state while otherwise ignoring the whole TLV.
Babelはステートフル圧縮方式を使用して、Update TLVSの宛先接頭辞によって撮影されたサイズを減らす（[RFC8966]のセクション4.5を参照）。この拡張子によって定義されたソースプレフィックスは圧縮されていません。一方、ソース固有のアップデートによって運ばれる宛先プレフィックスに圧縮が許可されています。[RFC8966]のセクション4.5で説明されているように、非拡張型実装は、それ以外の場合はTLV全体を無視しながらパーサー状態を正しく更新します。
A source-specific route request is a Route Request TLV with a Source Prefix sub-TLV. It prompts the receiver to send an update for a given pair of destination and source prefixes, as described in Section 3.8.1.1 of [RFC8966]. A wildcard request (route request with AE equal to 0) MUST NOT carry a Source Prefix sub-TLV; if a wildcard request with a Source Prefix sub-TLV is received, then the request MUST be ignored.
ソース固有の経路要求は、ソースプレフィックスサブTLVを備えたルート要求TLVです。[RFC8966]のセクション3.8.1.1で説明されているように、受信側に、指定された宛先プレフィックスのペアの更新を送信するように求められます。ワイルドカード要求（0に等しいAEを持つルート要求）は、ソースプレフィックスサブTLVを持ちません。ソースプレフィックスサブTLVを受信したワイルドカード要求が受信された場合は、要求は無視されなければなりません。
A source-specific seqno request is a Seqno Request TLV with a Source Prefix sub-TLV. It requests that the receiving node perform the procedure described in Section 3.8.1.2 of [RFC8966] but applied to a pair consisting of a destination and source prefix.
ソース固有のSEQNO要求は、ソースプレフィックスサブTLVを持つSEQNO要求TLVです。受信側ノードが[RFC8966]のセクション3.8.1.2で説明されているが、宛先およびソースプレフィックスからなるペアに適用されることを要求します。
IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV in the "Babel Sub-TLV Types" registry.
IANAは、「Babel Sub-TLV Type」レジストリのソースプレフィックスサブTLVにサブTLV番号128を割り当てました。
The extension defined in this document adds a new sub-TLV to three sub-TLVs already present in the original Babel protocol and does not change the security properties of the protocol itself. However, the additional flexibility provided by source-specific routing might invalidate the assumptions made by some network administrators, which could conceivably lead to security issues.
このドキュメントで定義されている拡張機能は、元のBabelプロトコルに既に存在する3つのサブTLVに新しいサブTLVを追加し、プロトコル自体のセキュリティプロパティを変更しません。ただし、ソース固有のルーティングによって提供される追加の柔軟性は、一部のネットワーク管理者によって行われた仮定を無効にする可能性があります。これにより、セキュリティ上の問題につながる可能性があります。
For example, a network administrator might be tempted to abuse route filtering (Appendix C of [RFC8966]) as a security mechanism. Unless the filtering rules are designed to take source-specific routing into account, they might be bypassed by a source-specific route, which might cause traffic to reach a portion of a network that was thought to be protected. A network administrator might also assume that no route is more specific than a host route and use a host route in order to direct traffic for a given destination through a security device (e.g., a firewall); source-specific routing invalidates this assumption, and, in some topologies, announcing a source-specific route might conceivably be used to bypass the security device.
たとえば、ネットワーク管理者は、セキュリティメカニズムとしてルートフィルタリング（[RFC8966]の付録C）を乱用するように誘惑される可能性があります。フィルタリングルールがソース固有のルーティングを考慮するように設計されていない限り、それらはソース固有のルートによってバイパスされる可能性があり、それはトラフィックが保護されていたネットワークの一部に到達する可能性があります。ネットワーク管理者はまた、ホストルートよりも具体的であると仮定し、セキュリティデバイス（例えばファイアウォール）を介して特定の宛先のトラフィックを直接送信するためにホストルートを使用することを前提としている。ソース固有のルーティングはこの仮定を無効にし、一部のトポロジでは、ソース固有のルートをアナウンスしてセキュリティデバイスを迂回するために使用されている可能性があります。
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[BCP84] Baker、F.およびP.Savola、「マルチホームネットワークの入口フィルタリング」、BCP 84、RFC 3704、2004年3月。
Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, February 2020.
Sriram、K.、Montgomery、D.、J.HAAS、「強化された実行可能なパスユニキャストリバースパス転送」、BCP 84、RFC 8704、2020年2月。
<https://www.rfc-editor.org/info/bcp84>
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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>。
[RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021, <https://www.rfc-editor.org/info/rfc8966>.
[RFC8966] Chroboczek、J.およびD.Schinazi、「The Babel Routing Protocol」、RFC 8966、DOI 10.17487 / RFC8966、2021年1月、<https：//www.rfc-editor.org/info/rfc8966>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「ストリーム制御伝送プロトコル」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https：//www.rfc-editor.org/info/rfc4960>。
[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, DOI 10.17487/RFC6126, April 2011, <https://www.rfc-editor.org/info/rfc6126>.
[RFC6126] Chroboczek、J.、「Babel Routing Protocol」、RFC 6126、DOI 10.17487 / RFC6126、2011年4月、<https：//www.rfc-editor.org/info/rfc6126>。
[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>。
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305] Schinazi、D.およびT. Pauly、 "Happy Eyaballs Version 2：並行性を使用したより良い接続"、RFC 8305、DOI 10.17487 / RFC8305、2017年12月、<https://www.rfc-editor.org/info/RFC8305>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続施設（氷）：ネットワークアドレス翻訳者のためのプロトコル」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC8684]フォード、A.、RaiCyu、C.、Handley、M.、Bonaventure、O.、およびC. PaaSch、RFC 8684、DOI 10.17487 / RFC8684、2020年3月、<https://www.rfc-editor.org/info/rfc8684>。
[SS-ROUTING] Boutier, M. and J. Chroboczek, "Source-Specific Routing", IFIP Networking Conference, DOI 10.1109/IFIPNetworking.2015.7145305, May 2015, <http://arxiv.org/pdf/1403.0445>.
[SS-ROUTING] Boutier、M.およびJ.Chroboczek、「ソース固有のルーティング」、IFIPネットワーキング会議、DOI 10.1109 / IFIPNetwork.2015.7145305、<http://arxiv.org/pdf/1403.0445>。
Acknowledgments
謝辞
The authors are indebted to Donald Eastlake, Joel Halpern, and Toke Hoiland-Jorgensen for their help with this document.
著者は、この文書の助けを借りて、Donald Eastlake、Joel Halpern、およびToke Hoiland-Jorgensenに留意されています。
Authors' Addresses
著者の住所
Matthieu Boutier IRIF, University of Paris Case 7014 75205 Paris Cedex 13 France
パリ大学マタイ・ブティエアイルフ・ケース7014 75205 Paris Cedex 13フランス
Email: boutier@irif.fr
Juliusz Chroboczek IRIF, University of Paris Case 7014 75205 Paris Cedex 13 France
Juliusz Chroboczek IRIF、パリ大学ケース7014 75205パリCEDEX 13フランス
Email: jch@irif.fr