[要約] RFC 9012は、BGPトンネルカプセル化属性に関する技術文書です。この文書の目的は、異なるネットワーク間でのデータパケットの安全かつ効率的な転送を可能にするための、BGPプロトコルによるトンネルエンドポイントの指定方法を定義することです。この技術は、VPN接続、クラウドサービス間のデータ転送、およびマルチキャスト通信など、さまざまなネットワーキングシナリオで利用されます。
Internet Engineering Task Force (IETF) K. Patel
Request for Comments: 9012 Arrcus, Inc
Obsoletes: 5512, 5566 G. Van de Velde
Updates: 5640 Nokia
Category: Standards Track S. Sangli
ISSN: 2070-1721 J. Scudder
Juniper Networks
April 2021
The BGP Tunnel Encapsulation Attribute
BGPトンネルカプセル化属性
Abstract
概要
This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.
この文書は「トンネルカプセル化属性」として知られているBGPパス属性を定義します。これは、トンネルと対応するカプセル化ヘッダーを作成するために必要な情報を提供するために、さまざまな後続のアドレスファミリID（Safis）のBGP更新で使用できます。それは、代替トンネルとルーティングパケットをトンネルに選択するための手順と共に、いくつかのトンネルタイプのエンコーディングを提供します。
This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.
この文書はRFC 5512を廃止し、これはトンネルカプセル化属性の以前の定義を提供しました。RFC 5512は製造に展開されていませんでした。RFC 5566はRFC 5512に依存しているので、同様に廃止されています。この文書は、ロードバランシングブロックサブTLVがロードバランシングが望まれる任意のトンネルカプセル化属性に含まれ得ることを示すことによってRFC5640を更新する。
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/rfc9012.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9012で入手できます。
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
1.1. Brief Summary of RFC 5512
1.2. Deficiencies in RFC 5512
1.3. Use Case for the Tunnel Encapsulation Attribute
1.4. Brief Summary of Changes from RFC 5512
1.5. Update to RFC 5640
1.6. Effects of Obsoleting RFC 5566
2. The Tunnel Encapsulation Attribute
3. Tunnel Encapsulation Attribute Sub-TLVs
3.1. The Tunnel Egress Endpoint Sub-TLV (Type Code 6)
3.1.1. Validating the Address Subfield
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types (Type
Code 1)
3.2.1. VXLAN (Tunnel Type 8)
3.2.2. NVGRE (Tunnel Type 9)
3.2.3. L2TPv3 (Tunnel Type 1)
3.2.4. GRE (Tunnel Type 2)
3.2.5. MPLS-in-GRE (Tunnel Type 11)
3.3. Outer Encapsulation Sub-TLVs
3.3.1. DS Field (Type Code 7)
3.3.2. UDP Destination Port (Type Code 8)
3.4. Sub-TLVs for Aiding Tunnel Selection
3.4.1. Protocol Type Sub-TLV (Type Code 2)
3.4.2. Color Sub-TLV (Type Code 4)
3.5. Embedded Label Handling Sub-TLV (Type Code 9)
3.6. MPLS Label Stack Sub-TLV (Type Code 10)
3.7. Prefix-SID Sub-TLV (Type Code 11)
4. Extended Communities Related to the Tunnel Encapsulation
Attribute
4.1. Encapsulation Extended Community
4.2. Router's MAC Extended Community
4.3. Color Extended Community
5. Special Considerations for IP-in-IP Tunnels
6. Semantics and Usage of the Tunnel Encapsulation Attribute
7. Routing Considerations
7.1. Impact on the BGP Decision Process
7.2. Looping, Mutual Recursion, Etc.
8. Recursive Next-Hop Resolution
9. Use of Virtual Network Identifiers and Embedded Labels When
Imposing a Tunnel Encapsulation
9.1. Tunnel Types without a Virtual Network Identifier Field
9.2. Tunnel Types with a Virtual Network Identifier Field
9.2.1. Unlabeled Address Families
9.2.2. Labeled Address Families
10. Applicability Restrictions
11. Scoping
12. Operational Considerations
13. Validation and Error Handling
14. IANA Considerations
14.1. Obsoleting RFC 5512
14.2. Obsoleting Code Points Assigned by RFC 5566
14.3. Border Gateway Protocol (BGP) Tunnel Encapsulation
Grouping
14.4. BGP Tunnel Encapsulation Attribute Tunnel Types
14.5. Subsequent Address Family Identifiers
14.6. BGP Tunnel Encapsulation Attribute Sub-TLVs
14.7. Flags Field of VXLAN Encapsulation Sub-TLV
14.8. Flags Field of NVGRE Encapsulation Sub-TLV
14.9. Embedded Label Handling Sub-TLV
14.10. Color Extended Community Flags
15. Security Considerations
16. References
16.1. Normative References
16.2. Informative References
Appendix A. Impact on RFC 8365
Acknowledgments
Contributors
Authors' Addresses
This document obsoletes [RFC5512]. The deficiencies of [RFC5512], and a summary of the changes made, are discussed in Sections 1.1-1.3. The material from [RFC5512] that is retained has been incorporated into this document. Since [RFC5566] relies on [RFC5512], it is likewise obsoleted.
この文書は廃止されています[RFC5512]。[RFC5512]の欠陥と変更された変更の要約については、セクション1.1-1.3で説明します。保持されている[RFC5512]からの材料がこの文書に組み込まれています。[RFC5566]は[RFC5512]に依存しているので、同様に廃止されています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
[RFC5512] defines a BGP path attribute known as the Tunnel Encapsulation attribute. This attribute consists of one or more TLVs. Each TLV identifies a particular type of tunnel. Each TLV also contains one or more sub-TLVs. Some of the sub-TLVs, for example, the Encapsulation sub-TLV, contain information that may be used to form the encapsulation header for the specified tunnel type. Other sub-TLVs, for example, the "color sub-TLV" and the "protocol sub-TLV", contain information that aids in determining whether particular packets should be sent through the tunnel that the TLV identifies.
[RFC5512]トンネルのカプセル化属性として知られているBGPパス属性を定義します。この属性は1つ以上のTLVで構成されています。各TLVは特定の種類のトンネルを識別します。各TLVには1つ以上のサブTLVも含まれています。サブTLV、たとえばカプセル化サブTLVのいくつかは、指定されたトンネルタイプのカプセル化ヘッダーを形成するために使用され得る情報を含む。他のサブTLV、例えば「カラーサブTLV」および「プロトコルサブTLV」は、特定のパケットがTLVが識別するトンネルを介して送信されるべきかどうかを判断することを助ける情報を含む。
[RFC5512] only allows the Tunnel Encapsulation attribute to be attached to BGP UPDATE messages of the Encapsulation Address Family. These UPDATE messages have an Address Family Identifier (AFI) of 1 or 2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the Network Layer Reachability Information (NLRI) is an address of the BGP speaker originating the UPDATE. Consider the following scenario:
[RFC5512]は、カプセル化アドレスファミリのBGP更新メッセージにトンネルカプセル化属性を添付するだけです。これらの更新メッセージには、1または2のアドレスファミリ識別子（AFI）、および7のSAFIがあり、カプセル化SAFIの更新において、ネットワーク層到達可能性情報（NLRI）は、更新を発信するBGPスピーカのアドレスである。次のシナリオを考慮してください。
* BGP speaker R1 has received and selected UPDATE U for local use;
* BGPスピーカーR1は、ローカル使用のためにUpdate Uを受信して選択しました。
* UPDATE U's SAFI is the Encapsulation SAFI;
* Update UのSafiはカプセル化SAFIです。
* UPDATE U has the address R2 as its NLRI;
* Update Uは、アドレスR2をNLRIとして持っています。
* UPDATE U has a Tunnel Encapsulation attribute.
* Update Uはトンネルのカプセル化属性を持ちます。
* R1 has a packet, P, to transmit to destination D; and
* R1は、宛先Dに送信するためのパケットPを有する。そして
* R1's best route to D is a BGP route that has R2 as its next hop.
* R1のDへの最良のルートは、R2をそのネクストホップとして持つBGPルートです。
In this scenario, when R1 transmits packet P, it should transmit it to R2 through one of the tunnels specified in U's Tunnel Encapsulation attribute. The IP address of the tunnel egress endpoint of each such tunnel is R2. Packet P is known as the tunnel's "payload".
このシナリオでは、R1がパケットPを送信すると、Uのトンネルカプセル化属性で指定されたトンネルの1つを介してR2に送信する必要があります。そのような各トンネルのトンネル出力エンドポイントのIPアドレスはR2である。パケットPはトンネルの「ペイロード」として知られています。
While the ability to specify tunnel information in a BGP UPDATE is useful, the procedures of [RFC5512] have certain limitations:
BGPアップデートでトンネル情報を指定する機能は便利ですが、[RFC5512]の手順には制限があります。
* The requirement to use the Encapsulation SAFI presents an unfortunate operational cost, as each BGP session that may need to carry tunnel encapsulation information needs to be reconfigured to support the Encapsulation SAFI. The Encapsulation SAFI has never been used, and this requirement has served only to discourage the use of the Tunnel Encapsulation attribute.
* カプセル化SAFIを使用する要件は、トンネルカプセル化情報を搬送する必要がある可能性がある各BGPセッションをカプセル化SAFIをサポートするために再設定する必要があるため、残念な動作コストを提示します。カプセル化SAFIは使用されていません。この要件は、Tunnel Encapsulation属性の使用を阻止するためだけに役立ちました。
* There is no way to use the Tunnel Encapsulation attribute to specify the tunnel egress endpoint address of a given tunnel; [RFC5512] assumes that the tunnel egress endpoint of each tunnel is specified as the NLRI of an UPDATE of the Encapsulation SAFI.
* トンネルのカプセル化属性を使用して、特定のトンネルのトンネル出力エンドポイントアドレスを指定する方法はありません。[RFC5512]各トンネルのトンネル出力エンドポイントがカプセル化SAFIの更新のNLRIとして指定されていると仮定します。
* If the respective best routes to two different address prefixes have the same next hop, [RFC5512] does not provide a straightforward method to associate each prefix with a different tunnel.
* 2つの異なるアドレスプレフィックスへのそれぞれの最良のルートが同じネクストホップを持っている場合、[RFC5512]は各プレフィックスを異なるトンネルと関連付けるための簡単な方法を提供しません。
* If a particular tunnel type requires an outer IP or UDP encapsulation, there is no way to signal the values of any of the fields of the outer encapsulation.
* 特定のトンネルタイプが外部IPまたはUDPカプセル化を必要とする場合、外部カプセル化のいずれかのフィールドの値を信号に信号を通知する方法はない。
* In the specification of the sub-TLVs in [RFC5512], each sub-TLV has a one-octet Length field. In some cases, where a sub-TLV may require more than 255 octets for its encoding, a two-octet Length field may be needed.
* [RFC5512]のSUB-TLVの仕様では、各SUB-TLVには1オクテット長フィールドがあります。場合によっては、SUB-TLVがその符号化のために255オクテットを超える可能性がある場合には、2オクテット長フィールドが必要とされ得る。
Consider the case of a router R1 forwarding an IP packet P. Let D be P's IP destination address. R1 must look up D in its forwarding table. Suppose that the "best match" route for D is route Q, where Q is a BGP-distributed route whose "BGP next hop" is router R2. And suppose further that the routers along the path from R1 to R2 have entries for R2 in their forwarding tables but do NOT have entries for D in their forwarding tables. For example, the path from R1 to R2 may be part of a "BGP-free core", where there are no BGP-distributed routes at all in the core. Or, as in [RFC5565], D may be an IPv4 address while the intermediate routers along the path from R1 to R2 may support only IPv6.
IPパケットPを転送するルータR1の場合は、DをPのIP宛先アドレスに転送します。R1は転送テーブルにDを調べる必要があります。Dの「最良の一致」ルートが経路Qであると仮定する。ここで、Qは、「BGPネクストホップ」がルータR2であるBGP分散経路である。さらに、R1からR2への経路に沿ったルータがそれらの転送テーブル内のR2のエントリを有するが、それらの転送テーブル内のDのエントリを持たないと仮定する。例えば、R1からR2への経路は、「BGPフリーコア」の一部であり得、ここで、コア内の全くBGP分散ルートはない。あるいは、[RFC5565]と同様に、DはIPv4アドレスであり、R1からR2への経路に沿った中間ルータはIPv6のみをサポートする可能性がある。
In cases such as this, in order for R1 to properly forward packet P, it must encapsulate P and send P "through a tunnel" to R2. For example, R1 may encapsulate P using GRE, Layer 2 Tunneling Protocol version 3 (L2TPv3), IP in IP, etc., where the destination IP address of the encapsulation header is the address of R2.
このような場合、R1がパケットPを正しく転送するためには、Pをカプセル化してPをR2に送信しなければならない。たとえば、R1は、GRE、レイヤ2トンネリングプロトコルバージョン3（L2TPv3）、IPなどのIPなどを使用してPを使用してPをカプセル化できます。ここで、カプセル化ヘッダーの宛先IPアドレスはR2のアドレスです。
In order for R1 to encapsulate P for transport to R2, R1 must know what encapsulation protocol to use for transporting different sorts of packets to R2. R1 must also know how to fill in the various fields of the encapsulation header. With certain encapsulation types, this knowledge may be acquired by default or through manual configuration. Other encapsulation protocols have fields such as session id, key, or cookie that must be filled in. It would not be desirable to require every BGP speaker to be manually configured with the encapsulation information for every one of its BGP next hops.
R1がR2へのトランスポートのためにPをカプセル化するために、R1は、さまざまな種類のパケットをR2に輸送するために使用するカプセル化プロトコルを知っている必要があります。R1はカプセル化ヘッダーのさまざまなフィールドに記入する方法も知っておく必要があります。特定のカプセル化タイプを使用すると、この知識はデフォルトまたは手動構成によって取得されることがあります。他のカプセル化プロトコルは、埋められなければならないセッションID、キー、またはCookieなどのフィールドを持っています。そのBGPの次のホップの1つごとにカプセル化情報で手動で設定されるようにすべてのBGPスピーカーを手動で設定する必要はありません。
This document specifies a way in which BGP itself can be used by a given BGP speaker to tell other BGP speakers, "If you need to encapsulate packets to be sent to me, here's the information you need to properly form the encapsulation header". A BGP speaker signals this information to other BGP speakers by using a new BGP attribute type value -- the BGP Tunnel Encapsulation attribute. This attribute specifies the encapsulation protocols that may be used, as well as whatever additional information (if any) is needed in order to properly use those protocols. Other attributes, for example, communities or extended communities, may also be included.
このドキュメントでは、他のBGPスピーカーが他のBGPスピーカーで使用できるようにする方法を指定します。BGPスピーカーは、新しいBGP属性タイプ値 - BGPトンネルカプセル化属性を使用して、この情報を他のBGPスピーカーに送ります。この属性は、それらのプロトコルを正しく使用するために使用され得るカプセル化プロトコル、ならびに追加の情報（ある場合）が必要である。他の属性、例えばコミュニティまたは拡張コミュニティも含まれてもよい。
This document addresses the deficiencies identified in Section 1.2 by:
この文書は、セクション1.2で識別された欠陥に対処します。
* Deprecating the Encapsulation SAFI.
* カプセル化SAFIを廃止する。
* Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that can be included in any of the TLVs contained in the Tunnel Encapsulation attribute. This sub-TLV can be used to specify the remote endpoint address of a particular tunnel.
* Tunnel Encapsulation属性に含まれるTLVのいずれかに含めることができる新しい "Tunnel Egress Endpoint Sub-TLV"（セクション3.1）を定義することができます。このサブTLVは、特定のトンネルのリモートエンドポイントアドレスを指定するために使用できます。
* Allowing the Tunnel Encapsulation attribute to be carried by BGP UPDATEs of additional AFI/SAFIs. Appropriate semantics are provided for this way of using the attribute.
* Tunnel Encapsulation属性を追加のAFI / SAFIのBGP更新によって実行できるようにします。この属性を使用する方法については、適切な意味論が提供されています。
* Defining a number of new sub-TLVs that provide additional information that is useful when forming the encapsulation header used to send a packet through a particular tunnel.
* 特定のトンネルを介してパケットを送信するために使用されるカプセル化ヘッダを形成するときに有用な追加情報を提供するいくつかの新しいサブTLVを定義する。
* Defining the Sub-TLV Type field so that a sub-TLV whose type is in the range from 0 to 127 (inclusive) has a one-octet Length field, but a sub-TLV whose type is in the range from 128 to 255 (inclusive) has a two-octet Length field.
* SUB-TLV TYPEフィールドの定義タイプが0から127の範囲内のSUB-TLV（INLUSUBLUS）が1オクテット長のフィールドを持つが、タイプが128から255の範囲内のサブTLV（包括的）2オクテット長フィールドがあります。
One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub-
TLV". For a given tunnel, the Encapsulation sub-TLV specifies some
of the information needed to construct the encapsulation header used
when sending packets through that tunnel. This document defines
Encapsulation sub-TLVs for a number of tunnel types not discussed in
[RFC5512]: Virtual eXtensible Local Area Network (VXLAN) [RFC7348],
Network Virtualization Using Generic Routing Encapsulation (NVGRE)
[RFC7637], and MPLS in Generic Routing Encapsulation (MPLS-in-GRE)
[RFC4023]. MPLS-in-UDP [RFC7510] is also supported, but an
Encapsulation sub-TLV for it is not needed since there are no
additional parameters to be signaled.
Some of the encapsulations mentioned in the previous paragraph need to be further encapsulated inside UDP and/or IP. [RFC5512] provides no way to specify that certain information is to appear in these outer IP and/or UDP encapsulations. This document provides a framework for including such information in the TLVs of the Tunnel Encapsulation attribute.
前の段落で言及されているカプセル化のいくつかは、UDPおよび/またはIP内にさらにカプセル化される必要がある。[RFC5512]これらの外部IPおよび/またはUDPのカプセル化に特定の情報が表示されることを指定する方法はありません。このドキュメントは、Tunnel Encapsulation属性のTLVS内のそのような情報を含めるためのフレームワークを提供します。
When the Tunnel Encapsulation attribute is attached to a BGP UPDATE whose AFI/SAFI identifies one of the labeled address families, it is not always obvious whether the label embedded in the NLRI is to appear somewhere in the tunnel encapsulation header (and if so, where), whether it is to appear in the payload, or whether it can be omitted altogether. This is especially true if the tunnel encapsulation header itself contains a "virtual network identifier". This document provides a mechanism that allows one to signal (by using sub-TLVs of the Tunnel Encapsulation attribute) how one wants to use the embedded label when the tunnel encapsulation has its own Virtual Network Identifier field.
Tunnel Encapsulation属性が、AFI / SAFIがラベル付きアドレスファミリの1つを識別するBGPアップデートに添付されている場合、NLRIに埋め込まれたラベルがトンネルカプセル化ヘッダのどこかに表示されるかどうかは必ずしも明らかではありません。ペイロードに現れるか、完全に省略できるかどうかを省略するかどうか。これは、トンネルカプセル化ヘッダ自体が「仮想ネットワーク識別子」を含む場合に特に当てはまります。このドキュメントでは、（トンネルカプセル化属性のサブTLVを使用することによって）1つの信号を使用すると、トンネルのカプセル化に独自の仮想ネットワークIDフィールドがある場合に埋め込みラベルを使用したいのかを示します。
[RFC5512] defines an Encapsulation Extended Community that can be used instead of the Tunnel Encapsulation attribute under certain circumstances. This document describes how the Encapsulation Extended Community can be used in a backwards-compatible fashion (see Section 4.1). It is possible to combine Encapsulation Extended Communities and Tunnel Encapsulation attributes in the same BGP UPDATE in this manner.
[RFC5512]特定の状況下では、トンネルカプセル化属性の代わりに使用できるカプセル化拡張コミュニティを定義します。この文書では、カプセル化拡張コミュニティを後方互換性のある方法で使用できる方法について説明します（セクション4.1を参照）。このようにして同じBGP更新でカプセル化拡張コミュニティとトンネルカプセル化属性を組み合わせることができます。
This document updates [RFC5640] by indicating that the Load-Balancing Block sub-TLV MAY be included in any Tunnel Encapsulation attribute where load balancing is desired.
この文書は、ロードバランシングブロックサブTLVがロードバランシングが必要な任意のトンネルカプセル化属性に含まれていてもよいことを示すことを示す。
This specification obsoletes RFC 5566. This has the effect of, in turn, deprecating a number of code points defined in that document. In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry [IANA-BGP-TUNNEL-ENCAP], the following code points have been marked as deprecated: "Transmit tunnel endpoint" (type code 3), "IPsec in Tunnel-mode" (type code 4), "IP in IP tunnel with IPsec Transport Mode" (type code 5), and "MPLS-in-IP tunnel with IPsec Transport Mode" (type code 6). In the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry [IANA-BGP-TUNNEL-ENCAP], "IPsec Tunnel Authenticator" (type code 3) has been marked as deprecated. See Section 14.2.
この仕様はRFC 5566を廃止します。これには、その文書で定義されているコードポイント数を非推奨するという効果があります。「BGPトンネルカプセル化属性トンネルタイプ」レジストリ[IANA-BGP-TUNNEL-ENCAP]では、次のコードポイントが非推奨としてマークされています。 "Transmit Tunnel Endpoint"（コード3タイプ3）、 "IPsec"（Tunnel-Mode "コード4）、「IPSECトランスポートモードを備えたIP IN IPトンネル」（コード5の種類）、および「IPSecトランスポートモードのMPLS-IN-IPトンネル」（コード6の種類）。「BGPトンネルカプセル化属性サブTLVS」レジストリ[IANA-BGP-TUNNEL-ENCAP]では、「IPsecトンネルオーセンティケータ」（コード3タイプ3）が廃止予定としてマークされています。14.2項を参照してください。
The Tunnel Encapsulation attribute is an optional transitive BGP path attribute. IANA has assigned the value 23 as the type code of the attribute in the "BGP Path Attributes" registry [IANA-BGP-PARAMS]. The attribute is composed of a set of Type-Length-Value (TLV) encodings. Each TLV contains information corresponding to a particular tunnel type. A Tunnel Encapsulation TLV, also known as Tunnel TLV, is structured as shown in Figure 1.
Tunnel Encapsulation属性は、オプションの推移的BGPパス属性です。IANAは、「BGPパス属性」レジストリ[IANA-BGP-PARAMS]の属性の型コードとして値23を割り当てました。属性は、一連のタイプ長値（TLV）エンコーディングで構成されています。各TLVには、特定のトンネルタイプに対応する情報が含まれています。トンネルTLVとも呼ばれるトンネルカプセル化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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Tunnel Encapsulation TLV
図1：トンネルカプセル化TLV
Tunnel Type (2 octets): Identifies a type of tunnel. The field contains values from the IANA registry "BGP Tunnel Encapsulation Attribute Tunnel Types" [IANA-BGP-TUNNEL-ENCAP]. See Section 3.4.1 for discussion of special treatment of tunnel types with names of the form "X-in-Y".
トンネルタイプ（2オクテット）：トンネルの種類を識別します。このフィールドには、IANAレジストリ「BGPトンネルカプセル化属性トンネルタイプ」[IANA-BGP-TUNNEL-ENCAP]からの値が含まれています。"x-in-y"という形式のトンネルタイプの特別な扱いについての議論については、セクション3.4.1を参照してください。
Length (2 octets): The total number of octets of the Value field.
長さ（2オクテット）：値フィールドのオクテットの総数。
Value (variable): Comprised of multiple sub-TLVs.
値（変数）：複数のサブTLVからなる。
Each sub-TLV consists of three fields: A 1-octet type, a 1-octet or 2-octet length (depending on the type), and zero or more octets of value. A sub-TLV is structured as shown in Figure 2.
各サブTLVは、1オクテットタイプ、1オクテット、または2オクテット長（タイプに応じて）、0オクテットの値の3つのフィールドで構成されています。図2に示すように、SUB-TLVが構成されています。
+--------------------------------+
| Sub-TLV Type (1 octet) |
+--------------------------------+
| Sub-TLV Length (1 or 2 octets) |
+--------------------------------+
| Sub-TLV Value (variable) |
+--------------------------------+
Figure 2: Encapsulation Sub-TLV
図2：カプセル化サブTLV
Sub-TLV Type (1 octet): Each sub-TLV type defines a certain property about the Tunnel TLV that contains this sub-TLV. The field contains values from the IANA registry "BGP Tunnel Encapsulation Attribute Sub-TLVs" [IANA-BGP-TUNNEL-ENCAP].
SUB-TLVタイプ（1オクテット）：各サブTLVタイプは、このサブTLVを含むトンネルTLVに関する特定のプロパティを定義します。フィールドには、IANAレジストリ「BGPトンネルカプセル化属性サブTLV」[IANA-BGP-TUNNEL-ENCAP]からの値が含まれています。
Sub-TLV Length (1 or 2 octets): The total number of octets of the Sub-TLV Value field. The Sub-TLV Length field contains 1 octet if the Sub-TLV Type field contains a value in the range from 0-127. The Sub-TLV Length field contains two octets if the Sub-TLV Type field contains a value in the range from 128-255.
サブTLV長さ（1または2オクテット）：SUB-TLV値フィールドのオクテットの総数。SUB-TLV TYPEフィールドに0~127の範囲の値が含まれている場合、SUB-TLVの長さフィールドには1オクテットが含まれています。SUB-TLV TYPEフィールドに128~255の範囲の値が含まれている場合、SUB-TLVの長さフィールドには2つのオクテットが含まれています。
Sub-TLV Value (variable): Encodings of the Value field depend on the sub-TLV type. The following subsections define the encoding in detail.
サブTLV値（変数）：値フィールドのエンコーディングは、サブTLVタイプによって異なります。以下のサブセクションでは、エンコーディングを詳細に定義します。
This section specifies a number of sub-TLVs. These sub-TLVs can be included in a TLV of the Tunnel Encapsulation attribute.
このセクションでは、サブTLVの数を指定します。これらのサブTLVは、トンネルカプセル化属性の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. Its Value field contains three subfields:
トンネル出力エンドポイントサブTLVは、トンネルの出力エンドポイントのアドレス、つまりペイロードをカプセル化するルータのアドレスを指定します。その値フィールドには3つのサブフィールドが含まれています。
1. a Reserved subfield
1. 予約されたサブフィールド
2. a two-octet Address Family subfield
2. 2オクテットアドレスファミリサブフィールド
3. an Address subfield, whose length depends upon the Address Family.
3. 長さがアドレスファミリに依存するアドレスサブフィールド。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family (2 octets) | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable) +
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Tunnel Egress Endpoint Sub-TLV Value Field
図3：トンネル出力エンドポイントサブTLV値フィールド
The Reserved subfield SHOULD be originated as zero. It MUST be disregarded on receipt, and it MUST be propagated unchanged.
予約サブフィールドはゼロとして発信されるべきです。それは領収書で無視されなければならず、それは変更されずに伝播されなければなりません。
The Address Family subfield contains a value from IANA's "Address Family Numbers" registry [IANA-ADDRESS-FAM]. This document assumes that the Address Family is either IPv4 or IPv6; use of other address families is outside the scope of this document.
アドレスファミリサブフィールドには、IANAの「アドレスファミリ番号」レジストリ[IANA-ADDRESS-FAM]からの値が含まれています。この文書は、アドレスファミリがIPv4またはIPv6のいずれかであると想定しています。他のアドレスファミリの使用はこの文書の範囲外です。
If the Address Family subfield contains the value for IPv4, the Address subfield MUST contain an IPv4 address (a /32 IPv4 prefix).
アドレスファミリサブフィールドにIPv4の値が含まれている場合、アドレスサブフィールドにはIPv4アドレス（A / 32 IPv4プレフィックス）が含まれている必要があります。
If the Address Family subfield contains the value for IPv6, the Address subfield MUST contain an IPv6 address (a /128 IPv6 prefix).
アドレスファミリサブフィールドにIPv6の値が含まれている場合、アドレスサブフィールドにはIPv6アドレス（A / 128 IPv6プレフィックス）が含まれている必要があります。
In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel Egress Endpoint sub-TLV is independent of the address family of the UPDATE itself. For example, an UPDATE whose NLRI is an IPv4 address may have a Tunnel Encapsulation attribute containing Tunnel Egress Endpoint sub-TLVs that contain IPv6 addresses. Also, different tunnels represented in the Tunnel Encapsulation attribute may have tunnel egress endpoints of different address families.
特定のBGPアップデートでは、トンネル出力エンドポイントサブTLVのアドレスファミリ（IPv4またはIPv6）は、アップデート自体のアドレスファミリとは無関係です。たとえば、NLRIがIPv4アドレスであるアップデートは、IPv6アドレスを含むトンネル出力エンドポイントサブTLVを含むトンネルカプセル化属性を持つことができます。また、トンネルカプセル化属性に表される異なるトンネルは、異なるアドレスファミリのトンネル出力エンドポイントを有することができる。
There is one special case: the Tunnel Egress Endpoint sub-TLV MAY have a Value field whose Address Family subfield contains 0. This means that the tunnel's egress endpoint is the address of the next hop. If the Address Family subfield contains 0, the Address subfield is omitted. In this case, the Length field of Tunnel Egress Endpoint sub-TLV MUST contain the value 6 (0x06).
特別な場合が1つあります。トンネル出力エンドポイントサブTLVは、アドレスファミリサブフィールドが0に含まれる値フィールドを持つことができます。これは、トンネルの出力エンドポイントがネクストホップのアドレスです。アドレスファミリサブフィールドに0が含まれている場合、アドレスサブフィールドは省略されます。この場合、トンネル出力エンドポイントサブTLVの長さフィールドには、値6（0x06）が含まれている必要があります。
When the Tunnel Encapsulation attribute is carried in an UPDATE message of one of the AFI/SAFIs specified in this document (see the first paragraph of Section 6), each TLV MUST have one, and only one, Tunnel Egress Endpoint sub-TLV. If a TLV does not have a Tunnel Egress Endpoint sub-TLV, that TLV should be treated as if it had a malformed Tunnel Egress Endpoint sub-TLV (see below).
このドキュメントで指定されているAFI / SAFIS（セクション6の最初の段落を参照）のアップデートメッセージでトンネルカプセル化属性が実行されると、各TLVには1つ、トンネル出力エンドポイントサブTLVが1つあります。TLVにトンネル出力エンドポイントサブTLVがない場合、そのTLVは、不正なトンネル出力エンドポイントサブTLVがあるかのように扱う必要があります（下記参照）。
In the context of this specification, if the Address Family subfield has any value other than IPv4, IPv6, or the special value 0, the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see Section 13). If any of the following conditions hold, the Tunnel Egress Endpoint sub-TLV is considered to be "malformed":
この仕様の文脈では、アドレスファミリサブフィールドにIPv4、IPv6、または特殊値0の値がある場合、トンネル出力エンドポイントサブTLVは「認識されていない」と見なされます（セクション13を参照）。次の条件のいずれかが保持されている場合は、トンネル出力エンドポイントサブTLVが「不正な形式」と見なされます。
* The length of the sub-TLV's Value field is other than 6 added to the defined length for the address family given in its Address Family subfield. Therefore, for address family behaviors defined in this document, the permitted values are:
* SUB-TLVの値フィールドの長さは、アドレスファミリサブフィールドに指定されたアドレスファミリの定義された長さに追加された6以外です。したがって、このドキュメントで定義されているアドレスファミリ動作の場合、許可された値は次のとおりです。
- 10, if the Address Family subfield contains the value for IPv4.
- 図10に示すように、アドレスファミリサブフィールドにIPv4の値が含まれている場合。
- 22, if the Address Family subfield contains the value for IPv6.
- 22、アドレスファミリサブフィールドにIPv6の値が含まれている場合。
- 6, if the Address Family subfield contains the value zero.
- 図6に示すように、アドレスファミリサブフィールドに値ゼロが含まれている場合。
* The IP address in the sub-TLV's Address subfield lies within a block listed in the relevant Special-Purpose IP Address registry [RFC6890] with either a "destination" attribute value or a "forwardable" attribute value of "false". (Such routes are sometimes colloquially known as "Martians".) This restriction MAY be relaxed by explicit configuration.
* SUB-TLVのアドレスサブフィールドのIPアドレスは、「宛先」属性値または「False」の属性値を持つ、関連する特殊目的IPアドレス・レジストリ[RFC6890]に記載されているブロック内にあります。（そのような経路は時々「マルティアン」として知られています。）この制限は明示的な構成によって緩和されてもよい。
* It can be determined that the IP address in the sub-TLV's Address subfield does not belong to the Autonomous System (AS) that originated the route that contains the attribute. Section 3.1.1 describes an optional procedure to make this determination.
* サブTLVのアドレスサブフィールドのIPアドレスは、属性を含むルートを発信した自律システム（AS）に属していないと判断できます。セクション3.1.1にこの決定を下すためのオプションの手順を示します。
Error handling is specified in Section 13.
エラー処理はセクション13で指定されています。
If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 address that is valid but not reachable, the sub-TLV is not considered to be malformed.
トンネル出力エンドポイントサブTLVに有効であるが到達できないIPv4またはIPv6アドレスが含まれている場合、サブTLVは不正なことに見なされません。
This section provides a procedure that MAY be applied to validate that the IP address in the sub-TLV's Address subfield belongs to the AS that originated the route that contains the attribute. (The notion of "belonging to" an AS is expanded on below.) Doing this is thought to increase confidence that when traffic is sent to the IP address depicted in the Address subfield, it will go to the same AS as it would go to if the Tunnel Encapsulation attribute were not present, although of course it cannot guarantee it. See Section 15 for discussion of the limitations of this procedure. The principal applicability of this procedure is in deployments that are not strictly scoped. In deployments with strict scope, and especially those scoped to a single AS, these procedures may not add substantial benefit beyond those discussed in Section 11.
このセクションでは、SUB-TLVのアドレスサブフィールド内のIPアドレスが属性を含むルートを発信したASに属することを検証するために適用できる手順を提供します。これを行うことは、アドレスサブフィールドに描かれているIPアドレスにトラフィックが送信されると、それが行くのと同じようになるという信頼性を高めると考えられています。トンネルのカプセル化属性が存在しない場合は、もちろん保証できません。この手順の制限についての議論については、セクション15を参照してください。この手順の主な適用性は、厳密にスコープされていない展開です。厳密な範囲を持つ展開、特に単一の方法でスコープされている展開では、これらの手順はセクション11で説明したものを超えて実質的な利益を追加することはできません。
The Route Origin Autonomous System Number (ASN) of a BGP route that includes a Tunnel Encapsulation attribute can be determined by inspection of the AS_PATH attribute, according to the procedure specified in [RFC6811], Section 2. Call this value Route_AS.
トンネルカプセル化属性を含むBGPルートの経路原点自律システム番号（ASN）は、[RFC6811]、セクション2で指定された手順に従って、AS_PATH属性の検査によって決定できます。この値route_asを呼び出します。
In order to determine the Route Origin ASN of the address depicted in the Address subfield of the Tunnel Egress Endpoint sub-TLV, it is necessary to consider the forwarding route -- that is, the route that will be used to forward traffic toward that address. This route is determined by a recursive route-lookup operation for that address, as discussed in [RFC4271], Section 5.1.3. The relevant AS path to consider is the last one encountered while performing the recursive lookup; the procedures of [RFC6811], Section 2 are applied to that AS path to determine the Route Origin ASN. If no AS path is encountered at all, for example, if that route's source is a protocol other than BGP, the Route Origin ASN is the BGP speaker's own AS number. Call this value Egress_AS.
トンネル出力エンドポイントサブTLVのアドレスサブフィールドに示されているアドレスのルート原点ASNを決定するためには、転送ルートを考慮する必要があります。つまり、そのアドレスに向かうトラフィックを転送するために使用されるルート。このルートは、[RFC4271]、5.1.3で説明したように、そのアドレスの再帰的なルートルックアップ操作によって決まります。考慮すべき経路として関連するものは、再帰的検索を実行しながら最後に発生したものです。[RFC6811]の手順は、経路原点ASNを決定するためのPATHとしてのそれに適用されます。たとえば、経路が全く遭遇した場合、そのルートのソースがBGP以外のプロトコルである場合、ルートオリジンASNはBGPスピーカー自身の番号です。この値のegress_asを呼び出します。
If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint sub-TLV is considered not to be valid. In some cases, a network operator who controls a set of ASes might wish to allow a tunnel egress endpoint to reside in an AS other than Route_AS; configuration MAY allow for such a case, in which case the check becomes: if Egress_AS is not within the configured set of permitted AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to be "malformed".
route_asがegress_as等しくない場合、トンネル出力エンドポイントサブTLVは有効ではないと見なされます。場合によっては、一連のASを制御するネットワークオペレータは、トンネル出力エンドポイントがroute_as以外のものに存在することを許可したいと思うかもしれません。このような場合には、その場合、チェックが許可されていない場合、Tunnelの出力エンドポイントサブTLVが「不正な形式」と見なされます。
Note that if the forwarding route changes, this procedure MUST be reapplied. As a result, a sub-TLV that was formerly considered valid might become not valid, or vice versa.
転送経路が変わると、この手順を再適用する必要があります。その結果、以前は有効であると見なされたサブTLVが無効になる可能性があります。またはその逆も同様です。
This section defines Encapsulation sub-TLVs for the following tunnel types: VXLAN [RFC7348], NVGRE [RFC7637], MPLS-in-GRE [RFC4023], L2TPv3 [RFC3931], and GRE [RFC2784].
このセクションでは、次のトンネルタイプのカプセル化サブTLVを定義します.VXLAN [RFC7348]、NVGRE [RFC7637]、MPLS-IN-GRE [RFC4023]、L2TPV3 [RFC3931]、およびGRE [RFC2784]。
Rules for forming the encapsulation based on the information in a given TLV are given in Sections 6 and 9.
所与のTLV内の情報に基づくカプセル化を形成するための規則は、セクション6および9に示されている。
Recall that the tunnel type itself is identified by the Tunnel Type field in the attribute header (Section 2); the Encapsulation sub-TLV's structure is inferred from this. Regardless of the tunnel type, the sub-TLV type of the Encapsulation sub-TLV is 1. There are also tunnel types for which it is not necessary to define an Encapsulation sub-TLV, because there are no fields in the encapsulation header whose values need to be signaled from the tunnel egress endpoint.
トンネルタイプ自体が属性ヘッダの[トンネルタイプ]フィールドで識別されることを思い出してください（セクション2）。カプセル化サブTLVの構造はこれから推測されます。トンネルタイプに関係なく、カプセル化サブTLVのサブTLVタイプは1です。値のカプセル化ヘッダーにフィールドがないため、カプセル化サブTLVを定義する必要がないトンネルタイプもあります。トンネル出力エンドポイントからシグナリングする必要があります。
This document defines an Encapsulation sub-TLV for VXLAN [RFC7348] tunnels. When the tunnel type is VXLAN, the length of the sub-TLV is 12 octets. The structure of the Value field in the Encapsulation sub-TLV is shown in Figure 4.
このドキュメントでは、VXLAN [RFC7348]トンネル用のカプセル化サブTLVを定義します。トンネルタイプがVXLANの場合、サブTLVの長さは12オクテットです。カプセル化サブTLVの値フィールドの構造を図4に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 octets) | Reserved (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: VXLAN Encapsulation Sub-TLV Value Field
図4：VXLANカプセル化サブTLV値フィールド
V: This bit is set to 1 to indicate that a Virtual Network Identifier (VN-ID) is present in the Encapsulation sub-TLV. If set to 0, the VN-ID field is disregarded. Please see Section 9.
v：このビットは1に設定されており、仮想ネットワーク識別子（VN-ID）がカプセル化サブTLVに存在することを示します。0に設定すると、VN-IDフィールドは無視されます。9節をご覧ください。
M: This bit is set to 1 to indicate that a Media Access Control (MAC) Address is present in the Encapsulation sub-TLV. If set to 0, the MAC Address field is disregarded.
M：カプセル化サブTLVにメディアアクセス制御（MAC）アドレスが存在することを示すために、このビットは1に設定されています。0に設定すると、MACアドレスフィールドは無視されます。
R: The remaining bits in the 8-bit Flags field are reserved for further use. They MUST always be set to 0 by the originator of the sub-TLV. Intermediate routers MUST propagate them without modification. Any receiving routers MUST ignore these bits upon receipt.
R：8ビットフラグフィールドの残りのビットは、さらに使用するために予約されています。サブTLVの発信者によって常に0に設定する必要があります。中間ルータは変更なしでそれらを伝播する必要があります。受信時に受信ルータはこれらのビットを無視する必要があります。
VN-ID: If the V bit is set to 1, the VN-ID field contains a 3-octet VN-ID value. If the V bit is set to 0, the VN-ID field MUST be set to zero on transmission and disregarded on receipt.
VN-ID：Vビットが1に設定されている場合、VN-IDフィールドは3オクテットVN-ID値を含みます。Vビットが0に設定されている場合、VN-IDフィールドは送信時にゼロに設定され、受信時に無視されます。
MAC Address: If the M bit is set to 1, this field contains a 6-octet Ethernet MAC address. If the M bit is set to 0, this field MUST be set to all zeroes on transmission and disregarded on receipt.
MACアドレス：Mビットが1に設定されている場合、このフィールドには6オクテットイーサネットMACアドレスが含まれています。Mビットが0に設定されている場合、このフィールドは送信時のすべてのゼロに設定され、受信時に無視されなければなりません。
Reserved: MUST be set to zero on transmission and disregarded on receipt.
予約済み：送信時にゼロに設定され、受信時に無視されます。
When forming the VXLAN encapsulation header:
VXLANカプセル化ヘッダーを作成するとき：
* The values of the V, M, and R bits are NOT copied into the Flags field of the VXLAN header. The Flags field of the VXLAN header is set as per [RFC7348].
* V、M、およびRビットの値は、VXLANヘッダーのFlagsフィールドにコピーされません。VXLANヘッダーのFlagsフィールドは[RFC7348]と同じように設定されています。
* If the M bit is set to 1, the MAC Address is copied into the Inner Destination MAC Address field of the Inner Ethernet Header (see Section 5 of [RFC7348]).
* Mビットが1に設定されている場合、MACアドレスは内側イーサネットヘッダの内部宛先MACアドレスフィールドにコピーされます（[RFC7348]のセクション5参照）。
If the M bit is set to 0, and the payload being sent through the VXLAN tunnel is an Ethernet frame, the Destination MAC Address field of the Inner Ethernet Header is just the Destination MAC Address field of the payload's Ethernet header.
Mビットが0に設定されており、VXLANトンネルを介して送信されているペイロードがイーサネットフレームである場合、内部イーサネットヘッダーの宛先MACアドレスフィールドはペイロードのイーサネットヘッダーの宛先MACアドレスフィールドだけです。
If the M bit is set to 0, and the payload being sent through the VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC Address field is set to a configured value; if there is no configured value, the VXLAN tunnel cannot be used.
Mビットが0に設定されており、VXLANトンネルを介して送信されるペイロードはIPまたはMPLSパケットである場合、内部宛先MACアドレスフィールドは設定値に設定されます。設定値がない場合は、VXLANトンネルを使用できません。
* If the V bit is set to 0, and the BGP UPDATE message has an AFI/ SAFI other than Ethernet VPNs (SAFI 70, "BGP EVPNs"), then the VXLAN tunnel cannot be used.
* Vビットが0に設定されており、BGP更新メッセージにはEthernet VPNS以外のAFI / SAFIがあります（SAFI 70、「BGP EVPNS」）、VXLANトンネルを使用できません。
* Section 9 describes how the VNI (VXLAN Network Identifier) field of the VXLAN encapsulation header is set.
* セクション9では、VXLANカプセル化ヘッダのVNI（VXLANネットワークID）フィールドがどのように設定されるかを説明しています。
Note that in order to send an IP packet or an MPLS packet through a VXLAN tunnel, the packet must first be encapsulated in an Ethernet header, which becomes the "Inner Ethernet Header" described in [RFC7348]. The VXLAN Encapsulation sub-TLV may contain information (for example, the MAC address) that is used to form this Ethernet header.
VXLANトンネルを介してIPパケットまたはMPLSパケットを送信するためには、最初にパケットをイーサネットヘッダにカプセル化する必要があります。これは[RFC7348]に記載されている「内側イーサネットヘッダー」となります。VXLANカプセル化サブTLVは、このイーサネットヘッダーを形成するために使用される情報（たとえば、MACアドレスなど）を含み得る。
This document defines an Encapsulation sub-TLV for NVGRE [RFC7637] tunnels. When the tunnel type is NVGRE, the length of the sub-TLV is 12 octets. The structure of the Value field in the Encapsulation sub-TLV is shown in Figure 5.
この文書は、NVGRE [RFC7637]トンネルのカプセル化サブTLVを定義しています。トンネルタイプがNVGREの場合、サブTLVの長さは12オクテットです。カプセル化サブTLVの値フィールドの構造を図5に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 octets) | Reserved (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NVGRE Encapsulation Sub-TLV Value Field
図5：NVGREカプセル化サブTLV値フィールド
V: This bit is set to 1 to indicate that a VN-ID is present in the Encapsulation sub-TLV. If set to 0, the VN-ID field is disregarded. Please see Section 9.
v：このビットは1に設定されており、vn-idがカプセル化サブTLVに存在することを示します。0に設定すると、VN-IDフィールドは無視されます。9節をご覧ください。
M: This bit is set to 1 to indicate that a MAC Address is present in the Encapsulation sub-TLV. If set to 0, the MAC Address field is disregarded.
M：このビットは1に設定されており、カプセル化サブTLVにMACアドレスが存在することを示します。0に設定すると、MACアドレスフィールドは無視されます。
R: The remaining bits in the 8-bit Flags field are reserved for further use. They MUST always be set to 0 by the originator of the sub-TLV. Intermediate routers MUST propagate them without modification. Any receiving routers MUST ignore these bits upon receipt.
R：8ビットフラグフィールドの残りのビットは、さらに使用するために予約されています。サブTLVの発信者によって常に0に設定する必要があります。中間ルータは変更なしでそれらを伝播する必要があります。受信時に受信ルータはこれらのビットを無視する必要があります。
VN-ID: If the V bit is set to 1, the VN-ID field contains a 3-octet VN-ID value, used to set the NVGRE Virtual Subnet Identifier (VSID; see Section 9). If the V bit is set to 0, the VN-ID field MUST be set to zero on transmission and disregarded on receipt.
VN-ID：Vビットが1に設定されている場合、VN-IDフィールドには3オクテットVN-ID値が含まれています.NVGRE仮想サブネット識別子（VSID; 9を参照）を設定します。Vビットが0に設定されている場合、VN-IDフィールドは送信時にゼロに設定され、受信時に無視されます。
MAC Address: If the M bit is set to 1, this field contains a 6-octet Ethernet MAC address. If the M bit is set to 0, this field MUST be set to all zeroes on transmission and disregarded on receipt.
MACアドレス：Mビットが1に設定されている場合、このフィールドには6オクテットイーサネットMACアドレスが含まれています。Mビットが0に設定されている場合、このフィールドは送信時のすべてのゼロに設定され、受信時に無視されなければなりません。
Reserved: MUST be set to zero on transmission and disregarded on receipt.
予約済み：送信時にゼロに設定され、受信時に無視されます。
When forming the NVGRE encapsulation header:
NVGREカプセル化ヘッダーを作成するとき：
* The values of the V, M, and R bits are NOT copied into the Flags field of the NVGRE header. The Flags field of the NVGRE header is set as per [RFC7637].
* V、M、およびRビットの値は、NVGREヘッダーのFlagsフィールドにコピーされません。NVGREヘッダーのFlagsフィールドは[RFC7637]と同じように設定されています。
* If the M bit is set to 1, the MAC Address is copied into the Inner Destination MAC Address field of the Inner Ethernet Header (see Section 3.2 of [RFC7637]).
* Mビットが1に設定されている場合、MACアドレスは内部イーサネットヘッダの内部宛先MACアドレスフィールドにコピーされます（[RFC7637]のセクション3.2を参照）。
If the M bit is set to 0, and the payload being sent through the NVGRE tunnel is an Ethernet frame, the Destination MAC Address field of the Inner Ethernet Header is just the Destination MAC Address field of the payload's Ethernet header.
Mビットが0に設定され、NVGREトンネルを介して送信されているペイロードがイーサネットフレームである場合、内部イーサネットヘッダーの宛先MACアドレスフィールドはペイロードのイーサネットヘッダーの宛先MACアドレスフィールドだけです。
If the M bit is set to 0, and the payload being sent through the NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC Address field is set to a configured value; if there is no configured value, the NVGRE tunnel cannot be used.
Mビットが0に設定されており、NVGREトンネルを介して送信されるペイロードはIPまたはMPLSパケットである場合、内部宛先MACアドレスフィールドは設定値に設定されます。設定値がない場合は、NVGREトンネルを使用できません。
* If the V bit is set to 0, and the BGP UPDATE message has an AFI/ SAFI other than Ethernet VPNs (EVPNs), then the NVGRE tunnel cannot be used.
* Vビットが0に設定されており、BGP UpdateメッセージにイーサネットVPN（EVPNS）以外のAFI / SAFIがある場合は、NVGREトンネルを使用できません。
* Section 9 describes how the VSID field of the NVGRE encapsulation header is set.
* セクション9は、NVGREカプセル化ヘッダーのVSIDフィールドがどのように設定されているかを説明しています。
When the tunnel type of the TLV is L2TPv3 over IP [RFC3931], the length of the sub-TLV is between 4 and 12 octets, depending on the length of the cookie. The structure of the Value field of the Encapsulation sub-TLV is shown in Figure 6.
TLVのトンネルタイプがL2TPV3である[RFC3931]では、Cookieの長さに応じて、SUB-TLVの長さは4~12オクテットです。カプセル化サブTLVの値フィールドの構造を図6に示す。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cookie (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: L2TPv3 Encapsulation Sub-TLV Value Field
図6：L2TPv3カプセル化サブTLV値フィールド
Session ID: A non-zero 4-octet value locally assigned by the advertising router that serves as a lookup key for the incoming packet's context.
セッションID：着信パケットのコンテキストのルックアップキーとして機能する広告ルータによってローカルに割り当てられたゼロ以外の4オクテット値。
Cookie: An optional, variable-length (encoded in 0 to 8 octets) value used by L2TPv3 to check the association of a received data message with the session identified by the Session ID. Generation and usage of the cookie value is as specified in [RFC3931].
Cookie：受信データメッセージとセッションIDによって識別されたセッションとの関連付けを確認するために、L2TPv3によって使用されるオプションの可変長（0から8オクテットでエンコードされています）値。Cookie値の生成と使用方法は[RFC3931]で指定されています。
The length of the cookie is not encoded explicitly but can be calculated as (sub-TLV length - 4).
クッキーの長さは明示的にエンコードされていませんが（SUB-TLVの長さ - 4）として計算できます。
When the tunnel type of the TLV is GRE [RFC2784], the length of the sub-TLV is 4 octets. The structure of the Value field of the Encapsulation sub-TLV is shown in Figure 7.
TLVのトンネルタイプがGRE [RFC2784]の場合、サブTLVの長さは4オクテットです。カプセル化サブTLVの値フィールドの構造を図7に示す。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GRE Encapsulation Sub-TLV Value Field
図7：GREカプセル化サブTLV値フィールド
GRE Key: 4-octet field [RFC2890] that is generated by the advertising router. Note that the key is optional. Unless a key value is being advertised, the GRE Encapsulation sub-TLV MUST NOT be present.
GREキー：広告ルータによって生成された4 - オクテットフィールド[RFC2890]。キーはオプションです。キー値がアドバタイズされていない限り、GREカプセル化サブTLVは存在してはならない。
When the tunnel type is MPLS-in-GRE [RFC4023], the length of the sub-TLV is 4 octets. The structure of the Value field of the Encapsulation sub-TLV is shown in Figure 8.
トンネルタイプがMPLS-IN-GRE [RFC4023]の場合、サブTLVの長さは4オクテットです。カプセル化サブTLVの値フィールドの構造を図8に示す。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MPLS-in-GRE Encapsulation Sub-TLV Value Field
図8：MPLS-IN-GREカプセル化サブTLV値フィールド
GRE Key: 4-octet field [RFC2890] that is generated by the advertising router. Note that the key is optional. Unless a key value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV MUST NOT be present.
GREキー：広告ルータによって生成された4 - オクテットフィールド[RFC2890]。キーはオプションです。キー値がアドバタイズされていない限り、MPLS-IN-GREカプセル化サブTLVは存在してはならない。
Note that the GRE tunnel type defined in Section 3.2.4 can be used instead of the MPLS-in-GRE tunnel type when it is necessary to encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel type is equivalent to including a TLV of the GRE tunnel type that also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS as the protocol to be encapsulated.
3.2.4節で定義されているGREトンネルタイプは、GRE内のMPLSをカプセル化する必要がある場合にMPLS-IN-GREトンネルタイプの代わりに使用できます。MPLS-IN-GREトンネルタイプのTLVを含めることは、カプセル化されるプロトコルとしてMPLSを指定するプロトコルタイプサブTLV（セクション3.4.1）を含むGREトンネルタイプのTLVと同等です。
Although the MPLS-in-GRE tunnel type is just a special case of the GRE tunnel type and thus is not strictly necessary, it is included for reasons of backwards compatibility with, for example, implementations of [RFC8365].
MPLS-IN-GREトンネルタイプはGREトンネルタイプの単なる特別な場合であるため、厳密には必要ありませんが、たとえば[RFC8365]の実装との後方互換性の理由で含まれています。
The Encapsulation sub-TLV for a particular tunnel type allows one to specify the values that are to be placed in certain fields of the encapsulation header for that tunnel type. However, some tunnel types require an outer IP encapsulation, and some also require an outer UDP encapsulation. The Encapsulation sub-TLV for a given tunnel type does not usually provide a way to specify values for fields of the outer IP and/or UDP encapsulations. If it is necessary to specify values for fields of the outer encapsulation, additional sub-TLVs must be used. This document defines two such sub-TLVs.
特定のトンネルタイプのカプセル化サブTLVは、そのトンネルタイプのカプセル化ヘッダーの特定のフィールドに配置される値を指定できます。ただし、いくつかのトンネルタイプは外部IPカプセル化を必要とし、一部のUDPカプセル化も必要です。特定のトンネルタイプのカプセル化サブTLVは通常、外部IPおよび/またはUDPのカプセル化のフィールドの値を指定する方法を提供しません。外部カプセル化のフィールドの値を指定する必要がある場合は、追加のサブTLVを使用する必要があります。この文書は2つのそのようなサブTLVを定義します。
If an outer Encapsulation sub-TLV occurs in a TLV for a tunnel type that does not use the corresponding outer encapsulation, the sub-TLV MUST be treated as if it were an unrecognized type of sub-TLV.
対応する外部カプセル化を使用しないトンネルタイプのTLVで外部カプセル化サブTLVが発生した場合、SUB-TLVは認識されないタイプのサブTLVであるかのように扱われなければなりません。
Most of the tunnel types that can be specified in the Tunnel Encapsulation attribute require an outer IP encapsulation. The Differentiated Services (DS) Field sub-TLV can be carried in the TLV of any such tunnel type. It specifies the setting of the one-octet Differentiated Services field in the outer IPv4 or IPv6 encapsulation (see [RFC2474]). Any one-octet value can be transported; the semantics of the DSCP (Differentiated Services Code Point) field is beyond the scope of this document. The Value field is always a single octet.
トンネルカプセル化属性で指定できるトンネルタイプのほとんどは、外部IPカプセル化を必要とします。差別化サービス（DS）フィールドSUB-TLVは、そのようなトンネルタイプのTLVで搬送できます。外部IPv4またはIPv6のカプセル化の1 OCTET差別化サービスフィールドの設定を指定します（[RFC2474]参照）。任意の1オクテット値を輸送することができます。DSCP（微分サービスコードポイント）フィールドの意味論はこの文書の範囲を超えています。値フィールドは常に単一のオクテットです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| DS value |
+-+-+-+-+-+-+-+-+
Figure 9: DS Field Sub-TLV Value Field
図9：DSフィールドサブTLV値フィールド
Because the interpretation of the DSCP field at the recipient may be different from its interpretation at the originator, an implementation MAY provide a facility to use policy to filter or modify the DS field.
受信者におけるDSCPフィールドの解釈は、発信者での解釈とは異なる可能性があるため、実装はDSフィールドをフィルタリングまたは変更するためのポリシーを使用する機能を提供することがあります。
Some of the tunnel types that can be specified in the Tunnel Encapsulation attribute require an outer UDP encapsulation. Generally, there is a standard UDP destination port value for a particular tunnel type. However, sometimes it is useful to be able to use a nonstandard UDP destination port. If a particular tunnel type requires an outer UDP encapsulation, and it is desired to use a UDP destination port other than the standard one, the port to be used can be specified by including a UDP Destination Port sub-TLV. The Value field of this sub-TLV is always a two-octet field, containing the port value. Any two-octet value other than zero can be transported. If the reserved value zero is received, the sub-TLV MUST be treated as malformed, according to the rules of Section 13.
トンネルカプセル化属性で指定できるトンネルタイプの中には、外部UDPカプセル化が必要です。一般に、特定のトンネルタイプの標準的なUDP宛先ポート値があります。ただし、非標準UDP宛先ポートを使用できることが便利です。特定のトンネルタイプが外部UDPカプセル化を必要とし、標準化されているUDP宛先ポートを使用することが望まれる場合、UDP宛先ポートサブTLVを含めることで使用するポートを指定することができる。このサブTLVの値フィールドは、ポート値を含む2オクテットフィールドです。ゼロ以外の2オクテット値は搬送されます。予約値0が受信された場合、セクション13の規則に従って、サブTLVは不正な形式として扱われなければなりません。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: UDP Destination Port Sub-TLV Value Field
図10：UDP宛先ポートサブTLV値フィールド
The Protocol Type sub-TLV MAY be included in a given TLV to indicate the type of the payload packets that are allowed to be encapsulated with the tunnel parameters that are being signaled in the TLV. Packets with other payload types MUST NOT be encapsulated in the relevant tunnel. The Value field of the sub-TLV contains a 2-octet value from IANA's "ETHER TYPES" registry [IANA-ETHERTYPES]. If the reserved value 0xFFFF is received, the sub-TLV MUST be treated as malformed according to the rules of Section 13.
プロトコルタイプサブTLVは、TLVでシグナリングされているトンネルパラメータでカプセル化されることが許可されているペイロードパケットのタイプを示すために、特定のTLVに含まれていてもよい。他のペイロードタイプのパケットは、関連トンネルにカプセル化してはいけません。SUB-TLVの値フィールドには、IANAの「エーテルタイプ」レジストリ[IANA-ETHERTYPES]から2オクテット値が含まれています。予約値0xFFFFを受信した場合、サブTLVはセクション13の規則に従って不正な形式として扱われなければなりません。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Protocol Type Sub-TLV Value Field
図11：プロトコルタイプサブTLV値フィールド
For example, if there are three L2TPv3 sessions, one carrying IPv4 packets, one carrying IPv6 packets, and one carrying MPLS packets, the egress router will include three TLVs of L2TPv3 encapsulation type, each specifying a different Session ID and a different payload type. The Protocol Type sub-TLV for these will be IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol type = 0x8847), respectively. This informs the ingress routers of the appropriate encapsulation information to use with each of the given protocol types. Insertion of the specified Session ID at the ingress routers allows the egress to process the incoming packets correctly, according to their protocol type.
たとえば、3つのL2TPv3セッション、IPv4パケットを搬送する1つがIPv4パケットを搬送すると、IPv6パケットを搬送する1つがMPLSパケットを搬送すると、それぞれのL2TPv3カプセル化タイプが3つのTLVSを含みます。それぞれは、異なるセッションIDと異なるペイロードタイプを指定します。これらのプロトコルタイプサブTLVは、IPv4（プロトコルタイプ= 0x0800）、IPv6（プロトコルタイプ= 0x86dd）、およびMPLS（プロトコルタイプ= 0x8847）になります。これにより、特定のプロトコルタイプのそれぞれで使用する適切なカプセル化情報の入力ルータに通知します。入力ルータに指定されたセッションIDを挿入すると、出力は、プロトコルの種類に従って、着信パケットを正しく処理できます。
Note that for tunnel types whose names are of the form "X-in-Y" (for example, MPLS-in-GRE), only packets of the specified payload type "X" are to be carried through the tunnel of type "Y". This is the equivalent of specifying a tunnel type "Y" and including in its TLV a Protocol Type sub-TLV (see Section 3.4.1) specifying protocol "X". If the tunnel type is "X-in-Y", it is unnecessary, though harmless, to explicitly include a Protocol Type sub-TLV specifying "X". Also, for "X-in-Y" type tunnels, a Protocol Type sub-TLV specifying anything other than "X" MUST be ignored; this is discussed further in Section 13.
なお、名前が "x-in-y"の形式であるトンネルタイプ（たとえば、MPLS-IN-GRE）では、指定されたペイロードタイプ "X"のパケットのみがタイプのトンネルを介して運ばれる予定です。"。これは、トンネルタイプ「Y」を指定し、そのTLV AプロトコルタイプのサブTLV（セクション3.4.1参照）を含むのと同じです（セクション3.4.1参照）。トンネルの種類が「X-in-y」の場合、無害ではなく、「x」を指定するプロトコルタイプのサブTLVを明示的に含めることは不要です。また、「X-IN-Y」タイプのトンネルについては、「X」以外のものを指定するプロトコルタイプSUB-TLVを無視する必要があります。これについてはさらにセクション13で説明されている。
The Color sub-TLV MAY be used as a way to "color" the corresponding Tunnel TLV. The Value field of the sub-TLV is eight octets long and consists of a Color Extended Community, as defined in Section 4.3. For the use of this sub-TLV and extended community, please see Section 8.
カラーサブTLVは、対応するトンネルTLVを「色」にする方法として使用することができる。SUB-TLVの値フィールドは8オクテット長さで、セクション4.3で定義されているように、カラー拡張コミュニティで構成されています。このサブTLVと拡張コミュニティを使用するには、セクション8をご覧ください。
The format of the Value field is depicted in Figure 15.
値フィールドのフォーマットは図15に示されています。
If the Length field of a Color sub-TLV has a value other than 8, or the first two octets of its Value field are not 0x030b, the sub-TLV MUST be treated as if it were an unrecognized sub-TLV (see Section 13).
カラーサブTLVの長さフィールドに8以外の値がある場合、またはその値フィールドの最初の2オクテットが0x030Bではない場合、SUB-TLVは認識されないサブTLVであるかのように扱われなければなりません（セクション13を参照）。）。
Certain BGP address families (corresponding to particular AFI/SAFI pairs, for example, 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in their NLRIs. The term "embedded label" is used to refer to the MPLS label that is embedded in an NLRI, and the term "labeled address family" to refer to any AFI/SAFI that has embedded labels.
特定のBGPアドレスファミリ（例えば、特定のAFI / SAFIペアに対応、例えば1/4,2 / 4,1 / 128,2/128）は、MPLSラベルがそれらのNLRIに埋め込まれています。「埋め込みラベル」という用語は、NLRIに埋め込まれているMPLSラベル、および「ラベル付きアドレスファミリ」という用語を参照するために使用され、埋め込みラベルを持つAFI / SAFIを参照してください。
Some of the tunnel types (for example, VXLAN and NVGRE) that can be specified in the Tunnel Encapsulation attribute have an encapsulation header containing a virtual network identifier of some sort. The Encapsulation sub-TLVs for these tunnel types may optionally specify a value for the virtual network identifier.
Tunnel Encapsulation属性に指定できるトンネルタイプ（たとえば、VXLANおよびNVGRE）の中には、ある種の仮想ネットワーク識別子を含むカプセル化ヘッダーがあります。これらのトンネルタイプのカプセル化サブTLVは、仮想ネットワーク識別子の値をオプションで指定することができます。
Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of a labeled address family, and it is decided to use a particular tunnel (specified in one of the attribute's TLVs) for transmitting a packet that is being forwarded according to that UPDATE. When forming the encapsulation header for that packet, different deployment scenarios require different handling of the embedded label and/or the virtual network identifier. The Embedded Label Handling sub-TLV can be used to control the placement of the embedded label and/or the virtual network identifier in the encapsulation.
トンネルカプセル化属性がラベル付きアドレスファミリの更新に添付されているとすると、その更新に従って転送されているパケットを送信するための特定のトンネル（属性のTLVで指定されている）を使用することが決定されます。そのパケットのカプセル化ヘッダを形成するとき、異なる展開シナリオは、埋め込みラベルおよび/または仮想ネットワーク識別子の異なる処理を必要とする。埋め込みラベル処理サブTLVは、埋め込みラベルおよび/またはカプセル化における仮想ネットワーク識別子の配置を制御するために使用することができる。
The Embedded Label Handling sub-TLV may be included in any TLV of the Tunnel Encapsulation attribute. If the Tunnel Encapsulation attribute is attached to an UPDATE of a non-labeled address family, then the sub-TLV MUST be disregarded. If the sub-TLV is contained in a TLV whose tunnel type does not have a virtual network identifier in its encapsulation header, the sub-TLV MUST be disregarded. In those cases where the sub-TLV is ignored, it MUST NOT be stripped from the TLV before the route is propagated.
埋め込みラベル処理サブTLVは、トンネルカプセル化属性の任意のTLVに含まれていてもよい。トンネルカプセル化属性が非ラベル付きアドレスファミリの更新に添付されている場合、サブTLVは無視されなければなりません。サブTLVがトンネルタイプがそのカプセル化ヘッダーに仮想ネットワーク識別子を持たないTLVに含まれている場合、サブTLVは無視されなければなりません。サブTLVが無視される場合は、経路が伝播する前にTLVから削除しないでください。
The sub-TLV's Length field always contains the value 1, and its Value field consists of a single octet. The following values are defined:
SUB-TLVの長さフィールドは常に値1を含み、その値フィールドは単一のオクテットで構成されています。以下の値が定義されています。
1: The payload will be an MPLS packet with the embedded label at the top of its label stack.
1：ペイロードは、ラベルスタックの上部にある埋め込みラベルを持つMPLSパケットになります。
2: The embedded label is not carried in the payload but is either carried in the Virtual Network Identifier field of the encapsulation header or else ignored entirely.
2：埋め込みラベルはペイロードでは実行されませんが、カプセル化ヘッダーの仮想ネットワーク識別子フィールドには搭載されているか、または完全に無視されます。
If any value other than 1 or 2 is carried, the sub-TLV MUST be considered malformed, according to the procedures of Section 13.
1または2以外の値が搭載されている場合、セクション13の手順に従って、サブTLVは不正なことを考慮する必要があります。
Please see Section 9 for the details of how this sub-TLV is used when it is carried by an UPDATE of a labeled address family.
このサブTLVがラベル付きアドレスファミリの更新によってどのように使用されるかの詳細については、セクション9を参照してください。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 1 or 2 |
+-+-+-+-+-+-+-+-+
Figure 12: Embedded Label Handling Sub-TLV Value Field
図12：埋め込みラベル処理サブTLV値フィールド
This sub-TLV allows an MPLS label stack [RFC3032] to be associated with a particular tunnel.
このサブTLVは、MPLSラベルスタック[RFC3032]を特定のトンネルと関連付けることができます。
The length of the sub-TLV is a multiple of 4 octets, and the Value field of this sub-TLV is a sequence of MPLS label stack entries. The first entry in the sequence is the "topmost" label, and the final entry in the sequence is the "bottommost" label. When this label stack is pushed onto a packet, this ordering MUST be preserved.
サブTLVの長さは4オクテットの倍数であり、このサブTLVの値フィールドは一連のMPLSラベルスタックエントリです。シーケンス内の最初のエントリは「最上位の」ラベルであり、シーケンス内の最後のエントリは「最ボックス」ラベルです。このラベルスタックがパケットにプッシュされると、この順序は保存されなければなりません。
Each label stack entry has the format shown in Figure 13.
各ラベルスタックエントリは、図13に示すフォーマットを持ちます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: MPLS Label Stack Sub-TLV Value Field
図13：MPLSラベルスタックサブTLV値フィールド
The fields are as defined in [RFC3032] and [RFC5462].
フィールドは[RFC3032]と[RFC5462]で定義されているとおりです。
If a packet is to be sent through the tunnel identified in a particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV, then the label stack appearing in the sub-TLV MUST be pushed onto the packet before any other labels are pushed onto the packet. (See Section 6 for further discussion.)
特定のTLVで識別されたトンネルを介してパケットを送信する場合、およびそのTLVがMPLSラベルスタックSUB-TLVを含む場合、サブTLVに表示されるラベルスタックは他のラベルがある前にパケットにプッシュされなければなりません。パケットを押し上げました。（さらなる議論については、セクション6を参照してください。）
In particular, if the Tunnel Encapsulation attribute is attached to a BGP UPDATE of a labeled address family, the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the packet before the label embedded in the NLRI is pushed onto the packet.
特に、トンネルのカプセル化属性がラベル付きアドレスファミリのBGPアップデートに接続されている場合、NLRIに埋め込まれたラベルがパケットにプッシュされる前に、MPLSラベルスタックサブTLVの内容をパケットにプッシュする必要があります。
If the MPLS Label Stack sub-TLV is included in a TLV identifying a tunnel type that uses virtual network identifiers (see Section 9), the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the packet before the procedures of Section 9 are applied.
MPLSラベルスタックSUB-TLVが仮想ネットワーク識別子を使用するトンネルタイプを識別するTLVに含まれている場合（セクション9を参照）、MPLSラベルスタックサブTLVの内容はセクション9の手順の前にパケットにプッシュされなければなりません。適用されます。
The number of label stack entries in the sub-TLV MUST be determined from the Sub-TLV Length field. Thus, it is not necessary to set the S bit in any of the label stack entries of the sub-TLV, and the setting of the S bit is ignored when parsing the sub-TLV. When the label stack entries are pushed onto a packet that already has a label stack, the S bits of all the entries being pushed MUST be cleared. When the label stack entries are pushed onto a packet that does not already have a label stack, the S bit of the bottommost label stack entry MUST be set, and the S bit of all the other label stack entries MUST be cleared.
サブTLV内のラベルスタックエントリの数は、SUB-TLV長フィールドから決定されなければなりません。したがって、SUB-TLVのラベルスタックエントリのいずれにSビットを設定する必要はなく、SUB-TLVの解析時にSビットの設定は無視されます。ラベルスタックエントリがすでにラベルスタックを持っているパケットにプッシュされると、プッシュされているすべてのエントリのSビットをクリアする必要があります。ラベルスタックエントリがまだラベルスタックをまだ持っていないパケットにプッシュされると、最ボックスラベルスタックエントリのSビットを設定する必要があり、他のすべてのラベルスタックエントリのSビットをクリアする必要があります。
The Traffic Class (TC) field [RFC3270][RFC5129] of each label stack entry SHOULD be set to 0, unless changed by policy at the originator of the sub-TLV. When pushing the label stack onto a packet, the TC of each label stack SHOULD be preserved, unless local policy results in a modification.
各ラベルスタックエントリの[RFC3270] [RFC5129] [RFC5129]は、SUB-TLVの発信元でポリシーによって変更されない限り、0に設定する必要があります。ラベルスタックをパケットに押すと、ローカルポリシーが変更されていない限り、各ラベルスタックのTCを保持する必要があります。
The TTL (Time to Live) field of each label stack entry SHOULD be set to 255, unless changed to some other non-zero value by policy at the originator of the sub-TLV. When pushing the label stack onto a packet, the TTL of each label stack entry SHOULD be preserved, unless local policy results in a modification to some other non-zero value. If any label stack entry in the sub-TLV has a TTL value of zero, the router that is pushing the stack onto a packet MUST change the value to a non-zero value, either 255 or some other value as determined by policy as discussed above.
各ラベルスタックエントリのTTL（Time to Live）フィールドは、SUB-TLVの発信元でポリシーによって他のゼロ以外の値に変更されていない限り、255に設定する必要があります。ラベルスタックをパケットに押すと、ローカルポリシーが他のゼロ以外の値に変更されていない限り、各ラベルスタックエントリのTTLを保持する必要があります。SUB-TLVのラベルスタックエントリがTTL値がゼロになっている場合、スタックをパケットにプッシュしているルータは、255またはその他の値を255またはその他の値に変更する必要があります。上記
Note that this sub-TLV can appear within a TLV identifying any type of tunnel, not just within a TLV identifying an MPLS tunnel. However, if this sub-TLV appears within a TLV identifying an MPLS tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role that would be played by an MPLS Encapsulation sub-TLV. Therefore, an MPLS Encapsulation sub-TLV is not defined.
このサブTLVは、MPLSトンネルを識別するTLV内だけでなく、任意のタイプのトンネルを識別するTLV内に表示される可能性があることに注意してください。ただし、このSUB-TLVがMPLSトンネル（またはMPLS-IN-Xトンネル）を識別するTLV内に表示される場合、このサブTLVはMPLSカプセル化サブTLVによって再生されるのと同じ役割を果たします。したがって、MPLSカプセル化サブTLVは定義されていません。
Although this specification does not supply detailed instructions for validating the received label stack, implementations might impose restrictions on the label stack they can support. If an invalid or unsupported label stack is received, the tunnel MAY be treated as not feasible, according to the procedures of Section 6.
この仕様では、受信したラベルスタックを検証するための詳細な命令は提供されていませんが、実装はサポートできるラベルスタックに制限を課す可能性があります。無効またはサポートされていないラベルスタックが受信された場合、セクション6の手順に従って、トンネルは実現不可能として扱われることがある。
[RFC8669] defines a BGP path attribute known as the "BGP Prefix-SID attribute". This attribute is defined to contain a sequence of one or more TLVs, where each TLV is either a Label-Index TLV or an Originator SRGB (Source Routing Global Block) TLV.
[RFC8669]「BGP Prefix-SID属性」と呼ばれるBGPパス属性を定義します。この属性は1つ以上のTLVのシーケンスを含むように定義されており、各TLVはラベルインデックスTLVまたは発信者SRGB（ソースルーティンググローバルブロック）TLVのいずれかである。
This document defines a Prefix-SID (Prefix Segment Identifier) sub-TLV. The Value field of the Prefix-SID sub-TLV can be set to any permitted value of the Value field of a BGP Prefix-SID attribute [RFC8669].
このドキュメントでは、prefix-sid（プレフィックスセグメント識別子）サブTLVを定義します。prefix-sid sub-tlvの値フィールドは、BGP Prefix-SID属性[RFC8669]の値フィールドの許可された値に設定できます。
[RFC8669] only defines behavior when the BGP Prefix-SID attribute is
attached to routes of type IPv4/IPv6 Labeled Unicast
[RFC4760][RFC8277], and it only defines values of the BGP Prefix-SID
attribute for those cases. Therefore, similar limitations exist for
the Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE
message for one of the address families for which [RFC8669] has a
defined behavior, namely BGP IPv4/IPv6 Labeled Unicast [RFC4760]
[RFC8277]. If included in a BGP UPDATE for any other address family,
it MUST be ignored.
The Prefix-SID sub-TLV can occur in a TLV identifying any type of tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB MUST be interpreted to be the SRGB used by the tunnel's egress endpoint. The Label-Index, if present, is the Segment Routing SID that the tunnel's egress endpoint uses to represent the prefix appearing in the NLRI field of the BGP UPDATE to which the Tunnel Encapsulation attribute is attached.
prefix-sid sub-tlvは、任意のタイプのトンネルを識別するTLVで発生する可能性があります。発信者SRGBがSUB-TLVに指定されている場合、そのSRGBはトンネルの出力エンドポイントによって使用されるSRGBになるように解釈されなければなりません。ラベルインデックスが存在する場合、トンネルの出力エンドポイントがトンネルのカプセル化属性が接続されているBGPアップデートのNLRIフィールドに表示されるプレフィックスを表すために使用するセグメントルーティングSIDです。
If a Label-Index is present in the Prefix-SID sub-TLV, then when a packet is sent through the tunnel identified by the TLV, if that tunnel is from a labeled address family, the corresponding MPLS label MUST be pushed on the packet's label stack. The corresponding MPLS label is computed from the Label-Index value and the SRGB of the route's originator, as specified in Section 4.1 of [RFC8669].
prefix-sid sub-tlvにラベルインデックスが存在する場合、TLVによって識別されたトンネルを介してパケットが送信されると、そのトンネルがラベル付きアドレスファミリからの場合、対応するMPLSラベルをパケットのプッシュする必要があります。ラベルスタック。対応するMPLSラベルは、[RFC8669]のセクション4.1で指定されているように、ルートの発信者のLabel-Index値とSRGBから計算されます。
The corresponding MPLS label is pushed on after the processing of the MPLS Label Stack sub-TLV, if present, as specified in Section 3.6. It is pushed on before any other labels (for example, a label embedded in an UPDATE's NLRI or a label determined by the procedures of Section 9) are pushed on the stack.
セクション3.6で指定されているように、MPLSラベルスタックサブTLVの処理後に、対応するMPLSラベルがプッシュされます。他のラベルの前にプッシュされます（たとえば、更新のNLRIに埋め込まれたラベルまたはセクション9の手順によって決定されたラベル）がスタックにプッシュされます。
The Prefix-SID sub-TLV has slightly different semantics than the BGP Prefix-SID attribute. When the BGP Prefix-SID attribute is attached to a given route, the BGP speaker that originally attached the attribute is expected to be in the same Segment Routing domain as the BGP speakers who receive the route with the attached attribute. The Label-Index tells the receiving BGP speakers what the Prefix-SID is for the advertised prefix in that Segment Routing domain. When the Prefix-SID sub-TLV is used, there is no implication that the Prefix-SID for the advertised prefix is the same in the Segment Routing domains of the BGP speaker that originated the sub-TLV and the BGP speaker that received it.
prefix-sid sub-tlvには、bgp prefix-sid属性よりわずかに異なる意味があります。bgp prefix-sid属性が特定のルートに接続されている場合、元に属性を付けたBGPスピーカーは、添付属性を持つルートを受け取るBGPスピーカーと同じセグメントルーティングドメインになると予想されます。label-indexは、そのセグメントルーティングドメイン内のアドバタイズされたプレフィックスの場合、受信側のBGPスピーカーに指示します。prefix-sid sub-tlvを使用する場合、アドバタイズされたプレフィックスのprefix-sidがサブTLVとそれを受信したBGPスピーカーのセグメントルーティングドメインで同じであるという意味はありません。
The Encapsulation Extended Community is a Transitive Opaque Extended Community.
カプセル化拡張コミュニティは、推移的な不透明な拡張コミュニティです。
The Encapsulation Extended Community encoding is as shown in Figure 14.
カプセル化拡張コミュニティエンコードは図14に示す通りです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 (1 octet)| 0x0c (1 octet)| Reserved (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (2 octets) | Tunnel Type (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Encapsulation Extended Community
図14：カプセル化拡張コミュニティ
The value of the high-order octet of the extended Type field is 0x03, which indicates it's transitive. The value of the low-order octet of the extended Type field is 0x0c.
拡張型フィールドの高次オクテットの値は0x03で、それが推移的であることを示しています。拡張型フィールドの下位オクテットの値は0x0cです。
The last two octets of the Value field encode a tunnel type.
値フィールドの最後の2オクテットはトンネルタイプをエンコードします。
This extended community may be attached to a route of any AFI/SAFI to which the Tunnel Encapsulation attribute may be attached. Each such extended community identifies a particular tunnel type; its semantics are the same as semantics of a Tunnel TLV in a Tunnel Encapsulation attribute, for which the following three conditions all hold:
この拡張コミュニティは、トンネルカプセル化属性が添付され得る任意のAFI / SAFIの経路に添付されてもよい。そのような拡張コミュニティごとに特定のトンネルタイプを識別します。そのセマンティクスは、トンネルカプセル化属性内のトンネルTLVのセマンティクスと同じです。これにより、次の3つの条件がすべて保持されます。
1. It identifies the same tunnel type.
1. 同じトンネルタイプを識別します。
2. It has a Tunnel Egress Endpoint sub-TLV for which one of the following two conditions holds:
2. 次の2つの条件のうちの1つが保持されているトンネル出力エンドポイントサブTLVがあります。
a. Its Address Family subfield contains zero, or
a. そのアドレスファミリサブフィールドには、ゼロ、または
b. Its Address subfield contains the address of the Next Hop field of the route to which the Tunnel Encapsulation attribute is attached.
b. そのアドレスサブフィールドには、トンネルカプセル化属性が接続されている経路のネクストホップフィールドのアドレスが含まれています。
3. It has no other sub-TLVs.
3. 他のサブTLVはありません。
Such a Tunnel TLV is called a "barebones" Tunnel TLV.
そのようなトンネルTLVは「ベアボーン」トンネルTLVと呼ばれる。
The Encapsulation Extended Community was first defined in [RFC5512]. While it provides only a small subset of the functionality of the Tunnel Encapsulation attribute, it is used in a number of deployed applications and is still needed for backwards compatibility. In situations where a tunnel could be encoded using a barebones TLV, it MUST be encoded using the corresponding Encapsulation Extended Community. Notwithstanding, an implementation MUST be prepared to process a tunnel received encoded as a barebones TLV.
カプセル化拡張コミュニティは、[RFC5512]で最初に定義されました。トンネルカプセル化属性の機能の小さなサブセットのみを提供しますが、それは多くのデプロイされたアプリケーションで使用され、依然として後方互換性に必要です。トンネルをベアボーンTLVを使用して符号化できる状況では、対応するカプセル化拡張コミュニティを使用してエンコードする必要があります。それにもかかわらず、実装は、ベアボーンTLVとして符号化された受信したトンネルを処理するために準備されなければならない。
Note that for tunnel types of the form "X-in-Y" (for example, MPLS-in-GRE), the Encapsulation Extended Community implies that only packets of the specified payload type "X" are to be carried through the tunnel of type "Y". Packets with other payload types MUST NOT be carried through such tunnels. See also Section 2.
"x-in-y"（たとえば、MPLS-IN-GRE）のトンネルタイプの場合、カプセル化拡張コミュニティは、指定されたペイロードタイプ "X"のパケットのみをトンネルを介して運ばれることを意味します。"y"と入力します。他のペイロードタイプを持つパケットは、そのようなトンネルを介して実行してはいけません。セクション2も参照してください。
In the remainder of this specification, when a route is referred to as containing a Tunnel Encapsulation attribute with a TLV identifying a particular tunnel type, it implicitly includes the case where the route contains an Encapsulation Extended Community identifying that tunnel type.
この仕様の残りの部分では、特定のトンネルタイプを識別するTLVを使用してトンネルカプセル化属性を含むルートを参照すると、そのルートがそのトンネルタイプを識別するカプセル化拡張コミュニティが含まれている場合を暗黙的に含みます。
[EVPN-INTER-SUBNET] defines a router's MAC Extended Community. This extended community, as its name implies, carries the MAC address of the advertising router. Since the VXLAN and NVGRE Encapsulation sub-TLVs can also optionally carry a router's MAC, a conflict can arise if both the Router's MAC Extended Community and such an Encapsulation sub-TLV are present at the same time but have different values. In case of such a conflict, the information in the Router's MAC Extended Community MUST be used.
[EVPN-Inter-Subnet]ルータのMAC拡張コミュニティを定義します。この拡張コミュニティは、その名前が示すように、広告ルータのMACアドレスを運びます。VXLANおよびNVGREのカプセル化サブTLVもまたルータのMACを携帯することができるので、ルータのMAC拡張コミュニティとそのようなカプセル化サブTLVの両方が同時に存在するが、異なる値を有する場合に競合が生じる可能性がある。このような競合の場合、ルータのMAC拡張コミュニティの情報を使用する必要があります。
The Color Extended Community is a Transitive Opaque Extended Community with the encoding shown in Figure 15.
カラー拡張コミュニティは、図15に示す符号化を伴う推移的な不透明拡張コミュニティです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 (1 octet)| 0x0b (1 octet)| Flags (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Color Extended Community
図15：カラー拡張コミュニティ
The value of the high-order octet of the extended Type field is 0x03, which indicates it is transitive. The value of the low-order octet of the extended Type field for this community is 0x0b. The color value is user defined and configured locally. No flags are defined in this document; this field MUST be set to zero by the originator and ignored by the receiver; the value MUST NOT be changed when propagating this extended community. The Color Value field is encoded as a 4-octet value by the administrator and is outside the scope of this document. For the use of this extended community, please see Section 8.
拡張型フィールドの上位オクテットの値は0x03です。これはそれが推移的であることを示します。このコミュニティの拡張型フィールドの下位オクテットの値は0x0bです。カラー値はユーザー定義およびローカルに設定されています。この文書ではフラグが定義されていません。このフィールドは、発信者によってゼロに設定され、受信者によって無視されなければなりません。この拡張コミュニティを伝播するときに値を変更しないでください。カラー値フィールドは、管理者によって4オクテット値としてエンコードされ、この文書の範囲外です。この拡張コミュニティを使用するには、セクション8をご覧ください。
In certain situations with an IP fabric underlay, one could have a tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker can advertise the IP-in-IP tunnel endpoint address in the Tunnel Egress Endpoint sub-TLV. When the tunnel type of the TLV is IP-in-IP, it will not have a virtual network identifier. However, the tunnel egress endpoint address can be used in identifying the forwarding table to use for making the forwarding decisions to forward the payload.
IPファブリックアンダーレイを使用した特定の状況では、トンネル型IP-IN-IPを使用してトンネルオーバーレイを持つことができます。出口BGPスピーカーは、トンネル出力エンドポイントサブTLVにIP-IN-IPトンネルエンドポイントアドレスをアドバタイズできます。TLVのトンネルタイプがIP IN-IPの場合、仮想ネットワーク識別子はありません。ただし、トンネル出力エンドポイントアドレスは、転送決定を使用してペイロードを転送するための転送テーブルを識別するのに使用できます。
The BGP Tunnel Encapsulation attribute MAY be carried in any BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70 (Ethernet VPN, usually known as EVPN). Use of the Tunnel Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is outside the scope of this document.
BGPトンネルカプセル化属性は、AFI / SAFIが1/1（IPv4ユニキャスト）、2/1（IPv6ユニキャスト）、1/4（IPv4ラベル付きユニキャスト）、2/4（IPv6ラベル付きユニキャスト）で任意のBGPアップデートメッセージで実行できます。）、1/128（VPN-IPv4標識ユニキャスト）、2/128（VPN-IPv6標識ユニキャスト）、または25/70（通常はEVPNとして知られています）。他のAFI / SAFIのBGP更新メッセージにおけるトンネルカプセル化属性の使用は、このドキュメントの範囲外です。
There is no significance to the order in which the TLVs occur within the Tunnel Encapsulation attribute. Multiple TLVs may occur for a given tunnel type; each such TLV is regarded as describing a different tunnel. (This also applies if the Encapsulation Extended Community encoding is used.)
TLVSがトンネルカプセル化属性内で発生する順序には重要はありません。特定のトンネルタイプに対して複数のTLVが発生する可能性があります。そのような各TLVは、異なるトンネルを記述すると見なされる。（カプセル化拡張コミュニティエンコーディングが使用されている場合も適用されます。）
The decision to attach a Tunnel Encapsulation attribute to a given BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs contained in the attribute is also determined by policy.
トンネルカプセル化属性を特定のBGPアップデートに接続するという決定は、ポリシーによって決定されます。属性に含まれているTLVとサブTLVのセットもポリシーによって決まります。
Suppose that:
仮定：
* a given packet P must be forwarded by router R;
* 与えられたパケットPはルータRによって転送されなければなりません。
* the path along which P is to be forwarded is determined by BGP UPDATE U;
* Pが転送されるべき経路は、BGP更新Uによって決定される。
* UPDATE U has a Tunnel Encapsulation attribute, containing at least one TLV that identifies a "feasible tunnel" for packet P. A tunnel is considered feasible if it has the following four properties:
* Update Uは、パケットPの場合は「実行可能トンネル」を識別する少なくとも1つのTLVを含むトンネルカプセル化属性を持っています。トンネルは、次の4つのプロパティがある場合に実行可能と見なされます。
1. The tunnel type is supported (that is, router R knows how to set up tunnels of that type, how to create the encapsulation header for tunnels of that type, etc.).
1. トンネルタイプがサポートされています（つまり、ルータRはそのタイプのトンネルを設定する方法、その型のトンネルのカプセル化ヘッダーの作成方法などを知っています）。
2. The tunnel is of a type that can be used to carry packet P (for example, an MPLS-in-UDP tunnel would not be a feasible tunnel for carrying an IP packet, unless the IP packet can first be encapsulated in a MPLS packet).
2. トンネルはパケットPを搬送するために使用できるタイプのものである（たとえば、IPパケットが最初にMPLSパケットでカプセル化できる限り、IPパケットを搬送するための実行可能なトンネルではないであろう）タイプのものです。。
3. The tunnel is specified in a TLV whose Tunnel Egress Endpoint sub-TLV identifies an IP address that is reachable. The reachability condition is evaluated as per [RFC4271]. If the IP address is reachable via more than one forwarding table, local policy is used to determine which table to use.
3. トンネルは、トンネル出力エンドポイントサブTLVが到達可能なIPアドレスを識別するTLVで指定されています。到達可能性条件は[RFC4271]と同様に評価されます。IPアドレスが複数の転送テーブルを介して到達可能な場合、ローカルポリシーを使用して使用するテーブルを決定します。
4. There is no local policy that prevents the use of the tunnel.
4. トンネルの使用を妨げるローカルポリシーはありません。
Then router R MUST send packet P through one of the feasible tunnels identified in the Tunnel Encapsulation attribute of UPDATE U.
次に、ルータRは、アップデートUのトンネルカプセル化属性で識別されている実行可能トンネルの1つを通してパケットPを送信する必要があります。
If the Tunnel Encapsulation attribute contains several TLVs (that is, if it specifies several feasible tunnels), router R may choose any one of those tunnels, based upon local policy. If any Tunnel TLV contains one or more Color sub-TLVs (Section 3.4.2) and/or the Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be influenced by these sub-TLVs. Many other factors, for example, minimization of encapsulation-header overhead, could also be used to influence selection.
トンネルのカプセル化属性に複数のTLVが含まれている場合（つまり、複数の実行可能なトンネルを指定している場合）、ルータRはローカルポリシーに基づいてそれらのトンネルのいずれかを選択できます。トンネルTLVが1つ以上のカラーサブTLV（セクション3.4.2）および/またはプロトコルタイプサブTLVを含む場合（セクション3.4.1）、トンネルの選択はこれらのサブTLVによって影響を受ける可能性があります。たとえば、カプセル化ヘッダーオーバーヘッドの最小化など、他の多くの要因を使用して選択に影響を与えることもできます。
The reachability to the address of the egress endpoint of the tunnel may change over time, directly impacting the feasibility of the tunnel. A tunnel that is not feasible at some moment may become feasible at a later time when its egress endpoint address is reachable. The router may start using the newly feasible tunnel instead of an existing one. How this decision is made is outside the scope of this document.
トンネルの出口エンドポイントのアドレスへの到達可能性は、時間とともに変化し、トンネルの実現可能性に直接影響を与える可能性があります。いくつかの瞬間に実現不可能なトンネルは、その出力エンドポイントアドレスが到達可能であるときに後で実行可能になる可能性がある。ルータは、既存のものの代わりに新たに実行可能なトンネルを使用し始めることがあります。この決定がなされている方法は、この文書の範囲外です。
Once it is determined to send a packet through the tunnel specified in a particular Tunnel TLV of a particular Tunnel Encapsulation attribute, then the tunnel's egress endpoint address is the IP address contained in the Tunnel Egress Endpoint sub-TLV. If the Tunnel TLV contains a Tunnel Egress Endpoint sub-TLV whose Value field is all zeroes, then the tunnel's egress endpoint is the address of the next hop of the BGP UPDATE containing the Tunnel Encapsulation attribute (that is, the Network Address of Next Hop field of the MP_REACH_NLRI attribute if the encoding of [RFC4760] is in use or the NEXT_HOP attribute otherwise). The address of the tunnel egress endpoint generally appears in a Destination Address field of the encapsulation.
特定のトンネルカプセル化属性の特定のトンネルTLVで指定されたトンネルを介してパケットを送信すると決定されると、トンネルの出力エンドポイントアドレスはトンネル出力エンドポイントサブTLVに含まれるIPアドレスです。トンネルTLVに値フィールドがすべてゼロのトンネル出力エンドポイントサブTLVが含まれている場合、トンネルの出力エンドポイントは、トンネルカプセル化属性（つまり、次のホップのネットワークアドレス）を含むBGPアップデートのネクストホップのアドレスです。[RFC4760]のエンコードが使用中の場合、またはそうでない場合はnext_hop属性がある場合は、MP_REACH_NLRI属性のフィールド。トンネル出力エンドポイントのアドレスは、通常、カプセル化の宛先アドレスフィールドに表示されます。
The full set of procedures for sending a packet through a particular tunnel type to a particular tunnel egress endpoint depends upon the tunnel type and is outside the scope of this document. Note that some tunnel types may require the execution of an explicit tunnel setup protocol before they can be used for carrying data. Other tunnel types may not require any tunnel setup protocol.
特定のトンネルタイプを介してパケットを特定のトンネル出力エンドポイントに送信するための手順のフルセットは、トンネルの種類によって異なり、この文書の範囲外です。一部のトンネルタイプは、データを伝送するために使用する前に明示的トンネル設定プロトコルの実行を必要とする可能性があることに注意してください。他のトンネルタイプはトンネル設定プロトコルを必要としない場合があります。
Sending a packet through a tunnel always requires that the packet be encapsulated, with an encapsulation header that is appropriate for the tunnel type. The contents of the tunnel encapsulation header may be influenced by the Encapsulation sub-TLV. If there is no Encapsulation sub-TLV present, the router transmitting the packet through the tunnel must have a priori knowledge (for example, by provisioning) of how to fill in the various fields in the encapsulation header.
トンネルを介してパケットを送信するには、常にパケットをカプセル化する必要があります。これは、トンネルタイプに適したカプセル化ヘッダーを使用します。トンネルカプセル化ヘッダの内容は、カプセル化サブTLVの影響を受ける可能性がある。存在するカプセル化が存在しない場合、トンネルを介してパケットを送信するルータは、カプセル化ヘッダ内のさまざまなフィールドに記入する方法の先験的な知識（プロビジョニングによって）されている必要があります。
A Tunnel Encapsulation attribute may contain several TLVs that all specify the same tunnel type. Each TLV should be considered as specifying a different tunnel. Two tunnels of the same type may have different Tunnel Egress Endpoint sub-TLVs, different Encapsulation sub-TLVs, etc. Choosing between two such tunnels is a matter of local policy.
トンネルカプセル化属性には、すべて同じトンネルタイプを指定するいくつかのTLVが含まれている可能性があります。各TLVは異なるトンネルを指定すると見なされるべきです。同じタイプの2つのトンネルは、異なるトンネル出力エンドポイントサブTLV、異なるカプセル化サブTLVなどを持つことができます。そのようなトンネルの2つの間で選択することは、ローカルポリシーの問題です。
Once router R has decided to send packet P through a particular tunnel, it encapsulates packet P appropriately and then forwards it according to the route that leads to the tunnel's egress endpoint. This route may itself be a BGP route with a Tunnel Encapsulation attribute. If so, the encapsulated packet is treated as the payload and encapsulated according to the Tunnel Encapsulation attribute of that route. That is, tunnels may be "stacked".
ルータRが特定のトンネルを介してパケットPを送信することにしたら、パケットPを適切にカプセル化してから、トンネルの出力エンドポイントをもたらす経路に従ってそれを転送する。このルートは、それ自体がトンネルカプセル化属性を持つBGPルートである可能性があります。もしそうであれば、カプセル化されたパケットはペイロードとして扱われ、その経路のトンネルのカプセル化属性に従ってカプセル化される。つまり、トンネルは「積み重ね」されている可能性があります。
Notwithstanding anything said in this document, a BGP speaker MAY have local policy that influences the choice of tunnel and the way the encapsulation is formed. A BGP speaker MAY also have a local policy that tells it to ignore the Tunnel Encapsulation attribute entirely or in part. Of course, interoperability issues must be considered when such policies are put into place.
この文書で言われたことにもかかわらず、BGPスピーカーはトンネルの選択に影響を与える地域のポリシーとカプセル化が形成される可能性があります。BGPスピーカーはまた、トンネルのカプセル化属性を完全にまたは部分的に無視するようにそれを指示するローカルポリシーを持つことができます。もちろん、そのようなポリシーが所定の位置に入れると、相互運用性の問題が考慮されなければなりません。
See also Section 13, which provides further specification regarding validation and exception cases.
検証と例外の場合に関するさらなる仕様を提供するセクション13も参照してください。
The presence of the Tunnel Encapsulation attribute affects the BGP best route-selection algorithm. If a route includes the Tunnel Encapsulation attribute, and if that attribute includes no tunnel that is feasible, then that route MUST NOT be considered resolvable for the purposes of the route resolvability condition ([RFC4271], Section 9.1.2.1).
トンネルカプセル化属性の存在はBGP最良のルート選択アルゴリズムに影響します。ルートにトンネルカプセル化属性が含まれている場合、その属性に実行可能なトンネルが含まれていない場合、そのルートはルート解消性状態（[RFC4271]、9.1.2.1）の目的で解決可能と見なされてはなりません。
7.2. Looping, Mutual Recursion, Etc.
7.2. ループ、相互再帰など
Consider a packet destined for address X. Suppose a BGP UPDATE for address prefix X carries a Tunnel Encapsulation attribute that specifies a tunnel egress endpoint of Y, and suppose that a BGP UPDATE for address prefix Y carries a Tunnel Encapsulation attribute that specifies a tunnel egress endpoint of X. It is easy to see that this can have no good outcome. [RFC4271] describes an analogous case as mutually recursive routes.
アドレスX宛のパケットを検討します。アドレスプレフィックスのBGPアップデートがYのトンネル出力エンドポイントを指定するトンネルカプセル化属性を搭載し、アドレスプレフィックスYのBGP更新がトンネル出力を指定するトンネルカプセル化属性を搬送するとします。Xの終点これは良い結果を持たないことがわかりやすいです。[RFC4271]互いに再帰的な経路として類似の場合を説明しています。
This could happen as a result of misconfiguration, either accidental or intentional. It could also happen if the Tunnel Encapsulation attribute were altered by a malicious agent. Implementations should be aware that such an attack will result in unresolvable BGP routes due to the mutually recursive relationship. This document does not specify a maximum number of recursions; that is an implementation-specific matter.
これは、誤った構成、偶然または意図的なものの結果として起こる可能性があります。トンネルカプセル化属性が悪意のあるエージェントによって変更された場合にも発生する可能性があります。そのような攻撃は、相互に再帰的な関係のために不容質のBGPルートをもたらすことに注意する必要があります。この文書は最大再帰数を指定しません。それは実装固有の問題です。
Improper setting (or malicious altering) of the Tunnel Encapsulation attribute could also cause data packets to loop. Suppose a BGP UPDATE for address prefix X carries a Tunnel Encapsulation attribute that specifies a tunnel egress endpoint of Y. Suppose router R receives and processes the advertisement. When router R receives a packet destined for X, it will apply the encapsulation and send the encapsulated packet to Y. Y will decapsulate the packet and forward it further. If Y is further away from X than is router R, it is possible that the path from Y to X will traverse R. This would cause a long-lasting routing loop. The control plane itself cannot detect this situation, though a TTL field in the payload packets would prevent any given packet from looping infinitely.
トンネルカプセル化属性の不適切な設定（または悪意のある変更）は、データパケットをループにする可能性があります。アドレスプレフィックスXのBGPアップデートが、Yのトンネル出力エンドポイントを指定するトンネルカプセル化属性を搬送するとします。ルータRルータRが広告を受信して処理する。ルータRがX宛のパケットを受信すると、カプセル化を適用し、カプセル化されたパケットをYに送信します.Yはパケットをカプセル化してさらに転送します。YがルータRよりもxから離れている場合、yからxへの経路がRを通過することが可能である。これにより、長期的なルーティングループが発生する可能性があります。ペイロードパケット内のTTLフィールドは、与えられたパケットが無限にループするのを妨げるであろうが、コントロールプレーン自体はこの状況を検出することはできません。
During the deployment of techniques described in this document, operators are encouraged to avoid mutually recursive route and/or tunnel dependencies. There is greater potential for such scenarios to arise when the tunnel egress endpoint for a given prefix differs from the address of the next hop for that prefix.
この文書に記載されている技術の展開中、演算子は、相互に再帰的な経路および/またはトンネルの依存関係を回避することを奨励されています。特定のプレフィックスのトンネル出力エンドポイントがその接頭辞の次のホップのアドレスと異なる場合、そのようなシナリオが発生する可能性があります。
Suppose that:
仮定：
* a given packet P must be forwarded by router R1;
* 所与のパケットPはルータR1によって転送されなければならない。
* the path along which P is to be forwarded is determined by BGP UPDATE U1;
* Pが転送されるべき経路はBGP更新U1によって決定される。
* UPDATE U1 does not have a Tunnel Encapsulation attribute;
* Update U1にはトンネルのカプセル化属性がありません。
* the address of the next hop of UPDATE U1 is router R2;
* 更新U1のネクストホップのアドレスはルータR2である。
* the best route to router R2 is a BGP route that was advertised in UPDATE U2; and
* ルータR2への最良のルートは、UPDATE U2でアドバタイズされたBGPルートです。そして
* UPDATE U2 has a Tunnel Encapsulation attribute.
* Update U2にはトンネルのカプセル化属性があります。
Then packet P MUST be sent through one of the tunnels identified in the Tunnel Encapsulation attribute of UPDATE U2. See Section 6 for further details.
次に、更新U2のトンネルカプセル化属性で識別されているトンネルの1つを介してパケットPを送信する必要があります。詳細についてはセクション6を参照してください。
However, suppose that one of the TLVs in U2's Tunnel Encapsulation attribute contains one or more Color sub-TLVs. In that case, packet P MUST NOT be sent through the tunnel contained in that TLV, unless U1 is carrying a Color Extended Community that is identified in one of U2's Color sub-TLVs.
ただし、U2のトンネルカプセル化属性にあるTLVの1つが1つ以上のカラーサブTLVを含むとします。その場合、U1がU2のカラーサブTLVのうちの1つで識別されているカラー拡張コミュニティを運ぶことがない限り、パケットPはそのTLVに含まれるトンネルを介して送信されてはならない。
The procedures in this section presuppose that U1's address of the next hop resolves to a BGP route, and that U2's next hop resolves (perhaps after further recursion) to a non-BGP route.
このセクションの手順では、次のホップのU1のアドレスがBGPルートに解決され、U2のネクストホップが（おそらくさらに再帰の後）を非BGPルートに解決することを前提としています。
9. Use of Virtual Network Identifiers and Embedded Labels When Imposing a Tunnel Encapsulation
9. トンネルカプセル化を課すときの仮想ネットワーク識別子と埋め込みラベルの使用
If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV, then when sending a packet through that tunnel, the procedures of Section 3.6 are applied before the procedures of this section.
トンネルを指定するTLVにMPLSラベルスタックSUB-TLVが含まれている場合、そのトンネルを介してパケットを送信するときは、セクション3.6の手順がこのセクションの手順の前に適用されます。
If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the procedures of Section 3.7 are applied before the procedures of this section. If the TLV also contains an MPLS Label Stack sub-TLV, the procedures of Section 3.6 are applied before the procedures of Section 3.7.
トンネルを指定するTLVに接頭辞SIDサブTLVが含まれている場合、このセクションの手順の前にセクション3.7の手順が適用されます。TLVにMPLSラベルスタックSUB-TLVが含まれている場合、セクション3.7の手順の前にセクション3.6の手順が適用されます。
If a Tunnel Encapsulation attribute is attached to an UPDATE of a labeled address family, there will be one or more labels specified in the UPDATE's NLRI. When a packet is sent through a tunnel specified in one of the attribute's TLVs, and that tunnel type does not contain a Virtual Network Identifier field, the label or labels from the NLRI are pushed on the packet's label stack. The resulting MPLS packet is then further encapsulated, as specified by the TLV.
トンネルカプセル化属性がラベル付きアドレスファミリの更新に添付されている場合、アップデートのNLRIに1つ以上のラベルが指定されています。パケットが属性のTLVの1つで指定されたトンネルを介して送信され、そのトンネルタイプに仮想ネットワーク識別子フィールドが含まれていない場合、NLRIのラベルまたはラベルはパケットのラベルスタックにプッシュされます。結果として得られるMPLSパケットは、TLVによって指定されているように、さらにカプセル化されます。
Two of the tunnel types that can be specified in a Tunnel Encapsulation TLV have Virtual Network Identifier fields in their encapsulation headers. In the VXLAN encapsulation, this field is called the VNI (VXLAN Network Identifier) field; in the NVGRE encapsulation, this field is called the VSID (Virtual Subnet Identifier) field.
トンネルカプセル化TLVで指定できるトンネルタイプの2つは、カプセル化ヘッダーに仮想ネットワーク識別子フィールドを持ちます。VXLANカプセル化では、このフィールドはVNI（VXLANネットワークID）フィールドと呼ばれます。NVGREカプセル化では、このフィールドはVSID（仮想サブネットID）フィールドと呼ばれます。
When one of these tunnel encapsulations is imposed on a packet, the setting of the Virtual Network Identifier field in the encapsulation header depends upon the contents of the Encapsulation sub-TLV (if one is present). When the Tunnel Encapsulation attribute is being carried in a BGP UPDATE of a labeled address family, the setting of the Virtual Network Identifier field also depends upon the contents of the Embedded Label Handling sub-TLV (if present).
これらのトンネルカプセル化のうちの1つがパケットに課されると、カプセル化ヘッダ内の仮想ネットワーク識別子フィールドの設定は、カプセル化サブTLVの内容（ある場合）に依存する。トンネルカプセル化属性がラベル付きアドレスファミリのBGPアップデートで実行されている場合、仮想ネットワークIDフィールドの設定は埋め込みラベル処理サブTLVの内容にも依存します（存在する場合）。
This section specifies the procedures for choosing the value to set in the Virtual Network Identifier field of the encapsulation header. These procedures apply only when the tunnel type is VXLAN or NVGRE.
このセクションでは、カプセル化ヘッダーの[仮想ネットワークID]フィールドに設定する値を選択するための手順を指定します。これらの手順は、トンネルタイプがVXLANまたはNVGREの場合にのみ適用されます。
This subsection applies when:
このサブセクションは次のように適用されます。
* the Tunnel Encapsulation attribute is carried in a BGP UPDATE of an unlabeled address family,
* トンネルカプセル化属性は、非標識アドレスファミリのBGP更新で行われます。
* at least one of the attribute's TLVs identifies a tunnel type that uses a virtual network identifier, and
* 属性のTLVのうちの少なくとも1つは、仮想ネットワーク識別子を使用するトンネルタイプを識別します。
* it has been determined to send a packet through one of those tunnels.
* これらのトンネルの1つを通してパケットを送信することが決定されました。
If the TLV identifying the tunnel contains an Encapsulation sub-TLV whose V bit is set to 1, the Virtual Network Identifier field of the encapsulation header is set to the value of the Virtual Network Identifier field of the Encapsulation sub-TLV.
トンネルを識別するTLVがVビットが1に設定されているカプセル化サブTLVを含む場合、カプセル化ヘッダの仮想ネットワーク識別子フィールドは、カプセル化サブTLVの仮想ネットワーク識別子フィールドの値に設定される。
Otherwise, the Virtual Network Identifier field of the encapsulation header is set to a configured value; if there is no configured value, the tunnel cannot be used.
それ以外の場合、カプセル化ヘッダの仮想ネットワーク識別子フィールドは設定値に設定される。設定値がない場合は、トンネルを使用できません。
This subsection applies when:
このサブセクションは次のように適用されます。
* the Tunnel Encapsulation attribute is carried in a BGP UPDATE of a labeled address family,
* トンネルのカプセル化属性は、ラベル付きアドレスファミリのBGPアップデートで実行されます。
* at least one of the attribute's TLVs identifies a tunnel type that uses a virtual network identifier, and
* 属性のTLVのうちの少なくとも1つは、仮想ネットワーク識別子を使用するトンネルタイプを識別します。
* it has been determined to send a packet through one of those tunnels.
* これらのトンネルの1つを通してパケットを送信することが決定されました。
If the TLV identifying the tunnel contains an Encapsulation sub-TLV whose V bit is set to 1, the Virtual Network Identifier field of the encapsulation header is set to the value of the Virtual Network Identifier field of the Encapsulation sub-TLV. However, the Embedded Label Handling sub-TLV will determine label processing as described below.
トンネルを識別するTLVがVビットが1に設定されているカプセル化サブTLVを含む場合、カプセル化ヘッダの仮想ネットワーク識別子フィールドは、カプセル化サブTLVの仮想ネットワーク識別子フィールドの値に設定される。しかしながら、埋め込まれたラベル処理サブTLVは、以下のようなラベル処理を決定するであろう。
* If the TLV contains an Embedded Label Handling sub-TLV whose value is 1, the embedded label (from the NLRI of the route that is carrying the Tunnel Encapsulation attribute) appears at the top of the MPLS label stack in the encapsulation payload.
* TLVに値が1の埋め込みラベル処理を含む場合、（トンネルのカプセル化属性を搬送しているルートのNLRIから）埋め込みラベルは、カプセル化ペイロードのMPLSラベルスタックの上部に表示されます。
* If the TLV does not contain an Embedded Label Handling sub-TLV, or it contains an Embedded Label Handling sub-TLV whose value is 2, the embedded label is ignored entirely.
* TLVに埋め込まれたラベル処理が含まれていない場合、またはその値が2の埋め込みラベル処理サブTLVが含まれている場合、埋め込みラベルは完全に無視されます。
If the TLV identifying the tunnel does not contain an Encapsulation sub-TLV whose V bit is set to 1, the Virtual Network Identifier field of the encapsulation header is set as follows:
トンネルを識別するTLVにVビットが1に設定されているカプセル化サブTLVが含まれていない場合、カプセル化ヘッダーの仮想ネットワークIDフィールドは次のように設定されています。
* If the TLV contains an Embedded Label Handling sub-TLV whose value is 1, then the Virtual Network Identifier field of the encapsulation header is set to a configured value.
* TLVに値が1の埋め込みラベル処理サブTLVが含まれている場合、カプセル化ヘッダーの仮想ネットワークIDフィールドは設定値に設定されます。
If there is no configured value, the tunnel cannot be used.
設定値がない場合は、トンネルを使用できません。
The embedded label (from the NLRI of the route that is carrying the Tunnel Encapsulation attribute) appears at the top of the MPLS label stack in the encapsulation payload.
埋め込みラベル（トンネルカプセル化属性を搭載しているルートのNLRI）は、カプセル化ペイロードのMPLSラベルスタックの上部に表示されます。
* If the TLV does not contain an Embedded Label Handling sub-TLV, or if it contains an Embedded Label Handling sub-TLV whose value is 2, the embedded label is copied into the lower 3 octets of the Virtual Network Identifier field of the encapsulation header.
* TLVに埋め込みラベル処理が含まれていない場合、またはその値が2の埋め込みラベル処理サブTLVが含まれている場合、埋め込みラベルはカプセル化ヘッダーの仮想ネットワークIDフィールドの下位3オクテットにコピーされます。。
In this case, the payload may or may not contain an MPLS label stack, depending upon other factors. If the payload does contain an MPLS label stack, the embedded label does not appear in that stack.
この場合、ペイロードは他の要因に応じてMPLSラベルスタックを含んでも含まなくてもよい。ペイロードにMPLSラベルスタックが含まれている場合、埋め込みラベルはそのスタックに表示されません。
In a given UPDATE of a labeled address family, the label embedded in the NLRI is generally a label that is meaningful only to the router represented by the address of the next hop. Certain of the procedures of Sections 9.2.2.1 or 9.2.2.2 cause the embedded label to be carried by a data packet to the router whose address appears in the Tunnel Egress Endpoint sub-TLV. If the Tunnel Egress Endpoint sub-TLV does not identify the same router represented by the address of the next hop, sending the packet through the tunnel may cause the label to be misinterpreted at the tunnel's egress endpoint. This may cause misdelivery of the packet. Avoidance of this unfortunate outcome is a matter of network planning and design and is outside the scope of this document.
ラベル付きアドレスファミリの特定の更新プログラムでは、NLRIに埋め込まれたラベルは一般に、ネクストホップのアドレスによって表されるルータにのみ意味があるラベルです。セクション9.2.2.1または9.2.2.2のうち、セクション9.2.2.1または9.2.2.2の一定の手順で、アドレスがトンネル出力エンドポイントサブTLVに表示されているルータにデータパケットによって伝送されることがあります。トンネル出力エンドポイントサブTLVがネクストホップのアドレスによって表される同じルータを識別しない場合、トンネルを介してパケットを送信すると、トンネルの出力エンドポイントでラベルが誤って解釈されることがあります。これはパケットの誤配信を引き起こす可能性があります。この不幸な結果の回避は、ネットワーク計画と設計の問題であり、この文書の範囲外です。
Note that if the Tunnel Encapsulation attribute is attached to a VPN-IP route [RFC4364], if Inter-AS "option b" (see Section 10 of [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV contains an IP address that is not in the same AS as the router receiving the route, it is very likely that the embedded label has been changed. Therefore, use of the Tunnel Encapsulation attribute in an "Inter-AS option b" scenario is not recommended.
トンネルのカプセル化属性がVPN-IPルート（RFC4364]に添付されている場合は、「オプションB」の場合は[RFC4364]（[RFC4364]のセクション10を参照）が使用されており、トンネル出力エンドポイントサブTLVが含まれている場合ルートを受信したルータと同じではないIPアドレスは、埋め込みラベルが変更された可能性が非常に高いです。したがって、「Inter-AsオプションB」シナリオでトンネルカプセル化属性を使用することはお勧めできません。
Other documents may define other ways to signal tunnel information in BGP. For example, [RFC6514] defines the "P-Multicast Service Interface Tunnel" (PMSI Tunnel) attribute. In this specification, we do not consider the effects of advertising the Tunnel Encapsulation attribute in conjunction with other forms of signaling tunnels. Any document specifying such joint use MUST provide details as to how interactions should be handled.
他の文書は、BGP内のトンネル情報をシグナリングするための他の方法を定義することができる。たとえば、[RFC6514]は「Pマルチキャストサービスインタフェーストンネル」（PMSIトンネル）属性を定義します。本明細書では、トンネルカプセル化属性を他の形式のシグナリングトンネルと組み合わせて広告するという効果を考慮していません。そのような共同使用を指定する文書は、対話の処理方法について詳細を提供する必要があります。
The Tunnel Encapsulation attribute is defined as a transitive attribute, so that it may be passed along by BGP speakers that do not recognize it. However, the Tunnel Encapsulation attribute MUST be used only within a well-defined scope, for example, within a set of ASes that belong to a single administrative entity. If the attribute is distributed beyond its intended scope, packets may be sent through tunnels in a manner that is not intended.
トンネルカプセル化属性は推移的属性として定義されているので、認識されないBGPスピーカーによって渡される可能性があります。ただし、トンネルのカプセル化属性は、単一の管理エンティティに属するASSのセット内で、明確に定義されたスコープ内でのみ使用する必要があります。属性がその意図された範囲を超えて分布している場合、パケットは意図されていない方法でトンネルを介して送信されてもよい。
To prevent the Tunnel Encapsulation attribute from being distributed beyond its intended scope, any BGP speaker that understands the attribute MUST be able to filter the attribute from incoming BGP UPDATE messages. When the attribute is filtered from an incoming UPDATE, the attribute is neither processed nor distributed. This filtering SHOULD be possible on a per-BGP-session basis; finer granularities (for example, per route and/or per attribute TLV) MAY be supported. For each external BGP (EBGP) session, filtering of the attribute on incoming UPDATEs MUST be enabled by default.
トンネルのカプセル化属性がその意図されたスコープを超えて配布されないようにするために、属性を理解しているBGPスピーカーは、入ってくるBGP更新メッセージから属性をフィルタリングできる必要があります。属性が着信更新からフィルタリングされると、属性は処理も分散されていません。このフィルタリングは、BGPごとのセッションごとに可能です。細かい粒度（たとえば、経路ごとおよび/または属性TLVあたり）サポートされている可能性があります。各外部BGP（EBGP）セッションについて、着信更新時の属性のフィルタリングはデフォルトで有効にする必要があります。
In addition, any BGP speaker that understands the attribute MUST be able to filter the attribute from outgoing BGP UPDATE messages. This filtering SHOULD be possible on a per-BGP-session basis. For each EBGP session, filtering of the attribute on outgoing UPDATEs MUST be enabled by default.
さらに、属性を理解しているBGPスピーカーは、属性を発信BGP更新メッセージからフィルタリングできなければなりません。このフィルタリングは、BGPごとのセッションごとに可能です。EBGPセッションごとに、発信アップデート上の属性のフィルタリングはデフォルトで有効にする必要があります。
Since the Encapsulation Extended Community provides a subset of the functionality of the Tunnel Encapsulation attribute, these considerations apply equally in its case:
カプセル化拡張コミュニティは、トンネルのカプセル化属性の機能のサブセットを提供しているため、これらの考慮事項はその場合も同様に適用されます。
* Any BGP speaker that understands it MUST be able to filter it from incoming BGP UPDATE messages.
* それを理解しているBGPスピーカーは、入ってくるBGP更新メッセージからフィルタリングできなければなりません。
* It MUST be possible to filter the Encapsulation Extended Community from outgoing messages.
* カプセル化拡張コミュニティを発信メッセージからフィルタリングすることは可能でなければなりません。
* In both cases, this filtering MUST be enabled by default for EBGP sessions.
* どちらの場合も、このフィルタリングはEBGPセッションのデフォルトで有効にする必要があります。
A potential operational difficulty arises when tunnels are used, if the size of packets entering the tunnel exceeds the maximum transmission unit (MTU) the tunnel is capable of supporting. This difficulty can be exacerbated by stacking multiple tunnels, since each stacked tunnel header further reduces the supportable MTU. This issue is long-standing and well-known. The tunnel signaling provided in this specification does nothing to address this issue, nor to aggravate it (except insofar as it may further increase the popularity of tunneling).
トンネルに入るパケットのサイズが最大伝送ユニット（MTU）を超えると、トンネルがサポートできる最大伝送ユニット（MTU）を超える場合、潜在的な動作困難が発生する。各積層トンネルヘッダは支持可能なMTUをさらに縮小するので、この困難さは複数のトンネルを積み重ねることによって悪化することができる。この問題は長年かつ有名です。この仕様で提供されているトンネルシグナリングは、この問題に対処したり、それを悪化させることもありません（トンネリングの人気をさらに高める可能性があるため）。
The Tunnel Encapsulation attribute is a sequence of TLVs, each of which is a sequence of sub-TLVs. The final octet of a TLV is determined by its Length field. Similarly, the final octet of a sub-TLV is determined by its Length field. The final octet of a TLV MUST also be the final octet of its final sub-TLV. If this is not the case, the TLV MUST be considered to be malformed, and the "Treat-as-withdraw" procedure of [RFC7606] is applied.
トンネルカプセル化属性は一連のTLVであり、その各々はサブTLVのシーケンスです。TLVの最後のオクテットはその長さフィールドによって決まります。同様に、サブTLVの最終オクテットはその長さフィールドによって決まります。TLVの最後のオクテットは、その最終的なサブTLVの最後のオクテットでもなければなりません。そうでない場合は、TLVが不正なことを考慮する必要があり、[RFC7606]の「扱いAS撤回」手順が適用されます。
If a Tunnel Encapsulation attribute does not have any valid TLVs, or it does not have the transitive bit set, the "Treat-as-withdraw" procedure of [RFC7606] is applied.
トンネルカプセル化属性に有効なTLVがない場合、またはトランジスタビットセットがない場合は、[RFC7606]の「扱いAS撤回」手順が適用されます。
If a Tunnel Encapsulation attribute can be parsed correctly but contains a TLV whose tunnel type is not recognized by a particular BGP speaker, that BGP speaker MUST NOT consider the attribute to be malformed. Rather, it MUST interpret the attribute as if that TLV had not been present. If the route carrying the Tunnel Encapsulation attribute is propagated with the attribute, the unrecognized TLV MUST remain in the attribute.
トンネルのカプセル化属性を正しく解析できるが、トンネルタイプが特定のBGPスピーカーによって認識されないTLVを含む場合、そのBGPスピーカーは不正な形式の属性を検討してはいけません。むしろ、TLVが存在しなかったかのように属性を解釈する必要があります。トンネルカプセル化属性を担う経路が属性と伝播されている場合、認識されないTLVは属性に残る必要があります。
The following sub-TLVs defined in this document MUST NOT occur more than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed below), Encapsulation, DS, UDP Destination Port, Embedded Label Handling, MPLS Label Stack, and Prefix-SID. If a Tunnel TLV has more than one of any of these sub-TLVs, all but the first occurrence of each such sub-TLV type MUST be disregarded. However, the Tunnel TLV containing them MUST NOT be considered to be malformed, and all the sub-TLVs MUST be propagated if the route carrying the Tunnel Encapsulation attribute is propagated.
このドキュメントで定義されている次のサブTLVは、特定のトンネルTLV：トンネル出力エンドポイント（後述）、カプセル化、DS、UDP宛先ポート、組み込みラベル処理、MPLSラベルスタック、およびPREFIX-SIDに複数回発生してはなりません。トンネルTLVがこれらのサブTLVのいずれかを複数持つ場合、そのような各SUB-TLVタイプの最初の出現はすべて無視されなければなりません。ただし、それらを含むトンネルTLVは不正な形式であると見なされてはならず、トンネルカプセル化属性を伝送する経路が伝播されている場合はすべてのサブTLVを伝播する必要があります。
The following sub-TLVs defined in this document may appear zero or more times in a given Tunnel TLV: Protocol Type and Color. Each occurrence of such sub-TLVs is meaningful. For example, the Color sub-TLV may appear multiple times to assign multiple colors to a tunnel.
この文書で定義されている次のSUB-TLVは、特定のトンネルTLVでは0回以上表示されます。プロトコルの種類と色。そのようなサブTLVのそれぞれの発生は意味があります。たとえば、カラーサブTLVは、トンネルに複数の色を割り当てるために複数回現れることがあります。
If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that is not recognized by a particular BGP speaker, the BGP speaker MUST process that TLV as if the unrecognized sub-TLV had not been present. If the route carrying the Tunnel Encapsulation attribute is propagated with the attribute, the unrecognized sub-TLV MUST remain in the attribute.
トンネルカプセル化属性のTLVに特定のBGPスピーカーによって認識されないサブTLVが含まれている場合、BGPスピーカーは、認識されていないサブTLVが存在していないかのようにそのTLVを処理しなければなりません。トンネルカプセル化属性を担う経路が属性と伝播されている場合、認識されていないサブTLVは属性に残る必要があります。
In general, if a TLV contains a sub-TLV that is malformed, the sub-TLV MUST be treated as if it were an unrecognized sub-TLV. There is one exception to this rule: if a TLV contains a malformed Tunnel Egress Endpoint sub-TLV (as defined in Section 3.1), the entire TLV MUST be ignored and MUST be removed from the Tunnel Encapsulation attribute before the route carrying that attribute is distributed.
一般に、TLVが不正な形式のサブTLVを含む場合、SUB-TLVは認識されていないサブTLVであるかのように扱われなければなりません。この規則には1つの例外があります.TLVに（セクション3.1で定義されているように）Malformed Tunnelの出力エンドポイントサブTLVが含まれている場合、TLV全体は無視され、その属性を持つルートがあるルートがある前にトンネルのカプセル化属性から削除する必要があります。配布されました。
Within a Tunnel Encapsulation attribute that is carried by a BGP UPDATE whose AFI/SAFI is one of those explicitly listed in the first paragraph of Section 6, a TLV that does not contain exactly one Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a malformed Tunnel Egress Endpoint sub-TLV.
AFI / SAFIがセクション6の最初の段落に明示的にリストされているものの1つのBGPアップデートによって運ばれるトンネルカプセル化属性内で、正確に1つのトンネル出力エンドポイントサブTLVを含まないTLVは、そのように扱われなければなりません。不正なトンネル出力エンドポイントサブTLVを含んでいました。
A TLV identifying a particular tunnel type may contain a sub-TLV that is meaningless for that tunnel type. For example, perhaps the TLV contains a UDP Destination Port sub-TLV, but the identified tunnel type does not use UDP encapsulation at all, or a tunnel of the form "X-in-Y" contains a Protocol Type sub-TLV that specifies something other than "X". Sub-TLVs of this sort MUST be disregarded. That is, they MUST NOT affect the creation of the encapsulation header. However, the sub-TLV MUST NOT be considered to be malformed and MUST NOT be removed from the TLV before the route carrying the Tunnel Encapsulation attribute is distributed. An implementation MAY log a message when it encounters such a sub-TLV.
特定のトンネルタイプを識別するTLVは、そのトンネルタイプに対して無意味なサブTLVを含み得る。たとえば、TLVにはUDP宛先ポートサブTLVが含まれていますが、識別されたトンネルタイプはUDPカプセル化をまったく使用しないか、または "x-in-y"のトンネルには、指定されたプロトコルタイプのサブTLVが含まれています。「X」以外の何か。このソートのサブTLVは無視されなければなりません。つまり、カプセル化ヘッダーの作成には影響しません。ただし、SUB-TLVは不正な形式であると見なされてはならず、トンネルのカプセル化属性を担う経路が配布される前にTLVから削除しないでください。実装は、そのようなサブTLVに遭遇したときにメッセージを記録することができる。
IANA has made the updates described in the following subsections. All registration procedures listed are per their definitions in [RFC8126].
IANAは以下のサブセクションに記載されている更新を行った。リストされているすべての登録手続きは、[RFC8126]の定義ごとです。
Because this document obsoletes RFC 5512, IANA has updated references to RFC 5512 to point to this document in the following registries:
この文書はRFC 5512を廃止するため、IANAは次のレジストリでこのドキュメントを指すようにRFC 5512への参照を更新しました。
* "Border Gateway Protocol (BGP) Extended Communities" registry [IANA-BGP-EXT-COMM]
* 「BORDERゲートウェイプロトコル（BGP）拡張コミュニティ」レジストリ[IANA-BGP-EXT-COMM]
* "Border Gateway Protocol (BGP) Parameters" registry [IANA-BGP-PARAMS]
* 「ボーダーゲートウェイプロトコル（BGP）パラメータ」レジストリ[IANA-BGP-PARAMS]
* "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry [IANA-BGP-TUNNEL-ENCAP]
* 「ボーダーゲートウェイプロトコル（BGP）トンネルカプセル化」レジストリ[IANA-BGP-TUNNEL-ENCAP]
* "Subsequent Address Family Identifiers (SAFI) Parameters" registry [IANA-SAFI]
* 「その後のアドレスファミリ識別子（SAFI）パラメータ」レジストリ[IANA-SAFI]
Since this document obsoletes RFC 5566, the code points assigned by that RFC are similarly obsoleted. Specifically, the following code points have been marked as deprecated.
この文書はRFC 5566を廃止するので、そのRFCによって割り当てられたコードポイントも同様に廃止される。具体的には、以下のコードポイントが推奨されていないとマークされています。
In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry [IANA-BGP-TUNNEL-ENCAP]:
「BGPトンネルカプセル化属性トンネルタイプ」レジストリ[IANA-BGP-TUNNEL-ENCAP]では、次のようにします。
+=======+==========================================================+
| Value | Name |
+=======+==========================================================+
| 3 | Transmit tunnel endpoint (DEPRECATED) |
+-------+----------------------------------------------------------+
| 4 | IPsec in Tunnel-mode (DEPRECATED) |
+-------+----------------------------------------------------------+
| 5 | IP in IP tunnel with IPsec Transport Mode (DEPRECATED) |
+-------+----------------------------------------------------------+
| 6 | MPLS-in-IP tunnel with IPsec Transport Mode (DEPRECATED) |
+-------+----------------------------------------------------------+
Table 1
表1
And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry [IANA-BGP-TUNNEL-ENCAP]:
そして、「BGPトンネルカプセル化属性サブTLVS」レジストリ[IANA-BGP-TUNNEL-ENCAP]：
+=======+=========================================+
| Value | Name |
+=======+=========================================+
| 3 | IPsec Tunnel Authenticator (DEPRECATED) |
+-------+-----------------------------------------+
Table 2
表2.
IANA has created a new registry grouping named "Border Gateway Protocol (BGP) Tunnel Encapsulation" [IANA-BGP-TUNNEL-ENCAP].
IANAは、「BORDERゲートウェイプロトコル（BGP）トンネルカプセル化」[IANA-BGP-TUNNEL-ENCAP]という名前の新しいレジストリグループ化を作成しました。
IANA has relocated the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry to be under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP].
IANAは、「BGPトンネルカプセル化属性トンネルタイプ」レジストリを「BORDWAING）トンネルカプセル化」グループ「IANA-BGP-TUNNEL-ENCAP」に基づいて再配置しました。
IANA has modified the "SAFI Values" registry [IANA-SAFI] to indicate that the Encapsulation SAFI (value 7) has been obsoleted. This document is listed as the reference for this change.
IANAは、カプセル化SAFI（値7）が廃止されていることを示すために、「SAFI値」レジストリ[IANA-SAFI]を変更しました。この文書はこの変更の参照としてリストされています。
IANA has relocated the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry to be under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP].
IANAは、「BGP Tunnel Encapsulation属性サブTLVS」レジストリを「Border Gateway Protocol（BGP）トンネルカプセル化」グループ化[IANA-BGP-TUNNEL-ENCAP]に移動しました。
IANA has included the following note to the registry:
IANAには、レジストリに次のメモが含まれています。
| If the Sub-TLV Type is in the range from 0 to 127 (inclusive), the
| Sub-TLV Length field contains one octet. If the Sub-TLV Type is
| in the range from 128 to 255 (inclusive), the Sub-TLV Length field
| contains two octets.
IANA has updated the registration procedures of the registry to the following:
IANAはレジストリの登録手順を次のように更新しました。
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 1-63 | Standards Action |
+---------+-------------------------+
| 64-125 | First Come First Served |
+---------+-------------------------+
| 126-127 | Experimental Use |
+---------+-------------------------+
| 128-191 | Standards Action |
+---------+-------------------------+
| 192-252 | First Come First Served |
+---------+-------------------------+
| 253-254 | Experimental Use |
+---------+-------------------------+
Table 3
表3.
IANA has added the following entries to this registry:
IANAはこのレジストリに次のエントリを追加しました：
+=======+=========================+===========+
| Value | Description | Reference |
+=======+=========================+===========+
| 0 | Reserved | RFC 9012 |
+-------+-------------------------+-----------+
| 6 | Tunnel Egress Endpoint | RFC 9012 |
+-------+-------------------------+-----------+
| 7 | DS Field | RFC 9012 |
+-------+-------------------------+-----------+
| 8 | UDP Destination Port | RFC 9012 |
+-------+-------------------------+-----------+
| 9 | Embedded Label Handling | RFC 9012 |
+-------+-------------------------+-----------+
| 10 | MPLS Label Stack | RFC 9012 |
+-------+-------------------------+-----------+
| 11 | Prefix-SID | RFC 9012 |
+-------+-------------------------+-----------+
| 255 | Reserved | RFC 9012 |
+-------+-------------------------+-----------+
Table 4
表4.
IANA has created a registry named "Flags Field of VXLAN Encapsulation Sub-TLVs" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP]. The registration policy for this registry is "Standards Action". The minimum possible value is 0, and the maximum is 7.
IANAは、「BORDEゲートウェイプロトコル（BGP）トンネルカプセル化」の「BGP）トンネルカプセル化」の「IANA-BGP-TUNNEL-ENCAP」の下にある「Flagsフィールド」というレジストリを作成しました。このレジストリの登録ポリシーは「標準アクション」です。可能な最小値は0で、最大値は7です。
The initial values for this new registry are indicated in Table 5.
この新しいレジストリの初期値は表5に示されています。
+==============+=================+===========+
| Bit Position | Description | Reference |
+==============+=================+===========+
| 0 | V (VN-ID) | RFC 9012 |
+--------------+-----------------+-----------+
| 1 | M (MAC Address) | RFC 9012 |
+--------------+-----------------+-----------+
Table 5
表5.
IANA has created a registry named "Flags Field of NVGRE Encapsulation Sub-TLVs" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP]. The registration policy for this registry is "Standards Action". The minimum possible value is 0, and the maximum is 7.
IANAは、「BDREゲートウェイプロトコル（BGP）トンネルカプセル化」グループのグループ化[IANA-BGP-TUNNEL-ENCAP]の下にあるNVGREカプセル化サブTLVSの「FLAGSフィールド」というレジストリを作成しました。このレジストリの登録ポリシーは「標準アクション」です。可能な最小値は0で、最大値は7です。
The initial values for this new registry are indicated in Table 6.
この新しいレジストリの初期値は表6に示されています。
+==============+=================+===========+
| Bit Position | Description | Reference |
+==============+=================+===========+
| 0 | V (VN-ID) | RFC 9012 |
+--------------+-----------------+-----------+
| 1 | M (MAC Address) | RFC 9012 |
+--------------+-----------------+-----------+
Table 6
表6.
IANA has created a registry named "Embedded Label Handling Sub-TLVs" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP]. The registration policy for this registry is "Standards Action". The minimum possible value is 0, and the maximum is 255.
IANAは、「BORDEDゲートウェイプロトコル（BGP）トンネルカプセル化」グループのグループ化[IANA-BGP-TUNNEL-ENCAP]の下に、「埋め込みラベル処理サブTLV」というレジストリを作成しました。このレジストリの登録ポリシーは「標準アクション」です。可能な限り最小値は0で、最大値は255です。
The initial values for this new registry are indicated in Table 7.
この新しいレジストリの初期値は表7に示されています。
+=======+=====================================+===========+
| Value | Description | Reference |
+=======+=====================================+===========+
| 0 | Reserved | RFC 9012 |
+-------+-------------------------------------+-----------+
| 1 | Payload of MPLS with embedded label | RFC 9012 |
+-------+-------------------------------------+-----------+
| 2 | No embedded label in payload | RFC 9012 |
+-------+-------------------------------------+-----------+
Table 7
表7.
IANA has created a registry named "Color Extended Community Flags" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP]. The registration policy for this registry is "Standards Action". The minimum possible value is 0, and the maximum is 15.
IANAは、「ボーダーゲートウェイプロトコル（BGP）トンネルカプセル化」の下に「カラー拡張コミュニティフラグ」という名前のレジストリを作成しました[IANA-BGP-TUNNEL-ENCAP]。このレジストリの登録ポリシーは「標準アクション」です。可能な最小値は0で、最大値は15です。
This new registry contains columns for "Bit Position", "Description", and "Reference". No values have currently been registered.
この新しいレジストリには、「ビット位置」、「説明」、「参照」の列が含まれています。現在登録されていません。
As Section 11 discusses, it is intended that the Tunnel Encapsulation attribute be used only within a well-defined scope, for example, within a set of ASes that belong to a single administrative entity. As long as the filtering mechanisms discussed in that section are applied diligently, an attacker outside the scope would not be able to use the Tunnel Encapsulation attribute in an attack. This leaves open the questions of attackers within the scope (for example, a compromised router) and failures in filtering that allow an external attack to succeed.
セクション11は説明すると、トンネルカプセル化属性は、例えば、単一の管理エンティティに属する一連のASS内で、明確に定義されたスコープ内でのみ使用されることが意図されている。そのセクションで説明されているフィルタリングメカニズムが熱心に適用されている限り、範囲外の攻撃者は攻撃でトンネルのカプセル化属性を使用することはできません。この葉は、範囲内の攻撃者（たとえば、侵入先のルータなど）と外部の攻撃を成功させるためのフィルタリングの失敗の質問を開きます。
As [RFC4272] discusses, BGP is vulnerable to traffic-diversion attacks. The Tunnel Encapsulation attribute adds a new means by which an attacker could cause traffic to be diverted from its normal path, especially when the Tunnel Egress Endpoint sub-TLV is used. Such an attack would differ from pre-existing vulnerabilities in that traffic could be tunneled to a distant target across intervening network infrastructure, allowing an attack to potentially succeed more easily, since less infrastructure would have to be subverted. Potential consequences include "hijacking" of traffic (insertion of an undesired node in the path, which allows for inspection or modification of traffic, or avoidance of security controls) or denial of service (directing traffic to a node that doesn't desire to receive it).
[RFC4272]について説明すると、BGPはトラフィック転換攻撃に対して脆弱です。トンネルカプセル化属性は、特にトンネル出力エンドポイントサブTLVが使用されている場合に、攻撃者がその通常のパスからトラフィックを転送させることができる新しい手段を追加します。そのような攻撃は、そのトラフィックが介在するネットワークインフラストラクチャを介して遠い目標にトンネリングされる可能性があるという事前の脆弱性とは異なり、インフラストラクチャの減少が少ないので、攻撃をより容易に成功させる可能性があります。潜在的な結果には、トラフィックの「ハイジャック」（パス内の望ましくないノードの挿入、トラフィックの検査や変更、セキュリティコントロールの回避）またはサービス拒否（受信に望まないノードへの転送を指示する）が含まれます。それ）。
In order to further mitigate the risk of diversion of traffic from its intended destination, Section 3.1.1 provides an optional procedure to check that the destination given in a Tunnel Egress Endpoint sub-TLV is within the AS that was the source of the route. One then has some level of assurance that the tunneled traffic is going to the same destination AS that it would have gone to had the Tunnel Encapsulation attribute not been present. As RFC 4272 discusses, it's possible for an attacker to announce an inaccurate AS_PATH; therefore, an attacker with the ability to inject a Tunnel Egress Endpoint sub-TLV could equally craft an AS_PATH that would pass the validation procedures of Section 3.1.1. BGP origin validation [RFC6811] and BGPsec [RFC8205] provide means to increase assurance that the origins being validated have not been falsified.
意図された目的地からのトラフィックの転送のリスクをさらに軽減するために、セクション3.1.1は、トンネル出力エンドポイントサブTLVで指定された宛先がルートのソースであるAS以内にあることを確認するためのオプションの手順を示しています。その後、トンネルトラフィックがトンネルカプセル化属性が存在していなかったのと同じ宛先になると、トンネルトラフィックが同じ宛先になるという保証がいくつかあります。RFC 4272が説明すると、攻撃者が不正確なAS_PATHを発表することが可能です。したがって、トンネル出力エンドポイントSUB-TLVを注入する機能を持つ攻撃者は、セクション3.1.1の検証手順に合格するAS_PATHを等しく作成できます。BGP Origin検証[RFC6811]とBGPSEC [RFC8205]は、検証されている起源が改ざんされていないという保証を増やす手段を提供します。
Many tunnels carry traffic that embeds a destination address that comes from a non-global namespace. One example is MPLS VPNs. If a tunnel crosses from one namespace to another, without the necessary translation being performed for the embedded address(es), there exists a risk of misdelivery of traffic. If the traffic contains confidential data that's not otherwise protected (for example, by end-to-end encryption), then confidential information could be revealed. The restriction of applicability of the Tunnel Encapsulation attribute to a well-defined scope limits the likelihood of this occurring. See the discussion of "option b" in Section 10 for further discussion of one such scenario.
多くのトンネルは、非グローバルネームスペースからの宛先アドレスを埋め込むトラフィックをキャリアします。一例はMPLS VPNSです。埋め込みアドレスに対して必要な翻訳が実行されずにトンネルが別の名前空間から別の名前空間に交差している場合、トラフィックの誤った配信のリスクが存在します。トラフィックに保護されていない機密データが含まれている場合（たとえば、エンドツーエンドの暗号化によって）、機密情報を明らかにすることができます。トンネルカプセル化属性の明確に定義された範囲への適用性の制限は、これが発生する可能性を制限します。そのようなシナリオの1つについてのさらなる議論については、セクション10の「オプションB」の説明を参照されたい。
RFC 8402 specifies that "SR domain boundary routers MUST filter any external traffic" ([RFC8402], Section 8.1). For these purposes, traffic introduced into an SR domain using the Prefix-SID sub-TLV lies within the SR domain, even though the Prefix-SIDs used by the routers at the two ends of the tunnel may be different, as discussed in Section 3.7. This implies that the duty to filter external traffic extends to all routers participating in such tunnels.
RFC 8402は、「SRドメイン境界ルータは外部トラフィックをフィルタリングしなければならない」（[RFC8402]、セクション8.1）を指定します。これらの目的のために、トンネルの両端にあるルータが使用するプレフィックスSIDが異なる場合でも、Prefix-SIDサブTLVを使用してSRドメインに導入されたトラフィックはSRドメイン内にありますが、セクション3.7で説明したように。これは、外部トラフィックをフィルタする義務がそのようなトンネルに参加しているすべてのルータに及ぶことを意味します。
[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>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F.、およびD.黒、「IPv4およびIPv6ヘッダーのDSフィールドの定義」、RFC 2474、DOI 10.17487 / RFC2474、1998年12月、<https：//www.rfc-editor.org/info/rfc2474>。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D.、およびP. Traina、「ジェネリックルーティングカプセル化（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<HTTPS//www.rfc-editor.org/info/rfc2784>。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <https://www.rfc-editor.org/info/rfc2890>.
[RFC2890] DOMMYTY、G、「GREおよびシーケンス番号拡張」、RFC 2890、DOI 10.17487 / RFC2890、2000年9月、<https://www.rfc-editor.org/info/rfc2890>。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032]ローゼン、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T.、およびA. CONTA、「MPLSラベルスタックエンコーディング」、RFC 3032、DOI 10.17487/ RFC3032、2001年1月、<https://www.rfc-editor.org/info/rfc3032>。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, <https://www.rfc-editor.org/info/rfc3270>.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、J.Heinanen、Multi-Protocol Label Switching（MPLS）差別化サービスのサポート、RFC 3270、DOI 10.17487 / RFC3270、2002年5月、<https：//www.rfc-editor.org/info/rfc3270>。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10.17487/RFC3931, March 2005, <https://www.rfc-editor.org/info/rfc3931>.
[RFC3931] Lau、J.、Ed。、Townsley、M.、Ed。、およびI。Goyret、Ed。、「レイヤ2トンネリングプロトコル - バージョン3（L2TPv3）」、RFC 3931、DOI 10.17487 / RFC3931、2005年3月<https：//www.rfc-editor.org/info/rfc3931>。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <https://www.rfc-editor.org/info/rfc4023>.
[RFC4023]深夜、T.、Rekhter、Y.、E.Rosen、ED、「IPまたはGeneric Routing Clackapulation（GRE）」、RFC 4023、DOI 10.17487 / RFC4023、2005年3月、<https：//www.rfc-editor.org/info/rfc4023>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T.、Chandra、R.、Katz、D.、およびY.Rekhter、「BGP-4」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<https：// www。rfc-editor.org/info/rfc4760>。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC5129]デイビー、B.、Briscoe、B.、J. Tay、「MPLSの明示的な輻輳マーク」、RFC 5129、DOI 10.17487 / RFC5129、2008年1月、<https://www.rfc-editor.org/情報/ RFC5129>。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5462] Andersson、L.およびR.Asati、 "Multiprotocol Label Switching（MPLS）ラベルスタックエントリ：" exp "フィールド"トラフィッククラス "フィールド"、RFC 5462、DOI 10.17487 / RFC5462、2009年2月、<https：//www.rfc-editor.org/info/rfc5462>。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R.、およびR.Austein、RFC 6811、DOI 10.17487 / RFC6811、2013年1月、<https：//ww.rfc-editor.org/info/rfc6811>。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <https://www.rfc-editor.org/info/rfc6890>.
[RFC6890]綿、M.、Vegoda、L.、Boicha、R.、Ed。、B. Haberman、BCP 153、RFC 6890、DOI 10.17487 / RFC6890、2013年4月、<https://www.rfc-editor.org/info/rfc6890>。
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M.、およびC.ライト「仮想拡張ローカルエリアネットワーク（VXLAN）：Layer 3ネットワーク上の仮想化レイヤ2ネットワークを重ねるフレームワーク「RFC 7348、DOI 10.17487 / RFC7348、2014年8月、<https：//www.rfc-editor.org/info/rfc7348>。
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.
[RFC7606] Chen、E.、Ed。、Scudder、J.、Ed。、Mohapatra、P.、およびK。Patel、「BGP更新メッセージの修正エラー処理」、RFC 7606、DOI 10.17487 / RFC7606、2015年8月、<https://www.rfc-editor.org/info/rfc7606>。
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <https://www.rfc-editor.org/info/rfc7637>.
[RFC7637] Garg、P.、ED。Y。、「NVGRE：汎用ルーティングカプセル化を使用したネットワーク仮想化」、RFC 7637、DOI 10.17487 / RFC7637、2015年9月、<https：//www.rfc-editor.org/info/rfc7637>。
[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>。
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI 10.17487/RFC8669, December 2019, <https://www.rfc-editor.org/info/rfc8669>.
[RFC8669] PREVIDI、S、FILSFILS、C。、Lindem、A.、ED。、SREKANTIAH、A.、およびH。GREDLER、「BGPのセグメントルーティングプレフィックスセグメント識別子拡張」、RFC 8669、DOI 10.17487 / RFC8669、2019年12月、<https：//www.rfc-editor.org/info/rfc8669>。
[EVPN-INTER-SUBNET] Sajassi, A., Salam, S., Thoria, S., Drake, J. E., and J. Rabadan, "Integrated Routing and Bridging in EVPN", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-inter-subnet-forwarding-13, 10 February 2021, <https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-13>.
[EVPN-Subnetnet] Sajassi、A.、Salam、S.、Thoria、S.、Drake、JE、J. Rabadan、「EVPNでの統合ルーティングとブリッジング」、進行中、インターネットドラフト、ドラフト - IETF-Bess-Evpn-Inter-Subnet-Forwarding-13,2021、<https：//tools.ietf.org/html/draft-ietf-vess-evpn-inter-subnet-forwarding-13>
[IANA-ADDRESS-FAM] IANA, "Address Family Numbers", <https://www.iana.org/assignments/address-family-numbers/>.
[IANA-address-fam] IANA、「アドレスファミリ番号」、<https：//www.iana.org/assignments/address-family-numbers/>。
[IANA-BGP-EXT-COMM] IANA, "Border Gateway Protocol (BGP) Extended Communities", <https://www.iana.org/assignments/bgp-extended-communities/>.
[IANA-BGP-EXT-COMM] IANA、「BORDER GATEWAY Protocol（BGP）拡張コミュニティ」、<https：//www.iana.org/assignments/bgp-extended-communities/>。
[IANA-BGP-PARAMS] IANA, "Border Gateway Protocol (BGP) Parameters", <https://www.iana.org/assignments/bgp-parameters/>.
[IANA-BGP-PARAMS] IANA、「ボーダーゲートウェイプロトコル（BGP）パラメータ」、<https：//www.iana.org/assignments/bgp-parameters/>。
[IANA-BGP-TUNNEL-ENCAP] IANA, "Border Gateway Protocol (BGP) Tunnel Encapsulation", <https://www.iana.org/assignments/bgp-tunnel-encapsulation/>.
[IANA-BGP-TUNNEL-ENCAP] IANA、「ボーダーゲートウェイプロトコル（BGP）トンネルカプセル化」、<https：//www.iana.org/assignments/bgp-tunnel-encaps-japsulation/>。
[IANA-ETHERTYPES] IANA, "IEEE 802 Numbers: ETHER TYPES", <https://www.iana.org/assignments/ieee-802-numbers/>.
[IANA-EtherTypes] IANA、「IEEE 802番号：エーテルタイプ」、<https：//www.iana.org/assignments/ieee-802-numbers/>。
[IANA-SAFI] IANA, "Subsequent Address Family Identifiers (SAFI) Parameters", <https://www.iana.org/assignments/safi-namespace/>.
[IANA-SAFI] IANA、「後続のアドレスファミリID（SAFI）パラメータ」、<https：//www.iana.org/assignments/safi-namespace/>。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.
[RFC4272] Murphy、S.、「BGPセキュリティ脆弱性分析」、RFC 4272、DOI 10.17487 / RFC4272、2006年1月、<https：//www.rfc-editor.org/info/rfc4272>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E.およびY.Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPNS）"、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https：//www.rfc-editor.org/info/ RFC4364>。
[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>。
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, June 2009, <https://www.rfc-editor.org/info/rfc5566>.
[RFC5566] Berger、L.、White、R.、およびE.ローゼン、「BGP IPsecトンネルカプセル化属性」、RFC 5566、DOI 10.17487 / RFC 5566、2009年6月、<https：//www.rfc-editor.org/情報/ RFC5566>。
[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>。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T.、およびY.Rekhter、「BGPエンコーディングおよびMPLS / BGP IP VPNSのマルチキャストの手順」、RFC 6514、DOI 10.17487 / RFC6514、2012年2月、<https://www.rfc-editor.org/info/rfc6514>。
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, <https://www.rfc-editor.org/info/rfc7510>.
[RFC7510] XU、X.、Sheth、N.、Yong、L.、Callon、R.、およびD.黒、「UDPのカプセル化MPLS」、RFC 7510、DOI 10.17487 / RFC7510、2015年4月、<https：//www.rfc-editor.org/info/rfc7510>。
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205] Lepinski、M.、ED。そして、K。SRIRAM、ED。、「BGPSECプロトコル仕様」、RFC 8205、DOI 10.17487 / RFC8205、2017年9月、<https：//www.rfc-editor.org/info/rfc8205>。
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.
[RFC8277] Rosen、E.、「MPLSラベルをアドレスプレフィックスにバインドするためのBGPの使用」、RFC 8277、DOI 10.17487 / RFC8277、2017年10月、<https://www.rfc-editor.org/info/rfc8277>。
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, <https://www.rfc-editor.org/info/rfc8365>.
[RFC8365] Sajassi、A.、ED。、Drake、J.、Ed。、Bitar、N.、Shekhar、R.、Uttaro、J.、およびW.HenderickX、「イーサネットVPNを使用したネットワーク仮想化オーバーレイソリューション（EVPN） "、RFC 8365、DOI 10.17487 / RFC8365、2018年3月、<https：//www.rfc-editor.org/info/rfc8365>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/ RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8365] references RFC 5512 for its definition of the BGP Encapsulation Extended Community. That extended community is now defined in this document, in a way consistent with its previous definition.
[RFC8365] BGPカプセル化拡張コミュニティの定義については、RFC 5512を参照しています。その拡張コミュニティはこの文書で定義され、以前の定義と一致するように定義されています。
Section 6 of [RFC8365] talks about the use of the Encapsulation Extended Community to allow Network Virtualization Edge (NVE) devices to signal their supported encapsulations. We note that with the introduction of this specification, the Tunnel Encapsulation attribute can also be used for this purpose. For purposes where RFC 8365 talks about "advertising supported encapsulations" (for example, in the second paragraph of Section 6), encapsulations advertised using the Tunnel Encapsulation attribute should be considered equally with those advertised using the Encapsulation Extended Community.
[RFC8365]のセクション6は、ネットワーク仮想化エッジ（NVE）デバイスがサポートされているカプセル化を通知できるように、カプセル化拡張コミュニティの使用について協議します。この仕様の導入により、この目的のためにトンネルカプセル化属性を使用することもできます。RFC 8365が「サポートされているカプセル化」について（例えば、セクション6の2番目の段落で）話をする目的のために、トンネルカプセル化属性を使用してアドバタイズされたカプセル化は、カプセル化拡張コミュニティを使用してアドバタイズされたものと同等に考慮されるべきです。
In particular, a review of Section 8.3.1 of [RFC8365] is called for, to consider whether the introduction of the Tunnel Encapsulation attribute creates a need for any revisions to the split-horizon procedures.
特に、[RFC8365]のセクション8.3.1のレビューは、トンネルカプセル化属性の導入がスプリットホライズンプロシージャーへのリビジョンの必要性を生み出すかどうかを考慮します。
[RFC8365] also refers to a draft version of this specification in the final paragraph of Section 5.1.3. That paragraph references Section 8.2.2.2 of the draft. In this document, the correct reference would be Section 9.2.2.2. There are no substantive differences between the section in the referenced draft version and that in this document.
[RFC8365]セクション5.1.3の最後の段落のこの仕様のドラフト版も参照しています。その段落はドラフトのセクション8.2.2.2を参照しています。この文書では、正しい参照はセクション9.2.2.2になります。参照されているドラフトバージョンのセクションとこのドキュメントの実質的な違いはありません。
Acknowledgments
謝辞
This document contains text from RFC 5512, authored by Pradosh Mohapatra and Eric Rosen. The authors of the current document wish to thank them for their contribution. RFC 5512 itself built upon prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Barber, Lili Wang, and Chris Metz, whom the authors also thank for their contributions. Eric Rosen was the principal author of earlier versions of this document.
この文書には、Pradosh MohapatraとEric Rosenが作成したRFC 5512からのテキストが含まれています。現在の文書の著者は彼らに彼らの貢献に感謝したいと思います。RFC 5512それ自体は、Gargi Nalawade、Ruchi Kapoor、Dan Tappan、David Ward、Scott Wainner、Simon Berber、Lili Wang、およびChris Metzによって以前の作業に基づいて構築されています。Eric Rosenは、この文書の以前のバージョンの主要な著者でした。
The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes, John Drake, Susan Hares, Satoru Matsushima, Thomas Morin, Dhananjaya Rao, Ravi Singh, Harish Sitaraman, Brian Trammell, Xiaohu Xu, and Zhaohui Zhang for their review, comments, and/or helpful discussions. Alvaro Retana provided an especially comprehensive review.
著者らはLou Berger、Ron Bonica、Martin Djernaes、John Djerake、Susan Djeraks、Susan Drake、Thomas Morin、Dhananjaya Rao、Ravi Sitara、Brian Trammell、Xiaohu Xu、およびZhaohui Zhang、Zhaohui Zhang、コメント、コメント、そして/または役に立つ議論。Alvaro Retanaは特に包括的なレビューを提供しました。
Contributors
貢献者
Below is a list of other contributing authors in alphabetical order:
以下は、他の貢献者のアルファベット順のリストです。
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, WA 98110 United States of America
ランディブッシュインターネットイニシアチブジャパン5147クリスタルスプリングスベインブリッジアイランド、ワシントン州98110アメリカ
Email: randy@psg.com
Robert Raszuk Bloomberg LP 731 Lexington Ave New York City, NY 10022 United States of America
Robert Raszuk Bloomberg LP 731 Lexington Ave New York City、NY 10022アメリカ合衆国
Email: robert@raszuk.net
Eric C. Rosen
エリックC.ローゼン
Authors' Addresses
著者の住所
Keyur Patel Arrcus, Inc 2077 Gateway Pl San Jose, CA 95110 United States of America
Keyur Patel Arrcus、Inc 2077 Gateway Pl San Jose、CA 95110アメリカ合衆国
Email: keyur@arrcus.com
Gunter Van de Velde Nokia Copernicuslaan 50 2018 Antwerpen Belgium
Gunter Van de Velde Nokia Copernicuslaan 50 2018 Antwerpen Belgium
Email: gunter.van_de_velde@nokia.com
Srihari R. Sangli Juniper Networks
Srihari R. Sangli Juniperネットワーク
Email: ssangli@juniper.net
John Scudder Juniper Networks
John Scudder Juniperネットワーク
Email: jgs@juniper.net