Network Working Group P. Mohapatra
Request for Comments: 5512 E. Rosen
Category: Standards Track Cisco Systems, Inc.
April 2009
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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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扬声器封装，由第二个BGP扬声器解封。为了支持这些情况，两位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
对于所有封装类型，封装信息不需要发出信号。在需要信令的情况下（如第二层隧道协议-版本3（L2TPv3）或带密钥的通用路由封装（GRE），本文档规定了BGP扬声器可以相互发送封装信息的方法。信令通过使用封装后续地址族标识符（SAFI）和IPv4或IPv6地址族标识符（AFI）发送BGP更新来完成。在不需要通知封装信息的情况下（例如，GRE没有
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.
该文档指定了一个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
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的情况，让D成为IP的IP目的地地址。R1必须在其转发表中查找D。假设D的“最佳匹配”路由是路由Q，其中Q是一个BGP分布式路由，其“BGP下一跳”是路由器R2。并且进一步假设沿着从R1到R2的路径的路由器在其转发表中具有针对R2的条目，但在其转发表中不具有针对D的条目。例如，从R1到R2的路径可能是“无BGP核心”的一部分，其中核心中根本没有BGP分布式路由。或者，正如在[MESH]中一样，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
为了让R1封装P以便传输到R2，R1必须知道用于将不同种类的数据包传输到R2的封装协议。R1还必须知道如何填写各种
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.
封装头的字段。对于某些封装类型，默认情况下或通过手动配置可以获得这些知识。其他封装协议具有必须填写的字段，如会话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扬声器使用可分辨的SAFI值（封装SAFI）将此信息发送给其他BGP扬声器。封装SAFI可用于IPv4的AFI或IPv6的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）由该更新的发起人的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扬声器只公布一次更新。相反，当前缀被修改时，不需要交换隧道封装信息。
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
在本规范中，单个SAFI用于承载所有封装协议的信息。可以采用另一种方法为每个封装协议定义一个新的SAFI。然而，通过指定的方法，封装信息可以透明和自动地通过中间BGP扬声器（例如，路由反射器），这些扬声器不一定理解封装信息。这是因为封装属性被定义为可选的可传递属性。因此，可以添加新的封装，而无需重新配置任何
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.
中间BGP系统。如果需要使用新的SAFI添加新的封装，则该封装的信息将不会通过中间BGP系统，除非重新配置这些系统以支持新的SAFI。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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使用AFI为1或2（IPv4或IPv6）[IANA-AF]且SAFI值为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 (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（1），则端点地址为4个八位字节的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.
带有封装SAFI的MP_REACH_NLRI或MP_UNREACH_NLRI属性的更新消息还必须带有BGP强制属性：ORIGIN、AS_PATH和LOCAL_PREF（对于IBGP邻居），如[RFC4271]中所定义。此外，这样的更新消息还可以包含任何BGP可选属性，如Community或Extended Community属性，以影响接收说话人的动作。
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具有最佳路径时，通过消息中的其他属性携带的封装数据才会由接收路由器使用。
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-in-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组成。每个子TLV由三个字段组成：1个八位组类型、1个八位组长度和零个或多个八位组值。子TLV的结构如下所示：
+-----------------------------------+
| Sub-TLV Type (1 Octet) |
+-----------------------------------+
| Sub-TLV Length (1 Octet) |
+-----------------------------------+
| Sub-TLV Value (Variable) |
| |
+-----------------------------------+
+-----------------------------------+
| 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.
当将执行封装的BGP扬声器正在处理TLV时，必须忽略并跳过任何未知的子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的隧道类型为L2TPv3 over IP时，封装子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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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用于检查接收到的数据消息与会话ID标识的会话之间的关联的可选可变长度（以八位字节编码——0到8位字节）值。Cookie值的生成和使用如[RFC3931]所述。
The length of the cookie is not encoded explicitly, but can be calculated as (sub-TLV length - 4).
cookie的长度没有显式编码，但可以计算为（sub-TLV length-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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
协议类型sub-TLV可被编码以指示将用TLV中正在发信号的隧道参数封装的有效载荷分组的类型。子TLV的值字段包含2-octet协议类型，该类型是[IANA-AF]中定义为以太类型的类型之一。
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
例如，如果我们想要使用三个L2TPv3会话，一个承载IPv4数据包，一个承载IPv6数据包，一个承载MPLS数据包，则出口路由器将包括三个L2TPv3封装类型的TLV，每个TLV指定不同的会话ID和不同的有效负载类型。这些子TLV的协议类型分别为IPv4（协议类型=0x0800）、IPv6（协议类型=0x86dd）和MPLS（协议类型=0x8847）。这将通知入口路由器要使用的适当封装信息
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.
使用每个给定的协议类型。在入口路由器处插入指定的会话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不需要协议类型sub 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着色的方式。子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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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前缀，则入口路由器可以定义本地策略，以选择L2TPv3作为IPv4前缀（前提是隧道属性中接收的协议类型匹配），选择GRE作为IPv6前缀。
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）。然后，入口路由器可以在向出口路由器发送分组时适当地选择封装数据。
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的封装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扬声器接收到前缀P的颜色为C的更新，BGP决策过程已选择该更新中的路由作为到P的最佳路由，并且下一跳是节点N，但尚未接收到来自包含颜色C的节点N的封装SAFI更新。在这种情况下，除非收到相应的封装SAFI更新，或者BGP决策过程选择不同的路由，否则转发表中不会安装到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扬声器接收到前缀P的“未着色”更新，下一跳为N，并且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的更新消息中使用的特定隧道类型。如果使用隧道协议的封装SAFI（例如不带密钥的GRE）没有显式的封装信息来发送信号，这将非常有用。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
值字段的最后两个八位字节编码本文档中定义的隧道类型。
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演讲者在解析隧道封装属性时遇到错误时，演讲者必须将更新视为撤回包含的封装SAFI 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.
适用于软线的安全注意事项可在mesh框架[mesh]中找到。通常，通过封装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将“后续地址系列”注册表中“标准操作”范围内的值7分配给“封装SAFI”，并以本文件为参考。
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隧道封装属性隧道类型”设置了注册表。这是两个八位组值（0-65535）的注册表，以先到先得的方式分配。初步任务如下：
Tunnel Name Type
--------------- -----
L2TPv3 over IP 1
GRE 2
IP in IP 7
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
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.，“边境网关协议4（BGP-4）”，RFC 42712006年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.，Townsley，M.，Ed.，和I.Goyret，Ed.，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890]Dommety，G.“GRE的密钥和序列号扩展”，RFC 28902000年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，“软线网格框架”，正在进行的工作，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号，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号，邮编01719电子邮件：erosen@cisco.com