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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
特定の状況では、別のボーダーゲートウェイプロトコル（BGP）スピーカ（BGPネクストホップ）からのパケットを搬送するパケットは最初のBGPスピーカによってカプセル化され、第二によってデカプセル化されることを必要とします。このような状況をサポートするために、「カプセル化情報」、即ち、カプセル化ヘッダのフォーマット、ならびにヘッダの様々なフィールドの内容に関して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）を使用してBGPアップデートを送信することによって行われ、IPv4またはIPv6ファミリー識別子（AFI）をアドレス。いかなるカプセル化情報は、（例えばキー無し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.
P.レッツは、PのIP宛先アドレスをD IPパケットを転送するルータR1の場合を考えてみましょう。 R1は、その転送テーブルにDをルックアップする必要があります。 Dのための「最良の一致」ルートと仮定すると、Qは「BGPネクストホップ」がルータR2であるBGP-分散経路である経路Q、です。そして、R1からR2へのパスに沿ったルータが転送テーブルにR2のエントリを持っていますが、そのフォワーディングテーブルでDのエントリを持っていないことをさらに仮定します。例えば、R2へのR1からの経路は、コアに全くBGP-分散ルートが存在しない「BGP-フリーコア」の一部であってもよいです。 R2へのR1からの経路に沿った中間ルータがIPv6のみをサポートするかもしれない、または、[MESH]のように、Dは、IPv4アドレスであってもよいです。
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をカプセル化しなければならず、R2に「トンネルを介して」Pを送信します。例えば、R1は、カプセル化ヘッダの宛先IPアドレスがR2のアドレスであるGRE、L2TPv3の、IPにおけるIP等を用いて、Pをカプセル化してもよいです。
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、キー、またはに充填しなければならないクッキーなどのフィールドを持っている。手動でその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は、IPv4またはIPv6のAFIとAFIと一緒に使用することができます。カプセル化されたパケットは、IPv4を使用して送信する場合のIPv4 AFIが使用されます。カプセル化されたパケットは、IPv6を使用して送信する場合のIPv6 AFIが使用されます。
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）は、その更新の発信元の（AFIで指定された家族の中で）IPアドレスで構成されています。カプセル化情報は、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のような）各プレフィックスにトンネルカプセル化属性を付けることができます。しかし、その技術を用いて、カプセル化情報の変更、更新の非常に多くを引き起こします。 1は実際に各プレフィックスに異なるカプセル化情報を指定したい場合を除き、カプセル化情報の変化がBGPスピーカは、単一の更新を通知する原因となるメカニズムを持つことがはるかに優れています。プレフィックスが変更得るとき逆に、トンネルカプセル化情報を交換する必要はありません。
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を定義する別のアプローチをとっている可能性があります。しかし、指定されたアプローチと、カプセル化情報は、必ずしもカプセル化情報を理解していない中間のBGPスピーカ（例えば、ルートリフレクタ）を透過的かつ自動的に通過することができます。カプセル化属性は、オプションの推移属性として定義されているので、これは動作します。新しいカプセル化は、このように任意の中間のBGPシステムを再構成する必要なしに追加することができます。新しいサフィを使用して、必要な新たなカプセル化を追加する場合、これらのシステムは、新しいサフィをサポートするように再構成した場合を除き、そのカプセル化のための情報は、中間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など）合図する必要はありませんカプセル化プロトコルの場合、出口ルータは、まだ入口ルータからのパケットを輸送するために使用するプロトコルを指定することもできます。この文書では、この目的のためにペイロードプレフィックスを運ぶメッセージを更新するように取り付けることができ、新たな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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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は、以下に定義される、カプセル化SAFIと呼ばれる1又は2（IPv4またはIPv6）のAFI [IANA-AF]及び7のSAFI値（と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スピーカを特定します。それは、典型的には、ルータで構成されたインタフェースアドレスのいずれかです。エンドポイントアドレスの長さは、公示されているAFIに依存しています。 AFIは、IPv4のに設定されている場合AFIがIPv6に設定されている場合（2）、エンドポイント・アドレスは、16オクテットのIPv6アドレスであるのに対し、（1）、その後、エンドポイントアドレスは、4オクテットのIPv4アドレスです。
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.
[RFC4271]で定義されるように、ORIGIN、AS_PATH、及び（IBGPネイバーのための）LOCAL_PREF：カプセル化SAFIとMP_REACH_NLRI又はMP_UNREACH_NLRI属性を運ぶ更新メッセージは、BGP必須属性を搬送しなければなりません。また、このような更新メッセージも受信スピーカーへの作用に影響を与えるため、コミュニティまたは拡張コミュニティ属性のように、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ネクストホップとして自身のアドレスを使用しています。ネクストホップアドレスは、属性でAFIに基づいて設定されています。 AFIは、IPv4のに設定されている場合、例えば、（1）、ネクストホップは、4バイトのIPv4アドレスとして符号化されます。 AFIがIPv6に設定されている場合（2）、ネクストホップルータの16バイトのIPv6アドレスとして符号化されます。受信ルータに、このような更新メッセージのBGPネクストホップルーティングテーブルに再帰ルートルックアップ動作を実行することによって確認されます。
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.
カプセルたNLRIのベストパス選択は[RFC4271]のセクション9.1で概説決定プロセスによって支配されています。メッセージ内の他の属性を通って運ばカプセル化データは、NLRIは最適パスを持っている場合にのみ、受信ルータによって使用されます。
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
- IP上のL2TPv3 [RFC3931]：トンネルタイプ= 1 - GRE [RFC2784]：トンネルタイプ= 2 - IPにおける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構成される。 1オクテットのタイプ、1オクテットの長さ、および値のゼロ以上のオクテット：各サブTLVは、三つのフィールドで構成されています。次のようにサブ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
- カプセル化：サブTLVのタイプ= 1 - プロトコルタイプ：サブTLVのタイプ= 2 - カラー：サブ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は、それが未知のサブ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.
*サブ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].
*クッキー：オプション、（オクテットで符号化 - 0〜8オクテット）可変長のL2TPv3によって使用される値は、セッションIDによって識別されるセッションに受信されたデータ・メッセージの関連付けを確認します。 [RFC3931]で指定されたクッキー値の生成および使用方法です。
The length of the cookie is not encoded explicitly, but can be calculated as (sub-TLV length - 4).
クッキーの長さは、明示的に符号化されていないが、として計算することができる（サブ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オクテットフィールド[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.
プロトコルタイプのサブTLVは、TLVにシグナリングされているトンネルパラメータでカプセル化されたペイロードパケットのタイプを示すために符号化されてもよいです。サブTLVの値フィールドは、エーテル型として[IANA-AF]で定義されたタイプの一つである2オクテットのプロトコルタイプを含みます。
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セッション、IPv4パケット、IPv6パケットを運ぶ1、およびMPLSパケットを運ぶものを運ぶものを使用したい場合たとえば、出口ルータはL2TPv3のカプセル化タイプの3つのTLV、異なるセッションIDと異なるペイロードを指定して、それぞれが含まれますタイプ。これらのプロトコルタイプのサブ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のトンネルタイプに符号化されなければなりません。一方、プロトコルタイプのサブTLVは、IPまたはGREトンネルにIPのために必要とされません。
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を着色する方法として符号化することができます。サブTLVの値フィールドは、以下のように定義されている拡張コミュニティが含まれています。
The Color Extended Community is an opaque extended community [RFC4360] with the following encoding:
カラー拡張コミュニティは、次の符号化で不透明拡張コミュニティ[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.
拡張タイプフィールドの上位オクテットの値は、それが推移的であることを示しており、0×03です。このコミュニティのための拡張型フィールドの下位オクテットの値は0x0Bのです。カラー値が定義され、ルータ上でローカルに設定されたユーザです。拡張コミュニティを同じ色は、ペイロードのプレフィックスが含まれているUPDATEメッセージに添付することができます。このように、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プレフィックスを広告する場合、例えば、入口ルータは、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.
また、カプセル化サフィUPDATEメッセージは、トンネルの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 UPDATEメッセージにカラーサブTLVを含む種々のトンネリング技術をサポートするルータを有するマルチベンダ配備に（例えば、GREのためのルータの設定とL2TPv3のためのルータのBセット）分類機構として機能することができます。出口ルータにパケットを送信しながら、入口ルータは、適切にカプセル化データを選択することができます。
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の更新を発信した場合、それは、カラーCを含有するカプセルサフィ更新を発信しなければなりません
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決定手順はPへの最適経路としてその更新にルートを選択したこと、BGPスピーカは、色CとのプレフィクスPの更新を受信すると仮定し、次のホップがノードNであることが、カプセル化SAFI更新が発信することをカラーCを含むノードNから受信していません。この場合、Pへの経路は、対応するカプセル化SAFI更新が受信されないとまで転送テーブルにインストールされません、またはBGP決定プロセスは、異なる経路を選択します。
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スピーカもサフィのまたは着色されないことがあり得る1つ以上のカプセル化を指定して、Nによって発信カプセルを受信したと仮定する。この場合、カプセル化の選択は、ローカルポリシーの問題です。必要なだけ「デフォルトポリシーは」スピーカーでサポートされているカプセル化のいずれかを選択することです。
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のUPDATEメッセージに添付することができBGP不透明な拡張コミュニティを定義します。セクション1からの例を考慮すると、R2はR1に経路Qを運ぶUPDATEメッセージ中で使用される特定のトンネルのタイプを指定し、この拡張コミュニティを含むかもしれません。 （例えば、キー無し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.
拡張タイプフィールドの上位オクテットの値は、それが推移だ示しており、0×03です。拡張タイプフィールドの下位オクテットの値が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.
[RFC4760]で定義されるトンネルエンドポイント情報を交換したいBGPスピーカは、対応する（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スピーカでエラーが発生したときに、スピーカが含まれるカプセル化SAFI NLRIをするために、既存の経路の離脱としてUPDATEを処理しなければならない、またはそのような経路が存在しない場合UPDATEを破棄する。ログエントリは、ローカル解析のために提起されなければなりません。
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.
softwiresに適用されるセキュリティ上の考慮事項は、メッシュのフレームワーク[MESH]で見つけることができます。一般に、カプセル化サフィ介してシグナリングトンネルプロトコルのセキュリティ上の問題が継承されています。
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不透明拡張コミュニティ」タイプのレジストリからの二つの新しい値を割り当てます。どちらも、推移範囲からです。最初の新しい値は、「カラー拡張コミュニティ」（0x030b）と呼ばれ、第二は、「カプセル化拡張コミュニティ」（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オクテットの値（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カプール、ダンタッパン、デビッド・ウォード、スコット・ワイナー、サイモン・理容室、そしてクリス・メッツすることにより、従来の作業に基づいています。現在の作者は彼らの貢献のためにすべてのこれらの著者に感謝したいです。
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.
作者は彼らの貴重なコメントや提案のためにジョン・スカダー、ロバートRaszuk、Keyurパテル、クリス・メッツ、ヤコフ・レックター、カルロスPignataro、とブライアン・カーペンターに感謝したいと思います。
[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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル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]ベイツ、T.、チャンドラ、R.、カッツ、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]サングリ、S.、タッパン、D.、およびY. Rekhterは、RFC 4360、2006年2月の "BGP拡張コミュニティ属性"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ラウ、J.、エド、Townsley、M.、エド、およびI. Goyret、エド、 "レイヤ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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（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]パーキンス、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.ギリガン、 "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]呉、J.、キュイ、Y.、メス、C.、およびE.ローゼン、 "Softwireメッシュフレームワーク、" 進歩、2009年2月に働いています。
Authors' Addresses
著者のアドレス
Pradosh Mohapatra Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: pmohapat@cisco.com
Pradosh Mohapatraシスコシステムズ、これ。 95134メールの170タスマン・ドライブサンノゼ、：पमोहपात@सिस्को.कॉम
Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 EMail: erosen@cisco.com
エリック・ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA、01719 Eメール：erosen@cisco.com