[要約] RFC 8965は、Babelルーティングプロトコルの適用性に関する文書です。このプロトコルは、多様なネットワーク環境での柔軟な経路選択を目的としています。主に、ワイヤレスメッシュネットワーク、IoTデバイス、および低品質のリンクが存在する環境での使用が想定されています。
Internet Engineering Task Force (IETF) J. Chroboczek
Request for Comments: 8965 IRIF, University of Paris-Diderot
Category: Informational January 2021
ISSN: 2070-1721
Applicability of the Babel Routing Protocol
Babelルーティングプロトコルの適用性
Abstract
概要
Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols.
Babelは、ループ回避と飢餓回避のためのメカニズムで増強された距離ベクトルアルゴリズムに基づくルーティングプロトコルです。この文書では、BABELが有用であることがわかっており、より成熟したプロトコルによって適切に提供されていないことがわかっています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8965.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/rfc8965で入手できます。
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. Technical Overview of the Babel Protocol 2. Properties of the Babel Protocol 2.1. Simplicity and Implementability 2.2. Robustness 2.3. Extensibility 2.4. Limitations 3. Successful Deployments of Babel 3.1. Heterogeneous Networks 3.2. Large-Scale Overlay Networks 3.3. Pure Mesh Networks 3.4. Small Unmanaged Networks 4. Security Considerations 5. References 5.1. Normative References 5.2. Informative References Acknowledgments Author's Address
1. 紹介と背景1.1。Babelプロトコルの技術概要2. Babelプロトコル2.1のプロパティ。単純さと実装可能性2.2。ロバストネス2.3。拡張性2.4。制限事項3. Babel 3.1の展開の成功異種ネットワーク3.2。大規模オーバーレイネットワーク3.3。ピュアメッシュネットワーク3.4。小さな管理されていないネットワーク4.セキュリティ上の考慮事項5.参考文献5.1。規範的参考文献5.2。有益な参照承認著者の住所
Babel [RFC8966] is a routing protocol based on the familiar distance-vector algorithm (sometimes known as distributed Bellman-Ford) augmented with mechanisms for loop avoidance (there is no "counting to infinity") and starvation avoidance. This document describes a number of niches where Babel is useful and that are arguably not adequately served by more mature protocols such as OSPF [RFC5340] and IS-IS [RFC1195].
Babel [RFC8966]は、ループ回避のメカニズムで拡張されたおなじみの距離ベクトルアルゴリズム（分散ベルマンフォーDとして知られている）に基づくルーティングプロトコルです（無限大へのカウントはありません）、飢餓回避。この文書では、BABELが有用であり、OSPF [RFC5340]などのより成熟したプロトコルによって適切に提供されていない多くのNICHESが記載されています[RFC1195]。
At its core, Babel is a distance-vector protocol based on the distributed Bellman-Ford algorithm, similar in principle to RIP [RFC2453] but with two important extensions: provisions for sensing of neighbour reachability, bidirectional reachability, and link quality, and support for multiple address families (e.g., IPv6 and IPv4) in a single protocol instance.
そのコアでは、Babelは、原則としてRIP [RFC2453]が2つの重要な拡張機能と同様に分散ベルマンフォードアルゴリズムに基づく距離 - ベクトルプロトコルです。隣接到達可能性、双方向到達可能性、およびリンク品質、およびサポートのための規定単一のプロトコルインスタンスの複数のアドレスファミリ（IPv6とIPv4）の場合。
Algorithms of this class are simple to understand and simple to implement, but unfortunately they do not work very well -- they suffer from "counting to infinity", a case of pathologically slow convergence in some topologies after a link failure. Babel uses a mechanism pioneered by the Enhanced Interior Gateway Routing Protocol (EIGRP) [DUAL] [RFC7868], known as "feasibility", which avoids routing loops and therefore makes counting to infinity impossible.
このクラスのアルゴリズムは理解するのが簡単で、実装が簡単ですが、残念ながら、彼らは非常にうまく機能しません - リンクが失敗した後のいくつかのトポロジで病理学的に遅い収束の1例です。Babelは、「実現可能性」として知られている拡張型インテリアゲートウェイルーティングプロトコル（EIGRP）[RFC7868]によって開拓されたメカニズムを使用しています。
Feasibility is a conservative mechanism, one that not only avoids all looping routes but also rejects some loop-free routes. Thus, it can lead to a situation known as "starvation", where a router rejects all routes to a given destination, even those that are loop-free. In order to recover from starvation, Babel uses a mechanism pioneered by the Destination-Sequenced Distance-Vector Routing Protocol (DSDV) [DSDV] and known as "sequenced routes". In Babel, this mechanism is generalised to deal with prefixes of arbitrary length and routes announced at multiple points in a single routing domain (DSDV was a pure mesh protocol, and only carried host routes).
実現可能性は保守的なメカニズムです.1つはすべてのループルートを回避するだけでなく、ループフリーのルートも拒否します。したがって、ループフリーのものでさえ、ルータがすべてのルートを拒否する "Starvation"として知られる状況につながる可能性があります。飢餓から回復するために、Babelは宛先順序距離 - ベクトルルーティングプロトコル（DSDV）[DSDV]によって先駆的なメカニズムを使用し、「シーケンスルート」として知られています。Babelでは、このメカニズムは任意の長さの接頭辞を扱うように一般化されており、単一のルーティングドメイン内の複数のポイントで発表されたルート（DSDVは純粋なメッシュプロトコル、および携帯ホストルートのみ）を参照してください。
In DSDV, the sequenced routes algorithm is slow to react to a starvation episode. In Babel, starvation recovery is accelerated by using explicit requests (known as "seqno requests" in the protocol) that signal a starvation episode and cause a new sequenced route to be propagated in a timely manner. In the absence of packet loss, this mechanism is provably complete and clears the starvation in time proportional to the diameter of the network, at the cost of some additional signalling traffic.
DSDVでは、シーケンスされたルートアルゴリズムは飢餓エピソードに反応するのが遅いです。Babelでは、飢餓リクエストを使用して、明示的な要求（プロトコル内の「seqno要求」と呼ばれ、順守のエピソードとして知られている）を使用し、新しいシーケンスされたルートをタイムリーに伝播させることによって加速されます。パケット損失がない場合、このメカニズムは、いくつかの追加のシグナリングトラフィックのコストで、ネットワークの直径に比例した時間的に飢餓を完全に完全にクリアします。
This section describes the properties of the Babel protocol as well as its known limitations.
このセクションでは、Babelプロトコルのプロパティとその既知の制限について説明します。
Babel is a conceptually simple protocol. It consists of a familiar algorithm (distributed Bellman-Ford) augmented with three simple and well-defined mechanisms (feasibility, sequenced routes, and explicit requests). Given a sufficiently friendly audience, the principles behind Babel can be explained in 15 minutes, and a full description of the protocol can be done in 52 minutes (one microcentury).
Babelは概念的に簡単なプロトコルです。それは、3つの単純で明確に定義されたメカニズム（実現可能性、順序付けられた経路、および明示的な要求）で拡張されたよく知られたアルゴリズム（分散ベルマン-ORD）で構成されています。十分にフレンドリーな視聴者を考えると、バベルの後ろの原則は15分で説明することができ、そしてプロトコルの全体的な説明は52分で行うことができます（1つの微小圧質）。
An important consequence is that Babel is easy to implement. At the time of writing, there exist four independent, interoperable implementations, including one that was reportedly written and debugged in just two nights.
重要な結果は、ベイベルが実装が容易なことです。書き込み時には、わずか2泊で書面で書面でデバッグされたものを含む4つの独立した相互運用可能な実装があります。
The fairly strong properties of the Babel protocol (convergence, loop avoidance, and starvation avoidance) rely on some reasonably weak properties of the network and the metric being used. The most significant are:
Babelプロトコルのかなり強い性質（収束、ループ回避、および飢餓回避）は、ネットワークの何らかの適度に弱い特性に依存して使用されているメトリックが依存しています。最も重要なのは以下のとおりです。
causality: the "happens-before" relation is acyclic (intuitively, a control message is not received before it has been sent);
因果関係：「起こる前」の関係は非密的です（直感的には、制御メッセージは送信される前に受信されません）。
strict monotonicity of the metric: for any metric M and link cost C, M < C + M (intuitively, this implies that cycles have a strictly positive metric);
メトリックの厳密な単調性：任意のメトリックMおよびリンクコストC、M <C m（直感的に、これはサイクルが厳密に肯定的な測定基準を有することを意味する）。
left-distributivity of the metric: for any metrics M and M' and cost C, if M <= M', then C + M <= C + M' (intuitively, this implies that a good choice made by a neighbour B of a node A is also a good choice for A).
メトリックの左分布率：メトリックMおよびM 'の場合、M <= M'の場合、CM <= cm '（直感的に、これはノードAの隣接Bによって行われることを意味することを意味する。A）も良い選択です。
See [METAROUTING] for more information about these properties and their consequences.
これらのプロパティとその結果の詳細については、[Metarouting]を参照してください。
In particular, Babel does not assume a reliable transport, it does not assume ordered delivery, it does not assume that communication is transitive, and it does not require that the metric be discrete (continuous metrics are possible, for example, reflecting packet loss rates). This is in contrast to link-state routing protocols such as OSPF [RFC5340] or IS-IS [RFC1195], which incorporate a reliable flooding algorithm and make stronger requirements on the underlying network and metric.
特に、Babelは信頼できる輸送を想定しておらず、注文配信が推移的であると仮定しておらず、それはメトリックが離散的であることを必要としない（例えば、パケット損失率を反映することが可能である）。）。これは、OSPF [RFC5340]またはIS-IS [RFC1195]などのリンクステートルーティングプロトコルとは対照的に、信頼性の高いフラッディングアルゴリズムを組み込んで、基礎となるネットワークとメトリックに強力な要件を確保します。
These weak requirements make Babel a robust protocol:
これらの弱い要件は、Babelを堅牢なプロトコルにします。
robust with respect to unusual networks: an unusual network (non-transitive links, unstable link costs, etc.) is likely not to violate the assumptions of the protocol;
異常なネットワークに関して堅牢なネットワーク（非推移的なリンク、不安定なリンクコストなど）は、プロトコルの仮定に違反しない可能性があります。
robust with respect to novel metrics: an unusual metric (continuous, constantly fluctuating, etc.) is likely not to violate the assumptions of the protocol.
新しい測定基準に関して堅牢な：異常なメトリック（連続、絶えず変動するなど）は、プロトコルの仮定に違反しない可能性があります。
Section 3 gives examples of successful deployments of Babel that illustrate these properties.
セクション3は、これらのプロパティを示すBabelの展開を成功させる例を示します。
These robustness properties have important consequences for the applicability of the protocol: Babel works (more or less efficiently) in a range of circumstances where traditional routing protocols don't work well (or at all).
これらの堅牢性の特性は、議定書の適用性にとって重要な結果を示します。
Babel's packet format has a number of features that make the protocol extensible (see Appendix D of [RFC8966]), and a number of extensions have been designed to make Babel work better in situations that were not envisioned when the protocol was initially designed. The ease of extensibility is not an accident, but a consequence of the design of the protocol: it is reasonably easy to check whether a given extension violates the assumptions on which Babel relies.
Babelのパケットフォーマットには、プロトコルを拡張可能にする数多くの機能があります（[RFC8966]の付録Dを参照）、プロトコルが最初に設計されたときに想定されていない状況でBabelが機能させるように設計されています。伸張性の容易さは事故ではありませんが、プロトコルの設計の結果：特定の拡張がBabelが依存する仮定に違反するかどうかを確認するのは合理的に簡単です。
All of the extensions designed to date interoperate with the base protocol and with each other. This, again, is a consequence of the protocol design: in order to check that two extensions to the Babel protocol are interoperable, it is enough to verify that the interaction of the two does not violate the base protocol's assumptions.
現在の拡張機能は、ベースプロトコルと互いに相互運用するように設計されています。これは、再びプロトコル設計の結果である.Babelプロトコルへの2つの拡張が相互運用可能であることを確認するために、2つの相互作用が基本プロトコルの仮定に違反しないことを確認するのに十分である。
Notable extensions deployed to date include:
日付に展開された注目すべき拡張機能は次のとおりです。
* source-specific routing (also known as Source-Address Dependent Routing, SADR) [BABEL-SS] allows forwarding to take a packet's source address into account, thus enabling a cheap form of multihoming [SS-ROUTING];
* ソース固有のルーティング（ソースアドレス依存ルーティング、SADRとも呼ばれる）[BABEL-SS]は、パケットの送信元アドレスを考慮に入れることを可能にし、したがって、マルチホーム[SSルーティング]の格納形式を可能にします。
* RTT-based routing [BABEL-RTT] minimises link delay, which is useful in overlay network (where both hop count and packet loss are poor metrics).
* RTTベースのルーティング[BABEL-RTT]は、リンク遅延を最小限に抑えます。これはオーバーレイネットワーク（ホップ数とパケット損失の両方がメトリックの両方である場合）に役立ちます。
Some other extensions have been designed but have not seen deployment in production (and their usefulness is yet to be demonstrated):
他のいくつかの拡張は設計されていますが、製造における展開を見たことがありません（そしてそれらの有用性はまだ証明されていません）。
* frequency-aware routing [BABEL-Z] aims to minimise radio interference in wireless networks;
* 周波数対応ルーティング[BABEL-Z]は、無線ネットワークにおける無線干渉を最小限に抑えることを目的としています。
* ToS-aware routing [BABEL-TOS] allows routing to take a packet's Type of Service (ToS) marking into account for selected routes without incurring the full cost of a multi-topology routing protocol.
* TOS対応ルーティング[BABEL-TOS]は、マルチトポロジールーティングプロトコルのフルコストを招くことなく、選択されたルートのパケットの種類のサービス（TOS）マーキングを取得するためのルーティングを許可します。
Babel has some undesirable properties that make it suboptimal or even unusable in some deployments.
Babelは、いくつかの展開では、それを最適なものにするか、さらには使用できない望ましくないプロパティを持っています。
The main mechanisms used by Babel to reconverge after a topology change are reactive: triggered updates, triggered retractions and explicit requests. However, Babel relies on periodic updates to clear pathologies after a mobility event or in the presence of heavy packet loss. The use of periodic updates makes Babel unsuitable in at least two kinds of environments:
トポロジの変更後にBabelによって使用される主なメカニズムは反応性です。トリガされたアップデート、トリガされた後退と明示的な要求。ただし、Babelは、モビリティイベントの後または重いパケット損失の存在後に、プロセスを明確にするための定期的な更新に依存しています。定期的な更新の使用は、BABELを少なくとも2種類の環境では不適切にします。
large, stable networks: since Babel sends periodic updates even in the absence of topology changes, in well-managed, large, stable networks the amount of control traffic will be reduced by using a protocol that uses a reliable transport (such as OSPF, IS-IS, or EIGRP);
大規模で安定したネットワーク：Babelは、トポロジの変更がない場合でも定期的な更新を送信してから、十分に管理されている大規模で安定したネットワークで、信頼できるトランスポートを使用するプロトコルを使用することで管理トラフィックの量が削減されます（OSPFなど）。-is、またはEIGRP）。
low-power networks: the periodic updates use up battery power even when there are no topology changes and no user traffic, which makes Babel wasteful in low-power networks.
低電力ネットワーク：位相更新は、トポロジの変更がなく、ユーザーのトラフィックがなくてもバッテリの電源を使用します。これにより、BABELは低電力ネットワークで無駄になります。
While there exist techniques that allow a Babel speaker to function with a partial routing table (e.g., by learning just a default route or, more generally, performing route aggregation), Babel is designed around the assumption that every router has a full routing table. In networks where some nodes are too constrained to hold a full routing table, it might be preferable to use a protocol that was designed from the outset to work with a partial routing table (such as the Ad hoc On-Demand Distance Vector (AODV) routing protocol [RFC3561], the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550], or the Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) [LOADng]).
Babelスピーカーが部分的なルーティングテーブル（例えば、デフォルトのルートを学習することによって、より一般的には経路集計を実行することによって）で機能することを可能にするテクニックが存在しますが、Babelはすべてのルーターが完全なルーティングテーブルを持つという仮定の周りに設計されています。一部のノードが完全なルーティングテーブルを保持するために制限されているネットワークでは、部分的なルーティングテーブル（AD HOCオンデマンド距離ベクトル（AODVなど）を使用して作業するために最初から設計されたプロトコルを使用することをお勧めします。ルーティングプロトコル[RFC3561]、低電力と非損失ネットワーク（RPL）[RFC6550]、または軽量オンデマンドアドホック距離 - ベクトルルーティングプロトコル - 次世代（LOADNG）[LOADNG]）。
Babel's loop-avoidance mechanism relies on making a route unreachable after a retraction until all neighbours have been guaranteed to have acted upon the retraction, even in the presence of packet loss. Unless the second algorithm described in Section 3.5.5 of [RFC8966] is implemented, this entails that a node is unreachable for a few minutes after the most specific route to it has been retracted. This delay makes Babel slow to recover from a topology change in networks that perform automatic route aggregation.
Babelのループ回避メカニズムは、パケット損失がある場合でも、すべての隣人が退避時に行動したことが保証されるまで、退避後に経路を到達できないように依存しています。[RFC8966]のセクション3.5.5で説明されている2番目のアルゴリズムが実装されていない限り、これはノードが後退されてから数分後に数分間到達できないことを伴います。この遅延により、自動ルート集約を実行するネットワークのトポロジ変更から回復するのが遅くなります。
This section gives a few examples of environments where Babel has been successfully deployed.
このセクションでは、Babelが正常にデプロイされた環境の例をいくつか示します。
Babel is able to deal with both classical, prefix-based ("Internet-style") routing and flat ("mesh-style") routing over non-transitive link technologies. Just like traditional distance-vector protocols, Babel is able to carry prefixes of arbitrary length, to suppress redundant announcements by applying the split-horizon optimisation where applicable, and can be configured to filter out redundant announcements (manual aggregation). Just like specialised mesh protocols, Babel doesn't by default assume that links are transitive or symmetric, can dynamically compute metrics based on an estimation of link quality, and carries large numbers of host routes efficiently by omitting common prefixes.
Babelは、非推移的なリンク技術を介して、クラシック、プレフィックスベース（「インターネットスタイル」）ルーティングとフラット（「メッシュスタイル」）ルーティングの両方に対処することができます。従来の距離 - ベクトルプロトコルと同じように、Babelは任意の長さの接頭辞を持ち運ぶことができ、該当する場合はスプリットホライズン最適化を適用することによって冗長発表を抑制することができ、冗長なアナウンスメントを除外するように構成することができます（手動集約）。特殊なメッシュプロトコルと同じように、Babelはデフォルトではリンクが推移的であるか対称であると仮定し、リンク品質の推定に基づいてメトリックを動的に計算することができ、共通のプレフィックスを省略することによって多数のホストルートを効率的に搬送することができます。
Because of these properties, Babel has seen a number of successful deployments in medium-sized heterogeneous networks, networks that combine a wired, aggregated backbone with meshy wireless bits at the edges.
これらのプロパティのために、Babelは、中規模の異種ネットワーク、有線、集約バックボーンをエッジで結合しているネットワーク、中規模の異種ネットワークに多くの成功した展開を見てきました。
Efficient operation in heterogeneous networks requires the implementation to distinguish between wired and wireless links, and to perform link quality estimation on wireless links.
不均一ネットワークにおける効率的な動作は、有線リンクと無線リンクを区別し、無線リンク上のリンク品質推定を実行するために実装を必要とする。
The algorithms used by Babel (loop avoidance, hysteresis, delayed updates) allow it to remain stable in the presence of unstable metrics, even in the presence of a feedback loop. For this reason, it has been successfully deployed in large-scale overlay networks, built out of thousands of tunnels spanning continents, where it is used with a metric computed from links' latencies.
Babel（ループ回避、ヒステリシス、遅延更新）によって使用されるアルゴリズムは、フィードバックループが存在していても、不安定なメトリックの存在下で安定したままであることを可能にします。このため、大陸のスパンスパンの数千のトンネルから構築された大規模なオーバーレイネットワークにうまく展開されています。ここでは、リンクの待ち時間から計算されたメトリックで使用されます。
This particular application depends on the extension for RTT-sensitive routing [DELAY-BASED].
この特定のアプリケーションは、RTTに敏感なルーティング[遅延ベース]の拡張によって異なります。
While Babel is a general-purpose routing protocol, it has been shown to be competitive with dedicated routing protocols for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. Although this particular niche is already served by a number of mature protocols, notably the Optimized Link State Routing Protocol with Expected Transmission Count (OLSR-ETX) and OLSRv2 (OLSR Version 2) [RFC7181] (equipped e.g., with the Directional Airtime (DAT) metric [RFC7779]), Babel has seen a moderate amount of successful deployment in pure mesh networks.
Babelが汎用ルーティングプロトコルであるが、無線メッシュネットワークの専用ルーティングプロトコルと競合的であることが示されています[Real-World] [Briding-Liapan]。この特定のニッチはすでに多数の成熟プロトコル、特に予想される送信数（OLSR-ETX）およびOLSRV2（OLSRバージョン2）[RFC7181]（例えば、DINEDAIR AIRTIME（DAT）を備えた最適化されたリンクステートルーティングプロトコルによって既に奉仕されています。）メトリック[RFC7779]）、Babelは純粋なメッシュネットワークで適度な量の成功した展開を見ました。
Because of its small size and simple configuration, Babel has been deployed in small, unmanaged networks (e.g., home and small office networks), where it serves as a more efficient replacement for RIP [RFC2453], over which it has two significant advantages: the ability to route multiple address families (IPv6 and IPv4) in a single protocol instance and good support for using wireless links for transit.
その小型で簡単な構成のため、Babelは小さくて管理されていないネットワーク（ホームおよび小売ネットワーク）に展開されており、そこでRIP [RFC2453]のためのより効率的な代替品として機能します。単一のプロトコルインスタンスで複数のアドレスファミリ（IPv6とIPv4）をルーティングする機能とトランジットのワイヤレスリンクを使用することをサポートします。
As is the case in all distance-vector routing protocols, a Babel speaker receives reachability information from its neighbours, which by default is trusted by all nodes in the routing domain.
すべての距離ルーティングプロトコルの場合と同様に、Babelスピーカーはその隣接者からの到達可能性情報を受信します。これはデフォルトではルーティングドメイン内のすべてのノードによって信頼されています。
At the time of writing, the Babel protocol is usually run over a network that is secured either at the physical layer (e.g., physically protecting Ethernet sockets) or at the link layer (using a protocol such as Wi-Fi Protected Access 2 (WPA2)). If Babel is being run over an unprotected network, then the routing traffic needs to be protected using a sufficiently strong cryptographic mechanism.
書き込み時には、Babelプロトコルは通常、物理層（例えば、イーサネットソケット）またはリンク層（Wi-Fi保護アクセス2などのプロトコルを使用して）のいずれか（例えば、プロトコルを使用して）））））。Babelが保護されていないネットワーク上で実行されている場合、ルーティングトラフィックは十分に強い暗号化メカニズムを使用して保護される必要があります。
At the time of writing, two such mechanisms have been defined. Message Authentication Code (MAC) authentication for Babel (Babel-MAC) [RFC8967] is a simple and easy to implement mechanism that only guarantees authenticity, integrity, and replay protection of the routing traffic and only supports symmetric keying with a small number of keys (typically just one or two). Babel-DTLS [RFC8968] is a more complex mechanism that requires some minor changes to be made to a typical Babel implementation and depends on a DTLS stack being available, but inherits all of the features of DTLS, notably confidentiality, optional replay protection, and the ability to use asymmetric keys.
書き込み時には、そのようなメカニズムの2つが定義されています。Babel（Babel-Mac）のメッセージ認証コード（BABEL-MAC）[RFC8967]は、ルーティングトラフィックの信頼性、整合性、および再生保護のみを保証し、少数のキーでの対称キーイングのみを保証するためのシンプルで実装が簡単なメカニズムです。（通常は1つか2つだけ）。Babel-DTLS [RFC8968]は、典型的なBabelの実装にいくつかの小さな変更を加える必要があり、利用可能なDTLSスタックによって異なりますが、特に機密性、オプションの再生保護のすべての機能を継承します。非対称キーを使用する能力。
Due to its simplicity, Babel-MAC should be the preferred security mechanism in most deployments, with Babel-DTLS available for networks that require its additional features.
その単純さのために、Babel-Macはほとんどの展開では好ましいセキュリティメカニズムであるべきです。
In addition to the above, the information that a mobile Babel node announces to the whole routing domain is often sufficient to determine a mobile node's physical location with reasonable precision. This might make Babel unapplicable in scenarios where a node's location is considered confidential.
上記に加えて、モバイルベイベルノードがルーティングドメイン全体をアナウンスする情報は、妥当な精度でモバイルノードの物理的な位置を決定するのに十分であることが多い。これにより、ノードの場所が機密と見なされるシナリオで、Babelが未解決になる可能性があります。
[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>。
[BABEL-RTT] Jonglez, B. and J. Chroboczek, "Delay-based Metric Extension for the Babel Routing Protocol", Work in Progress, Internet-Draft, draft-jonglez-babel-rtt-extension-02, 11 March 2019, <https://tools.ietf.org/html/ draft-jonglez-babel-rtt-extension-02>.
[BABEL-RTT] Jonglez、B.およびJ.Chroboczek、「Babelルーティングプロトコルのための遅延ベースのメトリック拡張」、進行中の作業、インターネットドラフト、ドラフト - Jonglez-Babel-RTT-Extension-02,219、<https://tools.ietf.org/html/ romft-jonglez-babel-rtt-extension-02>。
[BABEL-SS] Boutier, M. and J. Chroboczek, "Source-Specific Routing in Babel", Work in Progress, Internet-Draft, draft-ietf-babel-source-specific-07, 28 October 2020, <https://tools.ietf.org/html/draft-ietf-babel-source-specific-07>.
[Babel-SS] Boutier、M.およびJ.Chroboczek、「Babelのソース固有のルーティング」、進行中の作業、インターネットドラフト、ドラフト - Babel-Source-Seconde-Seconde-Seconde-07,2020、<https：//tools.ietf.org/html/draft-ietf-babel-Source-Specific-07>。
[BABEL-TOS] Chouasne, G. and J. Chroboczek, "TOS-Specific Routing in Babel", Work in Progress, Internet-Draft, draft-chouasne-babel-tos-specific-00, 3 July 2017, <https://tools.ietf.org/html/draft-chouasne-babel-tos-specific-00>.
[Babel-Tos] Chouasne、G.およびJ.Chroboczek、「BabelのTOS固有のルーティング」、進行中の作業、インターネットドラフト、ドラフト - Chouasne-Babel-Tos-Seconduct-00、<https：//tools.ietf.org/html/draft-chouasne-babel-tos-specific-00>
[BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing Protocol", Work in Progress, Internet-Draft, draft-chroboczek-babel-diversity-routing-01, 15 February 2016, <https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-01>.
[Babel-Z] Chroboczek、J.、「Babelルーティングプロトコルのための多様性ルーティング」、進行中の作業、インターネットドラフト、ドラフト - Chroboczek-Babel-Diversity-Routing-01,15,15、<https：//ツール.ietf.org / html / draft-chroboczek-babel-divel-routing-01>。
[BRIDGING-LAYERS] Murray, D., Dixon, M., and T. Koziniec, "An Experimental Comparison of Routing Protocols in Multi Hop Ad Hoc Networks", In Proceedings of ATNAC, DOI 10.1109/ATNAC.2010.5680190, October 2010, <https://doi.org/10.1109/ATNAC.2010.5680190>.
[ブリッジー層] Murray、D.、Dixon、M.およびT.Koziniec、「マルチホップアドホックネットワークにおけるルーティングプロトコルの実験的比較」、ATNAC、DOI 10.1109 / ATNAC.2010.5680190、2010年10月、<https://doi.org/10.1109/atnac.2010.5680190>。
[DELAY-BASED] Jonglez, B., Boutier, M., and J. Chroboczek, "A delay-based routing metric", March 2014, <http://arxiv.org/abs/1403.3488>.
[遅延ベース] Jonglez、B.、Boutier、M.、J.Chroboczek、「遅延ベースのルーティングメトリック」、2014年3月、<http://arxiv.org/abs/1403.3488>。
[DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers", ACM SIGCOMM '94: Proceedings of the Conference on Communications Architectures, Protocols and Applications, pp. 234-244, DOI 10.1145/190314.190336, October 1994, <https://doi.org/10.1145/190314.190336>.
[DSDV] Perkins、C、P.Bhagwat、「モバイルコンピュータのための高動的な宛先順序距離 - ベクトルルーティング（DSDV）」、ACM SIGCOMM '94：通信アーキテクチャ、プロトコル、およびアプリケーション、PP。234-244、DOI 10.1145 / 190314.190336、1994年10月、<https：//doi.org/10.1145/190314.190336>。
[DUAL] Garcia-Luna-Aceves, J. J., "Loop-Free Routing Using Diffusing Computations", IEEE/ACM Transactions on Networking, Volume 1, Issue 1, DOI 10.1109/90.222913, February 1993, <https://doi.org/10.1109/90.222913>.
[デュアル] Garcia-Luna-Aceves、JJ、「拡散計算を使用したループフリールーティング」、ネットワーキング、第1巻、IEEE / ACMトランザクション1993年2月、<https：//doi.org/ 10.1109/90.222913>。
[LOADng] Clausen, T. H., Verdiere, A. C. D., Yi, J., Niktash, A., Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. Dean, "The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)", Work in Progress, Internet-Draft, draft-clausen-lln-loadng-15, 4 July 2016, <https://tools.ietf.org/html/draft-clausen-lln-loadng-15>.
[Loadng] Chrausen、Th、Verdiere、ACD、Yi、J.、Niktash、A。、Igarashi、Y、佐藤、H.、Herberg、U.、Lavenu、C.、Lys、T.、J. Dean、「軽量オンデマンドアドホック距離ベクトルルーティングプロトコル - 次世代（LOADNG）」、進行中の作業、インターネットドラフト、ドラフトCLAUSEN-LLN-LOADNG-15,17月4日、<https：//ツール.ietf.org / html / draft-clausen-lln-loadng-15>。
[METAROUTING] Griffin, T. G. and J. L. Sobrinho, "Metarouting", ACM SIGCOMM Computer Communication Review, Volume 35, Issue 4, DOI 10.1145/1090191.1080094, August 2005, <https://doi.org/10.1145/1090191.1080094>.
[Metarouting] Griffin、T.G、J.L.Sobrinho、「メタルーティング」、ACM SIGCommコンピュータ通信レビュー、第35号、DOI 10.1145 / 1090191.1080094、<https：//doi.org/10.1145/1090191.1080094>。
[REAL-WORLD] Abolhasan, M., Hagelstein, B., and J. C.-P. Wang, "Real-world performance of current proactive multi-hop mesh protocols", 15th Asia-Pacific Conference on Communications, DOI 10.1109/APCC.2009.5375690, October 2009, <https://doi.org/10.1109/APCC.2009.5375690>.
[現実世界] Abolhasan、M.、Hagelstein、B.、J.C.-P。王、「現在の予防的マルチホップメッシュプロトコルの現実的なパフォーマンス」、第15回アジア太平洋コミュニケーション、DOI 10.1109 / APCC.2009.5375690、<https：//doi.org/10.1109/APCC.2009.5375699>。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC1195] Callon、R.、「OSIの使用はTCP / IPおよびデュアル環境でのルーティング用です」、RFC 1195、DOI 10.17487 / RFC1195、1990年12月、<https：//www.rfc-editor.org/情報/ RFC1195>。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.
[RFC2453] Malkin、G.、 "RIPバージョン2"、STD 56、RFC 2453、DOI 10.17487 / RFC2453、1998年11月、<https：//www.rfc-editor.org/info/rfc2453>。
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, <https://www.rfc-editor.org/info/rfc3561>.
[RFC3561] Perkins、C、Belding-Royer、E.、S.DAS、「アドホックオンデマンド距離ベクトル（AODV）ルーティング」、RFC 3561、DOI 10.17487 / RFC3561、2003年7月、<https：//www.rfc-editor.org/info/rfc3561>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J.、およびA. Lindem、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<https：///www.rfc-編集者.org / info / rfc5340>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T.、ED。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR.RPL：低消費電力ネットワークの「RPL：IPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<https：//www.rfc-editor.org/info/RFC6550>。
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, <https://www.rfc-editor.org/info/rfc7181>.
[RFC7181] Chrausen、T.、Dearlove、C.、Jacquet、P.、およびU.Herberg、「最適化されたリンクステートルーティングプロトコルバージョン2」、RFC 7181、DOI 10.17487 / RFC7181、2014年4月、<https：//www.rfc-editor.org/info/rfc7181>。
[RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)", RFC 7779, DOI 10.17487/RFC7779, April 2016, <https://www.rfc-editor.org/info/rfc7779>.
[RFC7779] Rogge、H.およびE.Baccelli、「最適化されたリンク状態ルーティングバージョン2（OLSRV2）」、RFC 7779、DOI 10.17487 / RFC7779、2016年4月、<https：// www.rfc-editor.org / info / rfc7779>。
[RFC7868] Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and R. White, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, May 2016, <https://www.rfc-editor.org/info/rfc7868>.
[RFC7868] Savage、D.、NG、J.、Moore、S.、Slice、D.、Paluch、P.、R. White、「シスコの強化インテリアゲートウェイルーティングプロトコル（EIGRP）」、RFC 7868、DOI 10.17487/ RFC7868、2016年5月、<https：//www.rfc-editor.org/info/rfc7868>。
[RFC8967] Dô, C., Kolodziejak, W., and J. Chroboczek, "MAC Authentication for the Babel Routing Protocol", RFC 8967, DOI 10.17487/RFC8967, January 2021, <https://www.rfc-editor.org/info/rfc8967>.
[RFC8967]Dô、C.、Kolodziejak、W.およびJ.Chroboczek、「BabelルーティングプロトコルのMAC認証」、RFC 8967、DOI 10.17487 / RFC8967、2021年1月、<https：//www.rfc-編集者。ORG / INFO / RFC8967>。
[RFC8968] Décimo, A., Schinazi, D., and J. Chroboczek, "Babel Routing Protocol over Datagram Transport Layer Security", RFC 8968, DOI 10.17487/RFC8968, January 2021, <https://www.rfc-editor.org/info/rfc8968>.
[RFC8968]Décimo、A.、Schinazi、D.、およびJ.Chroboczek、「データグラムトランスポート層のセキュリティ上の「Babelルーティングプロトコル」、RFC 8968、DOI 10.17487 / RFC8968、2021年1月、<https：//www.rfc-編集者.org / info / rfc8968>。
[SS-ROUTING] Boutier, M. and J. Chroboczek, "Source-specific routing", In Proceedings of the 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 / ifipnetworking.2015.7145305、<http://arxiv.org/pdf/1403.0445>。
Acknowledgments
謝辞
The author is indebted to Jean-Paul Smetz and Alexander Vainshtein for their input to this document.
著者は、この文書への彼らの入力のためのJean-Paul SmetzとAlexander Vainshteinに留学しています。
Author's Address
著者の住所
Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris CEDEX 13 France
Juliusz Chroboczek IRIF、パリ大学ケース7014 75205 Paris Cedex 13フランス
Email: jch@irif.fr