RFC 9080 - Homenet Profile of the Babel Routing Protocol 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9080.html
タイトル : RFC 9080 - Babelルーティングプロトコルのホームメネプロファイル
翻訳編集 : 自動生成

[要約] RFC 9080は、BabelルーティングプロトコルのHomenet（ホームネットワーク）プロファイルを定義しています。この文書の目的は、家庭内ネットワークでのBabelの使用を標準化し、設定を簡素化することです。利用場面としては、複数のルーターを持つ家庭内ネットワークでの効率的なルーティングと、異なるネットワーク技術間の接続性の向上が挙げられます。

Internet Engineering Task Force (IETF)                     J. Chroboczek
Request for Comments: 9080             IRIF, University of Paris-Diderot
Category: Standards Track                                    August 2021
ISSN: 2070-1721

Homenet Profile of the Babel Routing Protocol

Babelルーティングプロトコルのホームメネプロファイル

Abstract

概要

This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of the Homenet protocol suite, as well as the interactions between the Home Networking Control Protocol (HNCP) and Babel.

このドキュメントは、Babelルーティングプロトコルの正確なサブセットと、Homenetプロトコルスイートの実装、およびホームネットワーキング制御プロトコル（HNCP）と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/rfc9080.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9080で入手できます。

著作権表示

著作権（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
     1.1.  Requirements Language
     1.2.  Background
   2.  The Homenet Profile of Babel
     2.1.  Requirements
     2.2.  Optional Features
   3.  Interactions between HNCP and Babel
     3.1.  Requirements
     3.2.  Optional Features
   4.  Security Considerations
   5.  IANA Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgments
   Author's Address

1. Introduction

1. はじめに

The core of the Homenet protocol suite consists of the Home Networking Control Protocol (HNCP) [RFC7788], a protocol used for flooding configuration information and assigning prefixes to links, combined with the Babel routing protocol [RFC8966]. Babel is an extensible, flexible, and modular protocol: minimal implementations of Babel have been demonstrated that consist of a few hundred lines of code, while the "large" implementation includes support for a number of extensions and consists of over ten thousand lines of C code.

Homenet Protocol Suiteの中核は、ホームネットワーキング制御プロトコル（HNCP）[RFC7788]で構成されています。Babelは拡張性、柔軟でモジュラープロトコルです。「大きい」実装では、数百列のコードで構成されていますが、「大きい」実装では数百kmのコードで構成されており、1万列のCのCで構成されています。コード。

This document consists of two parts. The first specifies the exact subset of the Babel protocol and its extensions that is required by an implementation of the Homenet protocol suite. The second specifies how HNCP interacts with Babel.

この文書は2つの部分で構成されています。最初は、Babelプロトコルの正確なサブセットと、HomeNetプロトコルスイートの実装に必要なその拡張機能を指定します。2番目は、HNCPがBabelと対話する方法を指定します。

1.1. Requirements Language

1.1. 要件言語

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]で説明されているように、すべて大文字の場合にのみ解釈されます。

1.2. Background

1.2. バックグラウンド

The Babel routing protocol and its extensions are defined in a number of documents:

Babelルーティングプロトコルとその拡張機能は、いくつかの文書で定義されています。

* RFC 8966 [RFC8966] defines the Babel routing protocol. It allows Babel's control data to be carried either over link-local IPv6 or over IPv4 and in either case allows announcing both IPv4 and IPv6 routes. It leaves link cost estimation, metric computation, and route selection to the implementation. Distinct implementations of Babel [RFC8966] will interoperate, in the sense that they will maintain a set of loop-free forwarding paths. However, if they implement conflicting options, they might not be able to exchange a full set of routes. In the worst case, an implementation that only implements the IPv6 subset of the protocol and an implementation that only implements the IPv4 subset of the protocol will not exchange any routes. In addition, if implementations use conflicting route selection policies, persistent oscillations might occur.

* RFC 8966 [RFC8966] Babelルーティングプロトコルを定義します。これにより、Babelの制御データをリンクローカルIPv6またはIPv4を介して実行することができ、どちらの場合もIPv4とIPv6ルートの両方をアナウンスすることができます。それはリンクコスト推定、メトリック計算、およびルート選択を実装に残す。Babel [RFC8966]の明確な実装は、それらが一連のループフリー転送経路を維持するという意味で相互運用します。ただし、矛盾するオプションを実装すると、ルートのフルセットを交換できない可能性があります。最悪の場合、プロトコルのIPv6サブセットのみを実装し、プロトコルのIPv4サブセットのみを実装する実装はルートを交換しません。さらに、実装が競合するルート選択ポリシーを使用する場合、持続的な振動が発生する可能性があります。

* The informative Appendix A of [RFC8966] suggests a simple and easy-to-implement algorithm for cost and metric computation that has been found to work satisfactorily in a wide range of topologies.

* [RFC8966]の有益な付録Aは、幅広いトポロジで十分に機能することが判明したコストおよびメトリック計算のための簡単で実装の容易なアルゴリズムを提案しています。

* While RFC 8966 does not provide an algorithm for route selection, its Section 3.6 suggests selecting the route with the smallest metric with some hysteresis applied. An algorithm that has been found to work well in practice is described in Section III.E of [DELAY-BASED].

* RFC 8966はルート選択のためのアルゴリズムを提供していないが、そのセクション3.6は、いくつかのヒステリシスを適用して最小のメトリックを持つルートを選択することを提案します。実際にはうまく機能することが判明したアルゴリズムは、セクションIII.Eの「遅延ベース」に記載されています。

* Four documents define optional extensions to Babel: authentication based on Hashed Message Authentication Code (HMAC) [RFC8967], source-specific routing [RFC9079], delay-based routing [BABEL-RTT], and ToS-specific (Type of Service) routing [ToS-SPECIFIC]. All of these extensions interoperate with the core protocol as well as with each other.

* 4つのドキュメントのバベルにオプションの拡張子を定義します。ハッシュされたメッセージ認証コード（HMAC）[RFC8967]、ソース固有のルーティング[RFC9079]、遅延ベースのルーティング[BABEL-RTT]、およびTOS固有（サービスの種類）ルーティング[TOS固有]これらの拡張はすべて、互いにコアプロトコルと同様に相互運用しています。

2. The Homenet Profile of Babel

2. ベイベルのホームメニエプロフィール

2.1. Requirements

2.1. 要件

REQ1: A Homenet implementation of Babel MUST encapsulate Babel control traffic in IPv6 packets sent to the IANA-assigned port 6696 and either the IANA-assigned multicast group ff02::1:6 or to a link-local unicast address.

REQ1：BabelのHomEnet実装は、IANA割り当てられたポート6696に送信されたIPv6パケットとIANA割り当てられたマルチキャストグループFF02 :: 1：6またはリンクローカルユニキャストアドレスのいずれかをカプセル化する必要があります。

Rationale: Since Babel is able to carry both IPv4 and IPv6 routes over either IPv4 or IPv6, choosing the protocol used for carrying control traffic is a matter of preference. Since IPv6 has some features that make implementations somewhat simpler and more reliable (notably properly scoped and reasonably stable link-local addresses), we require carrying control data over IPv6.

根拠：BabelはIPv4またはIPv6のどちらかでIPv4とIPv6の両方のルートを運ぶことができますので、制御トラフィックを運ぶために使用されるプロトコルを選択することは好みの問題です。IPv6には、実装をややより簡単かつより信頼性が高い（特に適切にスコープされ、合理的に安定したリンクローカルアドレス）、IPv6を介して制御データを伝送する必要があります。

REQ2: A Homenet implementation of Babel MUST implement the IPv6 subset of the protocol defined in the body of RFC 8966.

REQ2：BABELのHomEnet実装は、RFC 8966の本文で定義されているプロトコルのIPv6サブセットを実装する必要があります。

Rationale: Support for IPv6 routing is an essential component of the Homenet architecture.

根拠：IPv6ルーティングのサポートは、HomeNetアーキテクチャの不可欠なコンポーネントです。

REQ3: A Homenet implementation of Babel SHOULD implement the IPv4 subset of the protocol defined in the body of RFC 8966. Use of other techniques for acquiring IPv4 connectivity (such as multiple layers of NAT) is strongly discouraged.

REQ3：BabelのHomenet実装は、RFC 8966の本体に定義されているプロトコルのIPv4サブセットを実装する必要があります.IPv4接続を取得するための他の技術の使用（NATの複数の層など）は強く推奨されます。

Rationale: Support for IPv4 will likely remain necessary for years to come, and even in pure IPv6 deployments, including code for supporting IPv4 has very little cost. Since HNCP makes it easy to assign distinct IPv4 prefixes to the links in a network, it is not necessary to resort to multiple layers of NAT, with all of its problems.

根拠：IPv4のサポートは何年もの間必要であると思われるでしょう、そしてIPv4をサポートするためのコードを含む純粋なIPv6展開でさえも、コストはほとんどありません。HNCPにより、ネットワーク内のリンクに異なるIPv4プレフィックスを簡単に割り当てることができれば、その問題がすべて異なるため、NATの複数の層に頼る必要はありません。

REQ4: A Homenet implementation of Babel MUST implement source-specific routing for IPv6, as defined in RFC 9079 [RFC9079].

REQ4：RFC 9079 [RFC9079]で定義されているように、BabelのHomEnet実装はIPv6のソース固有のルーティングを実装する必要があります。

Rationale: Source-specific routing is an essential component of the Homenet architecture. Source-specific routing for IPv4 is not required, since HNCP arranges things so that a single nonspecific IPv4 default route is announced (Section 6.5 of [RFC7788]).

根拠：Source固有のルーティングは、HomeNetアーキテクチャの重要なコンポーネントです。IPv4のソース固有のルーティングは必要ありません.HNCPは、単一の非スペックIPv4デフォルトルートがアナウンスされるように物事を整理するため（[RFC7788]のセクション6.5）。

REQ5: A Homenet implementation of Babel must use metrics that are of a similar magnitude to the values suggested in Appendix A of [RFC8966]. In particular, it SHOULD assign costs that are no less than 256 to wireless links and SHOULD assign costs between 32 and 196 to lossless wired links.

REQ5：Babelのホームメンテーションは、[RFC8966]の付録Aで示唆されている値と同様の大きさのメトリックを使用する必要があります。特に、無線リンクに256以上のコストを割り当てる必要があり、22~196号線から無損失の有線リンクを割り当てる必要があります。

Rationale: If two implementations of Babel choose very different values for link costs, combining routers from different vendors will cause suboptimal routing.

根拠：Babelの2つの実装がリンクコストに非常に異なる値を選択した場合、さまざまなベンダーのルータを組み合わせると、最適なルーティングが発生します。

REQ6: A Homenet implementation of Babel SHOULD distinguish between wired and wireless links; if it is unable to determine whether a link is wired or wireless, it SHOULD make the worst-case hypothesis that the link is wireless. It SHOULD dynamically probe the quality of wireless links and derive a suitable metric from its quality estimation. Appendix A of [RFC8966] gives an example of a suitable algorithm.

REQ6：BabelのHomenet実装は、有線リンクと無線のリンクを区別する必要があります。リンクが有線または無線であるかどうかを判断できない場合は、リンクが無線であるという最悪の場合の仮説を作成する必要があります。それは無線リンクの品質を動的に調べ、その品質推定から適切な測定基準を導き出すべきです。[RFC8966]の付録Aは適切なアルゴリズムの例を示しています。

Rationale: Support for wireless transit links is a distinguishing feature of Homenet, and one that is requested by our users. In the absence of dynamically computed metrics, the routing protocol attempts to minimise the number of links crossed by a route and therefore prefers long, lossy links to shorter, lossless ones. In wireless networks, "hop-count routing is worst-path routing".

根拠：ワイヤレストランジットリンクのサポートは、ホームメネットの際立った機能、およびユーザーが要求されているものです。動的に計算されたメトリックがない場合、ルーティングプロトコルは経路によって交差したリンクの数を最小限に抑えようと試み、したがってより短いロスレスなものへの長い損失のあるリンクを好みます。無線ネットワークでは、「ホップカウントルーティングは最悪の経路ルーティング」です。

While it would be desirable to perform link-quality probing on some wired link technologies, notably power-line networks, these kinds of links tend to be difficult or impossible to detect automatically, and we are not aware of any published link-quality algorithms for them. Hence, we do not require link-quality estimation for wired links of any kind.

いくつかの有線リンク技術、特に電力線ネットワークでリンク品質プロービングを実行することが望ましいであろうが、これらの種類のリンクは自動的に検出することが困難であるか不可能であり、そして我々は公開されたリンク品質アルゴリズムを知らない。彼ら。したがって、我々はあらゆる種類の有線リンクのためのリンク品質推定を必要としない。

2.2. Optional Features

2.2. オプションの機能

OPT1: A Homenet implementation of Babel MAY perform route selection by applying hysteresis to route metrics, as suggested in Section 3.6 of [RFC8966] and described in detail in Section III.E of [DELAY-BASED]. However, hysteresis is not required, and the implementation may simply pick the route with the smallest metric.

OPT1：BABELのホームメンテーションの実装は、[RFC8966]のセクション3.6で示唆され、[遅延ベース]のセクションIII.Eで詳細に説明されているように、ルートメトリックにヒステリシスを適用することによってルート選択を実行することができる。しかしながら、ヒステリシスは必要とされず、実装は単に最小のメトリックで経路を選択することができる。

Rationale: Hysteresis is only useful in congested and highly dynamic networks. In a typical home network, which is stable and uncongested, the feedback loop that hysteresis compensates for does not occur.

根拠：ヒステリシスは、混雑している高度なネットワークでのみ役立ちます。安定していない典型的なホームネットワークでは、ヒステリシスが補償されないフィードバックループが発生しません。

OPT2: A Homenet implementation of Babel may include support for other extensions to the protocol, as long as they are known to interoperate with both the core protocol and source-specific routing.

OPT2：Babelのホームメンテーションは、コアプロトコルとソース固有のルーティングの両方と相互運用することが知られている限り、プロトコルへの他の拡張のサポートを含むことができる。

Rationale: A number of extensions to the Babel routing protocol have been defined over the years; however, they are useful in fairly specific situations, such as routing over global-scale overlay networks [BABEL-RTT] or multi-hop wireless networks with multiple radio frequencies [BABEL-Z]. Hence, with the exception of source-specific routing, no extensions are required for Homenet.

根拠：Babelルーティングプロトコルに対するいくつかの拡張機能は、長年にわたり定義されています。ただし、グローバルスケールオーバーレイネットワーク[BABEL-RTT]または複数の無線周波数[BABEL-Z]を持つマルチホップワイヤレスネットワークをルーティングするなど、かなり具体的な状況で役立ちます。したがって、ソース固有のルーティングを除いて、ホームメネットには拡張機能は必要ありません。

3. Interactions between HNCP and Babel

3. HNCPとBabelの間の相互作用

The Homenet architecture cleanly separates configuration, which is done by HNCP, from routing, which is done by Babel. While the coupling between the two protocols is deliberately kept to a minimum, some interactions are unavoidable.

HomEnetアーキテクチャは、Babelによって行われているルーティングからのHNCPによって行われる構成をきれいに分離します。2つのプロトコル間の結合は意図的に最小限に抑えられているが、いくつかの相互作用は避けられない。

All the interactions between HNCP and Babel consist of HNCP causing Babel to perform an announcement on its behalf (under no circumstances does Babel cause HNCP to perform an action). How this is realised is an implementation detail that is outside the scope of this document; while it could conceivably be done using a private communication channel between HNCP and Babel, in existing implementations, HNCP installs a route in the operating system's kernel that is later picked up by Babel using the existing redistribution mechanisms.

HNCPとBabelの間のすべての相互作用はHNCPで構成されています。これはBabelがその代わりに発表を実行することからなります（Babelはhncpはhncpが行動を実行する原因）。これがどのように実現されるかは、この文書の範囲外の実装詳細です。既存の実装では、HNCPとBabelの間のプライベートコミュニケーションチャネルを使用して行うことができると考えられている可能性がありますが、HNCPは既存の再配布メカニズムを使用してBabelによって後でピックアップされているオペレーティングシステムのカーネルにルートをインストールします。

3.1. Requirements

3.1. 要件

REQ7: If an HNCP node receives a DHCPv6 prefix delegation for prefix P and publishes an External-Connection TLV containing a Delegated-Prefix TLV with prefix P and no Prefix-Policy TLV, then it MUST announce a source-specific default route with source prefix P over Babel.

REQ7：HNCPノードがPrefix P用のDHCPv6プレフィックスの委任を受け取り、プレフィックスpとプレフィックス・ポリシーTLVを含まない委任プレフィックスTLVを含む外部接続TLVを発行した場合、ソースプレフィックスを使用してソース固有のデフォルトルートをアナウンスする必要があります。赤ちゃんの上にp。

Rationale: Source-specific routes are the main tool that Homenet uses to enable optimal routing in the presence of multiple IPv6 prefixes. External connections with nontrivial prefix policies are explicitly excluded from this requirement, since their exact behaviour is application specific.

根拠：ソース固有のルートは、複数のIPv6プレフィックスの存在下で最適なルーティングを有効にするためにHomEnetが使用するメインツールです。それらの正確な動作はアプリケーション固有であるため、非論理プレフィックスポリシーとの外部接続はこの要件から明示的に除外されます。

REQ8: If an HNCP node receives a DHCPv4 lease with an IPv4 address and wins the election for NAT gateway, then it MUST act as a NAT gateway and MUST announce a (nonspecific) IPv4 default route over Babel.

REQ8：HNCPノードがIPv4アドレスを使用してDHCPv4リースを受信し、NATゲートウェイの選挙に勝利した場合は、NATゲートウェイとして機能し、（非特定）IPv4のデフォルトルートをBABEL上でアナウンスしなければなりません。

Rationale: The Homenet stack does not use source-specific routing for IPv4; instead, HNCP elects a single NAT gateway and publishes a single default route towards that gateway ([RFC7788], Section 6.5).

根拠：HomeNetスタックは、IPv4のソース固有のルーティングを使用しません。代わりに、HNCPは単一のNATゲートウェイを選択し、そのゲートウェイに向けて単一のデフォルトルートを公開します（[RFC7788]、セクション6.5）。

REQ9: If an HNCP node assigns a prefix P to an attached link and announces P in an Assigned-Prefix TLV, then it MUST announce a route towards P over Babel.

REQ9：HNCPノードが添付リンクに接頭辞Pを割り当てて、割り当てられたプレフィックスTLVでPを発表する場合は、BabelのPRへのルートを発表する必要があります。

Rationale: Prefixes assigned to links must be routable within the Homenet.

根拠：リンクに割り当てられたプレフィックスは、ホームメニット内でルーティング可能でなければなりません。

3.2. Optional Features

3.2. オプションの機能

OPT3: An HNCP node that receives a DHCPv6 prefix delegation MAY announce a nonspecific IPv6 default route over Babel in addition to the source-specific default route mandated by requirement REQ7.

OPT3：DHCPv6プレフィックスの委任を受け取るHNCPノードは、要件REQ7によって義務付けられているソース固有のデフォルトルートに加えて、Babelを介して非特定のIPv6デフォルトルートをアナウンスすることがあります。

Rationale: Since the source-specific default route is more specific than the nonspecific default route, the former will override the latter if all nodes implement source-specific routing. Announcing an additional nonspecific route is allowed, since doing that causes no harm and might simplify operations in some circumstances, e.g., when interoperating with a routing protocol that does not support source-specific routing.

根拠：ソース固有のデフォルトルートは非特異的なデフォルトルートよりも具体的であるため、すべてのノードがソース固有のルーティングを実装している場合、前者は後者を上書きします。害を及ぼさないため、ソース固有のルーティングをサポートしていないルーティングプロトコルと相互運用する場合は、そのため、追加の非特定のルートを発表することができます。

OPT4: An HNCP node that receives a DHCPv4 lease with an IPv4 address and wins the election for NAT gateway SHOULD NOT announce a source-specific IPv4 default route.

OPT4：IPv4アドレスを使用してDHCPv4リースを受信し、NATゲートウェイの選挙に勝つHNCPノードは、ソース固有のIPv4のデフォルトルートをアナウンスしないでください。

Rationale: Homenet does not require support for IPv4 source-specific routing. Announcing IPv4 source-specific routes will not cause routing pathologies (blackholes or routing loops), but it might cause packets sourced in different parts of the Homenet to follow different paths, with all the confusion that this entails.

根拠：HomEnetは、IPv4ソース固有のルーティングのサポートを必要としません。IPv4のソース固有のルートを発表すると、ルーティングのパスロジー（ブラックホールまたはルーティングループ）は原因ではありませんが、これが伴うすべての混乱を伴う、ホームメニットのさまざまな部分に入るパケットを引き起こす可能性があります。

4. Security Considerations

4. セキュリティに関する考慮事項

Both HNCP and Babel carry their control data in IPv6 packets with a link-local source address, and implementations are required to drop packets sent from a global address. Hence, they are only susceptible to attacks from a directly connected link on which the HNCP and Babel implementations are listening.

HNCPとBabelの両方が、リンクローカルの送信元アドレスを持つIPv6パケットに制御データを搭載し、グローバルアドレスから送信されたパケットをドロップするために実装が必要です。したがって、それらは、HNCPとBabelの実装がリスニングされている直接接続リンクからの攻撃のみを受けやすいです。

The security of a Homenet network relies on having a set of "Internal", "Ad Hoc", and "Hybrid" interfaces (Section 5.1 of [RFC7788]) that are assumed to be connected to links that are secured at a lower layer. HNCP and Babel packets are only accepted when they originate on these trusted links. "External" and "Guest" interfaces are connected to links that are not trusted, and any HNCP or Babel packets that are received on such interfaces are ignored. ("Leaf" interfaces are a special case since they are connected to trusted links, but HNCP and Babel traffic received on such interfaces is ignored.) This implies that the security of a Homenet network depends on the reliability of the border discovery procedure described in Section 5.3 of [RFC7788].

ホームメネットネットワークのセキュリティは、下位層で固定されているリンクに接続されていると仮定されている「内部」、「アドホック」、および「ハイブリッド」インターフェイス（[RFC7788]のセクション5.1）を持つことに依存しています。HNCPおよびBabelパケットは、それらがこれらの信頼されたリンクに起因するときにのみ受け入れられます。「外部」および「ゲスト」インタフェースは、信頼されていないリンクに接続され、そのようなインターフェイスで受信されたHNCPまたはBabelパケットは無視されます。（ "Leaf"インタフェースは信頼できるリンクに接続されているので特別な場合ですが、そのようなインターフェイスで受信されたHNCPとBabelトラフィックは無視されます。[RFC7788]のセクション5.3。

If untrusted links are used for transit, which is NOT RECOMMENDED, then any HNCP and Babel traffic that is carried over such links MUST be secured using an upper-layer security protocol. While both HNCP and Babel support cryptographic authentication, at the time of writing, no protocol for autonomous configuration of HNCP and Babel security has been defined.

信頼されていないリンクが推奨されていない場合、そのようなリンクを介して伝送されるHNCPとBabelトラフィックは、上位層のセキュリティプロトコルを使用して保護されなければなりません。HNCPとBabelの両方のサポート暗号認証は、書き込み時に、HNCPおよびBabelセキュリティの自律構成のためのプロトコルなしではありません。

5. IANA Considerations

5. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAの行動がありません。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[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>。

[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://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月、<https://www.rfc-editor.org/info/ RFC7788>。

[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>。

[RFC9079] Boutier, M. and J. Chroboczek, "Source-Specific Routing in the Babel Routing Protocol", RFC 9079, DOI 10.17487/RFC9079, August 2021, <https://www.rfc-editor.org/rfc/rfc9079>.

[RFC9079] Boutier、M.およびJ.Chroboczek、「Babelルーティングプロトコルのソース固有のルーティング」、RFC 9079、DOI 10.17487 / RFC9079、2021年8月、<https://www.rfc-editor.org/rfc/RFC9079>。

6.2. Informative References

6.2. 参考引用

[BABEL-RTT] Jonglez, B. and J. Chroboczek, "Delay-based Metric Extension for the Babel Routing Protocol", Work in Progress, Internet-Draft, draft-ietf-babel-rtt-extension-00, 26 April 2019, <https://datatracker.ietf.org/doc/html/ draft-ietf-babel-rtt-extension-00>.

[BABEL-RTT] Jonglez、B.およびJ.Chroboczek、「Babelルーティングプロトコルのための遅延ベースのメトリック拡張」、進行中の作業、インターネットドラフト、ドラフト - IETF-BABEL-RTT-extension-00,26 4月26日<https://datatracker.ietf.org/doc/html/ romft-ietf-babel-rtt-extension-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://datatracker.ietf.org/doc/html/draft-chroboczek-babel-diversity-routing-01>.

[Babel-Z] Chroboczek、J.、「Babelルーティングプロトコルのための多様性ルーティング」、進行中の作業、インターネットドラフト、ドラフト - Chroboczek-Babel-Diversity-Routing-01、2016年2月15日、<https：// DataTracker.ietf.org / doc / html / draft-chroboczek-babel diversity-routing-01>。

[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>。

[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>。

[ToS-SPECIFIC] 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://datatracker.ietf.org/doc/html/draft-chouasne-babel-tos-specific-00>.

[TOS特有] Chouasne、G.およびJ.Chroboczek、「BabelのTOS固有のルーティング」、進行中の作業、インターネットドラフト、ドラフト - Chouasne-Babel-Tos-Seconduct-00,37月3日、<HTTPS：//datatracker.ietf.org/doc/html/draft-chouasne-babel-tos-specific-00>。

Acknowledgments

謝辞

A number of people have helped with defining the requirements listed in this document. I am especially indebted to Barbara Stark and Markus Stenberg.

この文書に記載されている要件を定義するのに役立ちました。私は特にBarbara StarkとMarkus Stenbergにお世話になっています。

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