[要約] RFC 9013は、OSPF (Open Shortest Path First) プロトコルにおけるトンネルカプセル化の広告に関するものです。この文書の目的は、ネットワーク上でのトンネルエンドポイントの発見とトンネルパラメータの伝達を効率化する方法を提供することにあります。これは、VPNやオーバーレイネットワークの設定と最適化の場面で利用されます。
Internet Engineering Task Force (IETF) X. Xu, Ed.
Request for Comments: 9013 Capitalonline
Category: Standards Track B. Decraene, Ed.
ISSN: 2070-1721 Orange
R. Raszuk
NTT Network Innovations
L. Contreras
Telefonica I+D
L. Jalil
Verizon
April 2021
OSPF Advertisement of Tunnel Encapsulations
トンネルカプセル化のOSPF広告
Abstract
概要
Networks use tunnels for a variety of reasons. A large variety of tunnel types are defined, and the tunnel encapsulator router needs to select a type of tunnel that is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF Router Information Link State Advertisements (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator.
ネットワークはさまざまな理由でトンネルを使用します。さまざまなトンネルタイプが定義されており、トンネルカプセル化装置ルータはトンネルのカプセル化装置ルータでサポートされているトンネルの種類を選択する必要があります。この文書は、トンネルのカプセルでサポートされているトンネルカプセル化のリストであるOSPFルーター情報リンク状態広告（LSA）で宣伝する方法を定義しています。
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/rfc9013.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc9013で入手できます。
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
2. Terminology
3. Tunnel Encapsulations TLV
4. Tunnel Sub-TLV
5. Tunnel Parameter Sub-TLVs
5.1. Encapsulation Sub-TLV
5.2. Protocol Type Sub-TLV
5.3. Tunnel Egress Endpoint Sub-TLV
5.4. Color Sub-TLV
5.5. Load-Balancing Block Sub-TLV
5.6. DS Field Sub-TLV
5.7. UDP Destination Port Sub-TLV
6. Operation
7. IANA Considerations
7.1. OSPF Router Information (RI) TLVs Registry
7.2. OSPF Tunnel Parameter Sub-TLVs Registry
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Networks use tunnels for a variety of reasons, such as:
ネットワークは、次のようなさまざまな理由でトンネルを使用します。
* Partial deployment of IPv6 in IPv4 networks or IPv4 in IPv6 networks, as described in [RFC5565], where IPvx tunnels are used between IPvx-enabled routers so as to traverse non-IPvx routers.
* IPvx対応ルータをトラバースするためにIPvx対応ルータの間でIPvx対応ルータの間でIPvx対応ルータの間で使用されている[RFC5565]で説明されているように、IPv6ネットワークにおけるIPv6ネットワークまたはIPv4のIPv6の部分的な展開。
* Remote Loop-Free Alternate (RLFA) repair tunnels as described in [RFC7490], where tunnels are used between the Point of Local Repair and the selected PQ node.
* リモートループフリーの代替（RLFA）修復トンネルは、ローカル修復点と選択されたPQノードの間にトンネルが使用されている[RFC7490]に記載されています。
The tunnel encapsulator router needs to select a type of tunnel that is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF Router Information Link State Advertisements (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator. In this document, OSPF refers to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340].
トンネルカプセル化装置ルータは、トンネルのカプセル化装置ルータでサポートされているトンネルの種類を選択する必要があります。この文書は、トンネルのカプセルでサポートされているトンネルカプセル化のリストであるOSPFルーター情報リンク状態広告（LSA）で宣伝する方法を定義しています。この文書では、OSPFはOSPFv2 [RFC2328]とOSPFv3 [RFC5340]の両方を表します。
This memo makes use of the terms defined in [RFC7770].
このメモは[RFC7770]で定義されている用語を利用しています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Routers advertise their supported tunnel encapsulation type(s) by advertising a new TLV of the OSPF Router Information (RI) Opaque LSA [RFC7770], referred to as the "Tunnel Encapsulations TLV". This TLV is applicable to both OSPFv2 and OSPFv3.
ルータは、「トンネルカプセル化TLV」と呼ばれるOSPFルータ情報（RI）OPAQUE LSA [RFC7770]の新しいTLVを広告することによって、サポートされているトンネルカプセル化タイプをアドバタイズします。このTLVはOSPFv2とOSPFv3の両方に適用されます。
The Type code of the Tunnel Encapsulations TLV is 13, the Length value is variable, and the Value field contains one or more Tunnel Sub-TLVs, as defined in Section 4. Each Tunnel Sub-TLV indicates a particular encapsulation format that the advertising router supports, along with the parameters corresponding to the tunnel type.
トンネルカプセル化のタイプコードTLVは13で、長さの値は可変で、valueフィールドにはセクション4で定義されているように、1つ以上のトンネルサブTLVが含まれています。各トンネルサブTLVは、広告ルータが特定のカプセル化フォーマットを示します。トンネルタイプに対応するパラメータとともにサポートします。
The Tunnel Encapsulations TLV MAY appear more than once within a given OSPF Router Information (RI) Opaque LSA. If the Tunnel Encapsulations TLV appears more than once in an OSPF Router Information LSA, the set of all Tunnel Sub-TLVs from all Tunnel Encapsulations TLVs SHOULD be considered. The scope of the advertisement depends on the application, but it is recommended that it SHOULD be domain wide.
トンネルカプセル化TLVは、特定のOSPFルータ情報（RI）OPAQUE LSA内に複数回現れることがある。トンネルカプセル化TLVがOSPFルータ情報LSAに複数回表示されている場合、すべてのトンネルカプセル化TLVからのすべてのトンネルサブTLVのセットを考慮する必要があります。広告の範囲はアプリケーションによって異なりますが、ドメインの広さになることをお勧めします。
The Tunnel Sub-TLV is structured as shown in Figure 1.
トンネルサブTLVは図1に示すように構成されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tunnel Parameter Sub-TLVs |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Tunnel Sub-TLV
図1：トンネルサブTLV
Tunnel Type (2 octets): Identifies the type of tunneling technology signaled. Tunnel types are shared with the BGP extension [RFC9012] and hence are defined in the IANA registry "BGP Tunnel Encapsulation Attribute Tunnel Types". Unknown tunnel types are to be ignored upon receipt.
トンネルタイプ（2オクテット）：シグナリングされたトンネリング技術の種類を識別します。トンネルの種類はBGP拡張子[RFC9012]と共有され、したがってIANAレジストリ「BGPトンネルカプセル化属性トンネルタイプ」で定義されています。未知のトンネルタイプは受信時に無視されます。
Length (2 octets): Unsigned 16-bit integer indicating the total number of octets of the Tunnel Parameter Sub-TLVs field.
長さ（2オクテット）：トンネルパラメータサブTLVSフィールドのオクテットの総数を示す符号なし16ビット整数。
Tunnel Parameter Sub-TLVs (variable): Zero or more Tunnel Parameter Sub-TLVs, as defined in Section 5.
Tunnelパラメータsub-tlvs（変数）：セクション5で定義されているように、0個以上のトンネルパラメータサブTLVS。
If a Tunnel Sub-TLV is invalid, it MUST be ignored and skipped. However, other Tunnel Sub-TLVs MUST be considered.
トンネルサブTLVが無効な場合は、無視してスキップする必要があります。ただし、他のトンネルサブTLVを考慮する必要があります。
A Tunnel Parameter Sub-TLV is structured as shown in Figure 2.
図2に示すように、トンネルパラメータサブTLVが構成されています。
+---------------------------------------------+
| Tunnel Parameter Sub-Type (2 octets) |
+---------------------------------------------+
| Tunnel Parameter Length (2 octets) |
+---------------------------------------------+
| Tunnel Parameter Value (variable) |
| |
+---------------------------------------------+
Figure 2: Tunnel Parameter Sub-TLV
図2：トンネルパラメータサブTLV
Tunnel Parameter Sub-Type (2 octets): Each sub-type defines a parameter of the Tunnel Sub-TLV. Sub-types are registered in the IANA registry "OSPF Tunnel Parameter Sub-TLVs" (see Section 7.2).
トンネルパラメータサブタイプ（2オクテット）：各サブタイプはトンネルサブTLVのパラメータを定義します。サブタイプは、IANAレジストリ "OSPFトンネルパラメータサブTLVS"（セクション7.2を参照）に登録されています。
Tunnel Parameter Length (2 octets): Unsigned 16-bit integer indicating the total number of octets of the Tunnel Parameter Value field.
トンネルパラメータ長（2オクテット）：符号なし16ビット整数Tunnelパラメータ値フィールドのオクテット数の総数。
Tunnel Parameter Value (variable): Encodings of the Value field depend on the sub-TLV type. The following subsections define the encoding in detail.
Tunnelパラメータ値（変数）：値フィールドのエンコードは、サブTLVタイプによって異なります。以下のサブセクションでは、エンコーディングを詳細に定義します。
Any unknown Tunnel Parameter sub-type MUST be ignored and skipped upon receipt. When a reserved value (see Section 7.2) is seen in an LSA, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. When a Tunnel Parameter Value has an incorrect syntax or semantics, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. If a Tunnel Parameter Sub-TLV is invalid, its Tunnel Sub-TLV MUST be ignored. However, other Tunnel Sub-TLVs MUST be considered.
未知のトンネルパラメータサブタイプは無視され、受信時にスキップされなければなりません。予約値（セクション7.2を参照）がLSAで表示されている場合は、無効なトンネルパラメータサブTLVとして扱われなければなりません。トンネルパラメータ値に誤った構文またはセマンティクスがある場合は、無効なトンネルパラメータサブTLVとして扱う必要があります。トンネルパラメータサブTLVが無効な場合、そのトンネルサブTLVは無視されなければなりません。ただし、他のトンネルサブTLVを考慮する必要があります。
This sub-TLV type is 1. The syntax, semantics, and usage of its Value field are defined in Section 3.2 ("Encapsulation Sub-TLVs for Particular Tunnel Types") of [RFC9012].
このサブTLVタイプは1です。[RFC9012]のセクション3.2（「特定のトンネルタイプ用のカプセル化サブTLV」）で定義されています。
This sub-TLV type is 2. The syntax, semantics, and usage of its Value field are defined in Section 3.4.1 ("Protocol Type Sub-TLV") of [RFC9012].
このサブTLVタイプは2です.2。[Semantics]、[Semantics]、[Value]フィールドの使用量は[RFC9012]のセクション3.4.1（「プロトコルタイプサブTLV」）で定義されています。
The Tunnel Egress Endpoint Sub-TLV specifies the address of the egress endpoint of the tunnel -- that is, the address of the router that will decapsulate the payload.
トンネル出力エンドポイントサブTLVは、トンネルの出力エンドポイントのアドレスを指定します - つまり、ペイロードをカプセル化するルータのアドレス。
This sub-TLV type is 3. It MUST be present once and only once in a given Tunnel Sub-TLV. The Value field contains two subfields:
このサブTLVタイプは3です。特定のトンネルサブTLVに1回、1回だけ存在する必要があります。[値]フィールドには、2つのサブフィールドが含まれています。
* a two-octet Address Family subfield
* 2オクテットアドレスファミリサブフィールド
* an Address subfield, whose length depends upon the Address Family
* 長さがアドレスファミリに依存するアドレスサブフィールド
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Tunnel Egress Endpoint Sub-TLV
図3：トンネル出力エンドポイントサブTLV
The Address Family subfield contains a value from IANA's "Address Family Numbers" registry. In this document, we assume that the Address Family is either IPv4 or IPv6; use of other address families is outside the scope of this document.
アドレスファミリサブフィールドには、IANAの「アドレスファミリ番号」レジストリからの値が含まれています。このドキュメントでは、アドレスファミリがIPv4またはIPv6であるとします。他のアドレスファミリの使用はこの文書の範囲外です。
If the Address Family subfield contains the value for IPv4, the Address subfield MUST contain an IPv4 address (a /32 IPv4 prefix). In this case, the Length field of the Tunnel Egress Endpoint Sub-TLV MUST contain the value 6.
アドレスファミリサブフィールドにIPv4の値が含まれている場合、アドレスサブフィールドにはIPv4アドレス（A / 32 IPv4プレフィックス）が含まれている必要があります。この場合、トンネル出力エンドポイントサブTLVの長さフィールドには値6が含まれている必要があります。
If the Address Family subfield contains the value for IPv6, the address subfield MUST contain an IPv6 address (a /128 IPv6 prefix). In this case, the Length field of the Tunnel Egress Endpoint Sub-TLV MUST contain the value 18 (0x12). IPv6 link-local addresses are not valid values of the IP address field.
アドレスファミリサブフィールドにIPv6の値が含まれている場合、アドレスサブフィールドにはIPv6アドレス（A / 128 IPv6プレフィックス）が含まれている必要があります。この場合、トンネル出力エンドポイントサブTLVの長さフィールドには、値18（0x12）が含まれていなければなりません。IPv6リンクローカルアドレスは、IPアドレスフィールドの有効な値ではありません。
This sub-TLV type is 4. It may appear zero or more times in a given Tunnel Sub-TLV. The Value field is a 4-octet opaque unsigned integer.
このサブTLVタイプは4です。特定のトンネルサブTLVでは、0回以上表示されます。値フィールドは4オクテットの不透明な符号なし整数です。
The color value is user-defined and configured locally on the advertising routers. It may be used by service providers to define policies on the tunnel encapsulator routers, for example, to control the selection of the tunnel to use.
カラー値はユーザー定義で広告ルータにローカルに構成されています。使用するトンネルの選択を制御するために、トンネルカプセル化装置ルータのポリシーを定義するためにサービスプロバイダによって使用され得る。
This color value can be referenced by BGP routes carrying the Color Extended Community [RFC9012]. If the tunnel is used to reach the BGP next hop of BGP routes, then attaching a Color Extended Community to those routes expresses the willingness of the BGP speaker to use a tunnel of the same color.
この色の値は、Color Extended Community [RFC9012]を搭載したBGPルートによって参照できます。トンネルがBGPルートのBGPネクストホップに到達するために使用される場合、それらのルートにカラー拡張コミュニティを添付すると、同じ色のトンネルを使用するためのBGPスピーカーの意思が表現されます。
This sub-TLV type is 5. The syntax, semantics, and usage of its Value field are defined in [RFC5640].
このサブTLVタイプは5です。[RFC5640]では、[Semantics]、[Semantics]、[Value]フィールドの使用が定義されています。
This sub-TLV type is 6. The syntax, semantics, and usage of its Value field are defined in Section 3.3.1 ("DS Field") of [RFC9012].
このサブTLVタイプは6です.Symantics、Semantics、およびその値フィールドの使用法は、[RFC9012]のセクション3.3.1（「DSフィールド」）で定義されています。
This sub-TLV type is 7. The syntax, semantics, and usage of its Value field are defined in Section 3.3.2 ("UDP Destination Port") of [RFC9012].
このSUB-TLVタイプは7です。[Semantics]、[Semantics]、[Value]フィールドの使用量は[RFC9012]のセクション3.3.2（「UDP宛先ポート」）で定義されています。
The advertisement of a Tunnel Encapsulations Sub-TLV indicates that the advertising router supports a particular tunnel decapsulation along with the parameters to be used for the tunnel. The decision to use that tunnel is driven by the capability of the tunnel encapsulator router to support the encapsulation type and the policy on the tunnel encapsulator router. The Color Sub-TLV (see Section 5.4) may be used as an input to this policy. Note that some tunnel types may require the execution of an explicit tunnel setup protocol before they can be used to transit data.
トンネルカプセル化サブTLVの広告は、広告ルータがトンネルに使用されるパラメータと共に特定のトンネルのカプセル化をサポートすることを示す。そのトンネルを使用するという決定は、トンネルカプセル化装置ルータの能力によって、カプセル化タイプとトンネルカプセル化装置のポリシーをサポートすることによって駆動されます。カラーサブTLV（セクション5.4を参照）は、このポリシーへの入力として使用できます。いくつかのトンネルタイプは、データを転送するために使用する前に明示的なトンネル設定プロトコルの実行を必要とする可能性があることに注意してください。
A tunnel MUST NOT be used if there is no route toward the IP address specified in the Tunnel Egress Endpoint Sub-TLV (see Section 5.3) or if the route is not advertised in the same OSPF domain.
トンネル出力エンドポイントサブTLV（セクション5.3を参照）またはルートが同じOSPFドメインでアドバタイズされていない場合は、トンネルを使用しないでください。
IANA has allocated the following new code point in the "OSPF Router Information (RI) TLVs" registry.
IANAは、「OSPFルーター情報（RI）TLVS」レジストリに次の新しいコードポイントを割り当てました。
+=======+=======================+===========+
| Value | TLV Name | Reference |
+=======+=======================+===========+
| 13 | Tunnel Encapsulations | RFC 9013 |
+-------+-----------------------+-----------+
Table 1: Addition to OSPF Router Information (RI) TLVs Registry
表1：OSPFルーター情報（RI）TLVSレジストリへの追加
IANA has created a new subregistry called the "OSPF Tunnel Parameter Sub-TLVs" registry under the "Open Shortest Path First (OSPF) Parameters" registry. The registration procedures are as follows:
IANAは、「OSPF Tunnel Parameter Sub-TLVS」レジストリを「オープン最短パスFirst（OSPF）パラメータ」レジストリの下にある新しいサブレジストリを作成しました。登録手順は次のとおりです。
* The values in the range 1-34999 are to be allocated using the "Standards Action" registration procedure defined in [RFC8126].
* 1-34999の範囲の値は、[RFC8126]で定義されている「標準アクション」登録手順を使用して割り当てられます。
* The values in the range 35000-65499 are to be allocated using the "First Come First Served" registration procedure.
* 35000-65499の範囲内の値は、「最初にサービス提供された」登録手順を使用して割り当てられます。
The initial contents of the registry are as follows:
レジストリの初期内容は次のとおりです。
+=============+======================+=====================+
| Value | TLV Name | Reference |
+=============+======================+=====================+
| 0 | Reserved | RFC 9013 |
+-------------+----------------------+---------------------+
| 1 | Encapsulation | RFC 9013 & RFC 9012 |
+-------------+----------------------+---------------------+
| 2 | Protocol Type | RFC 9013 & RFC 9012 |
+-------------+----------------------+---------------------+
| 3 | Endpoint | RFC 9013 |
+-------------+----------------------+---------------------+
| 4 | Color | RFC 9013 |
+-------------+----------------------+---------------------+
| 5 | Load-Balancing Block | RFC 9013 & RFC 5640 |
+-------------+----------------------+---------------------+
| 6 | DS Field | RFC 9013 & RFC 9012 |
+-------------+----------------------+---------------------+
| 7 | UDP Destination Port | RFC 9013 & RFC 9012 |
+-------------+----------------------+---------------------+
| 8-65499 | Unassigned | |
+-------------+----------------------+---------------------+
| 65500-65534 | Experimental | RFC 9013 |
+-------------+----------------------+---------------------+
| 65535 | Reserved | RFC 9013 |
+-------------+----------------------+---------------------+
Table 2: Initial Contents of OSPF Tunnel Parameter Sub-TLVs Registry
表2：OSPFトンネルパラメータサブTLVSレジストリの初期内容
Security considerations applicable to softwires can be found in the mesh framework [RFC5565]. In general, security issues of the tunnel protocols signaled through this OSPF capability extension are inherited.
ソフトワイヤに適用可能なセキュリティ上の考慮事項は、メッシュフレームワーク[RFC5565]にあります。一般に、このOSPF機能拡張を通じてシグナリングされたトンネルプロトコルのセキュリティ問題は継承されます。
If a third party is able to modify any of the information that is used to form encapsulation headers, choose a tunnel type, or choose a particular tunnel for a particular payload type, user data packets may end up getting misrouted, misdelivered, and/or dropped. However, since an OSPF routing domain is usually a well-controlled network under a single administrative domain, the possibility of the above attack is very low.
サードパーティがカプセル化ヘッダーを形成するために使用される情報のいずれかを変更することができる場合は、トンネルタイプを選択するか、特定のペイロードタイプの特定のトンネルを選択し、ユーザーデータパケットは誤表示、誤解、および/または落とした。ただし、OSPFルーティングドメインは通常1回の管理ドメインの下で制御されたネットワークであるため、上記の攻撃の可能性は非常に低いです。
We note that the last paragraph of Section 6 forbids the establishment of a tunnel toward arbitrary destinations. It prohibits a destination outside of the OSPF domain. This prevents a third party that has gained access to an OSPF router from being able to send the traffic to other destinations, e.g., for inspection purposes.
セクション6の最後の段落は、任意の目的地へのトンネルの確立を禁止することに注意してください。それはOSPFドメインの外部の目的地を禁止します。これにより、OSPFルータへのアクセスが許可されている第三者が他の宛先にトラフィックを送信することができ、例えば検査目的のために妨げられる。
Security considerations for the base OSPF protocol are covered in [RFC2328] and [RFC5340].
基本OSPFプロトコルのセキュリティ上の考慮事項は[RFC2328]と[RFC5340]で説明されています。
[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>。
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-Balancing for Mesh Softwires", RFC 5640, DOI 10.17487/RFC5640, August 2009, <https://www.rfc-editor.org/info/rfc5640>.
[RFC5640] Filsfils、C、Mohapatra、P.、およびC.Pignataro、「メッシュソフトワイヤーの負荷分散」、RFC 5640、DOI 10.17487 / RFC5640、2009年8月、<https：//www.rfc-editor.org/ info / rfc5640>。
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7770]リンデム、A.、ED。、Shen、N.、Vasseur、JP。、Aggarwal、R.、およびS. Shaffer、RFC 7770、DOI 10.17487 / RFC7770、RFC7770、販売2016年2月、<https://www.rfc-editor.org/info/rfc7770>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>。
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, <https://www.rfc-editor.org/info/rfc9012>.
[RFC9012]聖母、K.、Van de Velde、G.、Sangli、S.、およびJ.Scudder、「BGPトンネルカプセル化属性」、RFC 9012、DOI 10.17487 / RFC9012、2021年4月、<https：// www.rfc-editor.org / info / rfc9012>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J.、 "OSPFバージョン2"、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https：//www.rfc-editor.org/info/rfc2328>。
[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>。
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, <https://www.rfc-editor.org/info/rfc5512>.
[RFC5512] Mohapatra、P.およびE.ローゼン、「BGPカプセル化後続のアドレスファミリ識別子（SAFI）およびBGPトンネルカプセル化属性」、RFC 5512、DOI 10.17487 / RFC5512、2009年4月、<https：//www.rfc-editor.org/info/rfc5512>。
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, <https://www.rfc-editor.org/info/rfc5565>.
[RFC5565] WU、J.、CUI、Y、METZ、CU、およびE.ローゼン、「ソフトワイヤーメッシュフレームワーク」、RFC 5565、DOI 10.17487 / RFC5565、2009年6月、<https：///www.rfc-編集者.org / info / rfc5565>。
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <https://www.rfc-editor.org/info/rfc7490>.
[RFC7490]ブライアント、S、FILSFILS、C、PREVIDI、S、SHAND、M.、およびN. SO、「リモートループフリーの代替（LFA）高速再ルーチ（FRR）」、RFC 7490、DOI 10.17487 /RFC7490、2015年4月、<https：//www.rfc-editor.org/info/rfc7490>。
Acknowledgements
謝辞
This document is partially inspired by [RFC5512].
この文書は[RFC5512]に部分的にインスパイアされています。
The authors would like to thank Greg Mirsky, John E. Drake, Carlos Pignataro, and Karsten Thomann for their valuable comments on this document. Special thanks should be given to Acee Lindem for his multiple detailed reviews of this document and help. The authors would like to thank Pete Resnick, Joe Touch, David Mandelberg, Sabrina Tanamal, Tim Wicinski, and Amanda Baber for their Last Call reviews. The authors also thank Spencer Dawkins, Mirja Kühlewind, Ben Campbell, Benoit Claise, Alvaro Retana, Adam Roach, and Suresh Krishnan for their AD reviews.
著者らはGreg Mirsky、John E. Drake、Carlos Pignataro、およびKarsten Thomannにこの文書についての貴重なコメントをありがとうございました。この文書の彼の複数の詳細レビューのためのAcee Lindemに特別な感謝を与えてくれてありがとう。著者らは、Pete Resnick、Joe Touch、David Mandelberg、Sabrina Tanamal、Tim Wicinski、Amanda Baberの最後のコールレビューに感謝します。著者らはまた、Spencer Dawkins、MirjaKühlewind、Ben Campbell、Benoit Claise、Alvaro Retana、Adam Roach、およびSuresh Krishnanありがとうございます。
Contributors
貢献者
Uma Chunduri Huawei
Uma Chunduri Huawei
Email: uma.chunduri@gmail.com
Authors' Addresses
著者の住所
Xiaohu Xu (editor) Capitalonline
Xiaohu XU（編集）CypectOnline.
Email: xiaohu.xu@capitalonline.net
Bruno Decraene (editor) Orange
ブルーノデトラエイン（編集）オレンジ
Email: bruno.decraene@orange.com
Robert Raszuk NTT Network Innovations 940 Stewart Dr Sunnyvale, CA 94085 United States of America
Robert Raszuk NTTネットワーク革新940 Stewart Dr Sunnyvale、CA 94085アメリカ合衆国
Email: robert@raszuk.net
Luis M. Contreras Telefonica I+D
LUIS M. Contreras Telefonica I D.
Email: luismiguel.contrerasmurillo@telefonica.com
Luay Jalil Verizon
Luay Jalil Verizon
Email: luay.jalil@verizon.com