Network Working Group T. Worster
Request for Comments: 4023 Motorola, Inc.
Category: Standards Track Y. Rekhter
Juniper Networks, Inc.
E. Rosen, Ed.
Cisco Systems, Inc.
March 2005
Network Working Group T. Worster
Request for Comments: 4023 Motorola, Inc.
Category: Standards Track Y. Rekhter
Juniper Networks, Inc.
E. Rosen, Ed.
Cisco Systems, Inc.
March 2005
Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
在IP或通用路由封装（GRE）中封装MPLS
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) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances.
MPLS的各种应用程序使用具有多个条目的标签堆栈。在某些情况下，可以使用基于IP的封装替换堆栈的顶部标签，从而使应用程序能够在其核心路由器中未启用MPLS的网络上运行。本文档指定了两种基于IP的封装：IP中的MPLS和GRE中的MPLS（通用路由封装）。这些都适用于某些情况。
Table of Contents
目录
1. Motivation .................................................. 2
2. Specification of Requirements ............................... 3
3. Encapsulation in IP ......................................... 3
4. Encapsulation in GRE ........................................ 4
5. Common Procedures ........................................... 5
5.1. Preventing Fragmentation and Reassembly ............... 5
5.2. TTL or Hop Limit ...................................... 6
5.3. Differentiated Services ............................... 7
6. Applicability ............................................... 7
7. IANA Considerations ......................................... 8
8. Security Considerations ..................................... 8
8.1. Securing the Tunnel with IPsec ......................... 8
8.2. In the Absence of IPsec ............................... 10
9. Acknowledgements ............................................. 11
10. Normative References ........................................ 11
11. Informative References ...................................... 12
Authors' Addresses ............................................... 13
Full Copyright Statement ......................................... 14
1. Motivation .................................................. 2
2. Specification of Requirements ............................... 3
3. Encapsulation in IP ......................................... 3
4. Encapsulation in GRE ........................................ 4
5. Common Procedures ........................................... 5
5.1. Preventing Fragmentation and Reassembly ............... 5
5.2. TTL or Hop Limit ...................................... 6
5.3. Differentiated Services ............................... 7
6. Applicability ............................................... 7
7. IANA Considerations ......................................... 8
8. Security Considerations ..................................... 8
8.1. Securing the Tunnel with IPsec ......................... 8
8.2. In the Absence of IPsec ............................... 10
9. Acknowledgements ............................................. 11
10. Normative References ........................................ 11
11. Informative References ...................................... 12
Authors' Addresses ............................................... 13
Full Copyright Statement ......................................... 14
In many applications of MPLS, packets traversing an MPLS backbone carry label stacks with more than one label. As described in section 3.15 of [RFC3031], each label represents a Label Switched Path (LSP). For each LSP, there is a Label Switching Router (LSR) that is the "LSP Ingress", and an LSR that is the "LSP Egress". If LSRs A and B are the Ingress and Egress, respectively, of the LSP corresponding to a packet's top label, then A and B are adjacent LSRs on the LSP corresponding to the packet's second label (i.e., the label immediately beneath the top label).
在MPLS的许多应用中，穿过MPLS主干的数据包携带有多个标签的标签栈。如[RFC3031]第3.15节所述，每个标签代表一个标签交换路径（LSP）。对于每个LSP，都有一个标签交换路由器（LSR）作为“LSP入口”，一个LSR作为“LSP出口”。如果lsr A和B分别是对应于分组的顶标签的LSP的入口和出口，则A和B是对应于分组的第二标签（即，顶标签正下方的标签）的LSP上的相邻lsr。
The purpose (or one of the purposes) of the top label is to get the packet delivered from A to B, so that B can further process the packet based on the second label. In this sense, the top label serves as an encapsulation header for the rest of the packet. In some cases, other sorts of encapsulation headers can replace the top label without loss of functionality. For example, an IP header or a Generic Routing Encapsulation (GRE) header could replace the top label. As the encapsulated packet would still be an MPLS packet, the result is an MPLS-in-IP or MPLS-in-GRE encapsulation.
顶部标签的目的（或目的之一）是获得从A到B递送的分组，以便B可以基于第二标签进一步处理分组。从这个意义上讲，顶部标签充当包其余部分的封装头。在某些情况下，其他种类的封装头可以替换顶部标签，而不会丢失功能。例如，IP头或通用路由封装（GRE）头可以替换顶部标签。由于封装的数据包仍然是MPLS数据包，因此结果是IP中的MPLS或GRE中的MPLS封装。
With these encapsulations, it is possible for two LSRs that are adjacent on an LSP to be separated by an IP network, even if that IP network does not provide MPLS.
通过这些封装，即使IP网络不提供MPLS，LSP上相邻的两个lsr也可能被IP网络分开。
To use either of these encapsulations, the encapsulating LSR must know
要使用这两种封装，封装LSR必须知道
- the IP address of the decapsulating LSR, and
- 解封装LSR的IP地址，以及
- that the decapsulating LSR actually supports the particular encapsulation.
- 去封装LSR实际上支持特定的封装。
This knowledge may be conveyed to the encapsulating LSR by manual configuration, or by means of some discovery protocol. In particular, if the tunnel is being used to support a particular application and that application has a setup or discovery protocol, then the application's protocol may convey this knowledge. The means of conveying this knowledge is outside the scope of the this document.
该知识可通过手动配置或通过某种发现协议传送到封装LSR。特别地，如果隧道正被用于支持特定应用程序，并且该应用程序具有设置或发现协议，则该应用程序的协议可传达该知识。传达这些知识的方法不在本文件的范围之内。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
MPLS-in-IP messages have the following format:
IP消息中的MPLS具有以下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MPLS Label Stack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MPLS Label Stack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Header This field contains an IPv4 or an IPv6 datagram header as defined in [RFC791] or [RFC2460], respectively. The source and destination addresses are set to addresses of the encapsulating and decapsulating LSRs, respectively.
IP报头此字段包含[RFC791]或[RFC2460]中分别定义的IPv4或IPv6数据报报头。源地址和目标地址分别设置为封装和解封装LSR的地址。
MPLS Label Stack This field contains an MPLS Label Stack as defined in [RFC3032].
MPLS标签堆栈此字段包含[RFC3032]中定义的MPLS标签堆栈。
Message Body This field contains one MPLS message body.
消息正文此字段包含一个MPLS消息正文。
The IPv4 Protocol Number field or the IPv6 Next Header field is set to 137, indicating an MPLS unicast packet. (The use of the MPLS-in-IP encapsulation for MPLS multicast packets is not supported by this specification.)
IPv4协议编号字段或IPv6下一报头字段设置为137，表示MPLS单播数据包。（本规范不支持在MPLS多播数据包的IP封装中使用MPLS。）
Following the IP header is an MPLS packet, as specified in [RFC3032]. This encapsulation causes MPLS packets to be sent through "IP tunnels". When the tunnel's receive endpoint receives a packet, it decapsulates the MPLS packet by removing the IP header. The packet is then processed as a received MPLS packet whose "incoming label" [RFC3031] is the topmost label of the decapsulated packet.
IP报头后面是MPLS数据包，如[RFC3032]中所述。这种封装导致MPLS数据包通过“IP隧道”发送。当隧道的接收端点接收到数据包时，它通过移除IP报头来解除MPLS数据包的封装。然后将该分组作为接收到的MPLS分组进行处理，该MPLS分组的“传入标签”[RFC3031]是解封分组的最顶部标签。
The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE [RFC2784]. The packet then consists of an IP header (either IPv4 or IPv6), followed by a GRE header, followed by an MPLS label stack as specified in [RFC3032]. The protocol type field in the GRE header MUST be set to the Ethertype value for MPLS Unicast (0x8847) or Multicast (0x8848).
GRE中的MPLS封装将MPLS数据包封装在GRE中[RFC2784]。然后，该数据包由一个IP报头（IPv4或IPv6）组成，后跟一个GRE报头，后跟一个MPLS标签堆栈，如[RFC3032]中所述。GRE头中的协议类型字段必须设置为MPLS单播（0x8847）或多播（0x8848）的Ethertype值。
This encapsulation causes MPLS packets to be sent through "GRE tunnels". When the tunnel's receive endpoint receives a packet, it decapsulates the MPLS packet by removing the IP and the GRE headers. The packet is then processed as a received MPLS packet whose "incoming label" [RFC3031] is the topmost label of the decapsulated packet.
这种封装导致MPLS数据包通过“GRE隧道”发送。当隧道的接收端点接收到数据包时，它通过移除IP和GRE头来解除MPLS数据包的封装。然后将该分组作为接收到的MPLS分组进行处理，该MPLS分组的“传入标签”[RFC3031]是解封分组的最顶部标签。
[RFC2784] specifies an optional GRE checksum, and [RFC2890] specifies optional GRE key and sequence number fields. These optional fields are not very useful for the MPLS-in-GRE encapsulation. The sequence number and checksum fields are not needed, as there are no corresponding fields in the native MPLS packets being tunneled. The GRE key field is not needed for demultiplexing, as the top MPLS label of the encapsulated packet is used for that purpose. The GRE key field is sometimes considered a security feature, functioning as a 32-bit cleartext password, but this is an extremely weak form of security. In order (a) to facilitate high-speed implementations of the encapsulation/decapsulation procedures and (b) to ensure interoperability, we require that all implementations be able to operate correctly without these optional fields.
[RFC2784]指定可选的GRE校验和，[RFC2890]指定可选的GRE密钥和序列号字段。这些可选字段对于GRE封装中的MPLS不是很有用。序列号和校验和字段是不需要的，因为在隧道传输的本机MPLS数据包中没有相应的字段。解复用不需要GRE密钥字段，因为封装包的顶部MPLS标签用于此目的。GRE密钥字段有时被认为是一种安全功能，用作32位明文密码，但这是一种极弱的安全形式。为了（a）促进封装/去封装过程的高速实现，以及（b）确保互操作性，我们要求所有实现能够在没有这些可选字段的情况下正确运行。
More precisely, an implementation of an MPLS-in-GRE decapsulator MUST be able to process packets correctly without these optional fields. It MAY be able to process packets correctly with these optional fields.
更准确地说，在GRE decapsulator中实现MPLS必须能够在没有这些可选字段的情况下正确处理数据包。它可以使用这些可选字段正确处理数据包。
An implementation of an MPLS-in-GRE encapsulator MUST be able to generate packets without these optional fields. It MAY have the capability to generate packets with these fields, but the default state MUST be that packets are generated without these fields. The encapsulator MUST NOT include any of these optional fields unless it is known that the decapsulator can process them correctly. Methods for conveying this knowledge are outside the scope of this specification.
GRE封装器中MPLS的实现必须能够生成没有这些可选字段的数据包。它可以生成包含这些字段的数据包，但默认状态必须是生成的数据包不包含这些字段。封装器不得包含任何这些可选字段，除非已知解封装器可以正确处理这些字段。传达此知识的方法不在本规范的范围内。
Certain procedures are common to both the MPLS-in-IP and the MPLS-in-GRE encapsulations. In the following, the encapsulator, whose address appears in the IP source address field of the encapsulating IP header, is known as the "tunnel head". The decapsulator, whose address appears in the IP destination address field of the decapsulating IP header, is known as the "tunnel tail".
某些过程对于IP中的MPLS和GRE封装中的MPLS都是通用的。在下文中，其地址出现在封装IP头的IP源地址字段中的封装器称为“隧道头”。解封装器的地址出现在解封装IP头的IP目标地址字段中，称为“隧道尾”。
If IPv6 is being used (for either MPLS-in-IPv6 or MPLS-in-GRE-in-IPv6), the procedures of [RFC2473] are generally applicable.
如果正在使用IPv6（对于MPLS-in-IPv6或MPLS-in-GRE-in-IPv6），则[RFC2473]中的程序通常适用。
If an MPLS-in-IP or MPLS-in-GRE packet were fragmented (due to "ordinary" IP fragmentation), the tunnel tail would have to reassemble it before the contained MPLS packet could be decapsulated. When the tunnel tail is a router, this is likely to be undesirable; the tunnel tail may not have the ability or the resources to perform reassembly at the necessary level of performance.
如果IP中的MPLS或GRE中的MPLS数据包被碎片化（由于“普通”IP碎片化），则隧道尾部必须在所包含的MPLS数据包被解封之前重新组装它。当隧道尾部是路由器时，这可能是不需要的；隧道尾部可能没有能力或资源以必要的性能水平进行重新组装。
Whether fragmentation of the tunneled packets is allowed MUST be configurable at the tunnel head. The default value MUST be that packets are not fragmented. The default value would only be changed if it were known that the tunnel tail could perform the reassembly function adequately.
隧道数据包的碎片是否允许，必须在隧道头部进行配置。默认值必须是数据包不分段。只有在已知隧道尾部能够充分执行重新组装功能的情况下，才会更改默认值。
THE PROCEDURES SPECIFIED IN THE REMAINDER OF THIS SECTION ONLY APPLY IF PACKETS ARE NOT TO BE FRAGMENTED.
本节剩余部分中规定的程序仅适用于不分割数据包的情况。
Obviously, if packets are not to be fragmented, the tunnel head MUST NOT fragment a packet before encapsulating it.
显然，如果数据包不被分段，则隧道头在封装数据包之前不得将其分段。
If IPv4 is used, then the tunnel MUST set the DF bit. This prevents intermediate nodes in the tunnel from performing fragmentation. (If IPv6 is used, intermediate nodes do not perform fragmentation in any event.)
如果使用IPv4，则隧道必须设置DF位。这将防止隧道中的中间节点执行分段。（如果使用IPv6，中间节点在任何情况下都不会执行分段。）
The tunnel head SHOULD perform Path MTU Discovery ([RFC1191] for IPv4, or [RFC1981] for IPv6).
隧道头应执行路径MTU发现（IPv4为[RFC1191]，IPv6为[RFC1981]）。
The tunnel head MUST maintain a "Tunnel MTU" for each tunnel; this is the minimum of (a) an administratively configured value, and, if known, (b) the discovered Path MTU value minus the encapsulation overhead.
隧道头必须为每个隧道维护一个“隧道MTU”；这是（a）管理配置值和（b）发现的路径MTU值减去封装开销的最小值（如果已知）。
If the tunnel head receives, for encapsulation, an MPLS packet whose size exceeds the Tunnel MTU, that packet MUST be discarded. However, silently dropping such packets may cause significant operational problems; the originator of the packets will notice that his data is not getting through, but he may not realize that large packets are causing packet loss. He may therefore continue sending packets that are discarded. Path MTU discovery can help (if the tunnel head sends back ICMP errors), but frequently there is insufficient information available at the tunnel head to identify the originating sender properly. To minimize problems, it is advised that MTUs be engineered to be large enough in practice to avoid fragmentation.
如果为了封装，隧道头接收到一个大小超过隧道MTU的MPLS数据包，则必须丢弃该数据包。然而，悄悄地丢弃这样的数据包可能会导致严重的操作问题；数据包的发起人会注意到他的数据没有通过，但他可能没有意识到大数据包导致数据包丢失。因此，他可以继续发送被丢弃的数据包。路径MTU发现可以有所帮助（如果隧道头发回ICMP错误），但通常在隧道头没有足够的可用信息来正确识别发起发送者。为了最大限度地减少问题，建议MTU的设计应足够大，以避免碎片。
In some cases, the tunnel head receives, for encapsulation, an IP packet, which it first encapsulates in MPLS and then encapsulates in MPLS-in-IP or MPLS-in-GRE. If the source of the IP packet is reachable from the tunnel head, and if the result of encapsulating the packet in MPLS would be a packet whose size exceeds the Tunnel MTU, then the value that the tunnel head SHOULD use for fragmentation and PMTU discovery outside the tunnel is the Tunnel MTU value minus the size of the MPLS encapsulation. (That is, the Tunnel MTU value minus the size of the MPLS encapsulation is the MTU that is to be reported in ICMP messages.) The packet will have to be discarded, but the tunnel head should send the IP source of the discarded packet the proper ICMP error message as specified in [RFC1191] or [RFC1981].
在某些情况下，隧道头接收IP数据包进行封装，它首先将其封装在MPLS中，然后将其封装在IP中的MPLS或GRE中的MPLS中。如果可以从隧道头访问IP数据包的源，并且如果在MPLS中封装数据包的结果是其大小超过隧道MTU的数据包，则隧道头在隧道外用于碎片和PMTU发现的值应为隧道MTU值减去MPLS封装的大小。（也就是说，隧道MTU值减去MPLS封装的大小就是要在ICMP消息中报告的MTU。）必须丢弃数据包，但隧道头应向丢弃数据包的IP源发送[RFC1191]或[RFC1981]中规定的正确ICMP错误消息。
The tunnel head MAY place the TTL from the MPLS label stack into the TTL field of the encapsulating IPv4 header or the Hop Limit field of the encapsulating IPv6 header. The tunnel tail MAY place the TTL from the encapsulating IPv4 header or the Hop Limit from the encapsulating IPv6 header into the TTL field of the MPLS header, but only if this does not increase the TTL value in the MPLS header.
隧道头可以将来自MPLS标签堆栈的TTL放入封装IPv4报头的TTL字段或封装IPv6报头的Hop Limit字段。隧道尾部可以将来自封装IPv4报头的TTL或来自封装IPv6报头的跃点限制放入MPLS报头的TTL字段，但前提是这不会增加MPLS报头中的TTL值。
Whether such modifications are made, and the details of how they are made, will depend on the configuration of the tunnel tail and the tunnel head.
是否进行此类修改以及如何进行修改的细节将取决于隧道尾部和隧道头部的配置。
The procedures specified in this document enable an LSP to be sent through an IP or GRE tunnel. [RFC2983] details a number of considerations and procedures that have to be applied to support the Differentiated Services Architecture properly in the presence of IP-in-IP tunnels. These considerations and procedures also apply in the presence of MPLS-in-IP or MPLS-in-GRE tunnels.
本文件中规定的程序允许通过IP或GRE隧道发送LSP。[RFC2983]详细说明了在IP隧道中存在IP的情况下，为正确支持差异化服务体系结构而必须应用的一些注意事项和程序。这些注意事项和程序也适用于IP中存在MPLS或GRE隧道中存在MPLS的情况。
Accordingly, when a tunnel head is about to send an MPLS packet into an MPLS-in-IP or MPLS-in-GRE tunnel, the setting of the DS field of the encapsulating IPv4 or IPv6 header MAY be determined (at least partially) by the "Behavior Aggregate" of the MPLS packet. Procedures for determining the Behavior Aggregate of an MPLS packet are specified in [RFC3270].
因此，当隧道头即将向IP中的MPLS或GRE隧道中的MPLS发送MPLS分组时，封装IPv4或IPv6报头的DS字段的设置可以（至少部分地）由MPLS分组的“行为聚合”确定。[RFC3270]中规定了确定MPLS数据包聚合行为的步骤。
Similarly, at the tunnel tail, the DS field of the encapsulating IPv4 or IPv6 header MAY be used to determine the Behavior Aggregate of the encapsulated MPLS packet. [RFC3270] specifies the relation between the Behavior Aggregate and the subsequent disposition of the packet.
类似地，在隧道尾部，封装IPv4或IPv6报头的DS字段可用于确定封装MPLS分组的行为聚合。[RFC3270]指定行为聚合和数据包的后续处置之间的关系。
The MPLS-in-IP encapsulation is the more efficient, and it would generally be regarded as preferable, other things being equal. There are, however, some situations in which the MPLS-in-GRE encapsulation may be used:
IP封装中的MPLS效率更高，在其他条件相同的情况下，通常认为它更可取。然而，在某些情况下，可以使用GRE封装中的MPLS：
- Two routers are "adjacent" over a GRE tunnel that exists for some reason that is outside the scope of this document, and those two routers have to send MPLS packets over that adjacency. As all packets sent over this adjacency must have a GRE encapsulation, the MPLS-in-GRE encapsulation is more efficient than the alternative, that would be an MPLS-in-IP encapsulation which is then encapsulated in GRE.
- 两个路由器在GRE隧道上“相邻”，GRE隧道因某种原因而存在，超出了本文档的范围，并且这两个路由器必须通过该相邻发送MPLS数据包。由于通过该邻接发送的所有数据包都必须具有GRE封装，因此GRE封装中的MPLS比另一种更有效，即IP封装中的MPLS，然后将其封装在GRE中。
- Implementation considerations may dictate the use of MPLS-in-GRE. For example, some hardware device might only be able to handle GRE encapsulations in its fastpath.
- 实施方面的考虑可能决定了在GRE中使用MPLS。例如，某些硬件设备可能只能在其快速路径中处理GRE封装。
The IANA has allocated IP Protocol Number 137 for MPLS-in-IP encapsulation, as described in section 3. No future IANA actions will be required. The MPLS-in-GRE encapsulation does not require any IANA action.
IANA为IP封装中的MPLS分配了IP协议编号137，如第3节所述。未来无需IANA行动。GRE封装中的MPLS不需要任何IANA操作。
The main security problem faced when IP or GRE tunnels are used is the possibility that the tunnel's receive endpoint will get a packet that appears to be from the tunnel, but that was not actually put into the tunnel by the tunnel's transmit endpoint. (The specified encapsulations do not by themselves enable the decapsulator to authenticate the encapsulator.) A second problem is the possibility that the packet will be altered between the time it enters the tunnel and the time it leaves. (The specified encapsulations do not by themselves assure the decapsulator of the packet's integrity.) A third problem is the possibility that the packet's contents will be seen while the packet is in transit through the tunnel. (The specification encapsulations do not ensure privacy.) How significant these issues are in practice depends on the security requirements of the applications whose traffic is being sent through the tunnel. For example, lack of privacy for tunneled packets is not a significant issue if the applications generating the packets do not require privacy.
使用IP或GRE隧道时面临的主要安全问题是，隧道的接收端点可能会收到一个看似来自隧道的数据包，但该数据包实际上并未由隧道的传输端点放入隧道。（指定的封装本身不能使解封装器对封装器进行身份验证。）第二个问题是数据包在进入隧道和离开隧道之间可能会发生变化。（指定的封装本身并不能保证数据包的完整性。）第三个问题是，当数据包通过隧道传输时，可能会看到数据包的内容。（规范封装不能确保隐私。）这些问题在实践中的重要性取决于通过隧道发送流量的应用程序的安全要求。例如，如果生成数据包的应用程序不需要隐私，则隧道数据包缺乏隐私不是一个重要问题。
Because of the different potential security requirements, deployment scenarios, and performance considerations of different applications using the described encapsulation mechanism, this specification defines IPsec support as OPTIONAL. Basic implementation requirements if IPsec is implemented are described in section 8.1. If IPsec is not implemented, additional mechanisms may have to be implemented and deployed. Those are discussed in section 8.2.
由于使用所述封装机制的不同应用程序的不同潜在安全需求、部署场景和性能考虑因素，本规范将IPsec支持定义为可选。第8.1节描述了实施IPsec的基本实施要求。如果未实施IPsec，则可能必须实施和部署其他机制。第8.2节讨论了这些问题。
All of these security issues can be avoided if the MPLS-in-IP or MPLS-in-GRE tunnels are secured with IPsec. Implementation requirements defined in this section apply if IPsec is implemented.
如果IP中的MPLS或GRE隧道中的MPLS使用IPsec进行保护，则可以避免所有这些安全问题。如果实施了IPsec，则本节中定义的实施要求适用。
When IPsec is used, the tunnel head and the tunnel tail should be treated as the endpoints of a Security Association. For this purpose, a single IP address of the tunnel head will be used as the source IP address, and a single IP address of the tunnel tail will be used as the destination IP address. The means by which each node knows the proper address of the other is outside the scope of this document. If a control protocol is used to set up the tunnels (e.g.,
使用IPsec时，应将隧道头和隧道尾视为安全关联的端点。为此，隧道头的单个IP地址将用作源IP地址，隧道尾的单个IP地址将用作目标IP地址。每个节点知道另一个节点正确地址的方法不在本文档的范围内。如果使用控制协议设置隧道（例如。，
to inform one tunnel endpoint of the IP address of the other), the control protocol MUST have an authentication mechanism, and this MUST be used when the tunnel is set up. If the tunnel is set up automatically as the result of, for example, information distributed by BGP, then the use of BGP's MD5-based authentication mechanism is satisfactory.
要将另一个隧道端点的IP地址通知一个隧道端点），控制协议必须具有身份验证机制，并且在设置隧道时必须使用该机制。如果隧道是根据BGP分发的信息自动设置的，那么使用BGP基于MD5的身份验证机制是令人满意的。
The MPLS-in-IP or MPLS-in-GRE encapsulated packets should be viewed as originating at the tunnel head and as being destined for the tunnel tail; IPsec transport mode SHOULD thus be used.
IP中的MPLS或GRE封装的数据包中的MPLS应被视为源于隧道头，目的地为隧道尾；因此，应使用IPsec传输模式。
The IP header of the MPLS-in-IP packet becomes the outer IP header of the resulting packet when the tunnel head uses IPsec transport mode to secure the MPLS-in-IP packet. This is followed by an IPsec header, followed by the MPLS label stack. The IPsec header has to set the payload type to MPLS by using the IP protocol number specified in section 3. If IPsec transport mode is applied on a MPLS-in-GRE packet, the GRE header follows the IPsec header.
当隧道头使用IPsec传输模式来保护IP包中的MPLS时，IP包中的MPLS的IP头将成为结果包的外部IP头。然后是IPsec头，然后是MPLS标签堆栈。IPsec报头必须使用第3节中指定的IP协议号将有效负载类型设置为MPLS。如果IPsec传输模式应用于MPLS in GRE数据包，则GRE报头将跟随IPsec报头。
At the tunnel tail, IPsec outbound processing recovers the contained MPLS-in-IP/GRE packet. The tunnel tail then strips off the encapsulating IP/GRE header to recover the MPLS packet, which is then forwarded according to its label stack.
在隧道尾部，IPsec出站处理恢复IP/GRE数据包中包含的MPLS。然后，隧道尾部剥离封装的IP/GRE报头以恢复MPLS数据包，然后根据其标签堆栈转发该数据包。
Note that the tunnel tail and the tunnel head are LSP adjacencies, which means that the topmost label of any packet sent through the tunnel must be one that was distributed by the tunnel tail to the tunnel head. The tunnel tail MUST know precisely which labels it has distributed to the tunnel heads of IPsec-secured tunnels. Labels in this set MUST NOT be distributed by the tunnel tail to any LSP adjacencies other than those that are tunnel heads of IPsec-secured tunnels. If an MPLS packet is received without an IPsec encapsulation, and if its topmost label is in this set, then the packet MUST be discarded.
请注意，隧道尾部和隧道头部是LSP邻接，这意味着通过隧道发送的任何数据包的最顶部标签必须是由隧道尾部分发给隧道头部的标签。隧道尾部必须准确地知道它已将哪些标签分发给IPsec安全隧道的隧道头部。此集合中的标签不得由隧道尾部分发到任何LSP邻接，IPsec安全隧道的隧道头除外。如果接收到的MPLS数据包没有IPsec封装，并且其最上面的标签在此集合中，则必须丢弃该数据包。
An IPsec-secured MPLS-in-IP or MPLS-in-GRE tunnel MUST provide authentication and integrity. (Note that the authentication and integrity will apply to the entire MPLS packet, including the MPLS label stack.) Thus, the implementation MUST support ESP will null encryption. ESP with encryption MAY be supported if a source requires confidentiality. If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given SA is the one expected.
IP中的IPsec安全MPLS或GRE隧道中的MPLS必须提供身份验证和完整性。（请注意，身份验证和完整性将应用于整个MPLS数据包，包括MPLS标签堆栈。）因此，实现必须支持ESP will null加密。如果源需要保密，则可能支持带加密的ESP。如果使用ESP，则隧道尾部必须检查在给定SA上接收的任何数据包的源IP地址是否为预期的IP地址。
Key distribution may be done either manually or automatically by means of IKE [RFC2409]. Manual keying MUST be supported. If automatic keying is implemented, IKE in main mode with preshared keys
密钥分发可以通过IKE[RFC2409]手动或自动完成。必须支持手动键控。如果实现了自动键控，IKE将在主模式下使用预共享键
MUST be supported. A particular application may escalate this requirement and request implementation of automatic keying.
必须得到支持。特定应用程序可能会升级此要求，并请求实现自动键控。
Manual key distribution is much simpler, but also less scalable, than automatic key distribution. Therefore, which method of key distribution is appropriate for a particular tunnel has to be carefully considered by the administrator (or pair of administrators) responsible for the tunnel endpoints. If replay protection is regarded as necessary for a particular tunnel, automatic key distribution should be configured.
手动密钥分发比自动密钥分发简单得多，但可扩展性也较差。因此，负责隧道端点的管理员（或一对管理员）必须仔细考虑哪种密钥分发方法适合于特定隧道。如果认为特定隧道需要重播保护，则应配置自动密钥分发。
If the MPLS-in-IP encapsulation is being used, the selectors associated with the SA would be the source and destination addresses mentioned above, plus the IP protocol number specified in section 3. If it is desired to secure multiple MPLS-in-IP tunnels between a given pair of nodes separately, each tunnel must have unique pair of IP addresses.
如果正在使用IP封装中的MPLS，则与SA相关联的选择器将是上面提到的源地址和目标地址，加上第3节中指定的IP协议号。如果希望在给定的一对节点之间的IP隧道中分别保护多个MPL，则每个隧道必须具有唯一的一对IP地址。
If the MPLS-in-GRE encapsulation is being used, the selectors associated with the SA would be the source and destination addresses mentioned above, and the IP protocol number representing GRE (47). If it is desired to secure multiple MPLS-in-GRE tunnels between a given pair of nodes separately, each tunnel must have unique pair of IP addresses.
如果正在使用GRE封装中的MPLS，则与SA相关联的选择器将是上面提到的源地址和目标地址，以及表示GRE的IP协议号（47）。如果希望在给定的一对节点之间分别保护GRE隧道中的多个MPL，则每个隧道必须具有唯一的一对IP地址。
If the tunnels are not secured with IPsec, then some other method should be used to ensure that packets are decapsulated and forwarded by the tunnel tail only if those packets were encapsulated by the tunnel head. If the tunnel lies entirely within a single administrative domain, address filtering at the boundaries can be used to ensure that no packet with the IP source address of a tunnel endpoint or with the IP destination address of a tunnel endpoint can enter the domain from outside.
如果隧道未使用IPsec进行保护，则应使用某些其他方法确保仅当隧道头封装了数据包时，数据包才被解除封装并由隧道尾部转发。如果隧道完全位于单个管理域内，则可以使用边界处的地址过滤来确保具有隧道端点的IP源地址或隧道端点的IP目标地址的数据包不能从外部进入域。
However, when the tunnel head and the tunnel tail are not in the same administrative domain, this may become difficult, and filtering based on the destination address can even become impossible if the packets must traverse the public Internet.
然而，当隧道头和隧道尾不在同一管理域中时，这可能变得困难，并且如果包必须穿越公共因特网，则基于目的地地址的过滤甚至可能变得不可能。
Sometimes only source address filtering (but not destination address filtering) is done at the boundaries of an administrative domain. If this is the case, the filtering does not provide effective protection at all unless the decapsulator of an MPLS-in-IP or MPLS-in-GRE validates the IP source address of the packet. This document does not require that the decapsulator validate the IP source address of the tunneled packets, but it should be understood that failure to do
有时，在管理域的边界上只进行源地址筛选（而不进行目标地址筛选）。在这种情况下，除非MPLS in IP或MPLS in GRE的解封装器验证数据包的IP源地址，否则过滤根本无法提供有效的保护。本文件不要求解封装器验证隧道数据包的IP源地址，但应理解，未能做到这一点
so presupposes that there is effective destination-based (or a combination of source-based and destination-based) filtering at the boundaries.
因此，前提是在边界处存在有效的基于目的地（或基于源和基于目的地的组合）的过滤。
This specification combines prior work on encapsulating MPLS in IP, by Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew G. Malis, and Rick Wilder, with prior work on encapsulating MPLS in GRE, by Yakov Rekhter, Daniel Tappan, and Eric Rosen. The current authors wish to thank all these authors for their contribution.
本规范结合了Tom Worster、Paul Doolan、Yasuhiro Katsube、Tom K.Johnson、Andrew G.Malis和Rick Wilder先前在IP中封装MPLS的工作，以及Yakov Rekhter、Daniel Tappan和Eric Rosen先前在GRE中封装MPLS的工作。现任作者希望感谢所有这些作者的贡献。
Many people have made valuable comments and corrections, including Rahul Aggarwal, Scott Bradner, Alex Conta, Mark Duffy, Francois Le Feucheur, Allison Mankin, Thomas Narten, Pekka Savola, and Alex Zinin.
许多人都做出了宝贵的评论和更正，包括拉胡尔·阿加瓦尔、斯科特·布拉德纳、亚历克斯·孔塔、马克·达菲、弗朗索瓦·勒弗切尔、埃里森·曼金、托马斯·纳滕、佩卡·萨沃拉和亚历克斯·齐宁。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[RFC2463]Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC2463，1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890]Dommety，G.“GRE的密钥和序列号扩展”，RFC 28902000年9月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]Grossman，D.“区分服务的新术语和澄清”，RFC 3260，2002年4月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
Authors' Addresses
作者地址
Tom Worster Motorola, Inc. 120 Turnpike Road Southborough, MA 01772
Tom Worster Motorola，Inc.马萨诸塞州南区收费公路120号，邮编01772
EMail: tom.worster@motorola.com
EMail: tom.worster@motorola.com
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks，Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。