[要約] RFC 5512は、BGPのエンカプセレーションSAFIとBGPトンネルエンカプセレーション属性に関する情報を提供します。このRFCの目的は、BGPネットワークでのトンネルエンカプセレーションのサポートを向上させることです。
Network Working Group P. Mohapatra
Request for Comments: 5512 E. Rosen
Category: Standards Track Cisco Systems, Inc.
April 2009
The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute
BGPカプセル化後のアドレスファミリ識別子（SAFI）およびBGPトンネルカプセル化属性
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.
特定の状況では、パケットをあるBorder Gateway Protocol（BGP）スピーカーから別の境界線（BGP Next Hop）に輸送するには、パケットが最初のBGPスピーカーによってカプセル化され、2番目で脱カプセル化される必要があります。これらの状況をサポートするには、「カプセル化情報」、つまりカプセル化ヘッダーの形式とヘッダーのさまざまなフィールドの内容に関して、2つのBGPスピーカーの間に何らかの合意が必要です。
The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used.
カプセル化情報は、すべてのカプセル化タイプに合図する必要はありません。シグナリングが必要な場合（レイヤー2トンネリングプロトコル - バージョン3（L2TPV3）または汎用ルーティングカプセル化（GRE）キーを使用）、このドキュメントは、BGPスピーカーがカプセル化情報を相互に通知できる方法を指定します。シグナル伝達は、後続のアドレスファミリ識別子（SAFI）とIPv4またはIPv6アドレスファミリ識別子（AFI）を使用してBGP更新を送信することによって行われます。カプセル化情報を信号する必要がない場合（キーのないGREなど）、このドキュメントは、使用するカプセル化プロトコルタイプを示すためにペイロードプレフィックスを伝達するBGP更新メッセージに添付できるBGP拡張コミュニティを指定します。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................4
3. Encapsulation NLRI Format .......................................4
4. Tunnel Encapsulation Attribute ..................................5
4.1. Encapsulation sub-TLV ......................................6
4.2. Protocol Type Sub-TLV ......................................7
4.3. Color Sub-TLV ..............................................8
4.3.1. Color Extended Community ............................8
4.4. Tunnel Type Selection ......................................8
4.5. BGP Encapsulation Extended Community .......................9
5. Capability Advertisement .......................................10
6. Error Handling .................................................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................10
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
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 [MESH], D may be an IPv4 address while the intermediate routers along the path from R1 to R2 may support only IPv6.
ルーターR1がIPパケットPを転送する場合を考えてみましょう。PをPのIP宛先アドレスとします。R1は、転送テーブルでDを検索する必要があります。Dの「ベストマッチ」ルートはルートQであると仮定します。ここで、Qは「BGP Next Hop」がルーターR2であるBGP分配ルートです。さらに、R1からR2へのパスに沿ったルーターには、転送テーブルにR2のエントリがあるが、転送テーブルにはDのエントリがないと仮定します。たとえば、R1からR2へのパスは、コア内にBGP分配ルートがまったくない「BGPフリーコア」の一部である場合があります。または、[メッシュ]のように、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, 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、L2TPV3、IPのIPなどを使用して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スピーカーが、BGPの次のホップのすべてのカプセル化情報を手動で構成することを要求することは望ましくありません。
In this document, we specify 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 distinguished SAFI value, the Encapsulation SAFI. The Encapsulation SAFI can be used with the AFI for IPv4 or with the AFI for IPv6. The IPv4 AFI is used when the encapsulated packets are to be sent using IPv4; the IPv6 AFI is used when the encapsulated packets are to be sent using IPv6.
このドキュメントでは、特定のBGPスピーカーがBGP自体を使用して他のBGPスピーカーに「パケットをカプセル化する必要がある場合は、私に送信する必要がある場合、カプセル化ヘッダーを適切に形成するために必要な情報があります。「。BGPスピーカーは、この情報を他のBGPスピーカーに識別したSAFI値であるカプセル化SAFIを使用してシグナルにします。カプセル化Safiは、IPv4のAFIまたはIPv6のAFIで使用できます。IPv4 AFIは、カプセル化されたパケットをIPv4を使用して送信する場合に使用されます。IPv6 AFIは、カプセル化されたパケットをIPv6を使用して送信する場合に使用されます。
In a given BGP update, the Network Layer Reachability Information (NLRI) of the Encapsulation SAFI consists of the IP address (in the family specified by the AFI) of the originator of that update. The encapsulation information is specified in the BGP "tunnel encapsulation attribute" (specified herein). 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, e.g., communities or extended communities, may also be included.
特定のBGPアップデートでは、カプセル化Safiのネットワークレイヤーリーチ可能性情報（NLRI）は、そのアップデートの発信者のIPアドレス（AFIで指定されたファミリー）で構成されています。カプセル化情報は、BGP「トンネルカプセル化属性」（ここで指定）で指定されています。この属性は、それらのプロトコルを適切に使用するために必要な追加情報（もしあれば）を使用する可能性のあるカプセル化プロトコルを指定します。他の属性、例えばコミュニティや拡張コミュニティも含まれる場合があります。
Since the encapsulation information is coded as an attribute, one could ask whether a new SAFI is really required. After all, a BGP speaker could simply attach the tunnel encapsulation attribute to each prefix (like Q in our example) that it advertises. But with that technique, any change in the encapsulation information would cause a very large number of updates. Unless one really wants to specify different encapsulation information for each prefix, it is much better to have a mechanism in which a change in the encapsulation information causes a BGP speaker to advertise only a single update. Conversely, when prefixes get modified, the tunnel encapsulation information need not be exchanged.
カプセル化情報は属性としてコード化されているため、新しいSAFIが本当に必要かどうかを尋ねることができます。結局のところ、BGPスピーカーは、宣伝する各プレフィックス（例のqなど）にトンネルカプセル化属性を単純に添付することができます。しかし、その手法により、カプセル化情報の変更は非常に多くの更新を引き起こします。プレフィックスごとに異なるカプセル化情報を実際に指定したい場合を除き、カプセル化情報の変更により、BGPスピーカーが1つの更新のみを宣伝するメカニズムがあります。逆に、プレフィックスが変更されると、トンネルのカプセル化情報を交換する必要はありません。
In this specification, a single SAFI is used to carry information for all encapsulation protocols. One could have taken an alternative approach of defining a new SAFI for each encapsulation protocol. However, with the specified approach, encapsulation information can pass transparently and automatically through intermediate BGP speakers (e.g., route reflectors) that do not necessarily understand the encapsulation information. This works because the encapsulation attribute is defined as an optional transitive attribute. New encapsulations can thus be added without the need to reconfigure any intermediate BGP system. If adding a new encapsulation required using a new SAFI, the information for that encapsulation would not pass through intermediate BGP systems unless those systems were reconfigured to support the new SAFI.
この仕様では、すべてのカプセル化プロトコルの情報を運ぶために単一のSAFIを使用します。カプセル化プロトコルごとに新しいSAFIを定義する代替アプローチをとることができます。ただし、指定されたアプローチを使用すると、カプセル化情報は、必ずしもカプセル化情報を理解していない中間BGPスピーカー（例：ルートリフレクター）を介して透過的かつ自動的に渡すことができます。これは、カプセル化属性がオプションの推移属性として定義されるため、機能します。したがって、中間BGPシステムを再構成する必要なく、新しいカプセルを追加できます。新しいSAFIを使用して必要な新しいカプセル化を追加する場合、それらのシステムが新しいSAFIをサポートするために再構成されない限り、そのカプセル化の情報は中間BGPシステムを通過しません。
For encapsulation protocols where no encapsulation information needs to be signaled (such as GRE without key), the egress router MAY still want to specify the protocol to use for transporting packets from the ingress router. This document specifies a new BGP extended community that can be attached to UPDATE messages that carry payload prefixes for this purpose.
カプセル化情報を信号する必要がないカプセル化プロトコル（キーのないGREなど）の場合、Egressルーターは、イングレスルーターからパケットを輸送するために使用するプロトコルを指定する必要があります。このドキュメントは、この目的のためにペイロードプレフィックスを伝えるメッセージに添付できる新しいBGP拡張コミュニティを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The NLRI, defined below, is carried in BGP UPDATE messages [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 1 or 2 (IPv4 or IPv6) [IANA-AF] and a SAFI value of 7 (called an Encapsulation SAFI).
以下に定義されているNLRIは、BGPマルチプロトコル拡張[RFC4760]を使用してBGPアップデートメッセージ[RFC4271]で運ばれます。）。
The NLRI is encoded in a format defined in Section 5 of [RFC4760] (a 2-tuple of the form <length, value>). The value field is structured as follows:
NLRIは、[RFC4760]のセクション5で定義されている形式でエンコードされています（フォーム<長さ、値>の2タプル）。値フィールドは次のように構成されています。
+-----------------------------------------------+
| Endpoint Address (Variable) |
+-----------------------------------------------+
- Endpoint Address: This field identifies the BGP speaker originating the update. It is typically one of the interface addresses configured at the router. The length of the endpoint address is dependent on the AFI being advertised. If the AFI is set to IPv4 (1), then the endpoint address is a 4-octet IPv4 address, whereas if the AFI is set to IPv6 (2), the endpoint address is a 16-octet IPv6 address.
- エンドポイントアドレス：このフィールドは、更新を発信するBGPスピーカーを識別します。通常、ルーターで構成されたインターフェイスアドレスの1つです。エンドポイントアドレスの長さは、宣伝されているAFIに依存します。AFIがIPv4（1）に設定されている場合、エンドポイントアドレスは4-OCTET IPv4アドレスですが、AFIがIPv6（2）に設定されている場合、エンドポイントアドレスは16オクテットIPv6アドレスです。
An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI attribute with the Encapsulation SAFI MUST also carry the BGP mandatory attributes: ORIGIN, AS_PATH, and LOCAL_PREF (for IBGP neighbors), as defined in [RFC4271]. In addition, such an update message can also contain any of the BGP optional attributes, like the Community or Extended Community attribute, to influence an action on the receiving speaker.
MP_REACH_NLRIまたはMP_UNREACH_NLRI属性をカプセル化SAFIを搭載する更新メッセージは、[RFC4271]で定義されているように、BGPの必須属性：Origin、As_Path、およびLocal_Pref（IBGP Neighborsの場合）も運ぶ必要があります。さらに、このような更新メッセージには、コミュニティや拡張コミュニティの属性などのBGPオプションの属性を、受信スピーカーのアクションに影響を与えることもできます。
When a BGP speaker advertises the Encapsulation NLRI via BGP, it uses its own address as the BGP nexthop in the MP_REACH_NLRI or MP_UNREACH_NLRI attribute. The nexthop address is set based on the AFI in the attribute. For example, if the AFI is set to IPv4 (1), the nexthop is encoded as a 4-byte IPv4 address. If the AFI is set to IPv6 (2), the nexthop is encoded as a 16-byte IPv6 address of the router. On the receiving router, the BGP nexthop of such an update message is validated by performing a recursive route lookup operation in the routing table.
BGPスピーカーがBGPを介してカプセル化NLRIを宣伝する場合、MP_REACH_NLRIまたはMP_UNREACH_NLRI属性のBGP Nexthopとして独自のアドレスを使用します。Nexthopアドレスは、属性のAFIに基づいて設定されています。たとえば、AFIがIPv4（1）に設定されている場合、Nexthopは4バイトIPv4アドレスとしてエンコードされます。AFIがIPv6（2）に設定されている場合、Nexthopはルーターの16バイトIPv6アドレスとしてエンコードされます。受信ルーターでは、このような更新メッセージのBGP Nexthopは、ルーティングテーブルで再帰的なルート検索操作を実行することにより検証されます。
Bestpath selection of Encapsulation NLRIs is governed by the decision process outlined in Section 9.1 of [RFC4271]. The encapsulation data carried through other attributes in the message are to be used by the receiving router only if the NLRI has a bestpath.
カプセル化NLRISのベストパス選択は、[RFC4271]のセクション9.1で概説されている決定プロセスによって支配されています。メッセージ内の他の属性を介して運ばれるカプセル化データは、NLRIがBestPathを持っている場合にのみ、受信ルーターによって使用されます。
The Tunnel Encapsulation attribute is an optional transitive attribute that is composed of a set of Type-Length-Value (TLV) encodings. The type code of the attribute is 23. Each TLV contains information corresponding to a particular tunnel technology. The TLV is structured as follows:
トンネルカプセル化属性は、タイプ長値（TLV）エンコーディングのセットで構成されるオプションの推移的属性です。属性のタイプコードは23です。各TLVには、特定のトンネルテクノロジーに対応する情報が含まれています。TLVは次のように構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 Octets) | Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Tunnel Type (2 octets): identifies the type of tunneling technology being signaled. This document defines the following types:
* トンネルタイプ（2オクテット）：シグナル伝達されるトンネル技術のタイプを識別します。このドキュメントでは、次のタイプを定義します。
- L2TPv3 over IP [RFC3931]: Tunnel Type = 1 - GRE [RFC2784]: Tunnel Type = 2 - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7
- L2TPV3 Over IP [RFC3931]：トンネルタイプ= 1 -GRE [RFC2784]：トンネルタイプ= 2-IP [RFC2003] [RFC4213]：トンネルタイプ= 7
Unknown types are to be ignored and skipped upon receipt.
未知のタイプは無視され、受領時にスキップされます。
* Length (2 octets): the total number of octets of the value field.
* 長さ（2オクテット）：値フィールドのオクテットの総数。
* Value (variable): comprised of multiple sub-TLVs. Each sub-TLV consists of three fields: a 1-octet type, 1-octet length, and zero or more octets of value. The sub-TLV is structured as follows:
* 値（変数）：複数のサブTLVで構成されています。各Sub-TLVは、1オクテットのタイプ、1-オクテットの長さ、ゼロ以上の値の3つのフィールドで構成されています。Sub-TLVは次のように構成されています。
+-----------------------------------+
| Sub-TLV Type (1 Octet) |
+-----------------------------------+
| Sub-TLV Length (1 Octet) |
+-----------------------------------+
| Sub-TLV Value (Variable) |
| |
+-----------------------------------+
* Sub-TLV Type (1 octet): each sub-TLV type defines a certain property about the tunnel TLV that contains this sub-TLV. The following are the types defined in this document:
* サブTLVタイプ（1オクテット）：各サブTLVタイプは、このサブTLVを含むトンネルTLVに関する特定のプロパティを定義します。以下は、このドキュメントで定義されているタイプです。
- Encapsulation: sub-TLV type = 1 - Protocol type: sub-TLV type = 2 - Color: sub-TLV type = 4
- カプセル化：sub-tlvタイプ= 1-プロトコルタイプ：sub-tlvタイプ= 2-色：sub-tlvタイプ= 4
When the TLV is being processed by a BGP speaker that will be performing encapsulation, any unknown sub-TLVs MUST be ignored and skipped. However, if the TLV is understood, the entire TLV MUST NOT be ignored just because it contains an unknown sub-TLV.
TLVがカプセル化を実行するBGPスピーカーによって処理されている場合、未知のサブTLVは無視してスキップする必要があります。ただし、TLVが理解されている場合、TLV全体を無視してはなりません。
* Sub-TLV Length (1 octet): the total number of octets of the sub-TLV value field.
* サブTLV長（1オクテット）：サブTLV値フィールドのオクテットの総数。
* Sub-TLV Value (variable): encodings of the value field depend on the sub-TLV type as enumerated above. The following sub-sections define the encoding in detail.
* Sub-TLV値（変数）：値フィールドのエンコーディングは、上記で列挙されているサブTLVタイプに依存します。次のサブセクションは、エンコードを詳細に定義します。
The syntax and semantics of the encapsulation sub-TLV is determined by the tunnel type of the TLV that contains this sub-TLV.
カプセル化サブTLVの構文とセマンティクスは、このサブTLVを含むTLVのトンネルタイプによって決定されます。
When the tunnel type of the TLV is L2TPv3 over IP, the following is the structure of the value field of the encapsulation sub-TLV:
TLVのトンネルタイプがIPよりもL2TPV3である場合、以下はカプセル化サブTLVの値フィールドの構造です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cookie (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Session ID: a non-zero 4-octet value locally assigned by the advertising router that serves as a lookup key in the incoming packet's context.
* セッションID：着信パケットのコンテキストのルックアップキーとして機能する広告ルーターによってローカルに割り当てられたゼロ以外の4オクターテット値。
* Cookie: an optional, variable length (encoded in octets -- 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：L2TPV3が使用するオプションの可変長さ（オクテットでエンコード-0〜8オクテット）値は、受信したデータメッセージの関連付けをセッションIDで識別したセッションと確認します。Cookie値の生成と使用は、[RFC3931]で指定されているとおりです。
The length of the cookie is not encoded explicitly, but can be calculated as (sub-TLV length - 4).
Cookieの長さは明示的にエンコードされていませんが、（サブTLVの長さ-4）として計算できます。
When the tunnel type of the TLV is GRE, the following is the structure of the value field of the encapsulation sub-TLV:
TLVのトンネルタイプがGREの場合、次のものはカプセル化サブTLVの値フィールドの構造です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* GRE Key: 4-octet field [RFC2890] that is generated by the advertising router. The actual method by which the key is obtained is beyond the scope of this document. The key is inserted into the GRE encapsulation header of the payload packets sent by ingress routers to the advertising router. It is intended to be used for identifying extra context information about the received payload.
* GREキー：広告ルーターによって生成される4-OCTETフィールド[RFC2890]。キーが取得される実際の方法は、このドキュメントの範囲を超えています。キーは、イングレスルーターによって送信されたペイロードパケットのGREカプセル化ヘッダーに広告ルーターに挿入されます。受信したペイロードに関する追加のコンテキスト情報を特定するために使用することを目的としています。
Note that the key is optional. Unless a key value is being advertised, the GRE encapsulation sub-TLV MUST NOT be present.
キーはオプションであることに注意してください。キー値が宣伝されていない限り、GREカプセル化サブTLVが存在してはなりません。
The protocol type sub-TLV MAY be encoded to indicate the type of the payload packets that will be encapsulated with the tunnel parameters that are being signaled in the TLV. The value field of the sub-TLV contains a 2-octet protocol type that is one of the types defined in [IANA-AF] as ETHER TYPEs.
プロトコルタイプのSub-TLVは、TLVで通知されているトンネルパラメーターでカプセル化されるペイロードパケットのタイプを示すためにエンコードされる場合があります。Sub-TLVの値フィールドには、[IANA-AF]でエーテルタイプとして定義されているタイプの1つである2-OCTETプロトコルタイプが含まれています。
For example, if we want to use 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セッション、1つはIPv4パケットを運ぶ1つ、IPv6パケットを携帯する1つ、およびMPLSパケットを1つ使用する場合、EgressルーターにはL2TPV3カプセル化タイプの3つのTLVが含まれます。タイプ。これらのプロトコルタイプSub-TLVは、それぞれIPv4（プロトコルタイプ= 0x0800）、IPv6（プロトコルタイプ= 0x86DD）、およびMPLS（プロトコルタイプ= 0x8847）です。これにより、指定された各プロトコルタイプで使用する適切なカプセル化情報の侵入ルーターに通知されます。イングレスルーターに指定されたセッションIDを挿入すると、プロトコルの種類に従って、出力が着信パケットを正しく処理できます。
Inclusion of this sub-TLV depends on the tunnel type. It MUST be encoded for L2TPv3 tunnel type. On the other hand, the protocol type sub-TLV is not required for IP in IP or GRE tunnels.
このサブTLVを含めると、トンネルの種類に依存します。L2TPV3トンネルタイプ用にエンコードする必要があります。一方、IPまたはGREトンネルのIPには、プロトコルタイプのサブTLVは必要ありません。
The color sub-TLV MAY be encoded as a way to color the corresponding tunnel TLV. The value field of the sub-TLV contains an extended community that is defined as follows:
カラーサブTLVは、対応するトンネルTLVを着色する方法としてエンコードされる場合があります。Sub-TLVの値フィールドには、次のように定義される拡張コミュニティが含まれています。
The Color Extended Community is an opaque extended community [RFC4360] with the following encoding:
Color Extended Communityは、次のエンコードを伴う不透明な拡張コミュニティ[RFC4360]です。
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 | 0x0b | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 on the routers. The same Color Extended Community can then be attached to the UPDATE messages that contain payload prefixes. This way, the BGP speaker can express the fact that it expects the packets corresponding to these payload prefixes to be received with a particular tunnel encapsulation header.
拡張型フィールドの高次オクテットの値は0x03であり、これは推移的であることを示します。このコミュニティの拡張タイプフィールドの低次のオクテットの値は0x0bです。色の値は、ユーザー定義であり、ルーターでローカルで構成されています。その後、同じ色の拡張コミュニティを、ペイロードプレフィックスを含む更新メッセージに添付できます。これにより、BGPスピーカーは、特定のトンネルカプセル化ヘッダーでこれらのペイロードプレフィックスに対応するパケットが受信されると予想されるという事実を表現できます。
A BGP speaker may include multiple tunnel TLVs in the tunnel attribute. The receiving speaker MAY have local policies defined to choose different tunnel types for different sets/types of payload prefixes received from the same BGP speaker. For instance, if a BGP speaker includes both L2TPv3 and GRE tunnel types in the tunnel attribute and it also advertises IPv4 and IPv6 prefixes, the ingress router may have local policy defined to choose L2TPv3 for IPv4 prefixes (provided the protocol type received in the tunnel attribute matches) and GRE for IPv6 prefixes.
BGPスピーカーには、トンネル属性に複数のトンネルTLVを含めることができます。受信スピーカーには、同じBGPスピーカーから受信したさまざまなセット/タイプのペイロードプレフィックスに対して、異なるトンネルタイプを選択するためにローカルポリシーが定義される場合があります。たとえば、BGPスピーカーにトンネル属性にL2TPV3とGREトンネルタイプの両方が含まれており、IPv4およびIPv6プレフィックスも宣伝する場合、Ingressルーターは、IPv4プレフィックスのL2TPV3を選択するためにローカルポリシーを定義することができます（トンネルで受け取ったプロトコルタイプを条件にしてください属性一致）およびIPv6プレフィックスのGRE。
Additionally, the Encapsulation SAFI UPDATE message can contain a color sub-TLV for some or all of the tunnel TLVs. The BGP speaker SHOULD then attach a Color Extended Community to payload prefixes to select the appropriate tunnel types.
さらに、カプセル化SAFI更新メッセージには、トンネルTLVの一部またはすべてのカラーサブTLVを含めることができます。BGPスピーカーは、色の拡張コミュニティをペイロードプレフィックスに添付して、適切なトンネルタイプを選択する必要があります。
In a multi-vendor deployment that has routers supporting different tunneling technologies, including color sub-TLV to the Encapsulation SAFI UPDATE message can serve as a classification mechanism (for example, set A of routers for GRE and set B of routers for L2TPv3). The ingress router can then choose the encapsulation data appropriately while sending packets to an egress router.
カプセル化SAFIアップデートメッセージへのカラーサブTLVを含むさまざまなトンネリングテクノロジーをサポートするルーターを備えたマルチベンダーの展開では、分類メカニズムとして機能します（たとえば、GREのルーターのAのセット、L2TPV3のルーターのセットB）。Ingressルーターは、出口ルーターにパケットを送信しながら、カプセル化データを適切に選択できます。
If a BGP speaker originates an update for prefix P with color C and with itself as the next hop, then it MUST also originate an Encapsulation SAFI update that contains the color C.
BGPスピーカーが色cを含むプレフィックスPの更新を発信し、次のホップとしてそれ自体を備えた場合、Color Cを含むカプセル化Safiアップデートも発生する必要があります。
Suppose that a BGP speaker receives an update for prefix P with color C, that the BGP decision procedure has selected the route in that update as the best route to P, and that the next hop is node N, but that an Encapsulation SAFI update originating from node N containing color C has not been received. In this case, no route to P will be installed in the forwarding table unless and until the corresponding Encapsulation SAFI update is received, or the BGP decision process selects a different route.
BGPスピーカーがColor CのプレフィックスPのアップデートを受信し、BGP決定手順がその更新のルートをPへの最適なルートとして選択し、次のホップはノードnであるが、カプセル化SAFIアップデートが発生することを仮定します。色Cを含むノードNからCは受信されていません。この場合、対応するカプセル化SAFIアップデートが受信されない場合、またはBGP決定プロセスが別のルートを選択しない限り、および対応するカプセル化SAFI更新がない限り、Pへのルートは転送テーブルにインストールされません。
Suppose that a BGP speaker receives an "uncolored" update for prefix P, with next hop N, and that the BGP speaker has also received an Encapsulation SAFI originated by N, specifying one or more encapsulations that may or may not be colored. In this case, the choice of encapsulation is a matter of local policy. The only "default policy" necessary is to choose one of the encapsulations supported by the speaker.
BGPスピーカーが次のホップnを使用して、プレフィックスPの「表現されていない」アップデートを受信し、BGPスピーカーがNから発信されたカプセル化SAFIも受け取っているとします。この場合、カプセル化の選択はローカルポリシーの問題です。必要な唯一の「デフォルトポリシー」は、スピーカーがサポートするカプセルのいずれかを選択することです。
Here, we define a BGP opaque extended community that can be attached to BGP UPDATE messages to indicate the encapsulation protocol to be used for sending packets from an ingress router to an egress router. Considering our example from the Section 1, R2 MAY include this extended community, specifying a particular tunnel type to be used in the UPDATE message that carries route Q to R1. This is useful if there is no explicit encapsulation information to be signaled using the Encapsulation SAFI for a tunneling protocol (such as GRE without key).
ここでは、BGPの更新メッセージに接続できるBGP不透明な拡張コミュニティを定義して、イングレスルーターから出力ルーターにパケットを送信するために使用されるカプセル化プロトコルを示します。セクション1の例を考慮して、R2にはこの拡張コミュニティが含まれており、ルートQをR1に運ぶ更新メッセージで使用する特定のトンネルタイプを指定することができます。これは、トンネリングプロトコル（キーのないGREなど）のカプセル化SAFIを使用して、明示的なカプセル化情報を合図する明示的なカプセル化情報がない場合に役立ちます。
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 | 0x0c | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Tunnel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 as defined in this document.
値フィールドの最後の2オクテットは、このドキュメントで定義されているトンネルタイプをエンコードします。
For interoperability, a speaker supporting Encapsulation SAFI MUST implement the Encapsulation Extended Community.
相互運用性のために、カプセル化SAFIをサポートするスピーカーは、カプセル化拡張コミュニティを実装する必要があります。
A BGP speaker that wishes to exchange tunnel endpoint information must use the Multiprotocol Extensions Capability Code as defined in [RFC4760], to advertise the corresponding (AFI, SAFI) pair.
トンネルエンドポイント情報を交換したいBGPスピーカーは、[RFC4760]で定義されているマルチプロトコル拡張機能コードを使用して、対応する（AFI、SAFI）ペアを宣伝する必要があります。
When a BGP speaker encounters an error while parsing the tunnel encapsulation attribute, the speaker MUST treat the UPDATE as a withdrawal of existing routes to the included Encapsulation SAFI NLRIs, or discard the UPDATE if no such routes exist. A log entry should be raised for local analysis.
BGPスピーカーがトンネルカプセル化属性を解析する際にエラーに遭遇する場合、スピーカーは、既存のルートの撤回を含むカプセル化サフィnlrisとして扱うか、そのようなルートが存在しない場合は更新を破棄する必要があります。ローカル分析のためにログエントリを提起する必要があります。
Security considerations applicable to softwires can be found in the mesh framework [MESH]. In general, security issues of the tunnel protocols signaled through Encapsulation SAFI are inherited.
ソフトウェアに適用可能なセキュリティ上の考慮事項は、メッシュフレームワーク[メッシュ]に記載されています。一般に、カプセル化Safiを通じてシグナルが継承されたトンネルプロトコルのセキュリティ問題は継承されます。
If a third party is able to modify any of the information that is used to form encapsulation headers, to choose a tunnel type, or to choose a particular tunnel for a particular payload type, user data packets may end up getting misrouted, misdelivered, and/or dropped.
サードパーティがカプセル化ヘッダーを形成するために使用される情報を変更したり、トンネルタイプを選択したり、特定のペイロードタイプの特定のトンネルを選択したりすることができる場合、ユーザーデータパケットは誤って誘惑され、誤って誘導される可能性があります。/またはドロップ。
IANA assigned value 7 from the "Subsequent Address Family" Registry, in the "Standards Action" range, to "Encapsulation SAFI", with this document as the reference.
IANAは、「標準アクション」範囲の「後続のアドレスファミリ」レジストリから「カプセル化Safi」に値7を割り当て、このドキュメントを参照として。
IANA assigned value 23 from the "BGP Path Attributes" Registry, to "Tunnel Encapsulation Attribute", with this document as the reference.
IANAは、「BGPパス属性」レジストリから「トンネルカプセル化属性」に値23を割り当て、このドキュメントを参照として。
IANA assigned two new values from the "BGP Opaque Extended Community" type Registry. Both are from the transitive range. The first new value is called "Color Extended Community" (0x030b), and the second is called "Encapsulation Extended Community"(0x030c). This document is the reference for both assignments.
IANAは、「BGP Opaque Extended Community」タイプレジストリから2つの新しい値を割り当てました。どちらも推移的な範囲からです。最初の新しい値は「Color Extended Community」（0x030B）と呼ばれ、2番目は「カプセル化拡張コミュニティ」（0x030c）と呼ばれます。このドキュメントは、両方の割り当てのリファレンスです。
IANA set up a registry for "BGP Tunnel Encapsulation Attribute Tunnel Types". This is a registry of two-octet values (0-65535), to be assigned on a first-come, first-served basis. The initial assignments are as follows:
IANAは、「BGPトンネルカプセル化属性トンネルタイプ」のレジストリを設定しました。これは、2オクセット値（0-65535）のレジストリであり、先着順で割り当てられます。最初の割り当ては次のとおりです。
Tunnel Name Type
--------------- -----
L2TPv3 over IP 1
GRE 2
IP in IP 7
IANA set up a registry for "BGP Tunnel Encapsulation Attribute Sub-TLVs". This is a registry of 1-octet values (0-255), to be assigned on a "standards action/early allocation" basis. This document is the reference. The initial assignments are:
IANAは、「BGPトンネルカプセル化属性サブTLV」のレジストリを設定しました。これは、「標準アクション/早期割り当て」ベースで割り当てられる1-OCTET値（0-255）のレジストリです。このドキュメントは参照です。最初の割り当ては次のとおりです。
Sub-TLV name Type
------------- -----
Encapsulation 1
Protocol Type 2
Color 4
This specification builds on prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Barber, and Chris Metz. The current authors wish to thank all these authors for their contribution.
この仕様は、Gargi Nalawade、Ruchi Kapoor、Dan Tappan、David Ward、Scott Wainner、Simon Barber、Chris Metzによる以前の作業に基づいています。現在の著者は、これらすべての著者の貢献に感謝したいと考えています。
The authors would like to thank John Scudder, Robert Raszuk, Keyur Patel, Chris Metz, Yakov Rekhter, Carlos Pignataro, and Brian Carpenter for their valuable comments and suggestions.
著者は、John Scudder、Robert Raszuk、Keyur Patel、Chris Metz、Yakov Rekhter、Carlos Pignataro、Brian Carpenterの貴重なコメントと提案に感謝したいと思います。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、ed。、Ed。、Townsley、M.、ed。、およびI. Goyret、ed。、「レイヤー2トンネリングプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（GRE）」、RFC 2784、2000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G。、「GREへのキーおよびシーケンス番号拡張」、RFC 2890、2000年9月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[IANA-AF] "Address Family Numbers," http://www.iana.org.
[IANA-AF] "アドレスファミリー番号" http://www.iana.org。
[MESH] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework," Work in Progress, February 2009.
[Mesh] Wu、J.、Cui、Y.、Metz、C。、およびE. Rosen、「Softwire Mesh Framework」、Work in Progress、2009年2月。
Authors' Addresses
著者のアドレス
Pradosh Mohapatra Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: pmohapat@cisco.com
Pradosh Mohapatra Cisco Systems、Inc。170 Tasman Drive San Jose、CA、95134メール：pmohapat@cisco.com
Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 EMail: erosen@cisco.com
Eric Rosen Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA、01719メール：erosen@cisco.com